3 Habits to Break for Better Product Roadmapping
By: Kate Hopkins
Bruce McCarthy
Mainsail hosted 33 leaders from its portfolio companies in San Francisco for our annual Product and Technology Summit in 2019. One of the product thought leaders who also came in for the workshop was Bruce McCarthy, author of “Product Roadmaps Relaunched”. Bruce helped attendees think about how to create better roadmapping to build more successful products. Hint: it’s all about focusing on solving problems, instead of focusing on building stuff.
1.Don’t build your roadmap from customer tickets
When customer tickets come in, they tend to be a request for a specific output, like “integrate with Salesforce” or “build an invoice dashboard”. But you shouldn’t jump to building those features without exploring why customers are making that request—there could be a better solution, or an unexplored larger need. As Bruce cautioned, “most requests are somebody’s best guess at how to solve a problem they’re not telling you about.”
Instead of framing your roadmap and backlog as a to-do list of outputs, format it in terms of themes. In “Roadmaps Relaunched”, Bruce puts forward a simple template:
Ensure [result] for [stakeholder]
Take the example of a request for an invoice dashboard. If you dug in with customers and learned that the “why” behind that ticket was that accounting users needed to be able to keep track of unpaid invoices so that they could follow up with their own delinquent clients, then the theme to work on might be “ensure that unpaid invoices get paid for accounting users”. When the task is framed in terms of the outcome instead of a specific output, there’s more flexibility for different types of solutions that might be even better. Maybe there should be a recurring report that goes to accounting users at the right time during their billing cycle, or maybe the clients should be reminded directly.
2.Don’t make feature promises to your stakeholders
In addition to customer requests, product teams need to manage inbound ideas from stakeholders within their own companies. When sales, customer success, prospects, or others bring forward specific requests, Bruce recommends that product flip the conversation, “tell me more about why you want that.” Like with customers, understand the underlying needs behind the request.
With internal stakeholders and trusted customers, you can take the collaboration a step further by letting them be a part of the prioritization process. Once you have a number of different options on the table, bring stakeholders to the table to discuss what’s most valuable. Value should be measured in terms of agreed-upon broad customer needs or business objectives. Is it most important to focus on things that could drive satisfaction for a key customer type, or maybe things that could increase sales in a new market, or maybe things that could decrease churn?
Once you have those goalposts for value, Bruce recommends coming up with a prioritization framework. There are lots of different options, but according to Bruce, the best have some measure of value, some measure of effort, and some measure of certainty. Combine the value metric with a level of effort estimate and your confidence level (things that you’re 80% sure will work will end up worth more than things you’re only 20% sure will work).
3.Don’t live and die by delivering “on-time and on-budget”
This piece of advice is not a get out of jail free card for poor planning, but as Bruce put it, “Your job is not to deliver on-time and on-budget; your job is to change the course of the business.” Rather than just project managing to a set plan, strong product teams keep their eyes on the bigger goals. If the company is trying to move upmarket, dynamically prioritize development that helps win bigger deals; if the company is trying to decrease onboarding costs, habitually assess whether feature ideas could help new users get up to speed faster. It’s important to continually check that the roadmap leads where the company wants to go, and to adjust it if necessary.
It can be useful to separate the idea of a release plan from a roadmap. It may be appropriate to have a release plan that details specific outputs that will be deployed at scheduled times in the near term, and to make a firm commitment to delivering those things. But that release plan shouldn’t be the same document as the strategic roadmap, and it shouldn’t extend many months or quarters into the future—there’s just too much that could change in the interim.
The big takeaways
- Instead of counting how many features you build in a given time period, measure how much you change usage patterns, simplify the product, reduce churn, drive new revenue, or any other metric that will augment the trajectory of the business.
- Instead of cataloging customer tickets, identify underlying needs. And, instead of committing to internal requests, start a conversation about what development is of the highest value.
- Instead of measuring success by the outputs (i.e. product launches), product teams should focus on the outcomes they achieve. This means that product teams need to shift the expectations of those they work with when it comes to what goes on the roadmap.
The information herein is based on the author’s takeaways on Bruce McCarthy’s presentation at the 2019 Mainsail Product and Technology Summit. Opinions and beliefs on product roadmapping and related topics are not necessarily representative of those of Mainsail. There can be no assurance other third-party analyses would reach the same conclusions as those provided herein. The information herein is not and may not be relied on in any manner as, legal, tax, business or investment advice.
Certain information contained in this content piece has been obtained from published and non‐published sources prepared by other parties, which in certain cases have not been updated through the date hereof. While such information is believed to be reliable for the purposes of this content piece, neither Mainsail nor the author assume any responsibility for the accuracy or completeness of such information and such information has not been independently verified by either of them. The content piece will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof, or for any other reason.
Third-party images and logos included herein are provided for illustrative purposes only. Inclusion of such images and logos does not imply affiliation with or endorsement by such firms or businesses.
Certain information contained herein constitutes “forward-looking statements,” which can be identified by the use of terms such as “may,” “will,” “should,” “could,” “would,” “predicts,” “potential,” “continue,” “expects,” “anticipates,” “projects,” “future,” “targets,” “intends,” “plans,” “believes,” “estimates” (or the negatives thereof) or other variations thereon or comparable terminology. Forward looking statements are subject to a number of risks and uncertainties, which are beyond the control of Mainsail. Actual results, performance, prospects or opportunities could differ materially from those expressed in or implied by the forward-looking statements. Additional risks of which Mainsail is not currently aware also could cause actual results to differ. In light of these risks, uncertainties and assumptions, you should not place undue reliance on any forward-looking statements. The forward-looking events discussed in this content piece may not occur. Mainsail undertakes no obligation to update or revise any forward-looking statements, whether as a result of new information, future events or otherwise.
No representation, warranty or undertaking, express or implied, is given as to the accuracy or completeness of the information or opinions contained in the enclosed materials by Mainsail and no liability is accepted by such persons for the accuracy or completeness of any such information or opinions. For additional important disclosures, please click here.