Tag Archives: business case

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.

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.

How I Sold A $1M Business Case For A Non-Revenue Product

biz-proposal-2Pitching a business case for any new product idea is a challenge. Pitching one for a non-revenue generating idea is even harder. A few years ago, I did exactly that, involving the small matter of an ask a little south of $1 million.

At the time, the product was being positioned as a customer benefit and a strategic differentiator for the company. Although the potential for driving revenue was there in the long-term existed, the immediate ROI was operational efficiency. The problem was it was going to cost a lot to do right. (Yes, we were waterfall, but that’s another matter.)

I still remember the day we pitched the business case. Up until the day before, I was crazy nervous. I mean, who approves close to a $1 million funding request for something that has no promise of revenue? Sounds crazy! We had 30 mins to present our case. I must have practiced my presentation a hundred times in the days prior to the meeting with the executive committee.

In the end, our ask was approved within two hours of our presentation. It was amazing. Several folks who had been at the company for many years told me they had never heard of any proposal – even one with revenue attached – being approved so quickly. I don’t know if that’s actually true, but I’ll admit – it felt real good!

As I reflected on the reasons for the success of that business proposal pitch, the lessons learned from that experience are captured in a famous Sun Tzu quote:

“Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”

I learned that in order to sell any proposal there are a number of pieces that need to be in an advantageous position prior to your actual pitch. The business case itself is, of course, a key asset. But it’s just as important to consider the market, company culture and human factors that can have a decisive effect on the success of any proposal. Here are the pieces I put into place to increase my odds of success:

A robust business case. Of course, it starts with this. Although, at the time, I wasn’t aware of tools like the Business Model Canvas or Lean Canvas, I did make sure my proposal contained all the necessary components. This can be a blog post in itself, but briefly: clear articulation of the customer problems, business challenge and proposed solution; fit with existing corporate strategy; critical resources needed; a financial analysis showing historical spending and benefits derived thus far (which, by the way, was not much), the investment ask and ROI; and the impact of pursuing the investment vs. not doing so.

Customer validation. We knew our chief problem was a poor user experience. But we had to make the case that it was beyond just “fixing a few broken links and prettying up the fonts”. To do that, we conducted a usability study to test three key customer hypotheses around validating the premise of our solution, the user experience, and the business model. For each hypothesis, we defined our success criteria to validate our assumptions. As we had predicted, while customers validated the premise of our solution, they overwhelmingly trashed the UX and completely invalidated our business model hypothesis.

We had video taped the entire study. So I cut a 90-second video montage to play to the execs that ended with what I called the Money Quote: “If this is the experience, then next time I see it offered to someone, I’m going to warn them, ‘Don’t buy it, because it sucks!'”

Fit with the corporate business strategy. I’ve talked about the importance of Opportunity/Company Fit for a product idea here.

A coalition of the willing. I knew there were others in the organization who felt my pain, and some who were more interested in trashing the product. I wanted to convert sympathizers into supporters and either minimize the detractors or at least be in a position to address their concerns. The goal here was to make sure that by the time I approached the execs, they knew there was organizational support behind the product. I also wanted them to know I had done the legwork to capture and address any concerns from those who remained unsupportive (especially the vocal ones).

“Earlyvangelists”. As early as possible, I began to meet with key members of senior and executive management to try to get their buy-in and early feedback. This allowed me to gather early insights into potential challenges, the things the C-suite in particular care about, any political concerns to ensure support from these stakeholders, and gain internal “earlyvangelists”. This word was coined by Steve Blank to define “a special breed of customers willing to take a risk on your startup’s products or service because they can actually envision its potential to solve a critical and immediate problem.” In my case, I was looking for those internal folks who could envision my proposal helping to solve a critical problem they were facing in their own agendas.

Influence Map

From MindTools.com: “Uncovering where the power lies in your projects”

Empowering others to pre-sell for me. Those early conversations helped me identify an “influence map” that depicted how organizational relationships worked top-down. For each member of the executive committee I identified the folks whose opinions he or she valued the most. If I had a direct relationship with this person, great. If not, I’d go down to the next degree. I then presented my proposal to these folks to get them on my side, tailoring my presentation to my audience. Once done, I’d ask the person for feedback on how to get the executive’s buy-in. This would empower them to pre-sell my idea to the exec in conversations that I would not be a part of.

A scorecard of who’s in vs. who’s not yet. I converted my influence map into a scorecard where I tracked who was on board vs. who wasn’t, and for the latter, what their concerns were and my next steps to address them.

A presentation that fit with the culture. How the presentation is prepared is just as important as the business case itself. I’ve worked at a company that had little appetite for decks: the rule was never more than 5 slides. I worked at another company where meetings would not be able to take place without a Powerpoint deck: 20-page, even 60-page, presentations were the norm.

Iterate the business case. As I gained feedback and insights from the above activities, I followed a Build-Measure-Learn cycle for creating the proposal itself, continually tweaking and re-testing it before it was show time ready.

Great mentors/advisors. This can also be a blog post by itself. Having solid mentors and advisors are so essential. I made sure to look beyond my immediate manager and his manager. For example, I built a relationship with a senior manager in Finance to get his feedback on my financial analysis. He had nothing to do with my proposal or product, but his feedback helped strengthen my financial model, and since he was closer to some of the senior executives who were close to the CFO, I gained insights into the the things important to them.

All this is not to say you can’t sell a business case or proposal on the strength of the content alone and (if you’re so lucky) personal charm. Certainly, there are situations where that’s all you have to rely on. But when possible, it’s important to spend the time upfront planning, strategizing and creating coalitions  If you do so, odds are you’ll be pleasantly surprised at how swimmingly the actual pitch goes. In other words, win the battle before it’s actually fought.