Over the last few months, I’ve been thinking about how to design a lightweight framework for product development that fits in with different ‘product cultures’ and scales from a few teams of a few people to up to 50 people.
My current ‘best guess’ of this is a modified version of the Now/Next/Later framework that Noah Weiss nicely laid out here. For each product line I’d recommend a separate roadmap of this otherwise it gets pretty unwieldy. You can always roll up specific projects into a higher level company level view, if needed.
Here are some principles that I suggest for your roadmap:
- The product roadmap needs to be publicly visible and easily accessible to folks in the whole organization.
- It needs to be easy for folks outside the immediate executing team to add ideas or requests to the ‘New’ section for triaging.
- Ideas should be tracked from ideation to completion without duplication of work to update projects by lots of unconnected tools.
- The tool you choose is not important, as long as everyone uses it. I’ve enjoyed using Asana in the past (although they don’t integrate super well with other services).
New (Inbox) : This is where all new items start to be prioritized. Items could be anything from large feature ideas, bugs or feature modifications. There should be a clear owner for prioritizing these items, usually the product lead, or on call engineer depending on the type of issue. Large projects should be broken up into milestones and prioritized. Try and keep this section at ‘Inbox Zero’.
Now (In Development) : This is what the team is actively working on right now, in order of priority. These tasks should be assigned to individuals on the team and usually correspond the the current sprint. Tasks in ‘Now’ are granular and well defined and have a clearly scoped deliverable and timeline. If you want more granular ordering or filtering in this list, I suggest tagging tasks by priority (e.g. P1, P2, P3).
Next (On Deck): These are the tasks/features that the team will work on in the next 1-2 development sprints. Tasks in this section should be in rough order of priority and have some definition around them, but may be broken up into more specific tasks when they move into the ‘Now’ bucket.
Later (Icebox): These are items that are unprioritized, but you know you want to get to them at some point. They could be bugs, loosely defined features, or feature modifications which should be tagged for clarity. The order or specificity around these is less important (especially for features) as you will prioritize and add more definition when the time comes.
Not Doing (Pit of Despair) : This bucket of tasks is usually hidden but is a list of ideas that you have explicitly decided that you are not doing. I suggest adding in a comment into the task to articulate the reason why you are not doing it, before moving it to this ‘Not Doing’ bucket.
In addition to the execution priority, it’s also useful to include some way to show the relative importance of tasks, so you can clearly see what tasks in the sprint can not drop. I suggest a Priority (Impact) and Project Size (Effort) tag like I’ve shown below.
This is an example of what a product roadmap could look in Asana:
In an ideal world, the tool is easily used and accessible by everyone in the organization and tightly integrates with other product development tools you use – e.g. Figma, Github, Google docs. Asana does not do a great job here and it’s hard to get information out of Asana if they whole company does not use it (which probably improves their retention, but makes it a worse tool overall).
These principles don’t just apply to user facing product development teams but would be also useful for ‘central teams’ like data/analytics or platform teams who are working cross functionally with folks across the organization. These teams often have ‘requestors’ of their time and expertise. It allows for better visibility into work and timelines, and also provides a structured system to ask for help or request reprioritization of work which hopefully leads to better visibility and trust between ‘central’ teams and ‘product’ teams.
Every company is different and each team may have different norms, but having a set of common principles, common tools and a shared language can improve visibility and reduce the switching costs for managers who oversee lots of projects and individual contributors moving between teams.