Moving from Sales-driven Commitments to Product Led Roadmaps
When Sales Cries Wolf: A Guide to Keeping Your Roadmap Sane!
Imagine this sales scenario:
A keen Sales Representative pitching a B2B solution to an enterprise customer discovers a significant opportunity that dwarfs all other sales deals by 2-3 times.
However, to secure the deal, certain features not currently supported by our core product are required, potentially requiring months of work.
The Sales Rep urgently contacts you, the Product Manager, via Slack, asking if these features can be prioritized for delivery within 30 days.
However, our roadmap is already full of planned initiatives for over the next 2 quarters or more.
Upon meeting with the Sales Rep, it's revealed that the prospect wants to finalize the deal in 7 days with a commitment to launching the requested features.
So you are now tasked with the question:
How do I manage existing priorities against this incoming request?
PMs collectively suffer the pain of context switching and constantly reviewing and setting priorities. Unfortunately, this pain gets far worse, especially when:
Escalation splash zone expands: the request is mentioned multiple times but different stakeholders, all increasing in seniority until the Top-level Management demand answers (and they want them yesterday!).
Competitor intensity is high: Ignoring this opportunity could allow competitors to further their differentiations on your product, increasing their market share at the expense of yours.
Internal politics is rampant: another department has already complained that their technical initiatives that save cost and retain customers have not been paid attention to.
As stakeholder demands increase in urgency and complexity, product managers risk decision paralysis: a state in which we are unable to make a decision due to being overwhelmed by too many options, conflicting information, or the fear of making the wrong choice.
If We Get Paid For This Custom Product Development, Why Does It Matter?
It can be extremely tempting to accept new requirements for new revenue. After all, if a handful of small features is all you need to deliver, the revenue should be enough to justify… right?
Well, the answer is often not as simple as you think, for a few key reasons:
Hidden costs: Fulfilling customised development requests often requires significant resources, including time and financial investment. This can divert resources away from core product development and delay roadmap commitments that are already aimed at revenue uplift.
Complexity Overload: Bespoke customer demands can introduce complexity into the product architecture, leading to increased maintenance costs, technical debt, and potential compatibility issues with future updates or releases.
Misalignment with Strategy or Vision: Tailoring products to individual customer requests may lead to a divergence from the product's core vision and strategic direction. This can dilute the value proposition and hinder scalability and market competitiveness in the long term.
Huge Dependency Risks: Over-reliance on customized solutions for individual customers can create dependencies that limit the ability to scale and adapt the product for broader market needs. This can hinder your organisation’s agility in responding to evolving market changes and competitive threats.
Ultimately, it comes down to trade-offs, where a PM needs to ask themselves:
What shorter and longer term impact does this incoming request have to our business?
If we make variances to plan, how do I explain this to stakeholders we’ve previously committed to?
The Different Stakeholder Perceptions Of Product Roadmaps
Roadmaps are perceived very differently depending on the stakeholder.
In a B2B/B2G context, Salespersons often perceive a roadmap to be a list of deliverables by delivery date. They often require precision and certainty to manage client expectations and sales pipelines. Any slippage from plan and they lose trust in Product.
In a B2C context, customer care or customer success teams may also demand precise commitments, often due to feedback received from existing customers. Sometimes a product may have bugs that are never prioritised due to lesser impact than planned initiatives or complexity to fix.
There’s a few risks with perceiving a roadmap as a list of commitments and dates:
Limited Flexibility: Treating roadmaps as sales commitments can lead to rigid timelines and scope creep as sales-driven demands override strategic considerations. This limits the team's ability to adapt to changing market dynamics, emerging technologies, and customer feedback effectively.
Undermining Trust: When roadmaps are consistently perceived as sales commitments, stakeholders, including customers, investors, and internal teams, may lose trust in the organization's ability to deliver on its promises. This can erode credibility and damage relationships over time.
Risk of Overpromising: Mistaking roadmaps for sales commitments may result in overpromising features or delivery timelines to customers, leading to disappointment, dissatisfaction, and potential churn if expectations are not met.
Instead, we want to view product roadmaps as an agile communication tool that articulates current strategic priorities in achieving established product vision or strategy.
I’ve transformed product organisations across different maturities and sectors towards Product-Led Roadmaps through many ways. In this post, we discuss five common elements and steps for any PM to shift these mindsets to a more collaborative “Product” way of working, focussing on outcomes and flexible, agile collaboration.
Let’s dive in!👇 🏊♂️
5 Steps Towards Product-Led Roadmaps
Keep reading with a 7-day free trial
Subscribe to The Product Post to keep reading this post and get 7 days of free access to the full post archives.