How to Build an Incremental Release Plan a Founder Will Actually Agree To

We worked on a sports club app with real funding behind it, built to handle finances, fixtures, schedules and player records across a range of sports. Before any build started, we put a smaller first release in front of the client. Launch with one sport, on one platform, with a core set of features, out to market in three to four months, and add the rest once people were using it.

The plan was never the hard part. Getting a founder to believe in the smaller version is the whole job.

The client said no to every part of that. They did not want to launch with a single sport, they did not want a single platform first, and they did not want an MVP. They wanted everything, and they did not want to go to market until all of it was ready. Twelve to fourteen months later the budget had almost doubled, nothing had been published to the app store, and we parted ways.

Our advice on that project was right, and being right changed nothing, because we had not won the agreement. So this piece is about the agreement. How to prepare for the conversation, how to run it, what to lead with, and how to tell the difference between a founder who has agreed and a founder who has stopped arguing.

Why Founders Resist Launching With Less

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products, feature by feature, with the aim of merging several of them into one. They were very excited and quite pleased with themselves. We started asking questions about prospective users, mainly why someone already using two specialised apps would switch to one product that did both jobs, and whether putting everything in one place risked dumbing each feature down. They were visibly deflated by the end of it.

That reaction tells you what the resistance is made of. The spreadsheet was the idea. Cutting it back felt like cutting the idea back, and a founder who has spent a year describing the full product to investors, friends and a first hire hears a smaller release as a smaller ambition.

The Money Version of the Same Fear

There is a budget version of this too. A client can work within a lower budget, and the expectation then is less flexibility and a sharper push to get to market quickly. On one project it became clear very early that the client wanted the low budget without the limitations that come with it. That gap is where the difficult conversations start, so it pays to name it in week one rather than month seven.

What All-or-Nothing Actually Costs: A Project That Never Shipped

On the sports club app, we warned the client early that the budget would get wildly out of control and that they risked a product that was not ready to launch with no money left to finish it. The warning was noted. Then feature after feature went in. What should have been out to market in three to four months had still not launched after twelve to fourteen months, the budget nearly doubled, and the app store listing never happened.

We saw a similar ending on a grassroots football product. The founders built against what they believed the product should do rather than what the market was telling them. We advised against cramming features in, the product became so complex that development had to stop, and we stopped working with them. More than a year on from scratch, there is still no marketable release, just shifting dates and repeated announcements of coming soon.

Neither of those outcomes is rare. According to The Standish Group, 31.1% of software projects are cancelled before they are completed. The money does not disappear at the end. It drains quietly, one agreed addition at a time, while everyone involved still believes the launch is close.

Preparing the Evidence Before You Open the Conversation

Walking into the meeting with an opinion about MVPs is a waste of everybody's morning, and a solid app planning and strategy process gives you something far more useful to bring. Walk in with a forecast instead, and make it specific enough to be argued with. Dates, costs, and the two or three assumptions in the product that nobody has tested yet.

Four things are worth having written down before you start.

• A dated plan for the smaller release, with a launch month on it
• A rough cost for each feature group, so trade-offs are visible in money
• The questions a live release answers that no amount of internal debate can
• What happens to the timeline and budget if the founder's main assumption turns out to be wrong

Find out first whether the evidence has anywhere to land. We worked with a founder who had deep industry experience and very strong opinions about how the product should work, and the research turned into a box-ticking exercise. We showed compelling evidence that large numbers of their potential user base did not want particular features and preferred alternatives. They did not move an inch.

Put your forecast in writing and date it. On the sports club app our warnings were given verbally and noted politely, which made them easy to leave behind.

The Conversation, Step by Step

The order matters more than the content. Lead with the full vision, because a founder who thinks you are trying to shrink their idea will spend the meeting defending it rather than listening.

1. Restate the whole product back to them, in their words, so it is clear nothing has been lost.
2. Put the launch date for the full build on the table, with the budget it needs, and let that sit.
3. Show the smaller release next to it, with its own date and its own cost.
4. Name what the smaller release teaches you, and what it costs to learn the same thing after a full build.
5. Ask them directly which parts of the product they want real feedback on first.
6. Write the rest down as a roadmap in the same meeting, in front of them.

