Tag Archives: stakeholders

The Dirty Dozen Product Roadmap Roadblocks

In my last post on defining an MVP in corporate innovation, I talked about how best practices in garnering stakeholder buy-in for product roadmaps espoused by Bruce McCarthy can be used as a framework for the same when defining an MVP in an “internal” startup product. Here, with permission, is a re-post of his excellent post on the the “Dirty Dozen” product roadmap roadblocks, and in a way, they seem applicable to internal startup products as well.

By Bruce McCarthy

A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.

It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.

What Is A Product Roadmap?

A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.

A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.

A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

The Dirty Dozen

In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”

1. No Strategic Goals

If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.

Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.

2. Focusing on Features

A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.

Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?

3. Inside-Out Thinking

Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.

Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.

4. One Size Fits All

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.

Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.

5. Trying Too Hard to Please

That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.

Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.

6. Playing Catch-up

It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.

How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?

7. Not Getting Buy-in

The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.

If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.

8. Prioritizing on Instinct

Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.

Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.

9. Being Too Agile

Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.

Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.

10. Being Too Secretive

Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.

A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.

11. No Buffer

One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.

Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.

12. Over- or Underestimating

ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.

Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?

AN INVITATION

If your organization’s progress toward its strategic goals is slowed by any of these roadmap roadblocks, feel free to set up a time to chat with me during my free office hours. You may also be interested my hugely popular roadmapping presentation from ProductCamp Boston, or in Reqqsthe smart roadmap tool for product people.

Use your product powers for good.

Bruce McCarthy is a serial entrepreneur, 20-year product person, and sought-after speaker on roadmapping and prioritization. He is Founder and Chief Product Person for UpUp Labs, where he and his team are at work on Reqqs, the smart roadmap tool for product people.

Original article can be found here.

3 Things Product Managers Can Learn from Management Consultants

By Alex Joseph

 

House Of LiesManagement Consultants are probably one of the most ridiculed professionals in popular culture (only next to Wall Street bankers). They are often portrayed as ruthless and self-obsessed mercenaries in Dilbert cartoons (‘Dogburt, the Consultant’) or in ‘House of Lies’, a show which is based on the book titled ‘How Management Consultants Steal Your Watch and Then Tell You the Time’!

However, most executives admire management consultants (at least secretly!) and would love to hire top-notch consultants. After having worked as a management consultant and a product manager, I have noticed that many product managers are still skeptical of ‘the consultants’, as most PMs come from engineering or design. I understand some of the concerns, but also believe that many consulting skills (apart from the passion and drive) can be extremely valuable in product management roles. Here are three of them. (BTW, according to consultants, any list should only have three items, since people can’t remember more than three things!)

Gather Data Smartly

Good management consultants are extremely analytical and are obsessed with data. Though sometimes bordering on ‘analysis paralysis’, consultants are methodical in proving or disproving their ‘hypotheses’ and often find creative ways to find proxy data, when it’s not easily available. Though often derided as ‘POOMA’ (you know what that means!), estimating something hard to observe based on something you can observe can be extremely valuable in product management, since the most interesting market data is rarely presented cleanly in an analyst report!

In my first consulting project, the engagement manager asked me (as the most junior member of the team) to analyze the success stories of the four biggest competitors. It was a painful task going through 100+ customer testimonials, but when I clustered them into industries creating a heat map (in one chart), it was an eye-popping revelation how few use cases they actually address – despite their public claims of solving every problem under the sun. It was a classic case of ’80-20’ (as consultants would call it). The conclusions were not entirely surprising, but we then had solid data to back that up, instead of getting into the ‘my opinion vs. yours’ religious battles.

Synthesize and Present Top-Down

Product managers sometimes get lost in a ton of data. I recently watched a product manager presenting a proposal using many dense data charts – pulled from various analysts segmenting the market in different ways and presenting numerous possible features and functions. At the end of the long presentation, I asked him, “Where should we focus?” His answer was, “They are all attractive, and if we have the resources we should do them all.” Something a good management consultant would never say!

In consulting, the ability to structure the message using the Pyramid Principle is extremely important. The goal is to communicate top-down with the most important message first (‘tip of the pyramid’). The supporting conclusions are presented at the next level (following ‘MECE’), resembling a pyramid. This makes it easier for the reader (and especially for busy executives) to grasp the gist of the message instead of being bombarded with a lot of rambling details.

While telling the story, most use a variation of an approach called Situation, Complication, & Resolution to drive to a clear course of action. All of these are equally important for product managers while communicating a product vision & strategy. (Good presentation on applying Pyramid Principle for structured communication).

Gallery of management consultants

