Tag Archives: product strategy

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!

An MVP Is Not The Smallest Collection Of Features You Can Deliver

Source: Spotify

Source: Spotify

There’s a lot of discussion and confusion about what is and isn’t a minimum viable product (MVP).

Worse, many execs have latched on to the term without really understanding what truly constitutes an MVP — many use it as a buzzword, and as a synonym to mean a completed version 1.0 ready to be sold to all customers.

Buzzwords are meaningless. They represent lazy thinking. And using “MVP” to mean “first market launch” or “first customer ship” means you’re back to the old waterfall, traditional project-driven software development, sales-focused approach. If that’s your approach, fine. Just don’t call what you’re delivering an MVP.

On the flip side, lots of folks in the enterprise world, including in product management, over-think the term. It gets lost in the clever nuances of market maturity, and a long entrenchment in the world of release dates and feature-based requirements thinking.

Many folks think of MVP as simply the smallest collection of features to deliver to customers. Wrong. It’s not.

The problem with that approach is it assumes we know ahead of time exactly what will satisfy customers. Even if we’ve served them for years, odds are when it comes to a new product or feature, we don’t.

Now, the challenge with the concept of a minimum viable product is it constitutes an entirely different way of thinking about our approach to product development.

It’s not about product delivery actually — in other words, it’s not about delivering product for the sake of delivering it or to hit a deadline.

An MVP is about validated learning.

As such, it puts customers’ problems squarely at the center, not our solution.

Reality check: Customers don’t care about your solution. They care about their problems. Your solution, while interesting, is irrelevant.

So if we’re going to use the term “MVP”, it’s important to understand what it really means.

Fortunately, all it takes to do that is to go back to the definition.


Download The Handy Primer “What Is An MVP?” >>


Minimum Viable Product (MVP) is a term coined by Eric Ries as part of his Lean Startup methodology, which lays out a framework for pursuing a startup in particular, and product innovation more generally. This means we need to understand the methodology of Lean Startup to have the right context for using terms like “MVP”. (Just like we shouldn’t use “product backlog” from Agile as a synonym for “dumping ground for all possible feature ideas”.)

Eric lays out a definition for what is an MVP:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Eric goes on to explain exactly what he means (emphasis mine):

MVP, despite the name, is not about creating minimal products… In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition’s use of the words maximum and minimum means an MVP is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Let’s break this down.

1. An MVP is a product. This means it must be something delivered to customers that they can use.

There’s a lot that’s been written about creating landing pages, mockups, prototypes, doing smoke tests, etc., and considering them as forms of MVPs. While these are undoubtedly worthwhile, and certainly “lean”, efforts to gain valuable learnings, they are not products. Read Ramli John‘s excellent post on “A Landing Page Is NOT A Minimum Viable Product“.

A product must attempt to deliver real value to customers. So a minimum viable product is an attempt — an experiment — to deliver real value to customer.

Which leads us to…

2. An MVP is viable. This means it must try to tangibly solve real world and urgent problems faced by your target customers. An MVP must attempt to deliver value.

So it’s not about figuring out the smallest collection of features. It’s about making sure we’ve understood our customers’ top problems, and figuring out how to deliver a solution to those problems in a way that early customers are willing to “pay” for. (“Pay” in quotes as it depends on your business model.)

If we can’t viably solve early customers’ primary problems, everything else is moot. That is why an MVP is about validated learning.

3. An MVP is the minimum version of your product vision. A few years ago, I had to build an online form builder app that would allow customers to create online payment forms without the need to write any HTML or worry about connecting to a payment gateway. Before having our developers write a single line of code to build the product, we first offered customers the capability as a service: we would get their specs, and then manually build and deliver each online payment form one-by-one, customer-by-customer. Customers would pay us for this service.

This “concierge” type service was our MVP version of our product vision. Of course, it wasn’t scalable. But we learned a heck of a lot: most common types of payment forms they wanted, what was most important to them in a form, frequency of wanting to make changes, reporting needs, and how they perceived the value of the service.

