Your first data-driven roadmap call: what to build next from usage and churn

You shipped the product. You launched, you kept your first cohort alive, you built a referral loop, you even survived your first churn-save flow. Now you hit the question that never stops arriving once you have paying customers: what do I build next?

It feels like it should be the hard one. Whole categories of software exist to answer it. Prioritisation frameworks, RICE scores, weighted backlogs, quarterly planning rituals, win-loss interview programmes. Read enough product-management advice and you will end up convinced you need a spreadsheet with reach, impact, confidence and effort columns before you are allowed to touch a line of code.

You don't. Not at 3 to 30 customers. That machinery is built for teams with a product manager, hundreds of accounts, and enough traffic to make a percentage point mean something. You have you, Claude Code, and a customer count you can still recite from memory. Your first real roadmap call is smaller than the frameworks assume, and the evidence you need is already sitting in two places you own.

This is the move: build only what a usage gap and a churn reason both point at. Everything else waits.

Why the roadmap call is different when you have few customers

The frameworks fail you at this stage for one plain reason: you don't have the volume to make them mean anything.

RICE asks you to estimate how many customers a feature reaches. With 12 customers, "reach" is a number between 0 and 12, and you already know every one of them by first name. The statistical machinery is pretending you have a population when you have a dinner table. Weighting a backlog of 40 feature requests by confidence and effort is theatre when eight of those requests came from the same vocal customer and the other 32 came from people who churned before you learned why.

At this size, two things are true that stop being true later. First, you can read every signal by hand. You don't need a model to summarise your usage data because there isn't that much of it. Second, your own time is the entire constraint. There is no team to parallelise across. Every hour you spend building the wrong thing is an hour the right thing didn't ship. So the discipline isn't "score everything and pick the top of the list". It's the opposite: look at a very small amount of honest evidence and make one confident call.

The good news is that at 3 to 30 customers you finally have that evidence. At launch you had guesses. Now you have two real signals you didn't have before.

The two signals you now own

You are looking for exactly two things, and you already have both.

Signal one: usage data. What customers actually touch, and where they stall. Not what they say in a call. What their behaviour shows. Which features get opened in week one and never again. Which flow people start and abandon halfway. Which screen they visit right before they go quiet for good.

You do not need a heavy analytics stack for this. Vercel Analytics gives you page and route-level traffic out of the box, cookieless, no config, so you can already see which parts of the app get visited and which are ghost towns. For feature-level and drop-off detail, add a lightweight event layer. A PostHog free tier, or a handful of events you write to a Supabase table yourself, is plenty at this volume. Ask Claude Code to add three or four events on the flows you care about most: feature opened, key action completed, flow abandoned. You want to answer one question per feature: do people who pay for this actually use it, and if they start, do they finish?

Signal two: cancel reasons. Why the ones who left, left. If you built a churn-save flow already, you have a cancel-reason field or exit survey capturing this. If you don't, that is your first job before any of this works: add one required question to the cancellation screen. "What's the main reason you're leaving?" with a free-text box. Claude Code can wire that into your cancel handler and drop the answers into a Supabase table in a single session.

Cancel reasons are the highest-signal data a small SaaS has, because they cost the customer nothing to be honest and they are attached to the strongest possible action: leaving. A feature request in a support ticket is a wish. A cancel reason is a verdict.

The convergence test: build what both signals agree on

Here is the whole method. Lay your usage data next to your cancel reasons and look for the one thing they both point at.

A usage gap on its own is not enough. Maybe nobody uses your reporting screen. That could mean it's useless, or it could mean it solves a problem only 1 in 20 customers has and those 19 others were never going to touch it. A cancel reason on its own is not enough either. One person who left saying "no Xero export" is a data point, not a pattern, and building for a single departed customer is how you end up with a swiss-army-knife product nobody asked for.

But when the two converge, you have something real. Watch how it works with plausible numbers.

Say you have 18 paying customers. You look at usage and see that 11 of them open your data-export screen at least once a month. It is one of your most-touched features. But of those 11, only 4 ever complete an export. The other 7 open it, poke around, and leave. That is a proven-mover usage gap: a feature people clearly want to use, with a completion cliff.

Now you read your last two months of cancel reasons. Six people cancelled. Three of them wrote some version of "I couldn't get my data out in the format my accountant needed" or "export was too fiddly." That is a churn reason.

