Product design decides what to build and why, before anyone argues about how it should look. We run the discovery, research, and scoping that turn an idea or a stalled backlog into a plan a team can actually execute.
The failure we are usually called in to fix is not bad execution. It is a product built well that nobody needed, a feature list too long to finish, or a roadmap where every item is somehow the top priority. Money is spent, the product ships, and the numbers do not move.
We work the other way round. Establish who the user is and what they are trying to get done, define what success would actually look like in numbers, then cut the scope to the smallest version that can prove or disprove the idea.
You end up with a validated concept, a prioritised roadmap, and a prototype that has been in front of real people. Those three are what make the build phase predictable instead of hopeful.
Product strategy answers what you are building, for whom, why they would choose it, and how you will know if it worked. Product design turns those answers into something concrete: flows, screens, and a prototype people can react to. Together they cover the decisions made before development, which are the decisions that most affect whether the result succeeds.
It works through a repeating loop. Research to understand the user and the market. Definition to state the problem and what success means. Ideation to generate and narrow options. Prototyping to make the idea tangible. Validation to test it with real people. Then prioritisation, which decides what makes the first release and what waits.
Founders building a first product need it most, but so does any team with more ideas than capacity, which is every team eventually. It is equally useful for products already live where growth has flattened and nobody agrees on why.
The problem it solves is expensive certainty. Building is the costliest way to find out an assumption was wrong. Design and research let you be wrong in a week instead of in a quarter.
Structured sessions that take a vague idea or a crowded backlog and turn it into a stated problem, a target user, and a defined outcome.
Evidence about who the users are, how they currently solve the problem, and what already exists in the market.
Cutting the idea down to the smallest version that still delivers value and can prove the core assumption.
Sequencing what gets built and when, with reasoning that survives the next stakeholder meeting.
Making the idea real enough to react to, well before development budget is committed.
Putting the concept in front of the intended audience and recording what they actually do.
Ongoing design work for live products: reading the data, forming hypotheses, and improving in cycles.
Testing a concept costs a fraction of building it. Most of the value here is in the features you decide not to develop.
A defined MVP gets to market sooner and starts producing real information instead of more internal opinion.
When prioritisation follows an agreed method tied to user value, roadmap discussions get shorter and stop depending on seniority.
Developers estimate a settled scope, not a moving one. That is what makes a timeline something other than a guess.
A tested prototype is far more persuasive to investors, partners, and internal sponsors than a deck describing intentions.
Agreeing the numbers upfront means you can tell afterwards whether it worked, instead of arguing about interpretation.
Effort concentrates on the parts users care about, instead of being spread evenly across features nobody requested.
We develop the products we help define, so recommendations account for what is actually feasible in the budget and timeline you have.
Our instinct is to cut. An agency paid by scope has every reason to grow it; we would rather ship your first version early and be right about the second.
Problem statements, success measures, and prioritisation reasoning are documented. Six months on, you can still see why something was chosen.
We match research depth to what is at stake. Not every decision needs a study, and pretending otherwise wastes time you do not have.
If validation says the concept does not hold up, we say so. That is uncomfortable and it is the entire point of testing first.
Discovery, design, and development can run with one team, so the reasoning behind decisions is not lost at each handover.
You have an idea and a budget and need to know the concept holds up before most of that budget is gone.
Investors respond to evidence. A tested prototype and a defined roadmap say more than projections do.
An established offline operation moving online, where the hard part is deciding what to keep, what to change, and what to drop.
Live products where usage has plateaued and the team is out of agreement about why. Research answers it faster than another feature will.
Hundreds of items, no prioritisation anyone trusts, and a roadmap that reshuffles every month.
Internal products where adoption, not launch, is the real risk. Staff will route around a tool they find slower than the old way.
Nothing exists yet and the priority is proving the idea cheaply. Research and a tested prototype de-risk the decision to build.
The product is live but the numbers disappoint. Analysis of behaviour identifies where users abandon, and the roadmap is re-cut around that.
A working product needs to grow without becoming bloated. Prioritisation decides what earns a place and what is politely refused.
Several tools have grown into one another's territory. Strategy work decides what merges, what retires, and how users get moved across.
Taking an existing product to a new region or segment, where research separates what has to change from what only looks like it does.
Where the money is capped, scoping decides what fits and what is deferred, so the release is a decision, not whatever the budget happened to run out during.
| Deliverable | What it covers |
|---|---|
| Discovery workshops | Facilitated sessions with stakeholders, written up as agreed problem statements and success measures. |
| Research findings | User interviews, analytics review, and competitor analysis condensed into decisions and open questions. |
| Personas & journey maps | Evidence-based user profiles and the journeys they take, including where they currently fail. |
| Assumption & risk map | The beliefs the product depends on, ranked by how damaging it would be if each were wrong. |
| Prioritised feature list | Features scored against user value and effort, with the reasoning recorded. |
| MVP scope definition | A written first-release scope, defined tightly enough to be estimated and quoted. |
| User flows | Task routes through the product for the journeys that matter most to the business. |
| Interactive prototype | Clickable prototype of the core journey, suitable for testing and for showing to investors. |
| Validation report | What test participants did, what that means, and a proceed, adjust, or stop recommendation. |
| Product roadmap | Phased plan with sequencing, dependencies, and outcomes attached to each phase. |
| Handover session | A walkthrough with whoever builds it, so the reasoning transfers along with the documents. |
Strategy work is priced by engagement rather than by deliverable, because the useful question is how much certainty you need before committing to a build, and that varies enormously.
What determines the cost:
A short discovery engagement is often the sensible first step: it produces a scoped, quotable brief and costs a fraction of the build it informs. We agree the scope and a fixed price in writing before starting.
Tell us what you are considering building and we will propose an approach and a quote.
It depends on the length of the engagement, how much primary research is involved, prototype fidelity, and how many validation rounds you want. Discovery engagements are typically a small fraction of a build budget. We scope and quote each one in writing before starting.
A focused discovery sprint usually runs one to three weeks. Engagements involving recruited user interviews and multiple validation rounds run longer. We agree the duration upfront rather than leaving it open-ended.
Not always. If your scope is clear, validated, and agreed across stakeholders, go straight to design and development. Strategy earns its cost when the scope keeps changing, the team disagrees, or a large budget rests on an untested assumption.
A minimum viable product is the smallest version that delivers real value and tests the core assumption. We prioritise features against user value and build effort, then draw a line. Everything below it moves to a later phase instead of being dropped.
Yes, if you want us to. We design and develop websites, web applications, and mobile apps, so strategy can carry straight through to a built product with one team. The strategy output is also written to hand cleanly to another developer.
With a clickable prototype and task-based sessions with people from your target audience. We give them real tasks and observe what they do instead of asking whether they like it, because stated preference and actual behaviour often disagree.
Yes. We regularly work alongside in-house designers, developers, and product managers, either facilitating the process or covering a specific gap such as research or prototyping.
We tell you, with the evidence. Finding that out during a short engagement is a far better outcome than finding it out after a full build, and usually the research also points to a nearby version that does hold up.
Yes. For existing products we review analytics and user feedback against your goals, identify where the experience is failing, and produce a prioritised roadmap with the reasoning documented.
Send a short description of the product or problem, who it is for, and any constraints on budget or timeline. We reply within one business day and suggest an approach sized to the decision you are trying to make.
