Quantcast

Bruce McCarthy is Founder and Chief Product Person at UpUp Labs, where he and his team are at work on Reqqs - the smart roadmap tool for product people.

Sunday
Nov032013

Is Your Roadmap One-Size-Fits-All?

This is the fifth article in a series called The Dirty Dozen Roadmap Roadblocks. In the first entry, I stated:

"You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs."

In this article, I will talk a little about why your roadmap should be tailored to specific audiences, the different flavors of roadmaps and how your “vision” should be differentiated for each market segment.

One Size Doesn't Fit All

At the annual user conference of a former employer one year, our SVP presented the roadmap for our complex product line in some detail, using a format I had helped to develop that showed horizontal “swim lanes” for each product and a timeline across the top. The leader of our team hated public speaking but the slide neatly illustrated the progress each product would make toward fulfilling our customers’ needs and gave him a structure to speak to; and the presentation was going well.

When he had spent about 45 minutes going through the roadmap, a German man in the back of the audience raised his hand and asked about our roadmap for one particular product which had not appeared in the presentation. That was a sweaty-palm moment for our SVP, and the rest of us felt for him as he tried to explain in front of hundreds of assembled customers that we did plan to continue supporting the product but that enhancements to it didn’t feature prominently in our roadmap.

The roadmap we presented spoke to many of the people in the audience, but it certainly was not a good fit for our customer from Germany.

Your Roadmap Should Sell Your Vision

Internal or external, a roadmap is a selling document and, as I’ve argued before, viewers should see their interests represented in it. It’s important, therefore, to know your audience when presenting a roadmap. Like any good sales pitch, a roadmap should speak directly to the needs of the customer.

By "customer," here I mean whoever you are presenting to. It might literally be a customer or prospect. It might also be a partner or reseller, a reporter or analyst. Often it is an internal audience such as your fellow employees, your development team, your executives, investors, or your Board.

And by “selling,” I don’t mean they are literally purchasing your roadmap. Customers are buying your product, of course, and showing them a roadmap gives them the confidence they need to buy your product based on your vision of where you intend to take it in the future. Others I’ve mentioned are not buying your product, but they are investing their time, energy, hopes for increased value, and perhaps money in your vision. In each case, the roadmap helps to convince the viewer that your plan will succeed and they will gain by investing in your product, service or company.

When a good salesperson makes a presentation, they spend time getting to know the needs, wants and expectations of their prospect, and then tailor that presentation accordingly. It is the same with roadmaps.

What Flavor Is Your Roadmap?

In my experience, there are three essential flavors of roadmaps. In this series, we have been focusing on what I call “Vision” roadmaps that lay out a high-level set of steps a product, product line, or company will take to achieve its vision of serving the needs of a particular market. Communicating who that target market is and how they will benefit is the core mission of this kind of roadmap.

The “Coordinating” roadmap is used internally or among partners to ensure everything comes together leading up to and after a release. It is more detailed than a Vision roadmap and focuses on what everyone has to do and when. It still requires buy-in from all participants to succeed, though, so make sure they see their needs and priorities reflected.

The “Technology” roadmap is similar but focuses only on deliverables for the tech team. Unlike Vision roadmaps, it often includes infrastructure build-out, rearchitecture efforts, and even specific feature deliverables that the team is committing to. Achievability is a key attribute of successful Technology roadmaps. If the engineers don't believe it's possible, they won't buy in and the roadmap won't stick. Because of its specificity, the technology roadmap should never be shown externally.

Have a Vision for Each Target Market

If you serve more than one target market, you should develop a separate vision roadmap document (or at least a slide) for each. Notice I didn’t say a separate roadmap for each product; I said a separate one for each market. Unless your products are strictly vertical with no overlap, your roadmap for a given market should include any and all products that you sell or intend to sell in that market.

If the same features of the same product would be viewed by individual markets differently, sell those benefits differently in each. Let’s say you have a new version of your tablet coming out next spring which will feature much greater graphics processing capabilities. You have two core markets that will care about this: gamers and architects. When you show your roadmap at E3, the main theme you’ll want to hit is “stunningly realistic explosions.” When you visit the annual AIA convention, though, you’ll emphasize “dramatically reduced rendering times.”

And if you’ve got a third vertical, say delivery services, for whom graphics power is unimportant, leave that theme out entirely. Focus instead on the lighter weight or the adjustable brightness for outdoor use that will come out in the follow-on model.

