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.

« Jason Brett on the 60-Second Business Case | Main | Reqqs Appears in Product Management Journal »
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.

Reader Comments (2)

I like the caution against determining the roadmap items and then retroactively attempting to identify an underlying theme. A coherent theme with clear benefit to users or buyers should drive most of the individual roadmap items.

I also think that the product's single, overarching value proposition should drive the themes for major releases. We should assess every theme and individual item in terms of its support of the value proposition.

Solving a hodgepodge of customer problems isn't enough - no matter how compelling the problems or how many customers possess them. I list "scattered value propositions" as a liability of naive left-brained approaches to making product decisions.

October 22, 2013 | Unregistered CommenterRoger L. Cauvin

Yes, your roadmap should tell a story about where you are taking the product, who you are serving, and how they will benefit. Excellent point, Roger.

October 22, 2013 | Registered CommenterBruce McCarthy

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>