--- title: Practice · Jensen Consulting description: "Seven practice areas across the delivery lifecycle: strategy, product ownership, project management, requirements definition, UX prototyping, development support, and operations support. A consultancy — we don't provide development services." canonical: https://jensen.inf.br/practice.html --- # Practice — end to end, minus the code We're a consultancy, not a software house — we don't employ developers. We join your project as project managers, business analysts, and business architects, and we run the delivery: from strategy and requirements through design, build oversight, go-live, and the support that follows. Everything except writing the code. ## 01 · Strategy Where the product should go, and why. We start with the business case — the market, the model, and the bet worth making. We size the opportunity, frame the product strategy, and turn it into a roadmap that your board and your delivery team can both get behind, rather than two documents that quietly disagree. The output is a clear direction you can fund and a sequence of moves that actually build on one another. - Typical length: 3–6 weeks - You get: opportunity read · product strategy · roadmap - Best when: you have ambition but no agreed direction ## 02 · Product ownership Someone to own the backlog when you can't. We act as product owner — or alongside yours — holding the roadmap, prioritising the backlog, and making the call on scope when delivery is under pressure. We keep the build pointed at outcomes, not output, and make the trade-offs explicit instead of letting them happen by accident. You get a backlog that reflects the strategy and a single, accountable answer to "why are we building this?" - Typical length: ongoing or per release - You get: prioritised backlog · roadmap governance · scope decisions - Best when: delivery is moving but no one owns the "why" ## 03 · Project management Someone whose only job is getting it delivered. We run the delivery itself — the plan, the dependencies, the risks, the budget, and the vendors and developers doing the building. As your project manager we keep everyone honest about dates and scope, surface problems while they're still cheap, and make the trade-offs visible instead of letting them happen quietly. We don't write the code, and we don't need to. We make sure the people who do are pointed at the right thing, in the right order, against a plan everyone can see. - Typical length: per project or ongoing - You get: delivery plan · risk & dependency tracking · vendor management - Best when: the build has the people but not the grip ## 04 · Requirements definition Turning intent into something a team can build. We translate strategy into requirements a delivery team can act on — user stories, acceptance criteria, and the edge cases everyone forgets until QA finds them. Clear enough that the thing that gets built is the thing the business actually meant. The deliverable is a scope baseline both sides can hold each other to, so "done" means the same thing to everyone. - Typical length: 2–5 weeks - You get: requirements & user stories · acceptance criteria · scope baseline - Best when: the vision is clear but the spec isn't ## 05 · UX prototyping See it before you build it. We prototype the experience — flows, wireframes, and clickable prototypes — so the important decisions get made on something you can see and test, not a paragraph in a document. It is a great deal cheaper to change a prototype than a finished sprint. You leave able to validate the experience with real users and hand engineering a target that won't move halfway through. - Typical length: 2–6 weeks - You get: user flows · wireframes · interactive prototype - Best when: you need to validate before committing engineering ## 06 · Development support We direct the build. We don't staff it. We're consultants, not a development shop — we don't employ developers and we don't sell development services. What we do is support the build: technical oversight, architecture and vendor review, and the product governance that keeps an engineering effort honest, whether the people writing the code are your team or a third party. We'll join any custom development project, on any stack, and make it deliver what the business specified — we just leave the keyboard to the people whose job it is. - Typical length: per build or ongoing - You get: technical oversight · architecture & vendor review · delivery governance - Best when: you have developers but need a product hand on the wheel ## 07 · Operations support After launch is where products are won or lost. Going live is the start, not the finish. We support the running product — monitoring the few metrics that matter, triaging what breaks, and feeding what you learn straight back into the roadmap. The work doesn't end at launch, and neither does ours. You get an operating rhythm that turns a live product into a product that keeps getting better. - Typical length: ongoing - You get: operating model · performance monitoring · improvement loop - Best when: the product is live and needs to keep improving ## How we work We embed with your team — we don't replace it. 1. **Frame** (at the start) — We agree the outcome and exactly where in the lifecycle we plug in — strategy, definition, design, build, or run. 2. **Embed** (through delivery) — We work alongside your people — product, design, and engineering — at the speed of the build, not above it on a deck. 3. **Hand back** (at the end) — We leave you with the work and a team that can run it. We build capability, not dependence. Most engagements span more than one practice area. Tell us where you are in the lifecycle and we'll tell you honestly where we'd start: [Contact](contact.html). --- [Home](index.html) · [Approach](work.html) · [About](about.html) · [Contact](contact.html)