Roughly twice a month, someone calls MagicWorks about a platform roadmap audit. The two calls look very different on the surface, and turn out to be about the same thing underneath.
The first call is from a founder who is three or four weeks from launching. The team has been building for a year, the runway is finite, and the founder wants a second pair of eyes on the roadmap before the launch commits them to a direction they cannot easily reverse. The question is: are we building the right thing?
The second call is from a founder whose platform has been live for six, twelve, sometimes eighteen months. There are users. There is revenue. There is not, however, growth that the founder can explain, or a clear reason for what to build next. The team is shipping features, and the numbers are not moving the way they should. The question is: are we still building the right thing?
Both founders assume the answer to their question depends on when they are asking it. Pre-launch calls for one kind of audit, post-launch for another. That assumption is wrong, and it is the reason most platform roadmap audits, ours included, spend the first week reframing the question the founder actually needs to answer.
Pre-launch versus post-launch is the wrong axis
The framing sounds clean: before you launch, an audit is about validation and sequencing; after you launch, it is about diagnosis and course correction. Different work, different outputs, different price. Two versions of the same service.
In practice, the two audits produce almost identical documents when the founder has done the underlying work, and almost identical documents when the founder has not. Launch status is not the variable that matters. The variable that matters is whether the founder can answer one question, in one sentence, with evidence.
The one question
“What is the specific thing a real user does on your platform that proves the model works?”
Read that again, slowly. There are four claims in it, and each one has to hold.
- 'A real user': not a friend, not a paid tester, not the founder's own team. Someone whose problem the platform is supposed to solve, who is using it because it solves that problem.
- 'Does': an action, not an intent. A signed-up user is not the same as a user who did the thing. A visitor is not a user.
- 'Specific thing': one observable behaviour that you can point to, count, and repeat. Not 'engagement'. A specific action, at a specific frequency, by a specific type of user.
- 'Proves the model works': the action is the causal link between what the platform does and the revenue the platform will earn. Not correlation, causation. Not a vanity metric, an economic one.
For an edtech platform, the answer might be: 'A learner who watches at least four consecutive lessons in week one converts to a paying subscriber at nineteen percent, versus two percent for the rest.' Specific action, specific user, evidence, and a clear economic link.
For a B2B sourcing marketplace, the answer might be: 'A verified buyer who requests quotes from three or more vendors in their first session returns within seven days sixty-eight percent of the time. The rest of the traffic does not return at all.' Same test. Passes.
For a wellness platform, the answer might be: 'A user who completes any three sessions in their first month goes on to renew at four times the rate of users who complete two or fewer.' Same test. Passes.
If you can answer the question, in that shape, with real data, an audit will not tell you very much you do not already know. If you cannot, an audit is the single most valuable exercise you can commission, whether you launched yesterday or two years ago.
If your answer is yes, with evidence, you probably do not need an audit
This will not be what your investor, your board or your product team wants to hear. But a founder who can name, with evidence, the specific action that proves the model works has a clarity most platform companies never reach. That clarity is worth defending.
What you need at this stage is not more strategy work. It is execution focus. Prioritisation discipline. A ruthless answer to the question 'if we can only ship three things this quarter, which three double down on the one action we already know matters?' An audit that produces another strategy document, another opportunity map, another future-features list, at this stage, is expensive procrastination. The founders who commission audits from a position of clarity are usually looking for permission to do something they already know they need to do.
If that describes you, save the money. Hire faster. Ship more. If in three months the numbers stop moving, then commission the audit.
If your answer is no, you need an audit, whatever your launch status
A founder who cannot answer the one question, in one sentence, with evidence, is building on assumption. Every feature shipped, every marketing rupee spent, every hire made on the current roadmap is a compounding bet on the guess. The longer you continue without answering the question, the more expensive the guess becomes.
This is the pre-launch founder who has been building for a year and has never watched a real user of their platform. It is also the post-launch founder who has ten thousand sign-ups, three thousand active users, and no idea which of those users actually got value in the way the platform was supposed to deliver it.
For both founders, the audit's job is not to hand back a shinier roadmap. It is to help you find the one question's answer. What the audit produces is a much shorter, much sharper roadmap than the one you brought in, focused entirely on the smallest number of moves that will either prove or disprove the platform's model in the shortest possible time. Everything else is deferred until you know.
What a pre-launch roadmap audit actually looks like
When the founder is a few weeks from shipping, the audit is largely a subtraction exercise. Almost every pre-launch platform we see has a feature list that is at least twice as long as the platform needs to prove or disprove its core assumption. The team's instinct is to launch with as much value as possible. The disciplined move is the opposite.
A pre-launch roadmap audit typically produces:
- An explicit, one-sentence hypothesis about which user, doing which action, at which frequency, will prove the platform works.
- A minimum viable proof: the smallest feature set that can test the hypothesis honestly, usually 30 to 50 percent smaller than the original launch scope.
- A ninety-day measurement plan defining what a positive answer, a negative answer, and an ambiguous answer look like, decided before the data arrives so the team cannot rationalise after the fact.
- A deferred-features list: everything cut from launch, held for later, and unbuildable until the hypothesis is answered one way or the other.
The output looks small. That is the point. A small, testable launch beats a large, untested one every quarter of every year, and never more than in the first six months of a platform's life.
What a post-launch roadmap audit actually looks like
When the founder is already live, the audit begins with behaviour, not opinion. Before anyone on our side offers a view on the roadmap, we spend a full week inside the platform's own analytics, session recordings, support tickets and cohort data. The goal is to reconstruct what real users actually do, versus what the team believes they do.
A post-launch roadmap audit typically produces:
- A cohort behaviour map showing which users got real value from the platform, which did not, and what distinguishes the two groups. Almost every post-launch audit finds the two groups look nothing like the personas the team designed for.
- A single hypothesis about the one action that predicts platform success, rebuilt from behaviour data, not from the original pitch deck.
- A 'kill, keep, double down' recommendation for the current feature set, evaluated against the newly identified action.
- A revised ninety-day roadmap focused on making the one action easier, more frequent, and more visible to the users who tend to do it.
The uncomfortable finding, more often than not, is that the platform was built for a user segment that turned out not to be the one paying the bills. That is not a failure of the founder or the team.
Why post-launch audits exist
The market almost always tells you something different from what the pitch deck predicted.
Where this matters most: edtech, B2B sourcing, wellness
MagicWorks' Pillar 04 practice focuses on three platform types, chosen because their economics are unforgiving of vague thinking. In each of them, the one question has a specific shape:
- Edtech: which learner behaviour in the first thirty days predicts renewal and referral. Platforms that cannot answer this build large content libraries and get low completion rates. Platforms that can answer it build small, well-sequenced paths and get high renewals.
- B2B sourcing and trade marketplaces: which pattern of buyer or vendor engagement in the first session predicts a closed transaction. Platforms that cannot answer this drown in registrations and starve of transactions. Platforms that can answer it design the first session around the action that matters.
- Wellness and lifestyle platforms: which content or programme engagement in the first month predicts habit formation and retention. Platforms that cannot answer this spend heavily on acquisition and hand the users back to the churn curve. Platforms that can answer it spend on onboarding, not just on ads.
In every one of these categories, the audit is not about the roadmap itself. It is about whether the founder has enough evidence to make the roadmap something other than a guess.
The audit's real job
A platform roadmap audit does not tell you what to build. It tells you whether you know enough to be building anything at all. That is the most useful thing a founder can be told, and it is almost never told inside the company.
Pre-launch or post-launch is the wrong question. The question is whether you can answer, in one sentence, with evidence, what a real user does on your platform that proves the model works. Answer that first. Everything else, including whether an audit will help you, follows from there.
If you cannot answer it yet, explore the MagicWorks Platform Roadmap Audit. You can also use our
Platform Strategy Checklist to test your own platform before you commission anything.
