Roadmap Alternative FAQ
In my prior article I discussed my favorite alternative to conventional product roadmaps. That article seemed to strike a chord in people, and I received quite a bit of very positive feedback. However, I also received more than a few questions. This didn’t really surprise me because as I said in the article, this is not a minor topic. But in my back and forth with people, I realized that there were several common and often significant confusions, and sometimes, the discussions would expose a more serious misunderstanding about product and how product teams work.
So I decided to sort through the feedback and write up an FAQ of your most common questions. Even if you didn’t have any questions on my prior article, I hope you’ll at least skim through these questions and answers in case something in there surprises you.
Q: I am worried my “dev team” can only decide how best to build something, not what to build.
Whenever I get this question, I always have to take a few breaths before I respond. I consider this mindset of the product owner (or more generally, the CEO or stakeholders) as the only one that can determine what to build, as toxic to teams, and a major reason for the lack of innovation. I’ve tried to explain many times that often the best single source of true innovation are our engineers. That doesn’t mean every engineer is going to be like this, but the mindset where no engineers can do this is a very serious problem. The engineers are working with the technology every day and are in the best position to see what’s just now possible. They are also disproportionately very bright people. When you combine this deep knowledge of technology, with a first-hand experience of the customer problems, great products can result.
Q: What if the CEO is the product person?
In most startups, the product person is the CEO (or at least one of the co-founders). There is nothing wrong with this, and in fact it’s my preferred scenario. The key is to avoid the trap above where the CEO views the product team as just his “dev team” rather than the true product team.
Q: What about outcome-based roadmaps?
Outcome-based roadmaps refer to stating the outcome you are trying to achieve rather than the specific feature that may or may not deliver the necessary results. This is very much what I am referring to here, with two differences, one substantial and the other more cosmetic. The first is that the outcome is not actually enough context. Product teams need the bigger picture as well, which is why I emphasized the importance of also having a comprehensive product vision. The second difference is really a format difference. I advocated the OKR model for describing the outcomes you’re after. In truth, it’s not hard to map 1:1 a set of OKR’s to an outcome-based roadmap.
Q: What about straightforward items (e.g. “keeping the lights on” items)?
Several people asked if everything really needed to be expressed as outcomes, especially with what’s known as “keep the lights on” items. These are those items that every company has to do as part of staying in business. Bug fixes make up the bulk of this category, but this might include compliance items (“we need to start reporting xyz because of some financial reporting need”) or partnership items (“our partner needs us to implement a tracking pixel”). And unless there’s real risk with any of these items, we typically just put these directly onto the product backlog. We don’t worry about the outcome, and we don’t worry about validation. We just knock these out.
Q: What do we call the list of high-integrity commitments?
In the article I discussed high-integrity commitments. If we don’t do conventional roadmaps, then where and how are these commitments communicated? Some companies use the term “Plan of Record” (POR) for these special commitments. This is a document that is managed by the delivery manager, but the only one that can typically add an item to this is the CTO/VP Engineering. That’s because he or she is the person ultimately responsible for delivery.
Q: What’s the difference between Product Scorecards and OKRs?
Many of you know that I’ve been a long-time advocate of product scorecards. A scorecard is a prioritized list of outcomes that defines “good” for a product. For example, if you run an A/B test, it’s likely that you’ll have two different sets of results. But often some numbers are better in one and some numbers better in the other. So which is best? The Product Scorecard helps you answer that. So this is very related to OKR’s but a bit different. The OKR’s describe the outcomes that the team is focusing on right now. So they are both KPI-based, and they complement each other, but they serve different purposes.
Q: How does this relate to “Theme-Based Roadmaps”
Theme-based roadmaps have been around for more than 20 years. The idea is that rather than have a somewhat random collection of features on your conventional roadmap each quarter, why not introduce a focus to the work and have a theme for the quarter. An example would be to have a big focus on ease of use in Q1, and then a big focus on on-boarding in Q2, etc. There was some confusion recently because Jared Spool published an article where he actually makes the case very well for outcome-based roadmaps, but for some reason he refers to the outcomes as “themes.” He says he heard the term from a product person, but I’m guessing there was some confusion in there somewhere. In any case, if you ignore his use of the term “themes” then it’s a very good summary of the benefits of what I’m talking about, in his case primarily from the perspective of user research.
Q: How to wean an organization off of roadmaps?
The most common question of all was that teams want to move to the alternative I describe, but their organization is old-school and really addicted to the old quarterly product roadmap, so how do they transition their organization forward? Here’s what I advocate in this case. Plan on continuing with your existing roadmap process for 6-12 months. However, starting immediately, every time you reference a roadmap item, or discuss it in a presentation or meeting, be sure to include a reminder on the business outcome that feature is intended to help. If the feature you’re working on is to add a payment method, and the reason is to increase conversion, then be sure to always show the current conversion rate and the result you’re hoping to achieve. Most importantly, after the feature goes live, be sure to highlight the impact on that conversion rate. If the impact was good, celebrate it. If the impact was negligible, then emphasize to everyone that while you did ship the feature, the result was not there but you have other ideas on ways to get the desired result. The goal is that over time (it can take as long as a year), the organization moves their focus from specific features launching on specific dates, to business results.
Q: How about a complex example of this alternative to roadmaps working well?
Recently the people at Radio Lab did a podcast of a team at Facebook doing product discovery on some very hard problems. The podcast does a good job of showing how they work, and by focusing on the outcomes, the team zeros in on solutions. I can’t help but contrast this with how most large companies would have instead created a product roadmap which as you’ll see would have been a complete waste of time and effort. The podcast also raises some ethical questions, which are interesting but not critical to understanding discovery and the alternative to roadmaps.
Please continue to send me your questions. I have articles coming on OKR’s and Product Vision so I will continue to try to clarify the issues.