Category Archives: Business Cases

You either ROI or die

Let’s face it:

Accounting is boring as isht.

Assets. Liabilities. Cost basis. Accrual. GAAP. Cost principle. Double entry system…

This is boring

Finance is not much funner… In fact, it can downright make your head spin…

Liquidity. Risk tolerance. Asset allocation. Dollar cost averaging. Capital asset pricing…

What the heck is he talking about?Eh?

As a product manager, why in the world would you need to know how to do financial analysis?

Actually, there are some excellent reasons why. And you ignore them at the risk of your “brilliant” product idea dying a painful death.

First, the exercise of financial analysis forces you to think long and hard about the viability of your product idea.

It can help surface major issues early on or support your hunch that what you’re wanting to work on actually has some potential.

Second, if you’ve got an idea for a new product or new major feature, you’ll need to articulate to your stakeholders the market opportunity and ROI for it.

They’ll want to understand your assumptions about the market opportunity, and what will be the key revenue or ROI drivers.

Third, these financial analyses, once done, can serve as a strategic roadmap for execution. They allow you to track benchmarks, and you’ll be able to quickly assess where you are vs. where you thought you’d be.

So many product managers are unable to do this effectively. And, as a result, their product ideas die. Don’t let this be your fate.

The good news is you don’t need to torture a spreadsheet for days and weeks with crazy unfounded assumptions to produce some silly made up 3-year projection.

It comes down to 3 core financial analyses that need to be understood:

  • Market sizing
  • Net Present Value (NPV)
  • Internal Rate of Return (IRR)

I talked about market sizing — it’s importance and how to do it — in a previous post. So let’s talk about the other two.

Remember: When you go ask to have your product idea funded, it means you’re trying to convince people that YOUR idea is the best place for the company to spend its money vs. something else.

So it’s almost certain your finance department is going to be in charge of running the numbers on your product idea. This means it’s important to understand how the finance department is going to evaluate the financial merits of your product idea.

NPV and IRR aren’t really that complicated once you learn them.

So here’s a quick primer to help you start using them TODAY:

Net Present Value (NPV)

To understand NPV, we first need to talk about weighted cost of capital.

Since you’re eventually going to have to work with your finance department on the numbers, you need to understand your company’s cost of capital so you can ensure that you’re going to get the best deal possible.

A simple way to think about cost of capital is that it’s the cost of the money used to pay for funding a business endeavor, which is exactly what your product idea is, of course.

The money may come from debt, like a bank loan. In this case, the cost of capital is the interest rate the bank charges you for the loan, called the cost of debt.

Alternatively, the money may come from equity, like from investors. In this case, the cost of capital is the return these investors expect, called the cost of equity.

Most companies have a mix of debt and equity on their balance sheets.

So the weighted cost of capital is typically a weighted average of the cost of their debt and the cost of their equity.

Let’s go through a simple example:

  • Let’s say your company’s cost of debt is 3.5% and cost of equity is 10%
      • In other words, the company is paying 3.5% interest on its loans and its investors are expecting a 10% return
  • Let’s also say your company’s capital structure is 70% equity and 30% debt (i.e., the percentage of debt relative to the percentage of equity the company uses to finance its operations)
  • So your company’s weighted average cost of capital = (70% * 10%) + (30% * 3.5%) = 8%

How is this related to Net Present Value?

The weighted cost of capital is used to calculate the NPV of a business investment.

And the higher the cost of capital, the lower the expected profitability of your product.

So you definitely want to know what your company’s cost of capital is and what assumptions are going into calculating it.

Net Present Value (NPV) is a way of assessing the profitability of an investment by factoring in the present value of any future cash flows your product projects to generate over a given period of time, like 3 or 5 years.

Let’s explain via another simple example:

  • Let’s say you deposit your money in a savings account at your bank, and you earn 10% interest on your money.
  • So $1,000 today would earn you $100 in a year — in other words, your $1,000 today will become $1,100 next year.
  • This means $1100 next year is the same as $1,000 now.
  • So the present value of $1100 next year = $1,000 at the discounted rate of 10%.

Note that the interest rate you’re earning in your savings account is also called the discounted rate when calculating the present value of your future earnings.

So to calculate NPV, your finance department will:

      1. Calculate the present value of future cash flows your product is expected to generate over a specific time horizon (i.e., revenue over 3 or 5 years)…
      2. Subtract from it the present value of the initial investment needed for your product and any future expenditures projected to be incurred over the same time horizon

NPV = present value of future cash inflows – present value of future cash outflows

NPV is pretty easy to calculate in Excel. In fact, it has a formula for it.

Internal Rate of Return (IRR)

Now that you know what NPV is, this one is easier to explain…

The IRR is the interest rate at which the net present value of all the cash flows from an investment equal zero.

So the idea is that the higher an investment’s IRR the more desirable it is to undertake that investment relative to other projects (assuming all other factors are equal).

BTW, this is also pretty easy to calculate in Excel — it has a formula for IRR too.

So let’s say you calculate the IRR of your product idea is 92%. Is this good or bad?

That depends on the IRRs of the other projects competing for the same dollars!

Additional thoughts on NPV and Cost of Capital

The cost of capital should vary depending on the type of product initiative you’re pursuing.

If it’s truly a new product innovation, a higher number could be justified, since the project is going to be riskier, but may be worth it.

For a line extension, a relatively lower rate could work, since it’s relatively less risky.

Either way, do your homework, and then sit down with your finance counterparts and understand what values they’re using and why.

You don’t need to be a finance genius, but you do want to be able to negotiate with them intelligently. You may or may not win the day, but you will gain their respect, and at least everyone will be aligned on how to value your product idea properly and in relation to other projects the company is investing in.

Bottom line: yeah, finance may be boring, but it doesn’t need to be confusing, and it’s super important. Rockstar product managers understand that it’s well worth their time to learn, and get decent enough at it to be able to justify and defend their product ideas.

The one skill your boss wants you to have (and how to do it)

When I announced my new product management course, Idea To Revenue Masterclass, I asked the folks who manage product teams — Directors, VPs, SVPs of Product — what they’re looking for in their product managers.

The responses I got were eye openers.

Here are some of the replies I got, with certain parts bolded by me that I think are super important:

“A well balanced product manager knows how to take a concept from ideation to delivery. I find some are strong in one but not the other.”

“Our product managers need to learn to drive product innovation by deeply understanding the ecosystem in which our customers operate, address the most pressing customer needs, and ensure we deliver business and customer value and drive company revenue.”

“Currently, our PM team is not leading. They mostly focus on fixes to the current products. They need to be more strategically driven, and be able to size the market opportunity for new ideas. As a result, to be honest, our executive team is not comfortable empowering our product managers to make decisions, and so priorities keep changing constantly.

1285302121_long-jump-fail

 

In other words, they want product managers who can be strategic product leaders that can drive innovation and deliver business results… not just be backlog grooming sprint release operators.

Having worked with 100s of product innovators and numerous software and digital products and services, I’ve learned that the best product managers think and act beyond tactical activities like backlog grooming, sprints, requirements, stories, releases, user testing, etc.

These activities are important, but in and of them they don’t drive innovation and don’t deliver business results that matter.