Targeting versions of your roadmap to specific markets is definitely more work, but it makes it much easier to sell benefits. Instead of selling the generic-sounding “increased graphics processing power,” in the above examples, the tablet maker can speak to what each market cares about.

This approach works well when you are presenting to individual markets — and, honestly, I would avoid presenting your roadmap to a large, undifferentiated audience. If we had it to do again, I would recommend to my SVP that we schedule breakout sessions for each target market so we could keep the main session very high level and go into more detail on the things each group cared about in their individual session.

Struggling With A One-Size-Fits-All Roadmap?

If your organization’s roadmap is too generic to be compelling for anyone specific, feel free to set up a time to chat with me during my free office hours. You may also be interested my popular roadmapping presentation from ProductCamp Boston, or in Reqqs, the smart roadmap tool for product people.

Use your product powers for good.

Monday
Oct282013

Jason Brett on the 60-Second Business Case

Jason Brett is a friend, fellow blogger, and a passionate product person for many years. He and I sat down over beers when he was last in Boston, and we ended up talking over his powerful 60-Second Business Case decision-making model.

If you haven’t seen this, you should. Jason has a brief overview in a few slides on his blog. Those of you who’ve seen my talk on prioritization or used the Reqqs Prioritization Scorecard will find his approach very familiar.

The 60-Second Business Case does not attempt to forecast ROI (at least not precisely), but simply to compare the relative alignment of any proposal with business goals. Jason has developed 8 specific business criteria, and each proposal is scored against those criteria. The higher the composite score across all 8 criteria, the higher the priority of a given proposal.

Each criterion has specific high, medium, low (and zero) levels. For example, expected revenue of over $1 million would be high, $250k to $1 million medium, and under $250k (or unknown) low.

Here are some of the questions I had for Jason and his thoughtful answers. Listen up, product people.

Interview Over Beers

[BMc] You point out that even after doing a 60-Second Business Case, you might sometimes need to do a full business case. Can you suggest when this might or might not be necessary?

[JB] The beauty of the 60-Second Business Case is that it allows you to quickly assess which ideas are even worth spending time on. If something scores high but there are a lot of risks or if the cost is very high, you’ll need to do some more due diligence.

Another signal that you’ll need more research or data is if your team or stakeholders start calling your scores into question. For example, if you claim a “High” customer impact for a particular feature, and other stakeholders don’t agree, you’ll need to prove that out with some more detailed evidence, and a formal business case may be the best vehicle for sharing that evidence.

But that still doesn’t mean you need to write a novel! Sometimes a 3-page business case based on real market data and a high-level resource estimate is enough to build the buy-in you need.

Clearly some companies require a formal business case and this won’t get you around that. The model can help PMs quickly focus on the most important efforts before investing significant time and resources.

[BMc] The Reqqs approach is less prescriptive, allowing users to enter their own criteria for prioritization. How did you develop these 8 criteria, and do you recommend these specific ones for everyone, or should people feel free to substitute their own?

[JB] We built these criteria based on our own needs [at Silverpop]. We had an early set of business alignment priorities that our senior stakeholders were starting to think about, but it was up to the Product Management team to figure out a way to make them quantifiable.

But the more I share this model with other product teams, the more we see that the criteria apply universally.

I have worked with non product-management teams to customize the model to make sense for other prioritization exercises (like engineering technical debt or even technology selection); and of course even other product managers should customize this if their situation is very different.

[BMc] But even your given 8 criteria are very flexible and easily tweaked.

[JB] Yes. Maybe $1 million is not a lot of revenue for you. If so, set your threshold higher. The Strategic Alignment score also refers to your company mission, your product vision, and goals your executive team has set. You’ll need to work these out early on. You may find that there are better measures of strategic alignment in your organization.

[BMc] Business priority is only one aspect of prioritization. If two items have similar business value but very different levels of effort, most people would favor the one with the higher ROI. Would you ever consider incorporating an LOE estimate in your model?

[JB] To be completely candid, I go back and forth on that very question. The first goal of this model is to help Product Managers quickly determine whether something is worth spending time on in the first place, and to spend a few seconds critically evaluating the potential of an enhancement, feature or effort. The model sits at the beginning of the process and represents the beginning of the conversation, not the end.

