What’s the deal with Product Roadmaps?

As a product manager, I’m sure you’ve had to create a roadmap or two to convey future plans or, at minimum, as a sales tool so the sales people can talk somewhat convincingly about a purely hypothetical future.

Product roadmaps are meant to be a tools that are used to provide a high level view of product direction over a number of release cycles. They are used for both internal and external communication, and should present a reasonable or likely predication of the future of a product.

But in reality, roadmaps are more often aspirational rather than acheivable. What other documents do you produce the regularly require massive disclaimers and Safe Harbour clauses on the very first slide?

Roadmaps too often represent the dreams or hopes of the PM, created without needed analysis of effort and resources. It’s very easy to create a roadmap that lays out a great story, with all the good stuff people want, being delivered 9-18 months out. Seems reasonable doesn’t it. There’s a lot of stuff that can be done in a year and a half, if we start thinking and planning for it now. Correct?

Funny how those plans quickly go awry. The reality is that most product roadmaps seem to have been created over coffee in the company cafeteria. They typically show aggressive development plans and signficant deliverables over a short period of time. All of this sounds great and enables the PM to make impressive presentations to wide audiences.

And therein lies the problem. While the individual has to hold some responsibility, the majority of the problem lies with PowerPoint, the preferred medium for describing roadmaps. Yes, you heard it here:

This medium corrupts the message!

People want to see the roadmap on a single slide. Now how much information can one actually put on a single slide and make it look “great” and “worth the wait”? If each release is about 6 months, then you’re likely to have about 2 years worth of roadmap projections displayed on that one slide. It’s all great, until someone tries to define what Dev has to do to build and deliver to the roadmap. At that point, the roadmap might as well be tissue paper, as it has little substance.

Now, we all know that well analysed development plans for a single release often significantly underestimate the amount of work and time needed to complete. We all know it, because we’ve all experienced it first hand in at least one company where we worked. And if that is the case, then how would it be possible that a 2 year roadmap built on high level bullets with little detailed effort and scoping analysis could actually bear any semblance to reality.

At one company where I worked, the PM team was well aware of this problem, and if a capability was “on the roadmap” (nudge nudge, wink wink), it meant it had an almost 0% chance of being released in the next 24 months.

Sales people want product roadmaps to be set in stone once defined. This helps them make firm commitments to customers who need some pending functionality. On the other hand, sales people also want PMs and Dev to react quickly when a “big deal” is on the table and closing it requires “a few enhancements” to the product.

In the end, the roadmap is simply one of several documents that can be used to communicate future plans to potential customers. For consumer software, this is rarely an issue. But for B2B or Enterprise Software, the best thing to do is define a clear and regular method of communicating the roadmap and any changes in it to key members of the sales and marketing teams, to ensure they can position and communicate the future plans to their audiences as confidently as possible.

Saeed

Some Product Management reading

Over the last few years I’ve written several articles that have been published by the folks at ProductMarketing.com.

I discussed one such article, Product Management Axioms, in another blog post.

The remaining articles cover different topics related to product management, from beta programs to prioritizing customer feedback to a discussion on how many product managers are really enough in an organization.

I’d love to hear your feedback on any of them.

Building a Better Beta
Detailed description of the key elements of beta programs and ways to make them effective across teams in a software company

A Model for Metrics Driven Feature Prioritization
Describes a method for including large numbers of customers in a closed-loop dialog on product direction

You Can Never Have Too Many Product Managers
Defining the value of Product Management in a software company is difficult but critical. Companies must ensure the Product Management role does not bottleneck other parts of the company.

A House with no Front Door
Creating great software products requires diligence and forethought. Efforts that put development efficiencies ahead of user needs simply increase complexity and cost for the vendor over time.

Saeed

How to be a GREAT Product Manager (part 5)

Be an integrator, translator and communicator. Don’t be a terminator.

I’m sure you’ve heard the phrase that Product Managers are “the hub of the wheel”. I really don’t like that line. Who wants to be the hub of any wheel? That’s like saying someone is the hinge of the door or the latch of the hood. Boooring! And not true.

Product Managers are collectors, analyzers and dispensers of information. They are routers of information flow. And being a great product manager means understanding how to optimize the information flow so that other teams in your company who are directly or indirectly dependent on you for information get it in a timely manner and in a form they can understand and use.

The following image is a coarse example of the major communication paths that exists in a software company. The blue are internal teams and the red are external.

[click to enlarge]

I say a coarse example, because it really only represents a high-level view of how information flows. Not all links in the diagram contain the same amount of information flow; not all nodes contribute as much information as they receive; and to keep the diagram from becoming cluttered, a number of links that rightfully should be shown are not.

I call these communication pathways the Information Supply Chain. And as a Product Manager, you are directly or indirectly responsible for a lot of the product and technical information that flows throughout your organization. How many times have you been asked if certain functionality is in an upcoming release? Or when a particular release is coming out? Or the details of a beta program? Or whether any pricing or packaging changes are being made to address market needs?