The best product managers think and act strategically — that is to say:

  • They think about and pursue monetizable market opportunities.
  • They think about and actively work at tying their activities to business results that matter — acquiring new customers, increasing LTV or ARPU, speeding time to market, etc.
  • They think about the “whole product” — not just the core software app itself, but also how to market, sell, deliver and support that product to customers — and execute accordingly.
The Whole Product

Product Canvas – downloadable here

It’s this strategic perspective that then drives their tactical day-to-day activities.

In this post, I’m going to talk about one of the ways — one of the most important ways, actually — that the best product managers impact business value:

Validating the market opportunity for a product idea.

The best product managers know that to pursue any product idea it must be a problem worth solving. In an earlier post, I talked about how there are 3 criteria any product idea must satisfy in order for it to be worth pursuing:

  • It must solve an urgent problem for a customer.
  • The problem must be pervasive — that is, enough customers must feel that pain or have that need.
  • Customers must be willing to pay to have the problem solved. Or, more specifically, they must be willing to buy your solution to their problem.

This is what it means to have a monetizable market opportunity. And being able to identify these opportunities (and then execute on them) is exactly what the product team leaders above are looking for in their product managers.

Unfortunately it’s a big area where many product managers fall short.

Why is it important to analyze the market potential for a product idea?

Because quite simply, if enough people aren’t experiencing the problem and are willing to pay for your solution, then the market potential for your product idea isn’t big enough, and it’s not worth pursuing it. Period.

viable_product_ideaSo you need to find out before investing considering capital and resources in developing the product or capability whether there may be a market for it.

Also it:

  • Establishes whether the business opportunity for your idea is reasonable.
  • Informs how you look at, analyze, understand, and segment the market.
  • Demonstrates an understanding of your customers’ pain points and the value of your solution.
  • In turn, informs how to enter the market — your go-to-market strategy, pricing model, etc.
  • Provides optics for the growth of your product — a sounding board to measure your financial model and your progress against it.

This isn’t just for brand new product ideas alone. It applies to new feature ideas for existing products and other product expansion ideas as well.

Any new feature or capability must deliver both customer value and business value. There has to be some clear ROI for adding a new feature to a product. Perhaps the new feature will help up-sell existing users to a higher pricing plan. Or maybe help accelerate new customer acquisitions in your target market segment. Or reduce churn and increase lifetime value. Or maybe it will help improve customer satisfaction leading to increased retention.

Your company has a choice of whether to focus its resources on developing feature A or feature B. In fact, it has a choice of whether to have its resources focused on your new feature idea or something else entirely.

So it’s important to vet whether there’s enough of a market demand for that feature before investing engineering cycles building it.

There are several common mistakes product managers make in estimating market potential. Let’s talk about these and then go through specific examples of how you can calculate the market potential for your product idea.

Common mistakes in estimating market size

Your market is NOT “everyone” or “anyone”, as in “everyone who drives a car”, or “every business that needs a CRM”, or “anyone who uses social networks”, etc.

Heck, the market for this blog isn’t “everyone who reads blogs”!

In fact, it’s not even “every product manager” out there. If you’re a product manager for a hardware product, it’s nice to think there may be nuggets in these posts that could help you, but I’ll tell you straight up I don’t specifically target you. So if you find zero value in these posts, that’s cool with me.

Even for a new feature for an existing product, your market potential may not be “all our existing customers”. For example, not all customers using your messaging service may be interested in archiving old messages.

You need to drill down and get specific about the true size of your market. Otherwise, your executives and Board will question the validity of your product idea — and, frankly, your credibility.

To make this super tangible, let’s talk through how you can size the market for a new product and a new feature.

Assessing the market size for a new product

The most common way folks do this is what’s called the “top-down approach”. This approach uses a broad market size figure and whittles it down to the target market.

It typically goes something like this:

  • Let’s say your product is an analytics algorithm that can decide the sentiment of a Twitter stream.
  • You find that IDC (or Gartner, whatever) says the market for big data technology services is $6.2 billion. You estimate that the portion that’s for sentiment analytics software is 20% = $1.24 billion.
  • With your existing sales and marketing channel, you believe you could realistically reach 25% of this market = $310 million.
  • But there are 10 other competitors in that same reach. So assuming you can capture 15% of the market, your target market share = $46.5 million.

Now, if you read that and are feeling uncomfortable, yeah, you should.

‘Cos it sounds squishy, right?

That’s why I’m not a big fan of the top-down approach:

  • The broad market size figure used as the starting point in the top-down analysis often includes different market segments, so it’s easy to forget to take some of these out of the estimate.
  • You’re extrapolating without direct customer validation. So top-down can come off as a bit optimistic (and even fuzzy).
  • When extrapolating, you’re typically using a percentage off a very large number, like 1% of a billion dollar market, but it doesn’t take into consideration which 1% or how you’ll get this 1% with your specific product.
  • Plus, how do you know if a 1% market share is the right success criteria for you?

As such, the top-down method can give you a false sense of comfort.

(Plus, smart execs will see right through it and tear it apart.)

Instead, a “bottom-up” approach is better. This approach builds up the total addressable market by using the main variables of the revenue model — typically total number of potential customers multiplied by what they typically spend or are willing to spend.

It requires more effort, because you’re evaluating where your product can be sold, the sales of comparable products, and the slice of current sales that you can carve out.

(BTW, this is where your customer persona and primary market research really comes in useful. You can use them to identify how many customers are in your target market, and extrapolate from there.)

Let’s go through an example:

Your product is an app that helps people play basketball more regularly by helping them find the right place, time and people.

You’ve discovered that people pay to book time at basketball venues, and your idea is to charge these venues a fee for referring basketball players who use your app.

You interview 10 basketball venues, and discover they typically get 100 bookings per month, each booking consists of 10 players, and each player typically pays $50 to play.

So the total value of monthly bookings at any given venue = $50 * 10 * 100 = $50,000 or $600k per year. And if there are 2,000 venues in your target market, that’s a total market of $1.2 billion.

You find that 70% of venues (1,400) have already signed deals with your competitors, leaving you with 600 unsigned venues. You believe you could steal 10% (140) of already signed venues — so if you signed up all 740 (i.e., 600+140) of these venues, that’s a serviceable market of $600k * 740 = $0.44 billion or 37% of the total market. (It may reasonably take several years to do that, of course.)

You feel confident all 10 of those venues you had interviewed could be initial customers. You extrapolate that there are about 200 venues just like those, i.e., they fit your customer persona. You could target them in the first year, giving you a target market of $120M (27% of your serviceable market and 10% of the total addressable market).

While there are undoubtedly some assumptions inherent in this analysis (and many dependencies to achieving those targets), this type of analysis is much more useful.

For one, it gives you more grounded assumptions to use to extrapolate to the broader market. It’s less likely to include non-addressable revenue since your basis is to start from your primary market research. Finally, it forces you to consider how you’ll be able to attract and acquire customers — for example, you’d love to sell internationally, but if that’s unrealistic for several years, you can’t really factor that in. On the other hand, you can focus your go-to-market efforts specifically on targeting that initial $120M in the first year.

You can also play with the variables to get a sense of best-case and worst-case scenarios. For example, what if you could steal 20% of already signed venues? Or only 5%? What if there are only 100 venues like the 10 customers you interviewed? What if it takes longer to acquire any of those 600 unsigned venues?