The next step after figuring out your priorities with this model is to talk with your development team about how much effort each of your highest priorities is. With an advanced platform like ours [at Silverpop], the answers are seldom easy. They require discussion and frequently some amount of research. I don’t want them spending time estimating things which have little business value.

[BMc] A lot of PM spreadsheets leave out “operational necessity.” Do you get into arguments about what’s really “necessary?”

[JB] There will certainly be some vigorous discussions about what is really necessary. It’s a very handy criterion because using it properly prompts you to ask the right questions.

Operational necessities are by definition things that must be done to avoid catastrophic consequences. Things like scalability requirements, security needs or even billing application maintenance can end up here. Usually these items are introduced by architecture or operations. It is rare that product management initiates an “operationally necessary” effort. When one does make its way onto the radar, our job is to help figure out what must be done to make it “no longer a necessity.”

[BMc] I imagine there is a temptation to try and squeeze things that don’t score well on any other scale into this bucket

[JB] Yes! But my team is pretty good about sniffing those out. We sit around the table and aren’t afraid to call BS on specific ideas. Product Management plays an important role here in balancing risk management with thinking about opportunity cost.

[BMc] I like the way you have neatly folded “first to market,” “buzz factor,” and “customer impact” into the “innovation” bucket. I imagine this one helps contain a lot of “we gotta do this because it’s so cool!” conversations.

[BMc] That’s a great observation and it’s true. It really does. Many companies place a high value on product innovation and it can be very difficult to maintain the discipline necessary to invest in the most valuable innovations as opposed to the coolest.

The trick is in calling attention to innovative ideas but making sure that they measure up in other key areas as well.

[BMc] I noticed you weighted the PM’s fudge factor higher than all other factors. I like that you are balancing the right brain with the left, but are we really that smart?

[JB] I’d like to think so, but in reality it’s not about how smart we are.

I was talking with a colleague who has recently started using The 60 Second Business Case with her staff. She told me about introducing the model to the officers in her C-Suite. The CTO questioned that in front of her CEO.

The CEO fired back though. He said that good judgment was exactly what he was paying product managers for and that 25% seemed about right to him.

[BMc] You can’t do everything strictly by the numbers or who is really running your company?

[JB] Exactly. But if it’s not 25%, then what is the right value to place on the Product Manager’s experience, intuition and ability to assimilate multiple priorities into an effective plan? Is it 5%, 10%, 50%? Let’s have a conversation about it and come up with a good percentage.

[BMc] What’s the significance of the hippopotamus photos in the latest version of your presentation?

[JB] I love this term! The HiPPO is a concept or person we all deal with in one way or another. It’s the “Highest Paid Person On Site”…or the “Highest Paid Person’s Opinion.” Maybe it’s your CEO or maybe it’s your boss. Sometimes it can even be a board member.

The point here is that there is often a stakeholder with their own agenda or opinion that we need to understand and integrate into our own thinking. Sometimes they have great ideas and occasionally they can create distractions to our work.

The 60 Second Business Case offers a powerful framework for explaining exactly why we’ve made the choices we’ve made, and allows us to help that stakeholder evaluate their own ideas through the exact same filter.

Recently, one of my top stakeholders had an idea for a great feature we could add to the product. He had already agreed that we were using the right criteria to rank product ideas, so we looked at his idea together and evaluated it on each of the 8 dimensions in the model.

We agreed on every single ranking. And the idea just didn’t stack up to the other priorities.

We didn’t move forward on his idea for now, and he was happy that we had made the right choice. It didn’t take a business case or endless debates and research. It just took agreement on our priorities and a simple framework to foster the conversation.

What questions do you have for Jason? Post them in the comments and let’s extend the conversation (beer optional).

Saturday
Oct192013

Is Your Roadmap Inside Out?

This is the fourth article in a series called The Dirty Dozen Roadmap Roadblocks. In the first entry, I stated:

"Your roadmap should be driven by the needs of the people and organizations you intend to serve."

Unfortunately, I've seen a lot of roadmaps that are filled with initiatives that are only relevant to people inside the company. "New Platform," "Social Media Integration," "Ecommerce," or "Server Upgrade" are perhaps things you should do (and some of them are nice buzzwords), but it is not clear whether any of them will benefit anyone in particular.

