6 non-obvious things you should do before building a roadmap

I consider the product roadmap an absolutely critical, strategic artifact. I further believe that product management must be in the driver's seat relative to its definition and communication. Here are a few steps I often see overlooked when PMs find themselves creating or updating a product roadmap.

1. Define a Business Motivation Model at the appropriate level of abstraction
Your roadmap should demonstrate how you will deliver offerings to the market that achieve your business objectives and move your organization toward its vision. I've blogged previously about the Object Management Group's Business Motivation Model as a great approach to defining key motivational concepts like vision, mission and goals and driving alignment on the team as to their meanings and the relationships between them. It's impossible to assess if your roadmap is helping you achieve business objectives if you haven't defined them. As a product manager, it is your accountability to define business motivation at the product level and align it with those at the business unit and company levels as appropriate.

2. Identify market and customer segments
Market segments represent groups of consumers (whether consumer or B2B) who share common requirements or prioritization thereof. In my experience, all product markets can be divided into segments. Although a critical input to planning, many product managers have insufficient understanding of relevant market segments both from a needs and business impact perspective. This lack of understanding make release investment prioritization sub-optimal, bordering on randomness at times. You might even consider a version of the roadmap that groups investment by segments (typically for internal consumption).

Customer segments are like market segments but represents groups of customers you've already done business with. Because you typically have deeper knowledge of them, further segmentation is possible and may be valuable. For example, it's nice to know what characteristics of existing customers make them most likely to upgrade immediately to new versions.

3. Assess investments in terms of their ability to delight customers
Prioritizing the requirements we'll satisfy and in turn the features we'll develop is a key competency of successful product managers. Due to a variety of factors such as late entry to market or leftovers from a previous release, our high priority investments may be of little direct customer value or simply boring. Tools like the Kano Model can help you categorize your investments to ensure you'll deliver something exciting enough to include in the press release.

4. Perform Formal Stakeholder Analysis
Although we canonically think of the roadmap as an artifact for communication of our intent to customers, it actually represents, sometimes indirectly, commitments we must deliver to a broader range of stakeholders like executive leadership and other product groups in the company. Stakeholder analysis is the process of identifying your stakeholders and what they expect from your product. An important part of stakeholder analysis is prioritizing stakeholders with respect to their influence on your success. Take a look at the interest-influence matrix for guidance on doing this prioritization.

5. Define Key Roadmap Consumers
Once you've defined and prioritized stakeholders "all up", you need to ponder which types of stakeholders will be most interested in your roadmap. When different stakeholders have significantly different interests in your product, you should consider creating multiple versions of the roadmap to highlight the elements that are most interesting to each. In my career, we've always had at least three versions of the roadmap:

• one for the core product development team that reflected reality (including all "warts")
• a roadmap for executive leadership, often highlighting integration with other parts of the portfolio and, truth be told, showing only the warts we wanted them to see
• the typical roadmap for customers, which was typically higher level and showed almost no warts.

BTW, don't forget that your competitors are would-be consumers of your roadmap! Make sure you have the proper governance around these artifacts to ensure only the right audiences see them.

6. Create a roadmap roll-out plan
The roadmap is a critical artifact for many stakeholders. Planning how you will present it and to whom is an important activity that is often overlooked. I would suggest you share it with the development team, executive leadership and then external stakeholders like customers and partners. Other audiences you'll need to include in the plan are other product groups and other organizational functions like marketing and sales. BTW, these functions should be involved in developing the roadmap from the beginning.

So that's a quick list that actually represents quite a bit of work. What is your experience with preparing to create roadmaps?

For more information on my consulting and training offerings, please see my site: http://www.prickril.com

Product Managers and the No-win Situation

