Ask a product managers to rank order their most vexing professional issues, it’s pretty certain product roadmap challenges are going to bubble to the top of the conversation
What Are The Challenges Of Building A Product Roadmap
The title of this article might of well been “Product Manager Job Description”.
Ignoring the paradox of the fact that product managers consider what is supposed to be one of their core competencies as one of their professional challenges (For our sakes, I hope surgeons don’t consider holding a scalpel to be a point of professional frustration), let’s figure out what the issues are so you can develop strategies to minimize your pain.
None of the issues we list are excuses not to do your job, in fact quite the opposite, they are literally your job description. Or to put it in the language of the product management world, the items we list below are the pain points that you as a product manager are supposed to solve.
No Pain, No Gain!!
The challenges of building the product roadmap are many and include:
- Getting help planning and prioritizing
- Communicating product strategy
As these are some pretty high level all encompassing issues, let’s dig into the details and get specific
Managing Time and Scope Estimates
When asked how long a roadmap item will take to deliver, your response should be “How long is a piece of string?”. While glib, it does make a point.
In a world with unlimited resources and no time constraints, you would never need to fix scopes and dates, but unfortunately for you, you live. in the real world. While part of the problem stems from the fact that most companies try to do much with too little and a lack of software development experience in executives, it is a situation that you must manage, much like you are constrained by your need to breath oxygen and deal with the forces of gravity. So, in order to minimize the impact of Hofstadler’s Law, on your product roadmap activities, I’d offer the following solutions
Stop discussing features: We are so emphatic about this, we enshrined talking in themes, not features in our Ten Commandments of Product Management.
Be a little loose with the details: Get all vision-y and non-committal, like a seasonsed senior executive and use ‘time horizons’ rather than a specific date in time horizons
Tie delivery to corporate milestones: Another senior executive trick, use corporate milestones as your delivery goals. Show progress, but allows for slippage in other areas of the business that have dependancies.
Unrealistic Expectations
- Damaging your relationship with the software engineers as you’re setting your developers up for failure.
- Disappoint everyone by failing to keep promises you’ve made with the roadmap.
Failure To Account For Problems
There is a story that has been going around about a physicist, a chemist, and an economist who were stranded on a desert island with no implements and a can of food. The physicist and the chemist each devised an ingenious mechanism for getting the can open; the economist merely said, "Assume we have a can opener"!
Product Feature Request Overload
Too Much Detail!! Not Enough Strategy!!
The evil twin sister/brother/person of product feature request overload is “too much detail and not enough strategy”. This is probably because people often confuse the product road map with the product development plan. Executive stakeholders do not care how you divide up your responsibilities amongst your team (They do not care how the sausage gets made).
While the devil may be in the details, you aren’t going to kill the devil with the roadmap. In fact, you will probably make your life worse as more details in the product roadmap will:
- Put people to sleep: Your teams could lose sight of the big-picture strategy.
- Kill forward momentum: The roadmap’s jobs is to help build enthusiasm for the product. If the reason for a product’s existence gets buried details, it is difficult to generate that enthusiasm.
Not Talking To The Propeller Heads, I Mean Developers
- Unless you have some hands on experience writing production quality code, you need to have an idea of how long your road map items are going to build out. While software developers are known for underestimating the effort required to build something, it is often because three items:
- Known unknowns: they haven’t been given a detailed enough scope of the problem.
- There are unknown unknowns with the project.
- They haven’t read the fucking spec docs!!!!
- While it’s a safe assumption(for your career, that is) that most engineers have little understanding of wider business or market strategy, when presented with a novel problem, a senior software development professional may have a perspective that allows for the development of a creative and simple solution.
Poor Organization Understanding Of Software Development
I’m pretty sure that that if you were an executive at a construction company and you didn’t understand or account for the time need for environmental impact studies, building permits or structural integrity test like “sounding” before a project was opened to the public, you might find yourself in bit of a professional predicament.
Yet, when it comes to account for the time needed to build, research and test software, many senior executives are at best clueless and at worse negligent, as their poor understanding of software development leads them to expect that software developers work 80 hours a week, know everything and never make mistakes. While if this were indeed the case, it begs the question as to why software developers would be working for you in the first place, it has some broader implications for your workflow.
To account for this ignorance, the reality is that research, testing and feedback need to be explicitly built into the product roadmap to make them obvious to senior stakeholders. Not doing so means that information from early-stage usability testing is wasted, feedback goes uncollected post-launch, and opportunity for future product growth is missed in the rush to meet falsely imposed deadlines
Much like you need to provide children under 18 with food, you need to account for research, testing and feedback when coming up with reasonable “time frames”. For example, when you take a step back, investing in the use of proper wire framing prototyping tools help speed up your overall project by:
- Cutting down the amount of time spent on each of development phase
- Increasing the ease with which information is disseminated. Requirements gathered from research can be stored within prototyping tools and linked to specific prototyped features, and feedback from testing can be noted within this visual requirements documentation.
- Further more, integration with usability tools means that user testing can start earlier and be done more efficiently as well.
Stakeholder Buy In
As I sit here writing about the difficulty product managers have getting stakeholder buy in, I think now is the time I deliver a dose of reality.
Product managers are not special.
Getting stakeholder buy in always has been and always be difficult, for everyone in an organization, finance, operations, marketing. Your job as a product manager is to deal with this reality, not some fictitious lala land. In fact, almost your entire job is about getting and managing stakeholder buy in. Do you hear firemen complaining about fires?
Furthermore, almost everything on this blog is about tools and strategies designed to get buy in. I would go as fo far to say, a good portion of the existence of your job function is based on the problem of getting buy in. If getting stakeholder buy in wasn’t an issue, product management wouldn’t be a thing.
Roadmap Rigor Mortis
While on first blush using “rigor mortis” to describe the a roadmap impervious to change may be a little extreme (perhaps, I should have used sclerotic), it’s quite apt. If your roadmap is too restrictive it difficult to react to inevitable changes and your product and company will eventually die.
The end.
(Out and out fraud will also land you here.)
Except that is not 100% accurate.
While some companies get locked in because divergence may be perceived like failure even thought it might be tantamount to rearranging deck chairs on the Titanic; senior executives may demand delivery on promised features or deadlines, or there might simply not be time to respond adequately.
While all of the above may sound great in terms of coming up it excuses, it over looks a central fact.
Your job as a product manager is taking calculated risks.
You cannot stick your finger in the air every Monday morning and decide you are going to build something else this week. To certain extent, you need to pick a position and stick to it for a certain period of time. The difference between good and bad product managers is that good product managers are better at divining the needs of the market place.
When you have lots of ideas (and demands) swirling around, it’s difficult to identify which initiatives to tackle and which to sacrifice. Product managers often need to make “big bets” — meaning some smaller projects get the axe.
Understanding the benefits and tradeoffs of these decisions is a central challenge not just for roadmapping, but for product management as a whole. It is unfortunate that a lot of the literature in the product management sphere smacks of victimhood.
While a product roadmap is a living document and should remain wide enough to accept changes are needed, it isn't a chameleon that changes color 5 time a day.
I would argue that excessive shift of the roadmap is symptomatic of a company that does not understand the marketplace and lacks true vision. To disguise this fact in a mask of “we need to be more responsive to the customer” or “the roadmap is a living document” is simply disingenuous and speaks of immaturity.
There should not be drastic changes involving new directions on a regular basis. While your roadmap is guaranteed to become outdated, if it is actually outdated within weeks, I would argue there is something wrong with your interpretation of the market need.
While it is a valid concern that the longer your development process, the more details in your roadmap will become inaccurate, I’d argue those details shouldn’t be there to being with is you should be working in themes
Roadmap Version Overload
As you may have read when learning to connect the product roadmap with corporate strategy and how to use your product roadmap as a communication tool the roadmap isn’t really a single document, but rather a group of documents customized for each audience.
The problem is that if you use the wrong tool (something like Microsoft Word or even Google Docs) to create the product roadmap, you will find that the document exists in several different versions around the company, with no one tracking which is the most up to date version.
Now you find yourself playing a game of “Broken Telephone: Product Management Edition” in which you trying and bring a product to market knowing that you aren’t sure everyone on your team is working with the same information. This happens because as the file gets passed around, the more it gets modified and renamed.
Luckily, you built and maintain your roadmaps using a web-based roadmap application designed to tackle this problem. No greater effort is needed to solve this issue.
Poorly Validated Product Hypothesis
If you haven’t validated your product hypothesis prior to building the roadmap, any product you build on top of faulty assumption will likely not lead you to bring a problem solving product to market.
Connecting Data To The Roadmap
So you have probably heard all the soundbites about data (“Data is the new oil, y’all”), most likely composed by PR managers rather than data experts. While it is easy to say that roadmaps are strongly rooted in both qualitative and qualitative data that supports the direction of the strategy, it’s not always easy to:
- Get your hands on it,
- Have universal agreement on what it interpretation
- Represent data explicitly in your roadmap.
Now that we have explored general roadmap challenges, let’s take a look at how the challenges are unique in companies of different sizes and stages of life
Startup Product Roadmap Challenges
While in some ways product roadmaps are much simpler at a startup, as there is less details to discuss, but it does introduce other product roadmap challenges:
Potential over-complicate things: Startup CEOs are often visionary control freaks who lack the experience building products, so they include way too much detail in their early plans. Shit, did I say that out loud?
Understand when to accepting change: At this stage, roadmaps are often a “best guess” of where the market is going and are designing a product to test their hypothesis.
SME Product Roadmap Challenges
As a company becomes more complex, so do the product roadmap challenges.
Learn to simplifying complex strategies: As a company grows and launches more ambitious products, the roadmap becomes increasingly complex. Special effort must be made to visualize and communicate all the aspects of the roadmap.
Managing the product team: There are probably more than one product manger on the team so some political maneuvering will be needed as the roadmap is built. The product roadmap challenge at this point is dealing with the internal struggles of the product team and presenting information in a meaningful way.
Keeping in touch with the customer: As a company grows and becomes more complex, the motivation to talk to customers wanes as product managers can get more removed from the the voice of the customer. It should be a regular task to understand the customer by engaging withe the sales and marking teams as they are often most in contact with the customer and market forces.
Enterprise Product Roadmap Challenges
Responding to market trends: One of the reasons large companies buy smaller ones is specifically to deal with the fact that responding to market trends with internal measures can be difficult. Those working within larger enterprises are normally not risk takers so they will often stick to what is working now at the expene of the future. As a product manager working inside of a large enterprise, you need to be aware of tow main items:
Change takes time: One of the product roadmap challenges you will have is building in this lead time.
Senior management is risk adverse: Especially if a company is publicly traded, senior management has numerous financial incentives not to risk current cashflow for an uncertain future. This requires product managers to really sell their vision of the future in order to convince stake holders that the opportunity cost of innovation is worth it.