Assessing the market size for a new feature

Now, for a new feature or capability for an existing product, how you analyze the market size depends on your goals for the new feature — things like accelerate new customer acquisition, up-sell existing customers, penetrate an adjacent market segment, etc.

For the sake of simplicity and illustration (and because this post is getting pretty long), let’s assume the goal is new customer adds — e.g., this feature is the key missing ingredient that has prevented new customers from purchasing your product till now.

Let’s say your product is targeting a $50 million market and currently generates $5 million in revenues. It’s been successful with early adopters, but now you want to expand within your target market to “early majority” type customers (in the technology adoption curve).

You’ve identified a new feature that your product would need to have to attract this group of customers, and your problem hypothesis testing validated the pain point it solves. From this work, you’ve built a customer persona to target for the new feature, and through further market research and analysis, have identified that 25% of your product’s current target market fit that persona (i.e., they have the same problem).

Your total market opportunity is 25% of your product’s target market * your product’s price (assuming no change).

You believe it could be possible to capture 10% of those customers in the first year. So your target share of market is 25% of your product’s target market * your product’s price * 10%.

Again you could play with the variables for best-case/worst-case scenarios. For example, what if you captured only 5% in the first year? Or 20%? What if it only 15% of your product’s current target market fit the persona?

Once you have your market size, what next?

Play around with the assumptions and variables in your analysis. For example, try different pricing levels, or vary the percentage or number of customers.

This analysis shouldn’t take you very long — you’re merely trying to estimate the opportunity to get a quick sense as to whether there’s a market opportunity for your product idea. If you’re spending hours or days torturing a spreadsheet, you’re spending too long on it.

Of course, you don’t know definitively whether customers will actually validate your product idea, let alone buy it. But you want to do this exercise at this stage because you’re essentially trying to answer if there are enough customers in the market with the problem you’ve identified, and how much revenue you could potentially target if they’re willing to buy?

In other words, is it big enough? If the market opportunity is too small, if there aren’t enough monetizable customers, it’s not worth going after, and you’ll be faced with a pivot. (And a pivot isn’t a bad thing.)

* * *

The best product managers understand that to really drive innovation and deliver value to their businesses they need to be thinking and acting strategically.

As part of that, they understand they need to be testing and validating whether a product idea is worth pursuing before investing major capital, budget or resources on it.

A critical part of that validation exercise is assessing the market potential for a product idea. Doing so exposes important assumptions inherent in the initial product strategy hypothesis. It helps product managers justify the product idea to themselves and to their internal stakeholders, and serves as a reality check for the product idea.

This kind of analysis it NOT about arbitrarily picking a large number out of thin air and then working some Excel magic to rationalize the number. As I’ve shown, there’s a grounded way to approach it.

And, as a result, should the market opportunity for the product idea have potential, it allows for a more actionable way to pursue it.

As Ash Maurya has correctly said:

“While we all need a ballpark destination to justify the journey, it’s not the destination itself but the starting assumptions and milestones along the way that inform whether we are on the right path or need a course-correction.”

To your product success!

Do You Have A Problem Worth Solving?

In order to pursue any product idea — a new product, or a new feature for an existing product — you must make sure it’s a problem worth solving.

If it doesn’t solve a tangible, real problem that lots of people are facing, and are willing to pay to have solved, it’s not worth spending your time on it. Move on to your next great idea.

So how do you go about figuring out if your product actually solves a problem that’s worth solving?

And what makes a problem worth solving?

In their book, Tuned In, authors Craig Stull, Phil Myers and David Meerman Scott talk about this in detail.

In order to know whether your product idea solves a problem that’s worth solving, it must it must satisfy the following criteria:

  1. Is the problem urgent?
  2. Is the problem pervasive?
  3. Are customers willing to pay to have the problem solved?

These three questions need to be answered before investing a ton of money or resources into developing and launching your product.

If the answer to any of these questions is “no”, then you need to pivot.

Let’s talk about each of these in turn.

Is the problem urgent?

Any product idea you’re pursuing must solve a problem people really care about. It needs to be a real pain point, a critical need, or a super important job for them.

The pain may manifest as costing them money, time, resources, effort, credibility, or some other significant inconvenience or frustration. Even perhaps emotional or physical pain.

The need or job could be social (look good, gain status, etc.), emotional (feel better, feel more secure, etc.), or functional (an important job that must get done).

If it’s truly a pain point or priority need/job, people will have expended time or effort to have tried to solve the problem. They may even have “hacked” together their own solution, or spent money on trying to solve it. This is what’s meant by the problem being urgent.

But why does this matter? Why is it so important to validate the urgency of the problem?

Because nothing is more frustrating than working yourself silly trying to solve a problem that either doesn’t exist yet or that people describe as “not a big deal”.

Here’s an example:

I hate taking out the trash.

I have to do it 2x a week, put it out on my driveway in the evening so the garbage truck can pick it up first thing the next morning.

I especially hate doing it in the winters when it gets really cold.

Is it a job I need done?

Most definitely!

Is it a pain?

Yes!

But have I done anything to solve my problem?

No.

I keep complaining about it. But I’ve done nothing to change the situation.

It’s just not a priority for me — it’s just not urgent enough.

As product people, we’re naturally wired to look for solutions. So we quickly and easily fall in love with our solutions.

(Thanks, Ash Maurya, for representing this first on your Lean Canvas.)

But we need to care about PROBLEMS.

So if you’ve got a product idea, you need to first care about your customers’ problems.

This is true whether you’re thinking about your next new feature or a wholly new product.

Remember:

Customers don’t care about your solution. They care about their problems.

Just make sure the problem is an urgent one.

Is the problem pervasive?

The urgent problem needs to be one felt by a large enough number of people to make it worthwhile for you to develop and sell your product.

Why?

Say one product will cost $1,000 to make, and only two people in the whole world will pay you $10,000 each for it, and another product costs $10,000 to make, but 10,000 people will pay you $10 each for that one.

Which product is better worth your time?

Quite simply, if enough people aren’t experiencing the problem, then the market potential for your product idea isn’t big enough, and it’s not worth pursuing your product idea. Period.

Even for a new feature, you need to size the market opportunity for it.

Your company has a choice of whether to focus its resources on developing feature A or feature B. In fact, it has a choice of whether to have its resources focused on your new feature idea or something else entirely.

So no matter whether you’re pursuing a new feature or a new product, make sure it’s solving a problem that’s pervasive.

Are they willing to pay to have the problem solved?

This is critical — you may find a lot of people are complaining of the problem you’ve identified… but are they willing to pay to have it solved?

Most people have all kinds of problems that they’re just not willing to pay money to solve.

For example, I may whine about taking out the trash, especially in the bitter cold of winter.

And it becomes an urgent enough problem that I finally get my teenage son to do it. (Hey, it builds character.)

And lots of other people may be doing the same thing as me.

But neither they nor I are willing to pay to have someone come to our house twice a week to put the garbage out by the curbside.

Even for an existing product, a new feature must be able to create some tangible business value. Will customers pay for the new feature? Will the new feature justify a higher price for your product? Will it increase customer lifetime value, or accelerate new customer acquisition?

