Tag Archives: business plan

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.


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.


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.


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.”.



And my favorite comment:

“You are describing my life!”


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.

A successful business case is not about the analysis

You’ve worked hard to prepare an air tight business case for that new product idea or that additional investment your current product needs to take it to the next level. You’ve clearly quantified the opportunity, identified the product solution, crafted the marketing strategy, thought through all possible risks and mitigation strategies, validated all assumptions, analyzed the investment requirements, and have developed a robust, stress-tested ROI model. You’ve vetted the business case with your boss and his or her boss as well. You’ve even practiced your presentation in front of the mirror. Despite some understandable anxiety, you’re feeling confident. You’re ready.

But your presentation ends in disaster. Your business case, while solid, falls flat. The execs either trash it completely, or worse, end up making no decision at all leaving you in limbo with no direction whatsoever. What happened? What did you miss?

In a nutshell, the people factor. When I started out, I thought if I had a well thought out presentation backed by solid analysis, that would be enough. After all, that’s what they taught us in business school, and it’s what the experts tell us we should all be doing. Good enough, right? Wrong. What I learned in the real world is that at the end of the day business runs on people, and you need to get people on your side if you want buy-in for your ideas and proposals. Yes, your analysis and recommendations have to be solid – that’s a given. But if number crunching and logic were all it took to convince people, this would probably be a very different world.

I learned that “pre-selling” ideas are critical to getting buy-in for my proposals, be they from execs or even among peers. And to do this, understanding “trust networks” is critical. This means figuring out who trusts whom, who has credibility with which folks, and understanding the personalities involved – what are their motivators, concerns, agendas. And the larger the organization and the more layers between you and those whose approval you seek, frankly, the more intricate the trust networks and the more “pre-selling” you will have to do.

The goal here is two-fold. For one, you can identify potential concerns and challenges early, and so be prepared to address them during the formal pitch. Second, in a ideal situation, everyone is already pre-sold on your proposal, so the meeting is really more of a formality with everyone at the table prediposed to nodding their agreement.

It’s tough work, and it requires its own special planning. But if done right, it can make your actual formal presentation go a whole lot smoother.