How I make product decisions.

Start with the real problem, not the assigned one

The brief and the bottleneck are often different things, and the distance between them is where most of the value sits. It is also the part of the job nobody assigns you.

My roadmap said engagement. The app took fifteen seconds to open. A feature shipped onto a fifteen-second launch is only ever measured on the people patient enough to wait, which is a smaller and far more forgiving group than the one the feature was designed for, so whatever numbers came back would not really have been about the feature.

The test I use is narrower than is the technical debt bad. It is whether the floor is currently corrupting the measurement, so that you could not read the result of the next thing you ship even if you shipped it. At fifteen seconds you cannot.

Before

15s

Benchmark

2s

What we measured against

Shipped

under 2s

Drawn to scale in seconds.

The failure mode on the other side is real, and worth naming: a team can spend a quarter on foundations, ship nothing anyone outside the building can see, and call it maturity.

Use evidence before instinct

Instinct picks the option you already like. Evidence tells you which options the problem actually has.

the problem arrived as a shape in the data rather than as a request, and three retention strategies were live options rather than one preference with two straw men beside it. Content, incentives, competition. All three had advocates, and there was appetite for roughly one.

What decided it was not which sounded best in a room. It was asking what each one costs in the twelfth week rather than the first.

Content

Recurring

Every week needs new material, and the bill never stops.

Incentives

Recurring

Withdraw the reward and the behaviour it bought goes with it.

Competition

Shipped

One-time, then self-sustaining

Other users supply the reason to return. The cost is the mechanic, not the fuel.

Make the trade-off explicit

A trade-off named at the time is judgment. The same trade-off named afterwards is a defence.

Choosing competition meant accepting that a standings table is a daily notice to whoever is last, and in a health product, the people most likely to be last are often the people the product exists for. That belongs in the same sentence as the choice.

The same applies to what I did not own. Every case study on this site says what engineering owned, what I did not decide, and where a number’s attribution stops.

Measure what shipped, and say what it proves

A number without its population is a claim. A number with one is evidence, and the limits are part of the finding rather than a disclaimer at the end of it.

The evidence on this site is behavioural: cohorts, funnels, completion rates, launch traces. It is not qualitative, and that is the gap I would close first: eight moderated sessions on mid-tier Android would tell me things no drop-off curve can.

3.5 min7.8 min

The declared north star for the Steps Premier League launch.

Session time moved 3.5 to 7.8 minutes, and it is a contestable north star in a health app. A product that works can shorten a session: open it, log the thing, leave. Time in app is a reasonable metric for a competitive feature whose loop is checking where you stand, and a poor one for a product whose job is to get you outside. Both are true at once, which is why the number needs an argument next to it.

What I would do differently

Three things, taken from the three case studies rather than invented for this page.

I would instrument before I pick the metric. On the league I chose a north star the existing instrument could produce, rather than the one the question needed: a week-two-to-week-four return rate on people who joined a league against people who did not. Choosing the metric second is how you end up defending it later.

I would build the guardrails into the launch plan. A retention mechanic that burns notification permission is a loss wearing a win’s clothes. Notification opt-outs, uninstalls and quiet season attrition are counter-metrics, and counter-metrics are worth nothing discovered afterwards.

I would treat a performance win as a position, not a state. Under two seconds is not somewhere you arrive; it is somewhere you hold, and the next three sprints of feature work are where it goes back. The size ceiling belongs in the build on week one, so the win stops depending on anyone remembering it.

What I cut, and why

The résumé says I prioritised using MoSCoW. A framework name is not a judgement. The cut is, and a prioritisation claim with no rejected item behind it proves nothing. So here are the decisions in the record that went the other way.

What this artifact is missing: who objected. The record captures what was decided and why. It does not capture who pushed back, on what grounds, or how it resolved, and a prioritisation table with no unhappy person in it is only half of what prioritisation actually is. That is a real gap in my own record rather than a gap in this page, and it is the first thing I would fix about how I document decisions.

Manual logging is the ceiling on health-app engagement in India

I think the retention ceiling on an Indian health app is set by how much typing its core loop requires, and that ABDM is the structural answer most products underuse, with four objections that are stronger than the pitch.

That argument is long enough to deserve its own page rather than a section here. Read the full thesis →