Step five does most of the persuading, because it hands the founder the knife. They choose the first slice, which makes the plan theirs. We ask permission to proceed rather than presenting a decision, and that gives people ownership of their own progress through the work.

Keep the meeting short and the document long. An hour of discussion with a written plan behind it holds up far better than three hours of agreement that nobody wrote down.

Leading With Budget and Time, Not Features

Feature arguments have no end, because every feature sounds reasonable on its own. Budget and time have an end, and a founder can see it. So open on those two, and let the feature list fall out of them.

The clearest way to do that is to put two plans side by side and compare them on the things a founder cares about.

You are better off launching something, listening to the feedback, seeing what resonates with the market and what does not, then coming back and spending a bit more budget on the next step. Spending heavily to perfect a product before launch only makes sense for a client with substantial resources to burn.

Figures help here when they are someone else's. McKinsey found IT projects run 45% over budget on average while delivering 56% less value than predicted. That carries more weight than an agency saying the same thing about its own client.

Choosing the First Slice: One Sport, One Platform, One Job

The slice we recommended on the sports club app was simple enough to describe in a sentence. One sport, so the rules, fixtures and squad logic only had to work one way. One platform, so the build and the testing halved. One job done properly, with the rest of the product waiting behind it.

A good first slice has a complete loop in it. Someone signs up, does the thing the product exists for, and gets the result. If the loop is broken, the release teaches you nothing, because every piece of feedback comes back as a complaint about the missing half.

What Happens When the Slice Is Too Wide

On a grassroots football app we worked on, the client kept asking for the booking process to be more intuitive, comparing each feature against best-in-class single-purpose competitors. We pushed back and then complied, and the changes made little to no difference. The core problem was that the client was trying to do too much in one product, and no amount of interaction polish fixes that.

Pick the slice by audience, not by feature. One sport, one club size, one city. A narrow audience gives you feedback you can act on, where a wide one gives you noise.

Answering the Competitor-Parity Objection

The objection usually arrives as a comparison. Their app has this, so ours needs it on day one. On the grassroots football project, that comparison ran feature by feature against products that each did one thing and did it well, and every gap read as a shortfall.

There was a reason those features existed across several separate apps. Despite real effort to build something cohesive and emotionally grounded, what came out was overly complex and too verbose, and it did not work for the audience or the core purpose.

There was a reason those features lived in separate apps, and merging them lost what made each one good.

The answer to parity is to change what is being compared. A new product does not win by matching a mature one across thirty features. It wins by being clearly better at one, for one group of people, which is a thing you can build in four months and defend in a sentence.

Worth saying plainly too, parity is partly a fantasy about usage. The Standish Group, 2015 put the share of software features that are never used at 45%. Matching a competitor feature for feature means paying to copy their unused half as well as their useful one.

Making a Smaller Release Feel Finished, Not Half-Built

The fear behind most resistance is reputational. A founder imagines a thin product with their name on it, reviewed badly by the first hundred people they care about. So the smaller release has to feel complete, and completeness is mostly about how the product behaves rather than how much of it there is.

On a health and wellbeing product we worked on, we replaced a single overall progress bar during onboarding with a segmented bar showing progress within each section. The number of steps stayed exactly the same. Splitting it into sections gave people a far more granular view of where they were, made progress feel quicker, and made it easier to judge how much further they had to go, rather than watching one long bar creep along.

That is the texture a smaller release needs. Three standards are worth holding to before anything goes live.

• The core proposition is visible within the first sixty seconds
• Someone can reach first value with no friction in the way
• Nobody is overwhelmed too early by things they do not need yet

A product that does one job and feels considered reads as finished. A product that does six jobs roughly reads as unfinished, whatever the feature count says.

Giving the Founder Something Back: The Roadmap and the Not-Now List

An incremental plan takes things away, and nobody agrees to subtraction on its own. So the roadmap has to arrive in the same meeting, with the removed features written on it under dates, owned by the founder rather than filed by the agency.

