The Rollout Roadmap: Plan by User, Not by Feature
-
When you're planning a major new product or a significant addition to an existing one, the instinct is to break out the design tools and start organizing. You sketch out the features, estimate the effort, and slot them into a timeline. Month one: authentication and basic CRUD. Month two: notifications and reporting. Month three: integrations and admin tools. It feels productive, but it's missing the right frame.
-
The problem with this approach is that you're measuring progress by what's been built, not by what's been delivered to users.
-
-
In this model, every feature advances in parallel, and nothing is truly usable until the final deadline. The team stays busy. Demos look impressive. But no user can do anything meaningful until the whole thing comes together at the end. With this plan the value is delivered on exactly one day: the last one.
-
This is risky for obvious reasons—you're betting months of work on assumptions that won't be tested until it's expensive to change course. But it's also demoralizing. The team ships nothing to users for a long time. Stakeholders grow impatient with demos that are perpetually "almost ready." And when the final deadline approaches, everything gets stitched together under pressure.
-
There's another way.
-
-
Instead of asking "which features can we finish this month?", ask "who can use this product by the end of this month, and for what?" The shift is subtle but transformative. Now each milestone has a clear definition of done: a real person can accomplish a real task. Not a checkbox on a feature list—an actual outcome.
-
In this model, you might deliver basic functionality to an internal operations team in month one. It won't have every feature, but it will have enough for them to do their job better than they could yesterday. In month two, you expand—maybe to external power users, maybe to additional use cases. By month three, you're ready for broader rollout. Each step is usable, testable, and valuable on its own terms.
-
This forces hard prioritization decisions upfront. You can't hand-wave about which features are truly essential when you're committing to ship something usable in 2 or 3 weeks. But that's the point. Those decisions were always going to be made—the question is whether you make them deliberately at the start or frantically at the end.
-
The benefit is feedback. When User Type A starts using the product in month one, you learn things that inform what you build for User Type B in month two. The team building milestone three has information that the team planning milestone one couldn't possibly have had. You're not just reducing risk; you're building a fundamentally better product.
-
There's a cultural dimension too. Teams that ship real value every month build momentum. Teams that work toward a distant all-or-nothing deadline burn out. The structure of your roadmap shapes the experience of building it.
-
So the next time you're staring at a blank timeline for a major initiative, resist the urge to organize by feature. Organize by user. Ask who benefits first, and what's the minimum they need to benefit. Build that, ship it, learn from it, and expand. You'll end up in a better place—and you'll know much sooner whether you're heading in the right direction.
-