When I watch the TV show Bob the Builder with my kids, the product manager in me always takes issue with Bob’s catchphrase question, “Can we build it?” I guess it’s because I get asked this deceptively simple question all the time at work. I try not to reflexively shout, “Yes, we can!” as Bob’s construction-equipment friends always do. My more pragmatic response is usually, “Sure, we can build just about anything, but should we?” I guess, “Should we build it?” doesn’t make for such a great catchphrase, but it would make Bob a better product manager.
The most successful ideas usually originate from the customer in some form, but there’s no shortage of contributions from internal stakeholders. Predictably, these ideas from within the organization are often internally focused. For example, marketing wants new purchasing options within the product, or support requires new administrative tools. These are things that typically provide internal value, but not much for the end customer. So, how can you help limit internal requests that often have competing goals? The following three suggestions have worked well in my career.
Get Aligned on a Set of Objectives
If information security’s goal is security and uptime, and sales’ goal is revenue, it’s difficult to prioritize each of their needs in a common backlog. But if you, as the gatekeeper, can point to one set of top-down objectives, it becomes easier. If the organization’s objectives include increasing revenue per customer, and sales asks for a product widget that enables them to sell add-ons, it’s clear this request trumps others that don’t directly contribute to the revenue goal.
This list of objectives should be limited to a select few. It should be clearly publicized by top leadership. And representatives from each part of the organization should be involved in its creation so they feel a sense of ownership. Of course, if you work with other product teams, the first step is to make sure your own team is in alignment!
Build a Transparent Roadmap
When you tell someone outside of product management that their idea will be “added to the backlog,” how do you think they interpret that? I suspect they visualize the closing scene from Raiders of the Lost Ark, in which the ark is shelved in some giant warehouse, never to see the light of day. While some ideas deserve such a fate, you should be completely open about what is included—and excluded—in your roadmap.
I recommend publishing your roadmap internally for all to see. Make sure it includes a simple executive summary with relative priorities, and leave out requirement details. Each project or feature within your roadmap should reference the business objective it supports, and, whenever possible, supporting data such as survey results or user testing. Also, add a change log to show regular additions and adjustments. When everyone can see your purposeful, prioritized roadmap, the potential impact of inserting additional projects becomes clear.
Don’t forget that your roadmap can and should be used for self-promotion. Put a big checkmark on completed projects and include results data, such as a project’s effect on your net promoter score or conversion rates.
Know the Facts
Let’s face it. It’s easy to blame the product. You’ve probably been in a meeting where the following conversation occurred:
“You know, Big Scary Competitor just released Super Cool Feature.”
“Really? Why don’t we have Super Cool Feature?”
“We should! I bet that’s why sales are soft this month!”
Suddenly everyone is giving you that desperate “Can we build it?” look. This is when some relevant data can help avoid debate and objectively explain why Super Cool Feature should not be a priority.
Regularly spending time with both customers and data will supply you with the qualitative and quantitative ammunition needed to fend off impulse projects. As with your roadmap, your research should be shared openly in an effort to help everyone make more informed decisions. The best way is to take survey data, analytics, conversations, tests and observations, and craft them into stories that educate and excite your team. As Paul Simon said, “Facts can be turned into art if one is artful enough.”
As a product manager, you should enthusiastically welcome your colleagues into the ideation process. You never know from where the next great opportunity will come. But it’s your responsibility, for which you are uniquely qualified, to evaluate each idea against a focused set of objectives. Be consistent in your message, candid with information and perhaps a bit diplomatic. You’ll find requests from colleagues become more focused as they join you in asking, “Should we build it?”