We parlayed these learnings into developing the software app itself — which, by the way, we delivered as an MVP to early customers to whom we had pre-sold the software product. (Yes, we delivered two different types of MVPs!)

Whether you take a “concierge” approach or your MVP is actual code, it most definitely does NOT mean it’s a half-baked or buggy product. (Remember viable from above?)

It DOES mean critically thinking through the absolute necessary features your product will need day 1 to solve your early customers’ top problems, focusing on delivering those first, and putting everything else on the backlog for the time being. It also means being very deliberate about finding those “earlyvangelists” that Steve Blank always talks about.

Ultimately, the key here is “maximum amount of validated learning”. This means being systematic about identifying your riskiest assumptions, formulating testable falsifiable hypotheses around these, and using an MVP — a minimum viable product version of your product vision — to prove or disprove your hypotheses.

Now, validated learning can certainly be accomplished via a landing page, mockup, wireframes, etc. And it may make sense to do these things. Super. But don’t call them MVPs, because while they may deliver value to you and your product idea, they’re not delivering actual value to the customer.

At the same time, the traditional product management exercise of identifying all the features of a product, force ranking them, and then drawing a line through the list to identify the smallest collection to be delivered by a given timeframe is not an MVP. Why? Because this approach is not predicated on maximizing validated learning. If you’re going to pursue this approach, go ahead and call it Release 1.0, Version 1.0, “Beta”, whatever. But don’t call it an MVP.

An MVP is about not just the solution we’re delivering, but also the approach. The key is maximizing validated learning.

I’ve created a handy primer on what is a minimum viable product. Download it below. I hope it helps you to become a pro at defining an MVP for your next great product idea!


Download The Handy Primer “What Is An MVP?” >>


Roadmaps Are Not A Popularity Contest

By Bruce McCarthy

I write a blog called User>Driven and my Twitter handle is @d8a_driven, so you would think I like the idea of setting roadmap priorities based primarily on customer requests. You would be wrong.

Dell Idea Storm

Back in 2007, Dell created an online customer forum where people could post “innovative” ideas for how Dell could improve their offering and others could vote on those ideas. I wrote at the time that I thought it was a very bad idea.

In my opinion, Dell had fundamentally misunderstood the uses of customer data and the best ways to collect it. The proof of that was that the voting had been hijacked by a small number of very vocal open source advocates. Checking back in this week, I see it mostly consists of >complaints and suggestions for minor tweaks to design and packaging. Interestingly, they have made it impossible to see which ideas have the most votes.

Tracking Customer Requests

Over 20 years as a product person, I’ve developed an objective scoring methodology for prioritizing ideas. (See my presentation on Slideshare.) It focuses on ranking proposed improvements or changes as to how much they contribute to strategic goals compared to their implementation cost.

So am I arguing for ignoring customer input? Not at all. If improving your customer retention rate is one of your strategic goals, it might make sense to include number of customer requests in your scoring. I know more than one product person who has tracked popularity as input to their planning and tools like UserVoice make this easier than ever.

Your Customers Can Hold You Back

Tracking customer requests can easily create a false sense of security for a product person, though. You’re collecting real, live market data, right? It’s all neatly tallied and summarized in your PowerPoint, right? Ok, fine, but bear these very real limitations in mind.

  • As Dell Idea Storm showed, you have to recognize that not all votes are equal. Vocal customers are not necessarily paying customers. And even if you could get evenly-distributed input, most customers are small. Should you be focused on their needs or on the needs of your largest customers? Tailor your data collection to your strategic goals and weight the input accordingly.
  • Expect incremental input only. Henry Ford famously said that if he’d asked customers what they wanted, they would have answered: “a faster horse.” Customers will give you ‘better, faster, cheaper’ advice, but are unlikely to propose a break-through idea that uses technology to solve problems in new ways.
  • Beware “featuritis.” We all complain about the lengthy list of features in Microsoft products that we never use but make things complex, crash-prone and slow. Where does all of this bloat come from? Customer requests. Beware of adding features that only a few will use but many will have to put up with.
  • Existing customers tell you nothing about non-buyers. People who are in your target market but don’t respond to your messaging or solution are your best source for information on how to expand your appeal. Reach out to people who evaluated your solution but decided to go with the competition or do nothing (this is called “win/loss analysis”) and ask them about their business, their problems, and why they went a different direction.
  • Existing customers won’t help you penetrate new markets. If you want to grow beyond your current market niche into other verticals or up to larger customers, engage with those people directly and, rather than talk about your solution, ask them about their needs and wants. Develop an understanding of the personas in that space and what they need and you will be on your way to designing a solution that will capture that market.