People are asking these questions because they are making decisions and need information to decide wisely. You can have a significant positive impact on those teams if you understand what information people need, when they need it, and in what form they need it? If you can do that for them, they’ll be able to make educated decisions sooner, streamline their work and be more effective. Deliver meager, late or difficult to understand information, and the opposite occurs. There is a real top-line impact to poor information flow in a company.

If you really want be analytic about mapping out the flow, you can do that. You need to look at all the stages of the product development cycle, from conception to completion to launch and beyond, and map out what information different groups need and when they need it. One way to represent it is via a heatmap that may end up looking something like this.

[click to enlarge]

The coloured cells represent areas where communication happens during the development cycle. The deeper the colour, or higher the number (from 1-3 in this case), then the more activity and information flow that happens. As you can see, Product Management is deeply involved in the information flow through all phases of the development cycle, but most heavily early on and in the middle, whereas Marketing and Sales, for example, really start toward the middle and have heavy information flow from the launch stages onward.

By understanding this, you can determine what information you need to produce and deliver to those groups to optimize their activities and decisions. Keep in mind that this is not solely a task for Product Management. Ideally all groups in the company use this analysis to optimize their communications. But, if you want to apply an 80/20 rule (80% impact for 20% effort), then teams like Product Management and Product Marketing must be the first ones to optimize their information flow to other downstream groups.

As technology workers, we exist in an information economy. And just like the manufacturing world, where materials, parts and inventory requirements are optimized for efficiency and minimizing costs, information needs can be understood and delivery processes optimized for greater efficiencies. And because of our role in defining product direction and driving strategy, Product Managers can play a key role in optimizing the Information Supply Chain. The question is, are you up to the task?

Saeed

Part 4 - The 4 Cs of leadership

Part 6 - Own the product from conception to completion and beyond 

What’s the deal with BizDev? pt. 2

James McGuirk left a detailed comment on my original post that warranted a response.

Nicely written article and one that addresses the likely perspective of a product-oriented organization. Fundamentally they have interest in cultivating relationships with larger vendors which inherently increases the possibility (at least) of expanding the channel.

Thanks, and yes, correct, though I’d have to say it is from the perspective of a market-driven product organization. i.e. the clash between an overall market focus for products vs. a deal-driven partner/customer focus is the crux of the problem. As I mentioned in my comment to Mike Sabat:

In a sales driven company, product follows the transaction. i.e. the company builds the product to fulfill the transaction criteria.

…

In a market driven company, which is where Product Management looks at overall market needs (and not strictly at individual customer needs), the transaction follows the product. i.e. the company sells what is built with little or no modification.

While sales-driven and market-driven may not sound like they are too far apart, they are almost complete opposites when thought of from an operational perspective. But I digress.

James continued:

My perspective on business development however is derived from the vantage point of a systems integrator, where there are significant differences between services and product. As someone who has spent over 20 years within federal business development, the term implies an understanding of all aspects of winning business.

Companies that sell services, or sell products which include services, are almost always transaction-oriented, and therefore sales driven. I can sell you my generic product, but also sell you services to customize the product for you in some way. As soon as the services component comes in, even if the service is simply to help someone choose a product, the particular needs of the individual customer drive the activity.

In aggregate therefore, business development experts within the federal marketplace should have all those aforementioned qualities to be successful. Suffice it to say because of the level of comprehensive knowledge required, their expertise is always welcomed. Hope that helps. Jim.

The aforementioned qualities laid out in James’ comment are: Sales, Marketing, Capture Management, Proposal Management. What James describes is a different type of business development than what I was describing. In a product development company (vs. a services company), BizDev is usually part of of the Channels organization. It’s goal, as James mentions, is to expand the channel. But the issue that has frustrated me is the way many BizDev managers go about it.

Sales people are told to sell the current product. They can’t sell futures and they can’t make promises of future functionality, even if it is “on the roadmap”. But BizDev managers aren’t always held by these rules, even though they are fundamentally also sales people. I’ve seen too many cases where they sell futures (in the name of being strategic), and they discuss issues that are way off the roadmap — like the IBM mainframe port I mentioned previously. When this happen, serious misalignment occurs.

I have no issue with BizDev or Strategic Alliances in general. I see the need for them clearly. But I also have the responsibility as a Product Manager to do what is best for the product and the company. And much more often than not, that means saying “No” to rogue BizDev managers (and even, with some professional risk, Senior Management), when they go “off roadmap” and start looking for that “company making deal” (I’ve heard that phrase far too often) with some gargantuan organization that frankly, is going to waste a lot of our time, and is unlikely to ever close the deal from their end.

Roadmaps

We’re product managers. Making the roadmap is one of our key jobs. But who gets to see the roadmap?

I was prompted when I found this roadmap shared on a company’s website. (and I’m not trying to pick on them, it just got me thinking on the topic) I’m all for transparency, but this strikes me as having gone too far. You need to be somewhat careful in choosing who you share your roadmap with. Customers, definitely. Prospects probably. But I find two things wrong with this approach. First, it’s mostly backward-looking. Maybe it’s simply been up a long time. But there’s not really any benefit in explaining your product’s history to customers, unless your product is Louis XV chairs. Second, there’s no context about why they did what they did.

The purpose of the roadmap is to convince customers of two things: that you will be doing the right things in the future and, more importantly,