Last month I had a coaching session that, I must admit, brought back some rough memories. The "coachee", an experienced, competent product manager, was feeling un-empowered and frustrated and was looking for ways to increase his impact on the product he was managing. After suggesting options from both strategic and operational perspectives, it became clear that he had unsuccessfully tried all the approaches I suggested. Furthermore, he shared that he was caught between two important stakeholders with conflicting goals (addressing installed base vs. new customers). He then shared that many of the people with execution power relative to product development actively avoided any contact with customers. To make matters worse, these people had no customer empathy and weren't concerned that the organization was regularly failing to meet customer expectations (software wasn't making it out of the lab on time or at the level of expected quality).

This conversation reminded me of a time in my career when I had spent months fighting to make a difference in vain. The organization was a mess in terms of accountabilities, we had massive development execution problems and we were being stretched in too many directions in terms of requirements (many from internal stakeholders). I remember how over a weekend I finally came to the realization that I was simply in a no-win situation. We as professionals don't like to talk about it and product managers are especially resistant to throwing in the towel (as they should be). However, I've since realized that the ability to recognize a no-win situation and react accordingly is an important career skill.

There is no checklist for identifying a no-win situation as a PM. Here are some of the symptoms I've encountered:

• You're accountable for the product but completely un-empowered to set priorities
• Those who are making decisions about scope and priorities don't understand software development and/or the markets you serve
• Multiple organizations are vying to drive the product roadmap and the level of management above them is unable or unwilling to grant charter and/or resolve conflicts
• Product management is staffed by people who are simply unable to do the job (whether from an experience, knowledge or core competency perspective)
• Product development execution is consistently failing to deliver a quality product on time and no one is addressing the associated issues
• You are prevented from effectively engaging with customers, sometimes by the imposition of an intermediary or unfavorable "rules of engagement"

If your organization is suffering from 3 or more of these symptoms and repeated efforts on your part haven't yielded the results you expect, you need to do be honest with yourself about the likelihood of the environment changing sufficiently to give you a fair chance at success. It's important to note that I simply assume that most professionals are clever and, over time, will take reasonable steps to identify key challenges and attempt to address them. Making generalizations about how to handle the realization of your plight obviously isn't possible, but here are few thoughts that I hope help:

• Realize that some situations are simply so dysfunctional that no amount of heroic effort on your part can change the organization's prospects
• You are not alone nor the first person to face a no-win professional situation
• Accepting what is happening and making plans in a relevant timeframe can make a big difference in your career (not just your job)
• Your career is a marathon, not a sprint -- conserve your energy and passion appropriately

This is a tricky topic. As I said, product managers tend to be the last folks to accept that they can't overcome the challenges before them. While it's an uncomfortable predicament to find oneself in, losing years tilting at windmills only to ultimately fail and, even worse, be blamed for the failure is a much worse fate. On a hopefully more constructive note, here is what I consider a reasonable way to approach situations in which you don't have the influence you feel you need to realize your and the product's potential:

• Identify and analyze the key obstacles in your way (in priority order)
• Identify the minimum set of conditions that must change for you to be successful
• Make reasonable efforts to bring these obstacles to the attention of those who can help clear them and make a genuine effort to be part of the solution
• Continuously assess the realistic chances of your and the organization's overcoming these obstacles
• After honest reflection, plan accordingly, including finding an environment in which you can have greater impact (and ultimately be happier).

What's your experience? Have you found yourself in a no-win situation as a product manager?

You can discover more about my consulting and training offerings at prickril.com

Getting Strategic Marketing Input: A Product Manager's Challenge

I've run across as many approaches to marketing as organizations I've belonged to. While I've met some very impressive professionals and have seen stellar execution in terms of communication at the tactical level, I must admit I haven't had the same luck getting market-oriented strategic input from marketing. To be fair, I think this gap was due more to organization setup and motivation than the skills and knowledge of the professionals involved. Regardless, although I've never felt at all that I could/should rely completely on marketing for strategic insight, I've always been convinced getting some insight is a reasonable ask.

This quandary had lead me to think about what other expectations I can reasonably have of marketing from a strategic perspective. For example, I've also rarely gotten good insight on the competitive landscape. Once again, I don't expect marketing to serve me up a platter of perfect information: I expect to contribute to knowledge about competitors too -- I just expect something. Anything.