One Way To Use Popularity To Prioritize

Ok, yes, I did create a forum where people could vote on what a roadmapping tool for product people should do when setting out to design Reqqs, my forthcoming tool for product people. But that was different. Really. Let me tell you why.

Before putting up the forum, I spent a lot of time interviewing other product people, asking them about their jobs, what were they trying to achieve, and what were their main obstacles and frustrations. I did this until it was pretty easy to guess what the next person would say. That kind of qualitative data helped me define the essence of the product as a roadmapping tool for product people.

The next step was to figure out which of the 10 or so problems I had uncovered were the most common and most painful. UserVoice’s voting feature is perfect for that. I set up the forum, pre-populated it with my 10 things, set up each user with 10 votes to allocate however they liked, and began promoting it on product discussion boards like those on LinkedIn. This limited my audience to qualified prospects, all of whom were equal in my eyes since none were yet a customer.

With the hard work of using interview data to develop innovative ideas done, a survey within my target market provided the quantitative data needed to determine the top few of those ideas that would form the MVP. As it happens, potential customers highlighted prioritization as the number one thing they wanted help with, and that will be the core feature of the initial release of Reqqs.

Customer Requests Are But One Input

So, yes, customer input can be a powerful tool to aid in decision-making. But like all superpowers, this one must be used responsibly. Set your strategic goals first, then decide which items from your utility belt will help you toward those goals.

Bruce

Bruce McCarthy is a serial entrepreneur, 20-year product person, and sought-after speaker on roadmapping and prioritization. By day, he is VP of Product for NetProspex, but only you know his secret identity as Chief Product Person for Reqqs, the smart roadmap tool for product people (forthcoming). He is available for advice on product management topics of all kinds.

How to Identify (and Mitigate) the Riskiest Parts of Your Product Strategy

Any product strategy is fraught with risks.

Three of the biggest risks to a startup are tech risk, market risk, and ego risk. Corporate innovation faces additional risks: resource risk (resources need to be assigned), implementation risk (need the right implementation skill sets and tools), operational risk (the product needs to be operationally cost-effective) and internal risk (need buy-in and alignment from internal stakeholders).

Identifying these risks and de-risking them are crucial to the success of any product strategy. One of the most compelling things to me about Lean Startup is the focus on systematically de-risking elements of a product innovation through experiments and Validated Learning — one of the five core principles of Lean Startup.

Of course, this is predicated on identifying each of the most essential elements of your product vision. The Product Canvas has been great in helping me do just that. Its 1-page format facilitates having important conversations with my partners and stakeholders to gather their feedback.

“[The Product Canvas] is a smart way for each product manager to have a succinct snapshot of what it means to ‘be’ a product. It is a great way to focus and present to others the critical elements of a product.”

Having conversations with my internal partners are critical to helping me uncover risks and assumptions that I may not have thought of.

As I started doing this, the question became how to capture these risks, track progress in de-risking them, and communicate back that progress?

Here, again, is where I found the principle of Innovation Accounting from Lean Startup appealing, which Eric Ries describes it in his book:

To improve entrepreneurial outcomes, and to hold entrepreneurs accountable, we need to focus on the boring stuff: how to measure progress, how to setup milestones, how to prioritize work. This requires a new kind of accounting, specific to startups.

In other words, Innovation Accounting provides a framework to measure and communicate progress. The unit of progress is a learning milestone, “an alternative to traditional business and product milestones.” (From the book.)