Two documents do this work. The roadmap holds everything that is coming, grouped into releases with rough months against them. The not-now list holds everything parked, with one line each explaining what has to be true before it moves onto the roadmap. Usage evidence, a funding round, a partner deal, whatever the real gate is.

The language matters more than it sounds. Parked reads as alive. Cut reads as dead, and a founder will fight to the end of the budget to stop a feature being cut.

Throughout this, we ask permission to proceed rather than announcing what happens next, which keeps the founder as the person steering. Giving someone ownership of their own progress through a project works the same way it works inside a product. People stay engaged with a process they feel they are driving.

Review the not-now list on a fixed date each month. A list that never gets revisited becomes a list of broken promises, and that is when features start creeping back into the current release.

Release Criteria, Sign-Off and Change Control

Agreement in a meeting is worth very little without something to hold it in place. Release criteria do that job. Write down what the first release contains, what it does not, and what counts as ready, and get it signed before design starts.

Then the harder part. Every new request after that point gets costed and dated against the launch, in writing, before anyone builds it. On the sports club app the additions each looked small on their own, and feature after feature went in until the entire budget was gone with nothing on the store.

The Signs a Plan Is Slipping

We have seen the same early warnings on a fitness and wellness app and on the grassroots football product. An excessive drive to perfect everything before launch. Sign-offs rolled back so more changes can be requested. Decisions that take weeks when they used to take days. We flagged the trajectory early on both, and both exhausted their budgets in design and build without ever reaching a full live version.

Rolled-back sign-off is the one to act on fastest. It shows the agreement has quietly stopped being an agreement, and the cost of raising it now is a fraction of the cost of raising it in month ten.

When the Yes Isn't Real: Spotting Agreement That Won't Hold

A founder saying yes to a smaller release and a founder planning to behave as though they had not are hard to tell apart in the room. We have been wrong about this more than once, so the signs are worth knowing.

We worked with a founder with deep industry experience who agreed to a research process and then treated it as a box-ticking exercise, with no genuine intention of acting on the findings. When we showed clear evidence that a large portion of their target users did not want certain features and preferred alternatives, they did not move. We walked away. They launched roughly the product they had always wanted about a year later, and it went nowhere.

A yes that arrives without a single question is usually a yes to end the meeting.

On the sports club app, our budget warnings were noted and the feature requests carried on the same week. Noted is not agreed. The reliable test is behaviour in the following fortnight, so watch whether the founder starts cutting their own features, defending the launch date to their own team, or asking what the first release teaches them. Silence followed by new requests tells you where you really are.

What to Do If They Still Won't Agree

Sometimes the answer stays no, and at that point you are choosing how much of someone else's money you are willing to spend proving a forecast right.

Put the risk in writing one final time, with numbers and dates, and ask for a written acknowledgement. Then set a review point with a trigger attached. If the build passes a named month or a named spend without a release, the smaller plan comes back on the table automatically. A trigger agreed in advance is much easier to invoke than an argument started from nothing in month nine.

If none of that holds, stopping is a legitimate decision. On the grassroots football product the complexity reached a point where we had to stop development and end the engagement, and more than a year later there is still nothing marketable out there. Walking away from that founder with the box-ticking research was the same call. Neither felt good.

Our view has not changed through any of it. Working with the development process and listening to professional advice is what makes these projects land, and resisting iterative release in favour of launching everything at once puts a project at genuine risk of never launching at all.

Conclusion

An incremental release plan is a design problem with a person in it. The plan itself takes an afternoon. The agreement takes preparation, a sensible order of conversation, a roadmap that gives the founder their idea back, and release criteria strong enough to survive month six.

What we learned from the sports club app was that we had to give them a smaller version they could be proud of. Three to four months, one sport, one platform, something real in people's hands, then more budget pointed at whatever the market actually responded to. That was available the whole time.

Start with budget and time rather than features. Let the founder choose the first slice. Make that slice feel finished, with a clear proposition inside the first sixty seconds and a path to first value with nothing in the way. Write down what is parked, and revisit it on a date everyone knows.

If you are heading into that conversation with a founder, or you are the founder and the full build has started to feel heavy, we are happy to talk it through. Let's talk about your first release plan.

Frequently Asked Questions