Convergence. A heavily-visited feature with a completion cliff, and the exact same friction showing up as a reason people quit. You are not guessing anymore. You build a better export. That is your roadmap call, and it took twenty minutes of reading, not a planning offsite.

Compare that to the request that does not converge. Your loudest customer emails weekly asking for a Kanban board view. It is the single most-repeated request in your inbox. But when you check usage, nobody is bumping against the limitation the Kanban view would fix, and no cancel reason has ever mentioned it. That request is loud, not real. It goes on the "maybe later" list and you move on with a clear conscience.

The trap of the loudest customer

The single most expensive mistake at this stage is mistaking volume of complaint for weight of evidence.

One engaged customer who emails you ten times is not ten customers. They are one customer with a lot of opinions, and their opinions are shaped by their specific workflow, which may be nothing like the workflow of the people who quietly pay and stay. Build everything they ask for and you get a product perfectly tuned to an audience of one, bristling with features that add support surface and confuse everyone else.

The convergence test protects you from this automatically, because a single customer, however loud, rarely produces both an aggregate usage gap and a pattern across cancel reasons. If their request is genuinely important, the usage data will corroborate it. If it doesn't, thank them, tell them it's on the list, and don't build it yet.

This is the discipline the frameworks miss. The failure mode of a solo founder is not "didn't score requests carefully enough." It is either building for the loudest voice or building your own fantasy feature that no signal supports. The middle path is narrow and it is simply this: two signals must agree before you commit.

Size it before you commit

Once convergence points you at a thing to build, run one more check before you start: can you ship a first version of it in roughly a weekend with Claude Code?

If yes, brilliant, that is exactly the size a roadmap call should produce at this stage. Describe the change, hand Claude Code the relevant files, let it scaffold the implementation, review the diff, ship.

If no, if the honest answer is "this is a three-week rebuild," you are not done deciding. Either break it into a smaller first slice that still relieves the friction the signals identified, or defer it and pick the next-strongest convergence. A better export might be a full rebuild, or it might be one extra format option that covers the accountant case the cancel reasons named. Ship the slice that kills the specific friction, not the grand version. You can always deepen it once you've confirmed people use the fix.

Keeping each roadmap call weekend-sized isn't a limitation, it's the point. It keeps your feedback loop tight. You build, you measure, you decide again, all inside a month. A three-month roadmap is a three-month bet placed before you've seen whether the last thing worked.

Ship behind a flag, then measure before the next call

Do not roll the new thing out to everyone on day one. Ship it behind a flag to a subset of customers first, ideally the ones whose usage and cancel-risk profile matches the signal you built for.

A feature flag is a boolean in your database and a conditional in your code. Claude Code can add one in minutes. Turn the feature on for five customers, watch the same usage events you instrumented earlier, and answer the only question that matters: are the people it was built for actually adopting it? If the completion cliff on that export flattens out for the flagged group, you built the right thing. Roll it wider. If nothing changes, you learned something cheap, and you learned it before you told your whole customer base about a feature that didn't land.

This closes the loop the convergence test opened. You decided from evidence, you built small, and now you confirm with evidence before you commit further. That confirmation feeds straight back into the next roadmap call, because "the export fix worked" and "the export fix did nothing" are two very different starting points for next month.

Make it a monthly ritual

The reason to do this deliberately once is so you can do it the same way every month without thinking hard about it.

Put a recurring 30-minute slot in your calendar. Same two inputs every time: pull the last month of usage data, read the last month of cancel reasons. Look for convergence. Pick the one thing both signals agree on. Size it, build it behind a flag, measure. One decision out, every month.

Thirty minutes is enough because you've kept the inputs small and the output singular. You are not maintaining a 200-item backlog or running a planning ceremony. You are reading two honest signals and making one call. Over a year that is twelve confident, evidence-backed build decisions, each one tightening the product around what your real customers actually do and why the ones you lost actually left.

That is a roadmap. Not a document you set once and defend in meetings, but a small monthly habit that keeps pointing you at the next right thing. And unlike the heavyweight frameworks, it's sized for exactly where you are: a solo founder, a copy of Claude Code, and a customer count you can still count.

You already have the data. The whole job is reading it honestly and building only what two signals agree on.