In my conversations with many companies, two key questions that one would expect product teams to have the answers for, but most do not are:
- How do you *authoritatively win in your category?
- If you were given $100 million of incremental investment tomorrow, how would you spend it?
*Authoritatively Win is defined as having a market-leading feature-set against competitors, no major gaps in Jobs-to-be-Done or adoption funnels (which implies best-in-class UX), unique functional or UX differentiation, and best-in-SaaS metrics for the category. Best case, you are actually defining a new category in which you can be a leader from the outset – even though this requires a ton of customer evidence and hard work with industry analysts.
The reality is that most product organizations are living quarter-to-quarter or have at most a one-year perspective on what the future could and should look like. A three-year viewpoint will satisfy virtually any investor in an exit or fundraise scenario as well as address the needs of enterprise customers, who often demand a long-term viewpoint.
Getting there is actually easier and more fun than one might think. The first steps are some close collaboration with engineering to align on a couple of key agile principles:
- Definition of an Epic – Atlassian defines an Epic as a large body of work that can be broken down into smaller stories or issues. They are delivered over a series of sprints. Atlassian also suggests that epics can span multiple teams or projects. However, when doing long-term roadmap planning, I would mandate that an epic should be limited to a single team. If other teams are required to do work, those would be epics defined and owned by those teams as dependent epics.
- Consistent Alignment on Estimation – The key to long-term roadmap planning is having a fully aligned taxonomy of high-level, rough order of magnitude estimates that can correspond to epics. For example, one could have T-shirt sizes of S, M, L, XL, 2XL, 3XL, etc. It really doesn’t matter so long as the sizing is consistent and can be traced back to man hours or man weeks (if it can’t, you’ll never be able to figure out what a high-level roadmap would actually look like).
With these two prerequisites in place, the fun can begin and it looks similar to the following:
- Engineering defines and estimates epics for their technical backlog. This should give them the freedom to define exactly what they think the platform and infrastructure should be, retiring technical debt, etc.
- Product defines and has Engineering estimate the epics to authoritatively win in the market, as defined previously.
- Using the principle of single team, single epic – teams collaborate together to identify, scope, and estimate any dependent epics, which should be tracked.
- Make sure to include epics for “innovation” items including cool feature ideas, experiments, etc. Just keep these bounded to as small a size as possible to asses viability, versus committing epic after epic. Consider also having dedicated tracks and placeholders for experimentation with boxed resources.
Once all epics are defined, estimated, and dependencies identified, product and engineering leadership can sequence out together the delivery of the product and engineering epics. Most teams will end up with a 3-year view very quickly, and often times have viewpoints that stretch considerably longer.
My recommendation is that this analysis be done once annually, in advance of budgeting season. You can then look to it to inform quarterly planning and execution, but still have the flexibility to adjust as market conditions change. And it is easy to create artifacts (with all of the appropriate caveats) for enterprise customers and investors.
With this information in hand, it will make justifying budget much easier during annual budgeting. And, it may out other issues with product or technology strategy that may significantly impact strategy or other decisions. Some examples:
- At Company A that I worked for in the past, this exercise materially helped to justify a very high purchase price for a pending acquisition because in addition to adding multiple new product categories, the underlying technology could be re-purposed to help accelerate the engineering roadmap materially faster than the company could reach organically.
At Company B that I worked for in the past, doing this exercise identified for one of the product lines that it would take ~4 years at current resourcing before the product would be in a state that anyone was truly happy with. Increasing resourcing to accelerate was not an option because nobody could rightfully justify an increase when looking at the SaaS metric impact of doing so. This resulted in a strategy shift to buy another company versus continuing to build for the product in question.