3 min readresearchproductdelivery
Run your roadmap like a research program
Doing a PhD while shipping products taught me an uncomfortable truth: most roadmaps would not survive peer review. Here is what research method fixes.
I’ve spent years running a doctorate alongside product work, and the longer I do both, the more one observation bothers me: the average research program is run with more intellectual honesty than the average product roadmap. Not more intelligence — more method. And the method transfers.
Here is what a roadmap looks like when you run it like a research program.
Features become hypotheses
A roadmap item that says “build X” cannot fail; it can only be late. A hypothesis — “we believe X will move Y for segment Z” — can be wrong, which means it can also be right. Rewriting the roadmap this way is a 30-minute exercise that changes everything downstream: suddenly you need a measurement, a timeframe, and a reason to believe.
The bar is not academic rigor. The bar is falsifiability. If nothing you could observe would make you drop the feature, it is not a bet — it is a belief wearing a Jira ticket.
Kill criteria, decided in advance
Research protocols state the conditions for abandoning a line of inquiry before the experiment starts, because everyone knows the human tendency to move goalposts once effort is sunk. Products need the same discipline. The moment to decide “we kill this if activation doesn’t move in six weeks” is before the build starts — while you are still neutral.
Most zombie features survive because the kill decision was never scheduled. Nobody decided to keep them; everybody just failed to decide anything. Deadlines slip for the same reason: the honest conversation happens too late, at the point of maximum sunk cost.
Literature review, product edition
No researcher starts a study without knowing what the field already knows. Product teams start builds without checking what the company already learned. Past experiments, churned-user interviews, support tickets, the competitor’s changelog — that is your literature. An afternoon in it kills more bad ideas than a quarter of A/B testing, and it costs nothing.
The output worth keeping is an internal “what we know” document per problem area — claims with evidence and dates. It reads exactly like a related-work section, and it stops the organization from re-running old failures with new enthusiasm.
Peer review before the experiment
The most useful academic habit is also the most uncomfortable: you show your design to people whose job is to find the flaw in it before you run the study. Product translation: a written spec, reviewed by someone with no stake in the feature shipping, whose explicit brief is “tell me why this measurement will lie to us.”
Note the emphasis on written. Slideware survives scrutiny that prose does not. If the argument for a bet cannot survive two pages of plain text, the bet is not ready.
What I’d steal first
If you adopt one practice, make features falsifiable: every major item gets a hypothesis, a metric, and a kill date, written down. It is the 80/20 of the whole method. The rest — the literature habit, adversarial review, treating the roadmap as a portfolio of experiments with different risk profiles — follows naturally once “we might be wrong” is stated out loud.
Research trained me to expect most hypotheses to fail, and to treat that as the system working. A roadmap run the same way ships fewer things and learns faster — which, over a year, means it ships more things that matter.