As long as you’re in a profit-making enterprise, it’s worth solving an urgent and pervasive problem only if the people with the problem are willing to pay for your solution.

Are you done? Not quite…

In order to decide whether to pursue your product idea or not, you need to consider a couple of additional things.

First, it’s possible that your company may have (likely has) a point of view (spoken or unspoken) on what it considers worthwhile revenue opportunities.

For example, at a $7 million company, a $50k opportunity could get the CEO’s attention…

…But at a $500 million company, anything less than $250k may not get much interest.

If so, it’s important to consider whether your product idea meets this threshold to be worthy of consideration.

Second, your product may have specific strategic business goals, such as driving new customer revenue, or generating expansion revenue from existing customers, etc.

If so, you’ll need to evaluate whether your product idea contributes in a meaningful way to achieving those goals.

In other words, is there enough monetizable value in your product idea?

If your product is currently generating $50 million in revenue with a goal to grow 15% in the next year, and you estimate your product idea could drive $500k in additional revenue, that means it will contribute less than 7% toward that goal.

Whether that’s good enough will depend on how it compares to other ideas that contribute toward achieving the goal, or whether it can be combined with other ideas in some rational way as part of a theme — then it will come down to how the theme in its entirety contributes toward the goal.

So to recap:

To pursue any product idea, make sure it’s a problem worth solving.

This means the problem must be urgent and pervasive, and your target customers must be willing to pay to have the problem solved.

Furthermore, your product idea must have enough monetizable value to contribute meaningfully toward your company’s strategic goals.

Fortunately, it’s not that difficult to learn how to do this. 🙂

The secret ingredient to getting product innovation done

So you’ve probably heard of “earlyvangelists”.

(No? Read this post by Steve Blank, who coined the term.)

In Lean Startup circles, we hear a lot about finding this special breed of customers. Why?

Because they’re the ones willing to make the initial bet on the startup. They’ve bought into the startup’s vision and potential. They’re not just buying a version of the product, but the entire vision of the startup. This is what keeps them committed even if the startup screws up a few times.

They are the true visionary customers talked about in the technology adoption lifecycle.

So a lot of focus is put in identifying, finding and nurturing these earlyvangelists in the form of testing customer and problem hypotheses, testing solution hypotheses, finding problem/solution fit, creating an MVP, and getting true customer validation by finding a handful of customers who are actually willing to pay you for your solution — the “earlyvangelists”.

Now, juxtapose this with traditional product management.

When I started out in product management, I was introduced to the technology adoption lifecycle. I read about it in books. People talked about it in conferences. “You must find those visionary customers and early adopters,” experts said in their presentations.Cool.

Cool.

Problem was: no one taught me how to get these magical customers.

Business school didn’t teach me how to get earlyvangelists.

Product management didn’t teach me how to get earlyvangelists.

Instead, what I was told was to develop a business case. Write an MRD. Create a business plan.

Business school told me I was supposed to do this. Smart consultants and well-meaning senior executives and mentors reinforced this. Elaborate PMO processes required this.

Want resources for your product idea? Show us your business case.

So what’s wrong with that? On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.

On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.

Shareholder returns, customer value, and employee paychecks depend on the successful execution of this business model.

So the company needs to evaluate its investments in terms of risk to this business model. A company needs to know whether to dedicate its resources to project A or B. To do that, it needs to know which has the better payoff.

Good intentions.

But here’s what actually happened.

Product managers began spending loads of time writing multi-page MRDs, crafting business case slideware, and crunching through multi-year financial “projections”. These documents were filled with unvalidated assumptions or HiPPO driven convictions.

“How the heck can I figure out whether customers will buy the product before it even exists?” they’d ask. “How can I figure out how much money it will make when no customer has bought it yet?”

The product manager would torture the spreadsheet, try and convince finance of adoption rates and growth trajectories based on mere guesses, and go to Engineering/IT for estimates.

“You need to give me requirements,” Engineering would say. “If they’re not documented, there’s no way I can give you estimates.”

So the product manager would then start writing an MRD / PRD / BRD / <stick your 3-letter acronym here>. Ah, the joy…

And under pressure to get “accurate” estimates, they’d pack in as much detail as possible, essentially guessing at the features and functionality that would be needed.

And every minute the product manager spent preparing the business case, writing the MRD/PRD or torturing the spreadsheet was valuable time not spent with customers.

So it’s no surprise that in a recent survey filled out by over 40 product managers who enrolled in my online course, Idea To Revenue Masterclass, they listed the following as their biggest product innovation challenges:

#1 Biggest Innovation Challenge: Testing product ideas without having a product.

Meaning testing with both customers and internally within their organizations. They need ways to test their understanding of the market, as well as evaluate the revenue potential for a product opportunity, but without having a product already.

“My number one product management challenge is creating business requirement documents on new products and demonstrating a return on investment for 1/3/5 years without releasing the product.” — survey response

#2 Biggest Innovation Challenge: Alignment, buy-in and communication.

How many people does it take to change a lightbulb?

(Or maybe the question is: how many people does it take to get approval to change the lightbulb? Ha!)

This challenge is a close second to the first. Product innovators are challenged with communicating product strategy to get buy-in, getting executive support for their product plans, aligning teams within the company to support new products, and managing communication across multiple stakeholders.

“In a growing organization, with lots of ‘people of interest’, communicating what you are building and why is a huge challenge.” — survey response

In a blog post titled, Why Internal Ventures are Different from External Startups, Henry Chesbrough argued:

The internal venture must fight on a second front at the same time within the corporation. That second fight must obtain the permissions, protection, resources, etc. needed to launch the venture initiative, and then must work to retain that support over time as conflicts arise (which they will).

#3 Biggest Innovation Challenge: Resources.

We can never have too many resources, can we? 🙂

Working with resource constraints is a fact of life. But product innovators feel this acutely so.

They’re pushed to accelerate time to market, yet are challenged with selling the business case for the right mix of resources to do just that.

And, of course, this leads to the chicken-or-egg dilemma from challenge #1:

We need a product to test whether customers value it…

But we need customer validation in order to get the resources to build the product!

“My #1 product planning challenge is getting and retaining key resources to minimize time to market consistent and aligned with company priorities.” — survey response

So what’s the solution?

This brings us back to “earlyvangelists”…

Lean practices can and should be adopted and adapted to pursue product innovation inside companies. But product innovators actually need to find two types of earlyvangelists:

  • Earlyvangelist customers.
  • Internal stakeholder advocates, a.k.a. “internalvangelists”.

One of the biggest factors that can derail any new product endeavor is lack of internal support. In product innovation, lack of stakeholder traction can often be a bigger roadblock than customer traction.

These stakeholders not only may have access to essential information and resources but also be able to influence key decision makers whose support is critical to the success of your product initiative.

The larger the organization you work in, the more stakeholders you’re likely to have. It’s important to identify who these folks are and make sure you’re not only bringing them along but in fact converting them into advocates — evangelists — for your product initiative.

Product management didn’t teach me how to get internalvangelists.

The good news is that a lean approach that fuses customer development methods with sound product management practices can be used to get early customers AND build the business case, create alignment, and cultivate internalvangelists iteratively.