One might think that given my background in huge shops, a well oiled marketing machine would inundate me with market insights. Sadly, nothing could be further from the truth. One might expect these mature, fairly bureaucratic organizations would force marketing to at least go through motions of penning a marketing requirements document (MRD). Once again, one would be wrong in my case.

I'm very curious what others think are reasonable expectations of marketing in terms of strategic insight. Please don't respond with the obvious observation that we PMs are accountable for gathering this information. I have always accepted this accountability but couldn't help expecting a bit of support. Here's a short list of things I would have liked some relevant insight into:

• "Mega trends" shaping related markets
• Input on defining the market segments we should target
• Key functional trends in related products (new capabilities, for example)
• Key players in the competitive landscape
• Fodder for at least the OT dimensions of a SWOT analysis

What are your experiences? What strategic insight do you expect from marketing? What kind of insights have you gotten?

5 Smart and Creative Questions You Should Be Asking Your Customers

As product managers, we're expected to interact with customers but, in my experience, typically receive little formal training on how to do it right. While some folks are naturals at this type of communication and often it's not difficult to find topics to discuss, I have the impression that I could have or should have gotten more out of customer interactions during my career. On balance, I have to admit that much of what I discussed with customers was fairly tactical, e.g., specific issues they were facing, input on investments for the next release.

I did a quick thought exercise, trying to uncover more open, creative and even perhaps strategic questions that I either stumbled upon or wish I had stumbled upon earlier. Reviewing them now, they're probably biased toward the enterprise market where I spent most of my career. I hope they provide food for thought.

1. What would it take for you to switch to a competitor?

This question can be intimidating or scary to ask, but has the potential to give you insight into what really differentiates your product in the mind of the customer. Their response (much of it nonverbal) may also give you some insight into the extent to which they've already pondered this query.

2. How would you characterize the business value of using our product?

This question can give you important insight into how your customer quantifies or qualifies the value of your product. Do they make a strict business case or are there other intangibles that they find valuable? As PMs, it nice to see both. You can then ask yourself if the benefits/value they perceive are based on factors that are likely to be stable and long-lived. If not, you've got some thinking to do. These types of conversations can help you understand your product's value proposition and create effective positioning that resonates with other similar customers.

3. Can I watch some people using our product?

We sometimes are hesitant to make a request that we perceive as disruptive to our customers'  business, but simply watching people use your product "in the wild" will give you insights that won't come from an artificial environment like a lab and will help you understand the broader business/operational context in which your product is used. You may also get input from stakeholders that you don't normally speak to (end users as opposed to decision makers, for example).

4. What would be the immediate impact on your company if you couldn't use our product tomorrow?

The answer to this question can be humbling. If the answer is "not much", you've got some soul-searching to do. Regardless, this question can help you understand the criticality of your product to the customer and may help you better prioritize development investments, including the typically neglected "stepchildren" of feature prioritization, topics like supportability.

5. If you could change one thing about our business relationship, what would it be?
This question shows sensitivity to your customers' non-functional challenges and may give you insight into adoption blockers that are generally reserved for sales professionals. For on-premise products, you may get insight into the potential value of other delivery and pricing models. You can also get insight on price point or the licensing model that would probably never come up in discussions about the product's functionality.

For more information on my training (including online options) and consulting offerings, please visit my site, www.prickril.com.

Lies product managers tell themselves (Prickril Edition)

I enjoyed Mark Silver's post on the Spechtechular blog on the lies product managers tell themselves. Let's face it, product management is normally a grind. We shouldn't be too hard on ourselves if we tell ourselves a few white lies to help us "get through the night" from time to time. As some of us learned in "The Big Chill", rationalizations are more important than almost anything. ("When was the last time you went a week without a rationalization?").

Mark's post inspired me to do a bit so soul searching. Here are a few ugly and pernicious lies I can now admit I've told myself over the years:

1. I talk to customers all the time so I obviously understand them.

