A Roadmap Doesn’t Have to Lead to Broken Promises [Mind the Product]
Gain Valuable Feedback Without Overpromising
We’d spent weeks perfecting the roadmap presentation for our annual customer conference. We thought it was pretty compelling. Every detail was worked out, every timeline de-risked, every benefit clearly articulated. Our SVP, who was usually uneasy in front of large crowds, even got through all the slides smoothly, even crisply. Then came the questions.
“What about feature X? You said you’d have it by this time.”
“Why don’t I see anything planned for product Y next year? Is it dead?”
It felt like people had overlooked all the greatness of our roadmap and were focused on the (relatively few) changes we’d made along the way. Conversely, they felt we had broken our word to them and they were incredulous, even a little angry.
For many product people, this is the nightmare scenario of sharing their product roadmap. They feel anything they say could come back and bite them. As Drift CEO David Cancel said when when we interviewed for our new book, Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty (O’Reilly): “Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.”
There are certainly risks when talking about the future, but my co-authors C. Todd Lombardo, Evan Ryan, and I agree that in most cases they are outweighed by the potential gains in market insight, customer intimacy, and mutual trust.
Why Have a Roadmap Conversation With Your Customer?
Boston startup InsightSquared has developed a culture of transparency. As chief product officer Samuel Clemens says: “We share the roadmap with our entire team — but with great power comes great responsibility.” Sam publishes a four-quarter roadmap: he updates it monthly, summarizes the reasons for changes in an email, and holds a quarterly Q&A for the whole company on how the roadmap is evolving and how it supports the company strategy.
This means that the customer-facing staff like sales and customer support have full visibility into the roadmap. In fact, Sam tells them: “Print this out. Tape it to your desk. And use this to answer questions when a customer asks you, ‘Hey, are you ever going to be doing any machine learning forecasting?'” The sales rep can say: “Yes, that’s currently on the roadmap for Q1.”
This not only helps the rep with that customer, it also provides an opportunity for direct feedback. Based on the questions they get, a rep might go to the product manager and ask, “You know that thing that’s currently out in Q4? I just heard it again. In fact I’ve heard it now three times this week. Why don’t we bring it forward?”
Helping People to Understand What a Roadmap is (and Isn’t)
Feedback is great, but what about that disappointing/lying factor again? Transformation Labs founder Saeed Khan was once asked in a roadmap review with his sales team why the roadmap kept changing all the time. He replied: “My roadmap is like your sales projection.”
“Based on what I know today, this is what I plan to achieve,” he added. “That’s what you say when you tell me, ‘by the end of the quarter,’ or whatever. But that will change, and it will change for reasons that you have no control over, right?”
The people in the room protested that it was different for them because they were dependent on external factors like customer decisions, budgets, and schedules. So Saeed pointed out that product development is actually quite similar. A roadmap can change “because of deals they brought us, or a change in the market like a competitor being bought by an industry giant. We’re trying to adjust our plan to what’s best for our business.”
“It really sunk in for them,” Saeed said. “And I learned a lot from it too. I never really understood how deeply people thought the roadmap was an absolute commitment.”
Ways to Manage Expectations
Fortunately, Saeed, Sam, and others have developed a number of ways to manage those expectations and communicate that, as the business changes, the roadmap will inevitably change.
Here are a few tips gleaned from the 80+ product people we interviewed for our book:
- Caveats – Place a “subject to change” notice on every roadmap to clearly indicate that you reserve the right to move dates, change scope, or drop items entirely from the roadmap.
- Update frequently – Even though his roadmap is organized into quarters, Sam updates it monthly. A regular, predictable cadence of updates with clear reasons for change will train your team (and your customers) that change is expected, even good.
- Confidence – See those percentages on the InsightSquared roadmap above? Those indicate the confidence Sam has that those items will still be on the roadmap when that quarter arrives. This clearly indicates that items further out are likely to change.
- Leave out dates – Many teams have taken the broad quarterly timeframes of InsightSquared’s roadmap even further and removed dates all together. Buckets with labels like “Now,” “Next,” and “Later” provide an indication of priorities and sequence without committing to dates. In many cases, this is enough for customers and just as useful for gaining feedback.
- Stage of Development – Marking something on the roadmap as in “Discovery,” “Design,” or “Prototyping” sets expectations that it may be some time before delivery and that things may change along the way. In contrast, items marked “Testing” are closer to finished and higher confidence.
Janna Bastow, CEO of ProdPad, says: “As long as we’re open and honest about our priorities, customers are actually very forgiving. We hold on to the feedback we get and reach back into it to guide the way we approach their problems—and our customers know that. Roadmap conversations have helped us to understand what resonates with people, and that helps us position our launches down the line.”
Get your free copy Nov 28th at our book signing at Workbar in Boston. Details here.
The post A Roadmap Doesn’t Have to Lead to Broken Promises appeared first on Mind the Product.
Source: Mind the Product http://ift.tt/2hZQjkE
Post a Comment