Lean product management can get you “earlyvangelists” and “internalvangelists”.

Here’s an example:

Customer learning driven investment strategy

The approach calls for spending plenty of time with customers in a methodical way, systematically testing assumptions at each phase, while also having regular check-ins with folks internally.

Each stage is informed by learnings from the previous stage — “mini business cases”, if you will, at each milestone, instead of wasting time writing a big tome of a business case up front.

Requirements for delivery need only be done when there’s a clear signal to do so. For example, if you find there’s no problem/solution fit, no need to write detailed requirements to build out an MVP or do financial projections. Only on achieving problem/solution fit does it make sense to spend the time doing those activities.

This customer learning driven approach makes for a more market-informed investment approach to the product strategy. This makes it easier to garner, maintain and accelerate stakeholder buy-in, because:

(1) Each investment stage is grounded in real customer data, resulting in less assumptive and more empirically based investment asks.

(2) Smaller continual investments that deliver continuous tangible ROI throughout the process are easier for folks to digest and support than a large bloated one upfront.

(3) Stakeholders continually feel involved in the process, increasing confidence to persevere.

There are surely other variants to this approach. The point here is that lean principles can be fused with sound product management practices to:

  • Test product ideas without a product.
  • Build the business case iteratively.
  • Get alignment and buy-in, and create internalvangelists.
  • And get those magical earlyvangelists!

Create Your Business Case Using Customer Development

The traditional product innovation process of writing a business case with long-term financial projections, then writing a big PRD, then doing development and launch your product doesn’t work.

At the 2015 Modev MVP and the Lean+Agile DC conferences, I presented an actual example of using Customer Development and Validated Learning to test a new product idea and build its business case, which produced far more impactful results.

Here my slides from those talks (same set used for both):

 

5 Steps To Validate Your Product Idea Without A Product

Here’s a scenario:

Top Exec at your company comes to you and says, “Yesterday, I was talking to Big Industry Player and they mentioned how they have Shiny Object. I think we should have Shiny Object too. How fast can we get it done?”

Sound familiar?

At last weekend’s ProductCamp DC event, my co-founder and I hosted a session called “Tales From The Product Frontlines”. Our first topic was about this very scenario, and it so energized the participants that it took up 30 of the 45 minutes we had been allotted!

During the session, we asked product people questions like:

  • What do you do now to vet new ideas, whether your own or from some other source?
  • How is that working?

Most folks talked about having some sort of governance structure, such as an Executive Steering Committee to vet new ideas based on some established criteria. Many talked about the need to create a business case, and some advocated that Product Management is best suited to do that, regardless of where the idea came from. Yet, after the session, every person I spoke with told me they felt writing a business case was a total waste of time.

Why is this? Because the old ways just don’t work.

Pragmatic Marketing’s 2013 survey revealed that product managers spend over a month’s worth of time writing business cases. These business cases are filled with highly assumptive 3- or 5-year projections that are used to support significant investment asks. It’s no wonder we hate this — we’re staking our professional credibility on these unvalidated assumptions!

The problem is we were never taught a systematic method by which to obtain the crucial information needed to inform a business case.

So what’s the solution?

Let me pause here to say if you’re hoping I have a magic secret for quickly validating a product idea, or if you’re totally married to writing business cases or MRDs, then stop. This post isn’t for you, because:

  • It’s different and requires you to THINK.
  • It’s hard work.
  • It can take some time to get results.

But it works. I’m writing for the 10% who (1) realize I’m telling the truth (that the old ways just don’t work), and (2) are willing to try something different.

(Thanks, Kevin Dewalt, for putting this so well, and forgiving me a little plagiarism!)

The solution is validated learning

Bottom line is spending time writing a big document is a colossal waste of time. Instead, focus on validated learning.

Because any new product idea is based on assumptions, those assumptions need to be validated. This can be achieved by formulating testable falsifiable hypotheses around the riskiest assumptions, and rigorously testing these hypotheses.

The process of validation can be outlined in 5 steps. Each step generally follows this meta-pattern:

  • Formulate a testable falsifiable hypothesis.
  • Test the hypothesis.
  • Analyze results and learnings.
  • Decide to pivot or persevere.
  • Repeat.

I’ve used these this process to validate ideas for software products, but I imagine it could be adapted for any product concept. (So give it a try and let me know your results!)

1. Write down your customer hypothesis.

Most folks typically start with the solution first, which is the wrong place to start.

You need to take a step back and think very deliberately about your customer. This is true whether you’re pursuing adding a new component to an existing product, or are pursuing a truly new product.

Note, by customer I mean the individual who will buy your product. Even in B2B, you need to think about the specific individual or set of individuals to whom you will need to sell your solution. That’s your customer.

2. Write down your problem hypothesis.

What problems does your idea solve for the customer? One way to do this is to think about the goal or job the customer is trying to accomplish. For example: “I believe [customer] has a problem achieving [goal].” Or: “I believe [customer] is trying to accomplish [job], because [desired benefit].”

I typically use the Product CanvasTM to do this, as it allows me in a focused manner to break down the problem domain into discrete problems, and then formulate hypotheses around what I believe to be the top problems that my solution absolutely has to solve for first.

3. Validate your customer/problem hypothesis.

Now it’s time to test your hypothesis. You do this by talking to folks you believe meet your target customer demographic.

Be sure to define a minimum success criteria, which is the minimum amount of data you will need from the test to justify investing more time, effort or resources into proceeding with the idea.

When you’ve met your minimum success criteria, analyze your data, and decide whether to pivot or persevere.

A pivot is a fundamental change in direction of your business model or product strategy. You face a pivot when your hypothesis has been invalidated (i.e., proven false).

At this early stage, you could expect a pivot in terms of a change to your target problems, your target customer, or both. This may mean going back to step 1 or 2.

However, if the results of your test prove (i.e., validate) your customer/problem hypothesis, you may decide to persevere, and move on to step 4.

4. Validate problem/solution fit.

Now that you’ve validated your customer/problem fit, you need to test whether your idea is a potentially viable solution to the customer’s problem.

There are many ways to go about this, but nothing really beats creating a visual representation of your envisioned solution in the form of a wireframe or mockup. To keep things simple and minimize work, I look to design a representational screen or flow for each discrete problem identified on my Product Canvas and validated via the previous steps.

The primary goal of this stage is to garner early customers who endorse your solution vision, and would be willing to use (and ideally pay for) an early version of the product. You’re also looking for directional feedback to identify the “right” handful of features to build for these early customers to prioritize your product development.

Formulate hypotheses around your screens, define your minimum success criteria, then reach back out to the customers you had interviewed earlier and demo the screens to them. Also try to mix in some new folks who fit your target customer demographic.

When done, just like you did at the end of step 3, analyze your data and decide whether to Pivot or Persevere. At this stage, you may pivot on the solution, the problem or even the customer. Or, if you’ve validated your hypothesis, you may have problem/solution fit, and can move on to step 5.

5. Validate your solution via an MVP.

There are many misconceptions about what constitutes an MVP, and I’ve written about these before. In short, an MVP is an actual product that attempts to deliver real value to customers.

It’s “minimum” in the sense that it’s an attempt to deliver the absolute necessary set of features or capabilities needed to solve the customer’s problem for which the customer will pay.