It's self-evident to most product managers that we should be talking to our customers. But let's face it, operational demands back at the lab and unfortunate constraints such as travel budget often make it difficult to engage with customers as often or as deeply as we'd like. This paucity of interaction with customers can create an exaggerated sense of value from the engagement we do have. That means sometimes we find ourselves actually believing that because we had some interaction with them that we really understand them. A few questions that can help us dispel this illusion:

• Think of a customer contact you have and list their top three professional pains (not necessarily related directly to your product).
• List the three biggest customer problems your product solves. This one leaves many an overconfident product manager scrambling for an answer when they're put on the spot.
• Are you talking to customers that are representative of important market segments or just the usual set of "groupies" (folks who love you and your product are perhaps too careful in giving you the feedback you need to radically improve your product).

2. Writing down a strategy is unnecessary because things around here change so often (and I've got a product roadmap!).

Good leaders will tell you that volatility is no excuse for not planning. Perhaps you need to tweak your planning horizon, but defining a vision and set of measurable, supporting objectives is critical and, moreover, one of your key accountabilities as a product manager! Be careful about falling into the trap that your vision and objectives are obvious to every one. You should also be wary if all your objectives are purely financial. Sustaining business success in the world of software will typically require more than short-term margin. Consider your reputation as a though-leader and your desired impact on the markets you serve. Shouldn't you define related objectives? BTW, your roadmap should be a delivery-centric expression of your strategy; it is not the strategy itself! Structurally, I like to define strategy using OMG's Business Motivation Model. This spec is, for the most part, undiscovered gold.

3. I'm extremely busy so I'm obviously getting a lot done.

Product managers are infamously busy people. I believe there are few (if any) other roles that stretch a person in so many different directions, e.g., functional vs. technical, tactical vs. strategic, inward- vs outward-facing. The shear volume and breadth of work means that we can easily delude ourselves into thinking that all this activity actually represents progress. Here's a simple exercise to help cut through "the fog of activity": Look at your calendar for the week and identify everything you're doing that has clear strategic importance. If you're not doing something strategic every day, consider reevaluating your priorities and asking yourself why your investments in your most important resource, time, are so tactical.

4. Everyone seems happy at the lab, so things must be going well for the product.

It's so easy for us to get lulled into a false sense of security during those sometimes rare periods of calm at the lab. Things are going swimmingly with development, executive leadership is happy with developments (or distracted with bigger priorities) and even the quality manager, who had been disrupting your sleep for months, seems content. It is at these times that successful product managers reflexively, even compulsively, assess what's going on "beyond the firewall" to make sure all this calm and contentedness is well-deserved. You should be asking yourself if you're getting regular, high quality information from the outside world about sales, customer satisfaction and other meaningful KPIs.

5. There are million reasons my product isn't performing like I expect it too, none of which have anything at all to do with my poor design, strategy or execution.

Much like a restaurant owner who can think of a million reasons why diners are scarce on a given evening ("There's an ice dancing special on TV tonight and Mars is in retrograde."), it is easy for us to surmise reasons why our product isn't performing at the level we expect. The hardest to accept is that we are simply not delivering what the market expects. This mismatch may be a product of simply not understanding the problem space sufficiently or failing to design the right solution. We might not have a strategy (see point 2 in this post) that is focusing our efforts on winning based on an explicit set of objectives we define. When your product is under-performing, focus you efforts on discovering why and addressing it, not concocting elaborate excuses and staying the same path. 

Lies Worthy of Honorable Mention

• My product offers enough functionality to really address my customers' pain.
• I'm clearly delivering what the market wants, not just what appeals to me.
• Every roadmap pitch I've ever made to execs. :)

So what do you think? What are the biggest lies you've told yourself over the years?

You can get more information on my consulting and training offerings on my site, www.prickril.com.

Lest we forget...

While it's clear that Agile can make you faster, make sure your efforts are guided by the right vision and strategy!

From Data to Wisdom

I've been looking for an intuitive way to make these distinctions for a long time. I think I'm on my way.