What Belongs in a Pre-Development Success Definition, and What Doesn't

A product team working on a fitness tracking app spent eight months in development before anyone asked a simple question: how will we know this worked? The answer they gave, "when we launch", was the clearest possible sign that they had never written a success definition at all. They had written a schedule.

A success definition written after launch is a post-hoc justification.

This is more common than it sounds, and the cost shows up later. A product ships on time, with every planned feature, and the team marks it done. Then three months pass and retention is flat, user feedback is thin, and nobody can agree whether the product succeeded or failed, because nobody agreed in advance what success meant. The argument that follows is exhausting and inconclusive, because it is trying to resolve something that should have been resolved before a single line of code was written.

The pre-development phase is the only moment when a team can set the terms clearly, before sunk costs and delivery pressure distort judgement. What goes into that definition matters enormously. So does what gets left out. Both tend to go wrong together, and this article is about why, and what to do instead.

What a Success Definition Actually Is

A success definition is a statement written before development begins that describes the specific change the product is supposed to produce in a real person's life, the timeframe in which that change should occur, and how the team will know it has happened. It sits outside the familiar categories of goal and milestone. It is a claim about the world that the product, if it works, will make true.

The distinction matters because goals and milestones describe what the team will do. A success definition describes what will be different for the user. Those are not the same thing. A team can complete every milestone and hit every goal and still produce a product that changes nothing for anyone. A success definition is the thing that prevents the team from declaring victory in that situation.

Writing one forces three questions that teams routinely skip. First: who is the user, specifically, and what is their situation before they encounter the product? Second: what does better look like for that person, in concrete and observable terms? Third: at what point after launch should that change be visible, and how will it be measured? If a team cannot answer all three before development starts, they do not yet have a success definition. They have an intention, which is a different thing entirely.

The Three Proxies Teams Use Instead

In practice, teams rarely write a genuine success definition. They substitute one of three proxies, each of which feels like success but measures something else. The proxies are feature completion, launch date, and adoption count. All three are real things worth tracking. None of them is a success definition, and treating them as one creates a specific kind of problem that only becomes visible after it is too late to fix.

The reason these proxies are so appealing is that they are easy to verify. You can look at a feature list and see whether items are ticked. You can look at a calendar and see whether the product shipped. You can look at an analytics dashboard and count installs. Genuine success is harder to verify, because it requires knowing what the user's life was like before and comparing it to what it is like after. That comparison takes time and intention, and teams under delivery pressure tend to avoid it.

The pattern we see is that teams adopt a proxy in good faith, believe they are being rigorous, and then discover at the post-launch review that they have no meaningful data on whether the product worked. At that point, the proxy has already done its damage. The team celebrated the wrong thing, relaxed the wrong way, and missed the window to course-correct.

Why Feature Completion Fails as a Success Definition

Feature completion as a success definition assumes that building the right things produces the right outcomes. The assumption is false, and there is substantial evidence behind that claim. Having the same or even superior features to a competitor does not guarantee that users adopt a product or find value in it. What matters is whether the feature addresses a real emotional and functional need in the specific context where users encounter it.

We worked on a grassroots football product where the founders built based on what they believed the product should do. The feature list grew to accommodate every use case the founders imagined, and the team advised repeatedly against this, pointing out that the complexity was making the product impossible to develop coherently. The product became so complex that development had to stop, and we ceased working with them. More than a year later, the product still had no publicly visible release, only a series of "coming soon" announcements that kept shifting forward. Every feature on the original list may well have been built. The product has not reached users.

Feature completion is a delivery metric. It tells you what the team produced. A success definition tells you what changed for the person who uses it. These are related, but a product can complete all its features and change nothing for anyone, which is exactly what feature completion as a proxy makes invisible.

Before finalising your feature list, write one sentence per feature describing the specific user problem it resolves. If you cannot write that sentence, the feature is not ready to be built.

Why Launch Date Fails as a Success Definition

Launch date is perhaps the most seductive proxy, because it has a binary quality that feels definitive. The product either shipped by the date or it did not. That clarity is real, but it measures only one thing: whether the team met a deadline. It says nothing about what the product does for the people who encounter it.