A primary outcome of the previous step is being able to understand your customers’ problems at a granular level, which helps prioritize the initial set of features to build. This drives the definition of your MVP.

Once again, formulate a set of testable hypotheses to ensure you’re continuing to drive your product development based on validated learning. Depending on the complexities of the problem and solution, and the nature of my target customer, I may opt to first demo the MVP before actually delivering it. The results of your MVP test will again determine whether to persevere or pivot.

If you’ve got this far, you’ve validated critical components of your product idea. It doesn’t mean your idea is guaranteed to succeed, but you will have gained a far better understanding of the market opportunity, allowing for a far less assumptive and much more robust business case for your new product idea.

Using Customer Development To Create The Business Case For Your Product Idea

Many of my product help calls are from folks frustrated with being able to pursue a new product in an existing company.

They complain about how difficult it is to secure resources and garner internal stakeholder buy-in.

If you find yourself in this position, congratulations!

As painful and frustrating as it is, many successful product people I’ve met have gone through exactly what you’re experiencing — including me!

The problem is the way we’ve been taught to pursue this — to first write a business case, business plan or MRD — just doesn’t work. The fact is, people think writing a business case is a waste of time and hate it.

And no where are we taught how to cultivate stakeholder support.

Like it or not, every project in an existing company, regardless of the size of the company, needs an internal champion or sponsor.

Lack of stakeholder buy-in can be the biggest impediment to your product no matter how good your product idea may be.

So it’s no surprise really that product people are frustrated.

 

So here’s a new process I’ve been following that’s worked much better for me:

Using Customer Development To Create The Business Case For My Product Idea

In a nutshell, I deferred asking for major dollars and resources until I absolutely needed to. I used a series of validated learning milestones to build momentum internally and to build the case for investing in my product idea.

Here’s what I did:

1. I quickly sketched out my product strategy on a 1-page Product Canvas. No wasting time writing a multi-page document no one is going to read.

2. I decomposed the product strategy into critical learning milestones meant to answer the most important questions in my product strategy:

  • How does our target customer describe the problem?
  • How are they solving it today?
  • Why is that solution not working for them? In other words, why is the problem still a pain for them?
  • How can we know before we invest a lot in development, sales and marketing that the solution we’re thinking of building really solves the problem?
  • How quickly can we get our first customer?
  • What are the most important features we need to have in our go-to-market product?

3. I figured out what’s the least amount of work I need to do to maximize my learning for each milestone.

4. I broke down my investment need into these milestones, showing how ROI could be tangibly achieved based on measurable results.

Here’s what the investment plan looked like:

validation_workflow

In the past, I would have asked to spend money on 3rd party market research (four to five figures), a design agency to craft the user experience (five to six figures — ugh!), a usability study (five figures), and a large development team (many figures).

This would be costly and take a long time before I would have delivered the product to a single customer.

And it’s a tough business case to make.

Instead, because I had broken down the plan into these learning milestones, I was able to easily accomplish the first two milestones by spending little to no money at all.

The first was simply my time, so required no money.

To validate our solution hypothesis, I used Balsamiq to sketch a handful of the key screens of our solution. Total cost was $79 for the tool and my time.

When we were ready to design the user experience, since we didn’t have an in-house designer, we commissioned a cracker-jack freelance designer — way cheaper than hiring an expensive design agency, and way faster. It got the job done.

(If you happen to have an in-house designer or design team, awesome — use them. Your investment “ask” may only be some of their time.)

In this way, I was able to use the resources I had at my disposal for as long as I could to create traction.

This approach not only allowed me to conserve precious funds and resources, but also allowed me to be less assumptive and more data-driven in identifying my investment ask at subsequent stages.

It also enabled me to not only build early traction with customers, but also have them help me define the minimum feature set we’d need to develop to go to market — labeled as the Minimum Sellable Product (MSP) in the picture above.

Here are the benefits that resulted:

  • Instead of writing a massive business case based largely on guesswork, I needed only to sell a bunch of mini-business cases. Way quicker and easier to do.
  • Each mini-business case was informed by the learnings from the previous stage, making each subsequent mini-business case better informed, more robust, and an easier sell.
  • The product strategy was informed by real market insights. (What a product manager needs to do anyway!)
  • I had a customer driven product roadmap that was tough for anyone to dispute as it was informed directly by tangible customer insights, which defined what went in our MVP vs. MSP vs. roadmap vs. nice-to-have.
  • This enabled our product development efforts to be more focused, as I had all the ammunition I needed to fend off arbitrary new feature requests that risked derailing our product development.
  • Because of our “co-innovation” approach with our customers, we were able to get “earlyvangelists” that we could leverage to generate momentum for our broader market launch. Customer Development in concert with Product Development!
  • All of this made it much easier for me to garner, maintain and accelerate buy-in from my internal stakeholders, because:
    1. My plan showed a clear milestone-based investment plan with the ROI to be gained at each phase.
    2. Smaller continual investments are easier to digest and support than a large upfront one.
    3. Each investment stage was grounded in real customer data, increasing confidence in pursuing the product.
    4. My stakeholders felt involved in the process, as I made sure to keep them informed and provide them an opportunity to provide feedback.
    5. This, in turn, kept me one step ahead of any potential concerns they may have had, and I could make sure to address them at a future stage.

Different worldviews of your product

Ash Maurya published an excellent post he titled, “The Different Worldviews of a Startup”1, in which he made the following astute observation:

“Different people — entrepreneurs, customers, investors, advisors, all see a startup differently.” — Ash Maurya

Spot on. He starts his post as follows:

In his book, “All Marketers Are Liars Tell Stories”, Seth Godin defines a “worldview” as the set of rules, values, beliefs, and biases people bring to a situation. He offers a strategy of not trying to change a person’s worldview, but rather framing your story in terms of their pre-existing worldview.

Boy, I wish I had this insight when I started out as a product manager! It totally applies to how product managers need to manage their stakeholders and partners with respect to their products. You need to tailor how you pitch your product strategy or business case to your audience based on the things they really care about.

And so with all due respect to Ash’s post, I will take the liberty of adapting his post to the discipline of product management. Similar to what he did in his post, I’ll illustrate this concept using the Product Canvas. If you’re unfamiliar, it’s a one-page encapsulation of the most essential elements that define your product strategy.

The Product Canvas

As Ash pointed out, different people see your product differently. I’ll expand on Ash’s post by discussing the different world views according to some of the different stakeholders a product manager has to deal with inside an organization.

Product Managers

Product Manager's world view

Product Managers, particularly those from technical backgrounds, are naturally drawn to the Solution box. Even yours truly. 🙂 They tend to spend a disproportionate amount of time on defining the features of their solution. As Ash puts it, “they fall in love with ‘awesome’.”

That’s why, like Ash did with his version, I kept the Solution box on the Product Canvas purposely small. This is not to replace user stories or a proper product definition. Rather, for one, to think about what are the most important elements of your solution that satisfy the primary problems of your target customer, as captured in the Problem box. Secondly, to make clear that the other components of your product strategy are equally, if not sometimes more, important.

Customers

Customer world view

I want you to write this down. Ready? Here it is:

Customers don’t care about your solution.

