The Early Product Cycle
The Early Product Cycle
How to prioritize features in a way that gets your new product off the ground.
Where to start? It’s a tricky question to answer for blog posts and equally challenging for new products, too. New greenfield projects are exciting. You have a fresh backlog of potential features, an exciting vision, gritty design decisions ahead, and absolutely no technical debt to service yet. This is the state I was in with Historio, a new app I’m building to explore history, a few weeks ago.
⏰ Short on time? Jump to The Framework section below to skip my ramblings and get on with prioritizing your roadmap
Getting to an MVP
In the early stages of building a product, before you have customers clamoring for bespoke features their account manager foolishly promised, generating development momentum and de-risking the product is paramount. Do both well, and you have a solid foundation for a product that will probably work. I use The Early Feature Cycle framework to achieve this balance, unblock my roadmap, and validate an MVP as fast as possible. The Early Feature Cycle is a special case of the product development cycle I’ve written about at length before.
First: The purpose of early product work. Before building big shiny features or investing months learning a new technology, it’s worth finding the best path to answer two questions:
Will this product work?
If it does work, will people use it?
Get to “yes” on both of these questions, with as little unnecessary feature work as possible, and you have yourself an MVP. 🎉 Congratulations! You can now go off and build the fun features while your product manager digs into further validating the product by answering boring questions like “How much will users pay for this?” and “Is this meaningfully different from products that already exist?”
The Priorities
To prioritize features, rate them 1-5 on Risk and Momentum:
Risk (5 = Feature is unlikely to work as envisioned)
Momentum (5 = Unblocks lots of additional features)
As described in The Framework section below, start with work on the highest risk and momentum features. You don’t need to build them out entirely, just enough to de-risk and unblock additional features. (Read: Don’t let perfect be the enemy of good just yet!).
De-Risking
To ensure the product will work, build out the riskiest features. Features are risky if either they are unlikely to work or if they’ll work but are unlikely to work the way you expect. For example, my vision for Historio is predicated on the ability to use AI to extract events with (mostly) accurate dates from history books, essays, and notes. Historio will be a fundamentally different product if this feature doesn't work. Users would have to bring and annotate their own notes instead of relying on Historio to generate some for them (which requires the user to be a particular type of nerd). This AI feature is likely to work but unlikely to work the way I expect. Events will likely be extracted successfully, but maybe not in the format I envisioned when defining early models. (I’ve already seen some of this: It turns out it’s not very easy to parse BC dates consistently from different date formats).
Example:
To de-risk Historio, I will validate the AI features early first to validate they will work and second to validate the format, variety, and consistency of data generated.
Building Momentum
The early days of building a new product should be fun. I mean, to be fair, All days building a product should be fun. But especially the early days, when every feature is new, nothing needs to be maintained, and there aren’t any disgruntled customers to appease.
In these early days, building development momentum is critical, individually and as a team. One way to build momentum is to correctly prioritize the features that unblock the highest impact features on your roadmap. Implementing login, for example, can unblock a whole set of user-specific features. While implementing iconography improves UX without unblocking other features. Prioritize the login early!
Think of this early prioritization as a depth-first search of your roadmap. Find the optimal path to your MVP that unblocks the most additional work (and balances risk; more on that in the next section). Crucially, do this search while prioritizing your backlog up front and not while you work. Try and find the optimal path before you start coding, otherwise you’re going to be taking costly steps backward to abandon developed features that weren’t ultimately on the optimal path.
To build momentum in Historio, I prioritized a Goodreads and Kindle Notes import and frontend work crafting interactive timelines.
The Framework
With your priorities set, it’s time to line ‘em up and knock ‘em down.
Start with features that have the highest risk and momentum (4-5 on the scale mentioned earlier).
Move to the features with the highest momentum but slightly lower risk.
Finish with the features that have lower risk and lower momentum.
Of course, as work starts, you’ll uncover new required features that you forgot about, new exciting features you want to build, and features that turned out to be way more complex than initially envisioned and necessitate further de-risking. After you’ve worked through the initial set of features, take stock of your roadmap, re-prioritize, and start again with the new set of features that are high risk and high momentum. This is where the “cycle” part of the Early Product Cycle comes into play.
I like to go so far as to break up my early roadmap into a few milestones or epics and identify the Early Product Cycle for each. Each milestone tackles the highest risk/momentum features, so each progressive milestone is lower-risk and more accessible due to prior investment in momentum.
The Size of Features
The Early Feature Cycle works best to prioritize medium size features — the kind that take a few days to implement. Small low-risk/high-momentum features often block these features. For example, my AI researchers would be blocked by setting up API access for OpenAI and Supabase Postgres. Don’t these blocking low-risk small features have to be done first? Yes. Of course. Anything that blocks the medium-sized features prioritized in your Early Feature Cycle must also be prioritized. For what it’s worth, usually loop these in as subtasks on the larger features.