Simon draws a clear lesson from working with teams that resist iterative methodologies and MVP thinking in favour of launching everything at once: those projects are at serious risk of never launching at all. The sports club app we worked on is a direct example of this. The resistance to working with the development process, treating launch as a single, total event rather than a series of incremental releases, meant that the pressure to hit a launch date distorted every upstream decision. Features were kept in when they should have been cut. Flows were left unresolved when they needed testing. The launch date drove the product, rather than the product driving the launch date.

A launch date can be a useful coordination tool. It creates a shared horizon and prevents scope from expanding indefinitely. But a coordination tool is not a success definition. Shipping on time with a product that does not work for users is punctual failure, which is in some ways harder to diagnose because the calendar says you won.

Why Adoption Count Fails as a Success Definition

Adoption count, measuring success by the number of users who install or sign up, is the most psychologically satisfying proxy, because it produces a number that grows. Growth feels like success. But adoption count measures arrival, not value. It tells you how many people showed up, not whether any of them found what they were looking for.

Between funding rounds on one project, the team made a deliberate decision to implement proper tracking of user retention and to ask users proactively how things were going. The reason was uncomfortable: investor confidence had been used as a proxy for product readiness, and the product's actual retention health had never been properly understood. Adoption numbers had been strong enough to satisfy investors. What those numbers masked was that users were arriving and leaving without reaching the point where the product's core value became clear. The adoption count looked healthy. The product was not.

There is also a specific distortion that adoption creates in internal conversations. A team watching installs grow tends to interpret that growth as validation of the product's design. The question worth asking is whether users are staying because the product genuinely works for them, or because they have not yet decided to leave. Those are very different situations, and adoption count alone cannot tell you which one you are in.

Set a retention checkpoint at 30 days post-launch alongside any adoption target. Adoption without retention is a leaky bucket, and the leak matters more than the flow.

The Cost of Getting This Wrong Before Development Starts

The cost of a missing or inadequate success definition is not visible at the start of development. It appears later, when the product has shipped and the team cannot agree on whether it worked. By that point, the cost is financial, organisational, and sometimes existential for the product itself.

According to Finish Line PDS, only one product development effort in every ten is estimated to produce a positive return on investment. That figure reflects a wide range of failure modes, but a missing success definition sits behind many of them, because a team that cannot define success before building has no reliable way to detect failure early enough to change course.

The grassroots football product and the investor-driven retention problem are two versions of the same underlying issue. In the first case, the founders defined success as completing a vision, and so every expansion of that vision felt like progress rather than risk. In the second case, investor confidence was treated as the signal, which meant the actual user experience was invisible until the moment it became undeniable. Both situations shared a common cause: the team had not written a clear statement, before development began, of what a working product would look like for a real user.

The pre-development phase is the only moment to set the terms clearly, before sunk costs distort judgement.

The earlier that definition is written, the more of the development process it can organise. The later it is written, the more it is shaped by what has already been built, which is the opposite of useful.

What Belongs in a Genuine Success Definition

A genuine success definition contains three things. It describes the target user state: the specific condition a user is in after the product has worked for them. It sets a time horizon: the point at which that state should be observable. And it names the signal that confirms the state has been reached.

A success definition does not belong in a product spec or a project plan. It belongs at the front of the brief, before any design or development decision is made, because every downstream decision should be orientated towards it. If a feature does not contribute to the target user state, it has no business being in the product. If a delivery milestone moves the team away from the time horizon, it needs to be questioned.

How to Describe the Target User State

Describing a target user state means describing a specific person in a specific situation, before and after. The before matters as much as the after, because the gap between them is where the product's value lives. A scheduling product, for example, is valuable because the person who used to write things in a notebook and forget them no longer misses appointments or deadlines. The after state is relief from a specific, observable failure. That is what belongs in the definition.

The test is whether the description would mean the same thing to two different people reading it independently. "Users feel more confident" fails this test. "A user who previously abandoned the process at step three completes it without prompting within their first session" passes it. The second version describes something observable. The first describes a sentiment that two people could interpret entirely differently.

Simon's question, are you solving a real problem that people will pay for, or are you in love with the solution?, is the right starting point here. A target user state written around a founder's vision of what the product does is a vision statement, not a success definition. It needs to be grounded in what users have said about their current situation, confirmed through research rather than assumed from experience.