In the previous entry, I argued that you must clearly state the benefit of each roadmap item to a particular customer segment or internal stakeholder. But trying to guess at the benefits provided by the things already on your roadmap is backwards. It's "inside-out" thinking. Your job as a product person is to understand market problems and devise solutions to those problems. You can't do that, though, if you are trapped within your organization's thinking.

Bringing The Outside In

ATG 10 was a huge win for the already successful ecommerce company. It was greeted enthusiastically by customers, kept us in the proper "quadrants" and "waves," and was a demonstration of continuing leadership in our space that resulted in the company's billion-dollar acquisition by Oracle in 2011.

This major release of the company's ecommerce suite was largely driven by work my team did to define "multi-site" capabilities for the company's enterprise ecommerce platform. The concept was to use a single platform and a common set of elements such as a product catalog to support multiple different online stores. The idea came initially from requests we'd received from customers such as Nike who owned multiple brands (and operated in many countries) and needed online stores for each, but didn't want to build each from scratch or support each completely separately.

The genesis of this "multi-site" support capability was requests from outside of the organization (from customers), but that wasn't enough to make it onto the roadmap by itself. Based on these requests, though, we did a study of companies in our target market and found that over half of them had some form of this need. Everyone from Neiman Marcus to Restoration Hardware seemed to have "sister sites" or "micro-sites" or "sub-brands" that needed their own web presence but leveraged parts from others in the family. And every one of them struggled with the work involved with supporting each on a separate stack.

We further developed the concept into sub-themes designed to support each of 5 major flavors of multi-site support needed by working with customers and observing other organizations in our target market. "We learned that folks use the idea of 'site' pretty loosely -- it can be a whole, self-contained site, or a fraction of another site," remembers one member of the team. "This gave us insight into how people were (and were not) using our customer segmentation features as well."

Once we had validated the prevalence and major outlines of this market need, it became the dominant theme for this major release of our product. The benefit of this new capability was self-evident to this large segment of our market that supported (or wanted to support) multiple online stores.

Validating Your Solution

All of this happened before we committed to specific features. Before we got to that point, we needed to validate that our proposed solution would actually solve the problems we'd identified. We worked closely with a few key customers, showing them mockups and early implementations of our tools.

Brian Collins, VP of Product Management and Design at ATG during this time, remembers that "Nike shared with us a clear view of their longer term strategic vision for multinational expansion. We had the chance to get feedback on what multi-site support would do for their business, as well as how the things we planned to build fit with their needs, and this helped to crystalize our product vision."

These were clearly not just a series of unconnected feaure requests, but part of a market trend we saw playing out across many customers all trying to solve the same core problems.

Be The Light Bringer

Should we upgrade our platform or our servers or our colo facility? Should we put a twitter button on the login page? I don't know. Do any of these address problems our target market has or will have in the the future? Are they an important part of a theme we've developed based on market problems? If not, perhaps they can wait. And if so, perhaps they are more a detail of how we will deliver on our product roadmap than roadmap items of their own.

As a product person, your role is to represent the perspective of the market. Engineering says "I can build that," and Marketing says "I can bring that to market," but your job is to define what "that" is based on market needs and then work with the other to groups to bring it all together in a roadmap that captures that market opportunity.

Be the one who brings the light of knowledge of market needs from outside into the organization. As a product person, you are the only one with that job description. Shed that light on inside-out thinking and it will illuminate your roadmap to success.

Struggling With Inside-Out Thinking?

If your organization’s roadmap is bogged down with internal matters, feel free to set up a time to chat with me during my free office hours. You may also be interested my popular roadmapping presentation from ProductCamp Boston, or in Reqqs, the smart roadmap tool for product people.

Use your product powers for good.

Wednesday
Oct092013

Reqqs Appears in Product Management Journal

The occasional UK Product Management Journal from the gang at ProductFocus was kind enough to quote me and mention Reqqs in their issue on Roadmaps this month. The journal is free for registrants and will arrive by email in pdf format.

They adapted some material from my ProductCamp presentation on Roadmapping (with permission, of course), including the wording in this cartoon about all of the conflicting (and very insistent) input a product person often gets on their roadmap priorities.

Here is how they describe the topic:

"A roadmap is a graphical way of showing where our product is heading. It’s a living document used to steer and co-ordinate teams across the business. It’s high-level with the ever-present danger that people will assume that what they want to see delivered is hidden in the detail. A roadmap is a plan … and yes, plans change. Above all a roadmap is a tool. And like any tool it can be used well or badly."