Write it down. Read it. Read it again. Sear this into your brain. Live it. Breathe it.

Customers care about only one thing: solving their problems. So to get them to care about your product you need to convince them that you understand them (identity), and then offer them something compelling that will solve their problem (your value proposition). How many times have we been told as product managers that customers don’t buy features, they buy benefits?

If you get these first two right, their next question is, “What’s it going to cost me?”. What they’re evaluating here is whether the price of your proposed solution is commensurate with its perceived value. (Value as perceived by them, not you.)

VP of Marketing

VP of Marketing world viewMarketing folks tend to naturally think about the market and customer first. Your VP of Marketing will be thinking about who are your target customers, what’s the plan to reach them, and how to measure the success of any marketing efforts. They know customers are bombarded with lots of noise, so your Marketing VP will be keenly interested in how the value prop of your product will be messaged, and its competitive positioning. (You do know who your competition is, don’t you?)

VP of Sales or Business Development

VP Sales worldview

Sales is interested in customers from the perspective of having a pipeline of hot leads. In particular, Sales will be trying to figure out who is that first named customer to whom they can take your product and quickly close a deal.

Sales folks love to talk about a product that “sells itself”. What they’re saying is they want you to have figured out who the customers are, and that you’ve built a massively appealing solution for them such that they’re thirsting for your solution.

Sales will also be keenly interested in pricing. It’s not just about their commission. (Well, it is about their commission, but stay with me here.) Many Sales folks look myopically at just price, because they’re worried about being undercut by a low-cost competitor. However, a good Sales or Business Dev exec will want to ensure your product’s price not only provides enough margin, but also communicates a value perception to the customer.

And that gets us to competition. Sales wants to be well-prepared before getting in front of customers. So be prepared to talk about what solutions customers may be using or considering, and how your product is positioned against these alternatives.

VP of Operations

VP Ops world view

Ops will want to assess the operational risk of delivering, fulfilling, distributing and supporting your product and marketing efforts. Ops will want to talk about business processes — if existing ones will be leveraged, will they need to be changed, or new ones created. And they will be looking to do these as efficiently as possible.

VP of Engineering / CIO

VP IT world view

When I talk software engineering folks through the Product Canvas, one of the most common questions I get is about capturing technology risk. They want to understand what it is you’re asking them to build (business/product requirements) so they can assess impacted systems and platforms, resource assignments, and architectural fit, in order to estimate the level of effort. They’ll want to understand if your product will require new technologies to be adopted, and if so, what that means in terms of skills sets and integration requirements. These considerations will impact the cost of developing, building and supporting your product.

Executives

Executive world view

Ok, saved the best for last…

Here, I’m talking about the senior execs in your organization who prioritize resources and approve operational budgets and capital investments.

Now, I want you to write this down too. Ready?

Executives don’t care about your solution.

Ok, maybe that sounds harsh. Maybe they do care. A little. But what they’re really doing is weighing your product as an investment. In other words, ROI. Similar to startup investors, executives are weighing the risks and opportunity costs of your proposed product strategy. Because they could easily allocate resources to something else they deem more worthy.

Executives do care about the customers you’re targeting, but less in terms of who they are, and more in terms of how many. In other words, market size, or more specifically, the addressable market.

They also want to know how much of it can be captured — in other words, market share. They’re doing the math of multiplying those numbers against the intersection of your revenues and costs to figure out the potential ROI.

For them to believe in your proposed ROI, they’re going to be interested in metrics. How will you know you’re being successful? What milestones will you need to hit? You need to figure out what metrics have line of sight to revenue and profit.

Ash makes a great point about traction: “If you have good traction, you can almost always convince the right investor to write you a check.” True for product managers too. If you can demonstrate traction, you’re more likely to get buy-in from your execs, and that means knowing how you’re defining and measuring success.

Finally, executives are often concerned about brand defensibility and differentiation. Especially in the case where the company has made heavy investments in its brand, execs will be evaluating whether your proposed solution will have a beneficial or detrimental impact on brand value.

Each of the boxes in the Product Canvas represents a risk or objection you must overcome towards building a successful product strategy. The true job of a product innovator then is to systematically de-risk their product strategy over time. To quote Ash one last time, “It helps to appreciate the different world views other people carry with them and frame your story accordingly.”

1“The Different Worldviews of a Startup”, Ash Maurya, LeanStack

How I Document My Product Vision

Over the last many years, I’ve been experimenting with applying Lean Startup andThe Lean Startup Customer Development concepts to product management. I first wrote about this here. Some time ago, I wrote about the challenges I and other product professionals have faced with the traditional approach of writing a business case.

One area where I had always struggled with was finding a simple and quick way to sketch out my product ideas. I used PowerPoint, Word, Google Docs, but they never really worked effectively. Often times my original notes would grow into a bloated morass of detailed thoughts about features, customers, marketing, partnerships, technologies, etc. There was no structure. Worst of all, if I wanted to share them with someone, I’d have to spend time figuring out how to translate them into something readable, since no one would be able to decipher my chicken scratch.

Before writing a requirements doc or business case, what I really wanted was a way to not only quickly capture a product idea in a structured manner, but also use the same format to share it with others to elicit feedback.

So you can imagine my delight when I came across Alex Osterwalder’s Business Model Canvas several years ago.

Business Model Canvas

What’s great about it is since it’s a single page, one can quickly jot down the basics of any business model, and it’s easy to share and more likely to get read than a PowerPoint deck or a Word doc. The single page also forces brevity: there isn’t a lot of space for a laundry list of features – you need to distil down your idea to its most essential building blocks.

Love at first sight, I started trying to use it for my products. But I ran into a few challenges. I found that while it does a good job capturing the key elements of a business, it’s not as customer focused as I would have liked because there was no place to capture the customer problems I was trying to solve or identify potential early adopters. There was also no place to capture my envisioned solution, and I often got confused between Channels and Customer Relationships.

That’s when I came across Ash Maurya’s Lean Canvas, an adaptation of the Business Model Canvas he created for his web startups.

Lean Canvas

Ash has correctly put the focus on customers and their problems. I also like that he calls out Unfair Advantage, which to me means competitive differentiation. This is especially true for a startup that may be fighting bigger, more established players.

So I started using his Lean Canvas, but ran into a new set of problems as a product manager:

Resources: Ash has left this out from Alex’s original version. I can understand this with respect to startups, but as a product manager working in an organization, it was important to me to identify which resources – platforms, systems, departments, vendors, etc. – I would need to make my product idea a reality.

Readability: When walking someone through a product or business idea, my inclination is always to start with the market opportunity, which means customers, their problems, and how we can solve them. I found neither of the above two canvases easily lend themselves to that flow. I’d have to start at the right-most column and then jump back left. This is non-intuitive to most English-speaking readers, and I found I’d quickly lose my audience as I criss-crossed columns.

Two other challenges I ran into as a product manager:

Stakeholders: Product Managers have to deal with internal stakeholders. The larger the org, the more. Often times a new product idea needs an executive sponsor. In my experience, I’ve found that the more I’m mindful of who are my key stakeholders, the greater the chance of internal support for my product.

Non-Revenue “Products”: Some products managers are responsible for initiatives that aren’t directly revenue generating, but do provide tangible business value, like improving CSAT, driving referrals, etc. I’ve lead several like that.