Write the target user state in the user's voice, not the product team's. If it sounds like a press release, rewrite it until it sounds like something a real person would say about their own life.

How to Set a Meaningful Time Horizon

A time horizon in a success definition is the point after launch at which the product's effect on users should be visible. Setting it requires thinking about the user's natural adoption curve: how long it takes a typical user to encounter the product, form a habit around it, and reach the point where it is working for them or failing them.

For some products, 30 days is enough. A habit-forming product in the fitness space, for instance, needs users to return on their own initiative after the initial novelty fades. A 30-day retention check tells you whether that is happening. For a product in a longer decision cycle, something in property or financial planning, 30 days may capture only the earliest stages of engagement, and 90 days is a more honest horizon.

The mistake teams make is setting the horizon at launch, which collapses the time dimension entirely and makes it impossible to distinguish between a product that works and one that has simply not yet been tested. A second common mistake is setting a horizon that is so long that it provides no usable signal during development. Six to 12 weeks post-launch is usually the right range for most consumer products, long enough to observe genuine behaviour and short enough to act on what is found.

How to Write a Defensible Success Definition

A defensible success definition is one that a sceptic, reading it six months after launch, could use to evaluate the product without being given any additional context by the team. It does not depend on the team's interpretation. It describes something that either happened or did not happen, in a way that both sides of a disagreement could agree on.

Writing one requires the team to do something uncomfortable: commit to a specific claim before they know whether the product will vindicate it. That discomfort is the point. A success definition that everyone on the team feels comfortable signing their name to before development starts is almost certainly too vague to be useful. A good one feels slightly exposed, because it is saying something specific enough to be proved wrong.

The structure that works is this: a named user type, in a described situation, reaches a described state, within a defined timeframe, as evidenced by a specific signal. For a charity donation platform, that might read: a first-time donor who previously gave once and did not return makes a second donation within 60 days of their first, without being prompted by an email campaign. Every word in that sentence does work. None of it is decoration.

How to Test Whether Your Success Definition Is Real

There are four questions that expose whether a success definition is genuine or whether it is still a proxy dressed in better language. They are worth running through before development begins, and again before launch, because the pressure of delivery has a way of softening definitions that started out sharp.

1. Could a person who had never seen the product read this definition and know whether the product succeeded?
2. Does the definition describe something the user experiences, or something the team delivers?
3. Would the team accept a product that met this definition even if it looked very different from what they planned to build?
4. Is there a realistic way to collect the evidence this definition requires, within the timeframe it names?

If the answer to any of these is no, the definition needs revision. The fourth question is the one teams most often skip. A success definition that requires data the team has no plan to collect is a statement of hope. The tracking, the feedback mechanism, and the data collection plan need to be in place before launch, because you cannot measure something you did not instrument for.

We made exactly this mistake on one project and corrected it between funding rounds, implementing proper retention tracking and proactive user feedback collection only after recognising that we had been treating investor confidence as a proxy for understanding how the product was actually performing. The correction worked, but it came later than it should have. Building the measurement infrastructure into the pre-development plan would have made the data available much earlier, when it could still have shaped the product rather than just evaluated it.

Conclusion

A success definition is the document that decides whether the product development process has a fixed point to organise around, or whether it is navigating without one. Teams that skip it do not avoid the question of success. They just defer it to a point where it is much harder to answer honestly.

The proxies, feature completion, launch date, adoption count, are appealing because they are easy to verify. The problem is that they verify the wrong things. A product that ships on time, with every feature built, and 10,000 installs in the first week, can still be a product that changes nothing for anyone. Without a success definition written before development started, the team has no agreed basis for knowing that, and no framework for deciding what to do about it.

Writing a real success definition is a discipline. It requires naming a specific user, a specific change, a specific timeframe, and a specific signal. It requires committing to that claim before the product exists, which means accepting the risk of being wrong. That risk is exactly what makes the definition useful. A claim that cannot be disproved is not a claim. And a team that cannot be wrong about success has no way of knowing when they have found it.

If you are in the pre-development phase and want to work through what a genuine success definition looks like for your product, let's talk about your project.

Frequently Asked Questions