Get Stakeholder Buy-In

One thing in common between consultants and product managers is that they often have to ‘influence without authority’. It’s critical for consultants to get buy-in from executives by finding common ground. Most construct a stakeholder diagram at the beginning of the project to figure out the key people to influence. Contrary to stereotypes, no smart consultant will walk in to the big meeting with a heavy PowerPoint deck without getting buy-in privately from these decision makers (‘pre-wiring’).

Product Managers (especially in a big company) have to navigate complex organizational units. Many PMs, especially those from a technical background, seem to have the naïve belief that ‘the best idea will win’. ‘Politics’ may sound like a dirty word, but it’s nothing more than using emotional intelligence while dealing with organizations and executives (that are human too!), considering their collective self-interests.

Does this mean that all management consultants would become excellent product managers? Not always, but that’s a topic for another post.

Alex Joseph is a product manager and former strategy consultant and engineer. He is now an ‘intrapreneur’ in a large software company in Silicon Valley applying what he has learned from startups and corporates. Alex reflects on consumerizing the enterprise by beautiful mobile apps on Twitter and his blog.

The Case Against The Business Case

Note: This is part of 1 of a two-part series. Read part 2 here.

I have a confession to share.

I don’t like business cases.

At least, I don’t like the traditional way I’ve been taught to prepare a business case.

The conventional approach to pursuing a new product idea in an organization is to first prepare a business case. This is what we’ve always been told.

It’s what we’re taught in business school.

There are even competitions organized around it.

And it’s been reinforced every time we need IT and implementation resources for a new idea — the only way I could get those resources was by having a business case.

And this usually meant writing a big document, preparing a multi-slided presentation, or filling out some cumbersome form.

Now, I’ve written many business cases in my career. Some good, some excellent, many bad ones. Over the years, I’ve gotten pretty good at it.

But every time I did it, I hated it.

Here are just three reasons:

1. I always felt it was a time consuming exercise in guesswork.

For example, I’d be asked to estimate (guestimate?) market size and put multi-year financial projections. This is an exercise in future prediction. Something we’re not good at. No one is. I’m certainly not.

2. No one reads it.

People are busy. They don’t have time. Most want the elevator pitch.

I can’t count how many pitches I’ve been in where the execs flip to the end or simply ask you for the bottom line: what’s the opportunity, how much do you need, why do you need it, when do we see return. 60 seconds. Go.

This means a business case is nothing more than a 20, 50, or 100-page paperweight. Steven Blank famously called a business plan “a document investors make you write that they don’t read.” The same could be said for the traditional business case:

“A business case is a document executives make you write that they don’t read.”

3. Selling the business case is hard.

This is especially true in larger organizations. Lots of opinions. Lots of approvals. Competing agendas.

So ensuring internal stakeholder alignment and support is a big challenge. Lack of stakeholder support can be the biggest impediment to your product idea.

It’s important to capture and address stakeholder concerns as early as possible to ensure continued buy-in, and that everyone is on the same page. This is time consuming.

Part of that has to do with the realities of coordinating schedules. But also I’ve found this experience to be very ad hoc and messy. There has to be a better way.

[optin-monster-shortcode id=”tjtsmjhkd0zsxede”]

 

Now, maybe the way I’ve gone about creating and selling my business cases has been wrong. Maybe my situation is unique. Maybe others don’t find this process so wasteful. Maybe they’re more brilliant than I am in creating awesome business cases that always get approved. Maybe they work in organizations that have streamlined the process to pursue a new product idea.

Maybe I could test that hypothesis.

So I did.

I set about to find out what other product management folks’ experiences have been with the traditional business case process.

Over a three week period, I spoke with over 24 product professionals in companies across a range of industries, from small 50-person companies to Fortune 100 organizations.

All had experienced preparing and selling a business case for a new product idea. They had an average of 7 years PM experience, and had titles ranging from Product Manager to VP of Product Management.

Business Case Interview Map

Here’s what I found out.

Getting buy-in was rated as the #1 problem by every person except one. And that person rated it as a very close #2.

75% of them validated that maintaining stakeholder support and alignment is important, but a real challenge. Only 3 out of 8 pursed doing this in any kind of systematic manner. Most agreed it was pretty ad hoc.

Furthermore, creating the business case was acknowledged as time consuming, and a “necessary evil”.

Necessary evil? Whoa.

When I probed deeper into their feelings about the actual act of preparing a business case, I uncovered an outpouring of vitriolic frustration.

