Assimilating new hires can take a big bite out of your schedule, but it’s a process I’ve always enjoyed, despite this. Having a captive audience eager to learn about the product is red meat to me.
The only part of it that ever made me cringe was when a question about the product roadmap caught me flat-footed: “Why is this on the roadmap?”
“Oh, it’s for a big deal of Laura’s which she expects to close this quarter…”
“This? It’s been on the roadmap for a while, but I’m not sure we’ll actually get to it…”
“Oh, the CEO really wants to do this. I wasn’t in that meeting, but I think it’s because…”
Sound familiar? Judging by what product managers have told us, my guess is that it sounds familiar to a good chunk of you reading this. So how do we all get to that point where we have caveats against multiple items on the product roadmap—and more importantly what do we do to mitigate it?
Managing the “Shadow Product Team”
Responsibility for defining the roadmap may officially rest with the product team, but there are others in the organization who can directly influence it. The heads of sales and partnerships are the usual suspects, but anyone with major influence on revenue or the customer experience has the potential to swoop in with feature requests that aren’t backed by market validation.
Practically all roadmaps will include a few things that fall outside the core product vision. For better and worse, being opportunistic to win a big deal here and there is a part of life. However, it’s a problem when those disruptions become more frequent or the product team loses control of the strategy.
Striking the right balance is hard. You want to support salespeople as best you can, but they need to close deals without offering custom features as a crutch. You need feedback and intelligence from all parts of the organization, but you can’t act on every request. In short, you need to be inclusive yet affirm that the product team is in charge of product decisions – end of story.
A consistent, transparent process for evaluating requests from the other departments can go a long way toward keeping bad features off the roadmap while keeping your internal partners happy.
What Makes a Good Product Roadmap?
Transparency goes a long way
I’ll paint with a broad brush here: most bad features get on the roadmap when people who simply don’t know better aren’t stopped by the product team. What do I mean by “people who don’t know better”? It’s those who:
- Don’t understand the effort involved
- Don’t think of the opportunity costs of spending time and money on their request
- Don’t see how their request contradicts some other priority
- Don’t think about how their idea fits into the product architecture
It’s not because they’re dumb; people who haven’t worked on the development side haven’t learned things that you probably take for granted. Here’s how you can mitigate the problem:
Review the requests: It’s obvious, but I had to put it here anyway. Don’t just add a feature to the next sprint because sales want it. Assess the requirements and prioritize the feature like you would anything else before you slot it in the development queue. (And if it can’t or shouldn’t be done, don’t add it.)
Track requests publicly: Something we did at Resonate that worked well was to keep a simple, internal wiki page with every bug report and enhancement request from the rest of the organization along with notes from product and its development status. Not only did people get to see their requests being completed, but it gave everyone a better appreciation of the volume of requests we had.
Enforce Executive-Product team cohesion: Few things are as disorienting and frustrating as conflicting orders from the bosses. Review the roadmap and any changes with the key executives outside Product at least once a month to keep everyone on the same page. Otherwise, they’ll make commitments to customers, partners, the Board and who knows who else that you may find yourself on the hook for delivering – this is perhaps the biggest source of “problem features” on the roadmap.
Explain how the development “machinery” works: Most people don’t understand how sensitive the agile process is to disruption. Put it in a diagram on the page with the request status. Hold a “lunch and learn” about it. The more people understand how products actually get built, the better.
Make sure product has a strong voice: The product team needs its own identity and voice within the company, especially where the most senior of executives still have a hand in product decisions. It’s important to have someone who can interact with those folks as a peer and push back effectively when that’s what is needed.
Sometimes, it’s the product’s job to be the “No Department,” but that doesn’t mean it’s destined to be a fight. If you show them that you’ll move their requests on when there’s a good business case, people tend to be a lot happier.
Discover more content on product roadmaps.
Comments 2