So I decided to create my own iteration that I felt was more suitable to me as a product manager, that I call the Product Canvas:

This version puts the customer and market on the left-hand side, which not only addresses the readability issue but also supports more intuitively how I think through a product opportunity. I can start with the customer and their problems on the left, and work my way toward the right to ultimately figure out how I’m going to deliver on the solution.

Here’s a brief description of each block and the order in which I typically approach them:

1. Customer Segment: Who is the target customer of our proposed product? This could be the company’s entire customer base, a segment, or a new market or vertical. Ash recommends using a separate Lean Canvas for each segment where one has multiple segments in mind, and I think that’s good advice as a starting point.

1a. Early Adopters: For any new product opportunity, it’s important to identify early adopters. There is already a ton written about this. While identifying early adopters is implied in the Lean Canvas, I wanted it called out explicitly, as I’ve found even in existing organizations there is a tendency to think any new product idea is applicable to all customers.

2. Problem: A brief description of the top problems we’re addressing. I try to limit this to at most 3.

2a. Existing Alternatives: How is the customer solving this problem today? This may not be just direct competitors. For example, in the early days, Quicken’s competition was not only other accounting software, but also checkbooks, and pen and paper.

3. Unique Value Proposition: How are we uniquely going to solve our customers’ problem(s)? This is the elevator pitch: the one sentence that clearly states the value we’re providing to our target customers.

4. Solution: What are the most essential features of our solution that will deliver on our UVP? This is not an exhaustive feature list. I try to limit it to the top 3 elements of my proposed solution.

5. Channels: How will we get (acquire), keep (retain), and grow (sell more to existing) customers? What is the marketing and sales strategy?

6. Revenue Streams/Business Value: How will we make money? What’s our pricing strategy? If this is not a revenue generating product, what other business value is it providing? Improving customer satisfaction? Customer lifetime value? Market positioning? Competitive differentiation? Operational efficiencies?

7. Key Metrics or Success Factors: What are the most important metrics that will tell us that we’re successful? Signups? Conversions? Referrals? CSAT? NPS? These are the metrics that are driving #6 above.

8. Key Resources: What are the most critical internal resources we need? These could be platforms, systems, business processes, departments. Are there external partners we need to rely on?

9. Cost Structure: What are the key cost drivers? Software/IT development? Customer acquisition? Account management? Hiring and talent development? This is also a good place to capture a back-of-the-envelope break-even calculation.

10. Unfair Advantage: This is the distinctive competence or advantage that your product has over other solutions in the marketplace. It’s something your product does better than any other, something that can’t be easily copied. It could be intimate knowledge of an industry, personal authority or brand, a business process or competence, a patent, or some other intellectual property.

After experimenting with using this Product Canvas as a product manager, I started sharing it with folks, asking them to use it, and the feedback has been very encouraging.

Feel free to download it here.

The Case Against The Business Case – Part II

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

In part 1, I talked about the problems of pursuing a new product idea in an organization, which traditionally starts with preparing and selling a business case. I shared research that I conducted in which I spoke with a number of product management professionals across the country in companies large and small who resoundingly shared their distaste for the process.

The response was amazing. It seems my post touched a chord!

Some interesting stats:

  • Within one week, the post became the 3rd most viewed on my blog.
  • Tweets, likes and positive comments on my blog and LinkedIn groups where I shared my post totaled 31. In other words, 31 additional people were in agreement with the original 24 with whom I had spoken.
  • On the flip side, there were a 6 disagreeing comments posted on the same LinkedIn groups.

Now, if there were any other detractors (because many more viewed the article), they either didn’t agree, didn’t comment, or didn’t care.

Still, with 83% promoters and 17% detractors, this would give an NPS-style score of 66%.

So it seems I’m on to something here.

Here’s something interesting. According to the Pragmatic Marketing’s 2013 Annual Product Management and Marketing Survey, 50% of respondents indicated they spend at least half a day per week preparing business cases.

part-of-job

Do the math on this, and that’s 17.6 hours per month or the equivalent of 1 month and 3 days per year spent preparing business cases.

So on average, a product manager is spending over one month of an entire year preparing business cases. Surely there should be some ROI to spending that much time? Yet, we all know the rate of failed products is sadly high.

To be clear, I’m not saying a business case is not necessary. Indeed, one needs to have a robust business case to ask for a commitment of resources and/or investment.

I’m saying that while well-intentioned, somewhere along the way, the process by which we’ve gone about preparing the business case has become wasteful.

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

 

Several months ago, Steve Blank wrote a column in the Wall Street Journal that talked about the need for a startup to begin not with a business plan, but with building and testing a business model.

Three years prior to that, he blogged about how Customer Development is more effective than the traditional product development process in helping startups raise VC money.

“In a traditional product development model, entrepreneurs come up with an idea or concept, write a business plan and try to get funding to bring that idea to fruition. The goal of their startup in this stage becomes “getting funded.” Entrepreneurs put together their funding presentation by extracting the key ideas from their business plan, putting them on PowerPoint/Keynote and pitching the company – until they get funded or exhausted.”

It seems to me the same logic can be applied to pursuing new product ideas in established organizations.

Just like entrepreneurs typically jump right into writing the business case and seeking funding, product managers (or any visionary employee) often go direct from coming up with a concept to writing the business case and seeking its approval.

traditional-biz-case

Here’s another quote from that WSJ article:

“Entrepreneurs treat a business plan, once written, as the culmination of everything they know and believe. All they need to do is add money and magically that five-year forecast in Appendix A will simply happen if they execute to the plan.”

I’ve found the same with business cases. There are two key problems with the traditional approach to preparing a business case.

One is, like with startups, pursuing a new product idea in an organization is also fraught with uncertainty. The assumptions that go into the financial forecast need to be tested.

The other is that when seeking approval, your goal and your execs’ goal may not necessarily be aligned.

You still have a lot to learn and prove in your model. But the execs are ultimately interested in only one thing: ROI. Perfectly understandable, given the financial responsibility entrusted upon them.

problem-with-biz-case

This often leads to wasteful execution. The focus becomes hitting an arbitrary delivery date and trying to hit a promised ROI.

The product manager is caught between a rock and hard place: learning from customers and launching on time. It often leads to delivering bloatware or crapware.

What was that stat again about the rate of failed products?

So it seems to me that to build a robust business case, it’s important to validate that you’ve truly understood your customers’ problems, that they’ve bought into your proposed solution, that the problem is worth solving, and that it fits with the company’s overall corporate strategy.

For extra credit, you need to identify some early adopters, or “earlyvangelists,” as Steve Blank calls them.

These insights can help you identify key metrics that will drive your financials, making for a much more solid business case, and increase the chances for more efficient execution.

To add to this, product managers face a unique challenge that entrepreneurs don’t, which is gaining and maintaining internal stakeholder support.

This can be especially true in larger organizations where there are simply more people to manage and placate. Lots of opinions. Capturing and addressing concerns. Following up. Competing agendas. Finding an executive champion. Lots of approvals.

These are real challenges with which the bold product manager has to deal.

How to address that? Perhaps there’s a way to apply Customer Development concepts to internal stakeholders…?

In fact, there is.