Here’s what some of them had to say:

  • “It’s a necessary evil. But it’s a wasteful process.”
  • “It’s a joke.”
  • “It’s just a lifeless Powerpoint deck.”
  • “It’s a manager fighting with an Excel spreadsheet for a month.”
  • “I’m forced to project revenues out of thin air. Putting revenue projections is a nonsensical exercise.”
  • “Financial analysis – it’s really just pretend.”

“Lifeless”. “Nonsensical.” “Pretend.” “A joke.”.

“Evil.”

Ouch.

And my favorite comment:

“You are describing my life!”

Yikes.

I feel safe to say this feedback clearly validated my entire hypothesis.

So what’s the solution?

This is not so easy to answer.

It seems to me we need a different way to pursue new product opportunities within our organizations.

One that will provide a systematic process to create validated business cases.

And one that provides us with tools and resources needed to obtain that validation.

One that will enable us to more systematically build and maintain critical internal support.

And one that allows us to spend more time with customers testing and developing product ideas than writing paperweights, while also providing an effective means to communicate progress internally for continued engagement, feedback and buy-in.

What has your experience been with business cases? How have you pursued a new product idea in your organization? Please share your frustrations or joys in the comments below!

Read part 2 here.

Before Product/Market Fit comes Opportunity/Company Fit

In his book, Running Lean, Ash Maurya presents a workflow for taking a product from idea to launch to Product/Market fit.

Ash Maurya workflow
In the Problem/Solution Fit stage, you are trying to answer the question, “Do you have a problem worth solving?” Ash breaks this down further into three questions:

  • Is the problem something customers want solved? (must-have)
  • Can it be solved? (feasibility)
  • Will they pay for it? If not, who will? (viability)

Problem/Solution Fit is pursued by capturing your business model hypothesis and then doing Customer Discovery via problem interviews and solutions interviews with customers. Once you’ve validated from customers that you have a viable problem worth solving, you move into Product/Launch Fit.

In the Product/Launch Fit stage, you are trying to answer the question, “Are you ready to learn from customers?” Key activities pursued here are reducing down your MVP, getting to Release 1.0, defining your key metrics, and continuous deployment. The purpose here is to lay the critical groundwork to maximize speed and learning for future iterations, and to establish “just enough” traction among customers to support learning.

Finally, in pursuing Product/Market Fit you are trying to answer the ultimate question: “Have you built something customers want?” This is where the rubber hits the road, and you’re validating your complete product. Identifying the “right” metric or set of metrics, prioritizing your feature backlog, and ensuring retention and getting paid are critical to the success of achieving product/market fit.

This Lean Startup workflow is one that could be used by a product manager pursuing a new product idea or looking to introduce an existing product into a new market. After all, the product manager in such a situation must be able to answer the same set of questions about who is the customer, what customer problem is the product trying to solve, and will enough customers care enough to pay for the solution. The product manager typically starts with some sort of informed hypotheses to answer these questions, which form the basis of the product vision. And the product manager must stay in close touch with customers to validate whether the product is truly something they want.

I feel there is one critical step missing in this workflow, though. It has to do with the unique situation product managers find themselves in versus entrepreneurs. Whereas an entrepreneur is trying to discover a business model that works, a product manager is typically an employee in an existing company already executing a repeatable and scalable business model. As such, the new product idea being pursued by the product manager could represent a change to the company’s existing business model. As such, because of the potential impact on the company’s existing business model, a critical consideration for the product manager pursuing a new product is whether the new product is aligned with the company’s corporate strategy.

In his book, Product Leadership: Creating and Launching Superior New Products, author Robert G. Cooper talks about the need for new product development efforts to be closely linked to the overall business strategy. In Beyond the Core, Chris Zook makes the case that the further a new product or business idea is from the core business — what he calls an “adjacency move” — the riskier it is and more prone to failure. What this means is that the more closely aligned the new product idea is to the company’s existing business strategy, the more favorably it will be looked upon by the company’s executives. This does not mean something completely outside of a company’s existing core will never be approved. But it does mean the bar to get that buy-in is much higher.

So in order for the new product idea to garner the necessary stakeholder support, its business case must be able to articulate the business opportunity it presents to the company, how it fits (or departs) from the company’s current business model and strategy, and the risks associated with pursuing it.

As such, Ash’s workflow can be modified as follows:

opportunity-company-fit

I call this stage Opportunity/Company Fit.

Critical questions for the product manager to figure out are:

  • Does the idea align with the company’s strategic goals?
  • Who do I have to convince to get buy-in?
  • Can I get a sponsor? Who?

Just like with using customer validation to achieve Problem/Solution Fit, I’m sure it’s possible to use lean principles to achieve Opportunity/Company Fit.