The team was building fast. Nobody could say what "done" looked like.

The Challenge

The founders had a strong idea, a talented team and real momentum. Development was already well underway when we met them. Screens were being designed, services were being built, and every week the list of things the product could do got a little longer.

What it did not have was a shape. There was no roadmap, no agreed order of work and no shared answer to the question every early product eventually has to face: what is the smallest thing we can put in front of real people that is genuinely worth using?

The company is in stealth, working in a personal and sensitive area of health, so the stakes of getting the first experience wrong were higher than usual. People handing over this kind of information need to trust a product quickly. A pile of half-finished features does not build that trust.

Nobody in the team was being careless. Quite the opposite. Everyone was working hard and making sensible decisions inside their own corner. The trouble was that the corners did not quite line up.

The Approach

Assess the landscape before touching the plan

We started by listening, separately, to the founders, the clinical input, the designers and the engineers. We asked each person the same simple questions. Who is this for? What is the first moment they love? What would you cut if you had to launch in six weeks?

We then compared those answers with what had actually been built, and with what had only been discussed. This is the part most teams skip, because it feels slower than just carrying on. It was also where the picture changed.

• There were several different versions of the MVP in circulation, each one reasonable, none of them the same.
• Some of the most polished work sat in areas that only matter once the product has an established user base.
• A few of the things users would meet in their first five minutes were the least finished parts of the product.
• Good ideas were arriving faster than anyone could decide on them, and there was no agreed place to put them.

Get everyone on the same page, in the same room

We brought the whole team together and played the findings back, without blame and without a verdict. The point was not to say who was right. It was to make the differences visible, so the team could see them for themselves and choose.

That conversation did more than any document could have. For the first time the founders heard how the engineers were interpreting their priorities, and the engineers heard the reasoning behind decisions that had previously arrived as instructions. By the end of the session there was one description of the customer and one description of the problem, written in words everyone had signed up to.

Define the features in terms of outcomes

Next we went through the feature list and rewrote each item around what it needed to achieve for the person using it, rather than what it was called internally. Several items turned out to be the same thing under different names. A few were solving a problem nobody had yet confirmed existed. Some were genuinely essential and had barely been discussed.

Every feature ended up with a plain statement of who it was for, why it mattered and how the team would know it was working. That made the next stage possible.

Draw the MVP line, then sort everything else

We worked through the list with the founders using a deliberately blunt test: would a first-time user be able to get real value, and trust the product enough to come back, without this? If yes, it was in. If not, it was out of the first release, however much everyone liked it.

Everything on the other side of the line was sorted into two groups. A fast follow list held the things that would make the product noticeably better in the weeks right after launch, ordered by what the first real users were most likely to ask for. A later list held everything else, parked with a short note on why, so good ideas were kept without being allowed to crowd the work.

Make it something the team can run

A roadmap that lives in a slide deck is not a roadmap. We set up a simple way of working that fitted a small team: one place where the priorities lived, a regular rhythm for deciding what moved, and a clear owner for the final say on trade-offs. We kept it as light as we could, because a start-up has no spare capacity for ceremony.

The Results

A team that knows what it is building

The engineers now start each cycle knowing what comes next and why. The founders have a way to say yes to good ideas without derailing the plan, because there is a place for them to go and a way to bring them forward when the time is right. Work that was already in flight was not thrown away. Most of it found its place, and the parts that did not were set aside deliberately rather than abandoned by drift.

A product lead on call

Once the roadmap existed, the next risk was that it would slowly drift back to where it started. The founders asked us to stay on, and one of us now works with the team as a fractional product lead. That means someone holding the line on the MVP, keeping the fast follow list honest, and helping the team make the next set of decisions with the same discipline as the first. It is the part of the role a company at this stage rarely needs full time, and badly needs some of.

Key Learnings

• Teams with development already in flight rarely have a speed problem. They have an alignment problem that looks like a speed problem.
• Ask everyone the same questions separately before bringing them together. The differences in the answers are the most useful material you will get.
• Writing features as outcomes exposes duplicates, assumptions and gaps that a feature list hides.
• The MVP line is a decision, not a document. The value comes from agreeing it, out loud, with everyone present.
• Parking an idea with a reason is kinder than leaving it in limbo, and it keeps trust intact with the person who raised it.
• A roadmap only survives if someone owns it. For many early-stage teams that owner is part time, and that is fine.

What We Delivered

• Individual discovery conversations across founders, clinical input, design and engineering
• A comparison of what the team believed against what had actually been built
• A facilitated alignment session and a single written description of the customer and the problem
• Outcome-based definitions for every feature
• An agreed MVP, a prioritised fast follow list and a parked later list with reasons
• A lightweight operating rhythm for planning and decisions
• Ongoing fractional product leadership