This last part really appeals to me. Developing a grounded, workable product strategy cannot be moved forward by a date-driven approach, and I’ve seen too many new product development efforts descend into chaos, and even outright failure, by the traditional project management process.

Again, from Eric’s book:

“Learning milestones are useful for entrepreneurs as a way of assessing their progress accurately and objectively; they are also invaluable to managers and investors who must hold entrepreneurs accountable.”

I’d argue we could replace “entrepreneur” with “product manager” or “product innovator”, and “investors” with “executives”.

But again, the question is how to actually do this in practice. Let’s go back to the issue of capturing and tracking assumptions and risks.

At first, I used stickies:

pmc_hypotheses_1_lowrez

That worked great as a start. Especially for brainstorming or a live update if a colleague or stakeholder was in the room with me.

But not so much for tracking ongoing progress. Plus, translating all that into an update report to share with someone not in the room is just too much work, quite frankly.

I needed something that doubled up as a tool to use and a way to communicate progress, similar to the Product Canvas.

Then I came across Ash Maurya’s blog posts on his Lean Stack approach to doing Innovation Accounting. I liked how he’s mapped the Build-Measure-Lean cycle into a Kanban style approach to track his progress.

After experimenting with his approach, I developed a version that worked for me as a product manager. I’ll explain via a made up, yet tangible, example.

Below is an initial Product Canvas for an online bill payment app that allows customers of a bank to view all their bills in one place and pay directly through their bank account.

billpay-product-canvas

Now, as product manager, I should be intimate with my customer base. So let’s say their input was the genesis for this product — e.g., lots of customer requests asking to enhance the existing bill pay service with the ability to view and pay utility bills.

As such, initially I may not see my Customer Segment or Problems as the highest risks. But I do need to identify my early adopters.

In other words, I feel confident in the initial demand, but I’m not certain which of my customers will be most likely to switch their behavior to paying all their bills through our bank. (After all, people don’t always do what they say.) So I highlight this as a risk.

After speaking with my stakeholders, I identified numerous additional risks, which I highlight via PowerPoint’s comments feature:

billpay-product-canvas-with-comments1

All I need to do is click on any comment to view the details:

billpay-product-canvas-with-open-comments

Now, to track and communicate progress on how risks are being addressed, I use a Kanban style board similar to what Ash uses, called the Validated Learning Board.

billpay-validated-learning-board

Risks and assumptions are placed in the Backlog column. When I begin working on a particular risk card, I move the card to the IN PROGRESS section. I place a blue card under the Build column to note the experiment I’m conducting. On the card, I note the experiment that I’m running and the falsifiable hypothesis of my experiment.

If an experiment serves to tackle more than one risk, no problem. You’ll see an example in the image above representing that.

Once I start the experiment (e.g., interview the first customer, or day 1 of user testing, etc.), I move the card to the Measure column.

Once the experiment is over, I move the risk card to the Learn/DONE column, and color code it green if the assumption has been validated or risk de-risked, and red if not.

If I’m running multiple experiments simultaneously, I separate them with a line.

billpay-validated-learning-board-2

I don’t capture all the details of my experiment on the cards. This is meant for a high-level progress view. Details of the experiment can be presented on its own slide or report.

Finally, I need to make sure I’m systematically identifying the right set of internal stakeholders and capturing their feedback. I covered that in my blog post on Stakeholder Development, in which I talked about the Stakeholder Development Tracker.

As I continue to get feedback from both the experiments and further internal conversations, I use these learnings to update the product strategy represented in the Product Canvas.

A team can use these artifacts to track progress on, say, the wall of an agile room, while also quickly converting them into 3 quick slides to provide a high-level update to anyone on the progress of the product strategy.

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.

Before Product/Market Fit comes Opportunity/Company Fit

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

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

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

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

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

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

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

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

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

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

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

opportunity-company-fit

I call this stage Opportunity/Company Fit.

Critical questions for the product manager to figure out are:

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

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