Other good advice in this issue includes this quote from Jonathan Wright, VP Products at Interoute:

"Arming your sales team with a roadmap and delivering against it sends out two fundamental messages to customers: we are continuing to be progressive and we deliver against our promises. These may be all that’s needed to swing the deal."

Check out this issue of the Product Management Journal here.

Sunday
Oct062013

Roadmaps Focus on Vision & Benefits -- Not Features

This is the third article in a series called The Dirty Dozen Roadmap Roadblocks. In the first entry, I stated:

"A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team."

This next article is about building your roadmap around high-level benefit-oriented themes for both internal and external audiences, and about what to say when asked for commitments on specific features.

Is This a Committed Relationship?

If I'm your customer or a new prospect and I've asked to see your product roadmap, what is it I want to see? I might want to see specific features I have requested and when they are scheduled for release, but you probably can't commit to things in that much detail.

I might also be interested in what breakthrough solutions you have planned for the future, but you'd be foolish to tip your hand to the market too early there as well.

The real question I am asking when I ask to see your roadmap is: "How committed are you to me?" I want to see myself and my issues reflected in your priorities. Much as I might like it, I know that you can't promise specific features on specific dates, but I do want to see that there are ongoing benefits to me and others like me in your vision of the future.

If Not Features, Then What?

Seeing features I might like on your roadmap is certainly one way for me to infer that you have my interests in mind, but it's even better if you can come right out and say what problems you are trying to solve for me. Roadmaps, like any other sales document, should focus on benefits.

Now you probably do have a lot of features in mind for specific releases, but rather than list them all (which wouldn't fit on a slide anyway), there's a better way. What I recommend, instead, is rolling features up into themes.

As I explained in my ProductCamp presentation on roadmapping, a theme is "a group of features tied together by a simple, clear benefit, usually to the user." A theme should:

  • Be high-level and consist of few words. "Streamlined workflow" is much better than "fewer steps in the check-in, check-out process."
  • Make the benefit obvious. "Match your branding" is better than "Support millions of colors."
  • Roll up many details. "Quicker access to your data" is much better than a list of access points with time reduction stats.

Themes Provide Focus and Flexibility

Focusing a release on a small number of themes (1-3) gives your development team goals to strive for and motivates them to deliver on the promised benefits. Given a goal rather than just a list of features, they may even come up with better ways to deliver the value promised by your theme.

This focus also spills over to the marketing and sales teams, which can speak to the specific benefits of particular new releases. Press releases and CEO quotes practically write themselves.

Also, because themes mask detail, they provide you the flexibility to cut individual features without cutting the theme itself. You may have 10 features planned for the "efficiency" theme, but if the work takes longer than planned and you can only deliver on 5, you can still claim you've improved efficiency. (And then start planning for "Efficiency Phase II" or decide there are higher priorities.)

Your Board is Just Another Customer Segment

The roadmap you show your Board of Directors is just a special case of a customer roadmap. The Board wants to see that you are investing wisely to grow your business and reward their investment of time and/or money in the company.

The themes the Board wants to see are even higher level than those most customers care about, though. Typical Board themes might include:

  • Introduce flagship product to China
  • Expand add-on portfolio for core market
  • Enhance competitiveness with investment in analytics

I will cover different roadmaps for different audiences in more detail when I get to Roadmap Roadblock #4: One Size Fits All.

If Asked About Features

When asked (and you will be), avoid committing to specific features on specific dates. Every once in a great while, for a very large or strategic deal, it can make business sense to commit to a feature, even in writing. But this is a very rare situation. Giving in to this often will wreck your credibility, divert your roadmap, and make achieving your vision near impossible. (It can also cause the revenue from the deal to not be recognized until you deliver the feature.)

If someone asks if a given theme includes some pet feature of theirs, your answer should be something like "We’re looking at the best ways to [provide the benefit promised in the theme]. [Feature] is something we’re looking at, but I don’t want to tie my team's hands.

This answer focuses on the benefit you want to provide and reassures the customer you are looking out for them without promising a specific outcome.

Focusing Too Much on Features Rather Than Benefits?

If your organization’s roadmap is bogged down by specific features and commitments, feel free to set up a time to chat with me during my free office hours. You may also be interested my popular roadmapping presentation from ProductCamp Boston, or in Reqqs, the smart roadmap tool for product people.

Use your product powers for good.