Category Archives: Lean Startup

How To Define An MVP: A Case Study

In my last post, I talked about how a minimum viable product (MVP) is not the smallest collection of features to be delivered. An MVP is basically an in-market experiment of a product idea that involves delivering real product to actual customers to get their feedback.

An MVP can be tested whether your idea is a brand new product or a new feature for an existing product.

And even if your product is software, your MVP doesn’t necessarily have to be software too.

Folks may be familiar with how Groupon started as a WordPress blog, called “The Daily Groupon”, on which the team posted daily discounts, restaurant gift certificates, concert vouchers, movie tickets, and other deals in Chicago area.

Food On The Table, a family meal planning and grocery shopping site eventually acquired by the Food Network, started by working with their customers individually, creating meal plans and shopping lists for them on spreadsheets and email, and then bought and delivered food items themselves.

So how do you go about defining an MVP for your product idea?

It starts with having a hypothesis for what features or capabilities you believe need to be delivered to your target customer in order to provide them value.

This is predicated on having done the hard upfront work of validating your customer’s problem (that it exists, it’s urgent, and pervasive), and then maybe even having tested a prototype of your solution vision.

If you feel you have a good enough understanding of your customer’s problem (pain point, job to be done, etc.), use that as a basis to identify what you believe are the must-have features for your MVP that are aligned with your solution vision.

Then test that MVP with real customers. Evaluate your results. Rinse and repeat.

To make this more tangible, here’s an example from my own experience.

For a product idea we had, we wanted to test our understanding of our customers’ top problems and get directional feedback on our solution approach. Directional feedback meant identifying the “right” handful of features to build first for early customers.

Based on some early customer conversations and market research, we developed a view of the problem domain. We sketched out our product vision on the Product CanvasTM, which allowed us to break down the problem domain into discrete problems and formulate testable falsifiable hypotheses around what we believed to be the top problems that our solution absolutely had to solve for first.

We built a clickable mockup defined by the key elements of our solution captured in our Product Canvas exercise. To keep things simple, we built a screen for each discrete problem to represent our solution vision — real html and css, in color, no lorem ipsum, with clickable interactions to represent the primary workflow through the screens.

We didn’t build out every interaction — just the main ones. We formulated a testable falsifiable hypothesis around the ability of each screen to solve a specific problem.

We then set up a number of customer interviews to test our problem hypotheses. During these customer conversations, we listened carefully to fully understand our customers’ world views and their current work flows, even noting the emotions in their voice and their body language (during in-person meetings, when we could do them) as they discussed their challenges and reacted to our screens.

We were deliberate and meticulous about documenting the results.

It turned out that while we had identified a viable problem domain, our view of what early customers considered as their chief problems was invalidated. We also learned that while our solution approach was generally in the right direction, there were features that we had not envisioned that early customers considered as must-have’s in the initial delivery.

As a massive bonus, we were actually able to garner a handful of very early customers who were willing to co-test the solution with us, further validating the fact that we had pricked a real pain point and were directionally correct in our solution approach.

As a primary outcome of this work we were able to understand our customers’ problem at a granular level, which helped prioritize the initial set of features to build. That drove the definition of the minimum viable product version of our solution.

And that’s what we did. We built just those features, and nothing else, and delivered it to those handful of early customers.

In fact, our first MVP wasn’t software. Our first MVP was more a concierge type service, sort of like what Food On The Table did — we “manually” delivered the service to each customer individually.

We learned a ton of really useful stuff. Things like what was really important to the customer, what features of the service they used more often than others, real insights into their workflow and how our solution could help improve it, and — crucially — what they were willing to pay for.

We used these learnings to then define a software MVP, and deliver it to early committed customers. The learnings from our “concierge” MVP experiment helped boost our confidence in defining the requirements for our software MVP. In other words, it was much less of a guess than it otherwise would have been.

We didn’t really bother with calling the software MVP a “release 1.0” or “version 1.0”, because that was irrelevant. We just focused on testing the solution until we received customer validation that it was truly providing value.

That gave us the confidence to know our product idea was “good to go” to scale up, put some real sales and marketing muscle behind it, and sell to more customers.

There’s no one way necessarily to approach an MVP. This is just one example of an approach. As Eric Ries states, defining an MVP is not formulaic: “It requires judgment to figure out, for any given context, what MVP makes sense.” Hopefully, this example gives you a template to define and test your own minimum viable product for your next great product idea.

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!

 

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


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.

Applying Lean Techniques in a Big Company: The “Hothouse”

Large companies are always trying to find ways to move at “startup speed” or “digital speed”. The challenge often times is quite simply people: there are just too many of them to keep aligned in order to move swiftly. For any initiative, there are usually multiple stakeholders and affected parties. That means multiple opinions and feedback cycles.

It’s easy to say decision making should be centralized, but the reality is it’s much harder to execute in practice. Even a 1,000-person company has multiple departments, and bigger companies often have sub-departments. If I’m driving a new initiative that will materially impact the customer and/or the business, the fact of the matter is I need to ensure I’m actively coordinating with many of these groups throughout the process, like marketing, operations, call centers, brand, legal, IT/engineering, design, etc. That means not only coordinating with those departments heads (usually VPs), but also their lieutenants (usually Directors) who are responsible for execution within their domains and control key resources, and thus have a material influence over the decisions of the department heads.

In addition, large companies are often crippled by their own processes. Stage-Gate type implementations can be particularly notorious for slowing things down with the plethora of paperwork and approvals they tend to involve.

All of this means tons of emails, socialization meetings, documentation, and needless deck work. All of which is a form of waste, because it prevents true forward progress in terms of driving decision making, developing solutions, and getting them to market.

Initiatives involving UI are particularly susceptible to this sort of corporate bureaucracy for the simple reason that UI is visual and therefore easy to react to, and everyone feels entitled to opine on the user experience. Once, one of my product managers spent a month trying to get feedback and approvals from a handful of senior stakeholders on the UX direction for his initiative. A month! Why did it take so long? For the simple and very real reason that it was difficult to get all these senior leaders in the same room at the same time. What a waste of time!

So how to solve for this? Several years ago, my colleagues and I faced this exact challenge. While an overhaul of the entire SDLC was needed, that takes time in a large organization. What we needed was something that could accelerate decision making, involve both senior stakeholders and the project team, yet be implemented quickly. That’s when we hit upon our true insight: What we needed was to apply lean thinking to the process of gaining consensus on key business decisions.

And that’s how we adopted an agile innovation process that we called a “Hothouse.” A Hothouse combines the Build-Measure-Learn loop from Lean Startup with design thinking principles and agile development into a 2- to 3-day workshop in which senior business leaders work with product development teams through a series of iterative sprints to solve key business problems.

That’s a mouthful. Let’s break it down.

The Hothouse takes place typically over 2 or 3 days. One to three small Sprint teams are assembled to work on specific business problems throughout those 2-3 days in a series of Creative Sprints that are typically about 3 hours each. (4 hours max, 2.5 hours minimum.) Between each Creative Sprint is a Design Review in which the teams present the deliverables from their last sprint to senior leaders, who provide constructive, actionable feedback to the teams. The teams take this feedback into the next Creative Sprint.

This iterative workflow of Creative Sprints and Design Reviews follows the Build-Measure-Learn meta pattern from Lean Startup:

Hothouse Build-Measure-Learn

During the Creative Sprints, teams pursue the work using design thinking and agile principles, like reframing the business challenge, collaborative working between business and developers, ideation, user-centric thinking, using synthesis for problem solving, rapid prototyping, iterative and continuous delivery, face-to-face conversation as the primary means of communication, and team retrospections at the start of each sprint.

The Hothouse is used to accelerate solution development for a small handful of key business problems. So job #1 is to determine the specific business problems you want to solve in the Hothouse. The fewer, the better, as a narrow scope allows for more focused, efficient and faster solution development. For each business problem, teams bring in supporting material, such as existing customer research, current state user experience, business requirements, prototypes, architectural maps, etc. as inputs into the Hothouse. The expected outputs from the Hothouse depend on the business problems being addressed and the specific goals of the Hothouse, but can take the form of a refined and approved prototype, prioritized business requirements or stories, system impacts assessment, high-level delivery estimates, and even a marketing communication plan.

Hothouse process

At the end of the Hothouse, the accepted outputs becomes the foundation for further development post-Hothouse.

I’ve been part of numerous Hothouses, both as a participant and facilitator, and I’ve seen Hothouses applied to solve business challenges of varying scope and scale. For example:

  • Re-design of a web page or landing page.
  • Design of a user flow through an application.
  • Development of specific online capabilities, such as online registration and customer onboarding.
  • A complex re-platforming project involving migration from an old system to a new one with considerations for customer and business impacts.
  • An acquisition between F1000 companies.

The benefits to a large organization are manifold:

  • Accelerates decision making. What typically takes weeks or months is completed in days.
  • Senior leadership involvement means immediate feedback and direction for the project team.
  • Ensures alignment across all stakeholders and teams. The folks most directly impacted — senior leadership and the project delivery team — are fully represented. By the end of the Hothouse, everyone is on the same page on everything: the business problems and goals, proposed solutions, high-level system impacts, potential delivery trade-offs, priorities, and next steps.
  • This alignment serves as a much-needed baseline for the project post-Hothouse.
  • Bottom-line is faster product definition and solution development, which speeds delivery time-to-market.

A Hothouse can help you generate innovative solutions to your organization’s current problems, faster and cheaper. More details here. If you’re interested in learning more about agile innovation processes like the Hothouse, or how to implement one at your organization, reach out to me via Twitter or LinkedIn.

Disclaimer: I didn’t come up with the term Hothouse. I don’t know who did. But it’s a name we used internally, and it stuck. I think the original methodology comes from the UK, but I’m not sure. If you happen to know if the name is trademarked, please let me know and I’ll be happy to add the credit to this post.

Selling An MVP

By John Peltier

The Lean Startup movement led by Eric Ries has put the concept of minimum viable product (MVP) into the current vernacular, and certainly into Shardul’s vocabulary. 🙂 An MVP is generally understood to be a product that has just enough functionality to validate that you’ve found market problems buyers are willing to pay to solve, and that your offering solves the problems effectively enough to capture some of the market. This is an attempt to avoid over-building a solution, and solving problems that buyers don’t actually have.

Conducting a full-scale launch of an MVP can be both rewarding and dangerous.

Fraught with Peril

One area of danger is building an MVP that best fits a segment of the market, but selling the solution to the entire market. Buyers from multiple segments force language into their contracts demanding their most critical features, partially solving problems for multiple segments but delaying fully solving the problem for any segment. This makes it more difficult to get glowing references, since buyers from all market segments perceive gaps for a longer period of time.

Another danger is defining your MVP by the functionality needed to demo, versus the functionality needed to use. Teams may be tempted to defer under-the-hood capabilities until after release, especially when feeling the pressure of time-to-market. This gets you to market faster, but with a product that has known gaps.

As things progress, Sales meets resistance due to needs not met in your MVP, and starts bargaining for delivery promises to win deals. Meanwhile, this can crowd out bandwidth to close the gaps–which represent under-the-hood capabilities all buyers will need. Once you say yes to a few deal-makers, you can’t say yes to any more. This will also strain the relationship with Sales.

One way to adjust is to proactively include fewer big-ticket items on the roadmap, while allocating some percentage of capacity to under-the-hood needs. At some point your estimations won’t line up with reality, though, and you’ll have to escalate something that everyone assumed was already there. The silver lining is that these episodes–often a response to onboarding needs, and sometimes useful in winning an early reference–can be used later as an example of why you need to invest in the engine!

A Focused Solution

On the other hand, selling an MVP delivers revenue at perhaps the earliest possible date.  Prospects who don’t need all the bells and whistles encounter a solution that meets their needs, without having to wait for you to build feature after feature that they don’t need. Early adopters likely wouldn’t wait for you to deliver your solution; it’s much more likely that they purchase another vendor’s solution. The other vendor’s efforts to increase the buyer’s switching costs will then make it difficult for you to get that prospect at a later date.

As early adopters, your first clients get to help you decide which 15% of the hundreds of possible features you actually need to build. While a market is much bigger than a handful of early adopters, some effort towards satisfying their needs is warranted if it can deliver you early references, and especially if the things they need are known needs you’ll have to address at some point in the product’s development.

These benefits carry an important condition: the MVP that you provide must solve the core needs well. Adequate won’t win over prospects with lesser needs, and it won’t convince early adopters to provide glowing references. Prospects will need to be convinced that your solution is already so good, that it’s in their best interest to come along with you for the ride.

Your Turn

Depending on the quality of your execution, the early days of being in the market with an MVP can be both hairy and immensely rewarding. What other benefits or drawbacks do you encounter when going to market with an MVP?

John

John Peltier is an accomplished product manager and marketer working in the growing technology community in Atlanta, Georgia. John shares his passion for product management by organizing ProductCamp Atlanta, and by writing at The PM Vision.  John is most easily contacted on Twitter at @johnpeltier.

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.

Top 7 Lessons Product Managers Can Learn From Lean Startup Machine

A few weekends ago, I participated in the Lean Startup Machine workshop held in Washington DC. For some time now, I’ve been thinking about how Lean Startup principles can be utilized to drive product innovation and if they can help product management become more efficient in driving product development and delivery. The Lean Startup Machine (LSM) workshop offered an opportunity to gain hands-on learning in applying Lean Startup techniques. The workshop proved to be an unforgettable experience.

Here are the top lessons I learned from the workshop and how they’re applicable to product management.

1. “Lean Startup is about running the simplest experiment to validate a business assumption.” – @SargeSalman. As I’m learning myself, there are many misconceptions about Lean Startup. Chief among them is that lean means cheap. It does not. Lean means not being wasteful. And the way it’s applied to business problems is by challenging you to think critically about the assumptions underlying your business or product idea, and then to systematically and rigorously test them to prove them true or false.

build-measure-learnLean Startup challenges the traditional business practice of using product releases as the as the metric of execution by espousing learning as the metric of progress through the use of validation/invalidation of one’s assumptions through testable hypotheses. As a product manager, this makes sense to me as one of the things I should be doing is thinking critically and analytically about my product solution.

2. Go talk to your customers. Constantly. Lean Startup starts with Customer Development, a method Steven Blank introduces in his book The Four Steps to the Epiphany. Customer Development asks entrepreneurs to “get out the building”, which is another way of saying, “go talk to your customers.” This exactly what product management should be doing.

As such, this should come intuitively to product management, because product managers should always be focused on the customer. What the Lean Startup movement has done, though, is provided a methodical way to think about and approach how to conduct customer research. At the LSM workshop, we were forced to continually go find and talk to customers. LSM goes beyond theory by providing its participants with a tool called the Validation Board to capture one’s assumptions, create experiments, document learnings, and make the next pivot.

3. Traditional product development is wasteful. On the surface, this systematic way of hypothesizing, experimenting and learning can seem slow, because it’s not visibly tangible. Whereas a requirements document is. And code is. So both business management and even product management get trigger happy to start getting some code written, as its a way of showing demonstrable progress and makes us feel good that the product is getting developed. After all, the sooner the product is out there, the sooner we can make money!

Unfortunately, this traditional approach gives us a false sense of progress. The LSM workshop was a valuable reminder that if you don’t spend time upfront understanding your customers and their needs, you will build products no one wants. I learned this the hard way from first hand experience when I built a first-of-its-kind web product that cost a lot of money and took 6 months to launch only to achieve a miserable 2% registration rate two years after its initial launch. Ouch.

4. You must have a strong team. Now, granted, product managers can’t always choose their team members. Yet, what LSM got me to think is how many product managers think critically about the kinds of team members they’d like and then actually ask for them? And even in the case where one cannot choose their team members, as the leader of that team, how many actually spend time cultivating team unity?

5. Leadership is always, always required. This falls from the above point. The LSM workshop groups participants into teams and each team pursues an idea that received the most votes from the participants themselves. My experience reinforced the need for strong leadership by the team lead. This not only means building strong team unity of purpose, but also being able to effectively arbitrate discussions and be decisive. Exactly what a product manager is supposed to do.

6. LSM will test your influencing skills. Leadership is about influence. Product managers need to be strong influencers and negotiators. At the LSM workshop, you are working with people you’ve never met before on a team, and under a stringent timeline all of you need to come together as a team and demonstrate progress. I found my influencing skills were strenuously tested during the workshop, and it was wonderful.

7. Your solution, while interesting, is irrelevant. Sounds familiar, right? A riff on the traditional product management mantra of “your opinion, while interesting, is irrelevant”, though this takes it to the next level and targets the proposed solution itself.

Customers don't care about your product

Entrepreneurs love their ideas. They love their solutions. And so do product managers. While I’m not saying entrepreneurship and product management are the same, like entrepreneurs, product managers are natural problem solvers and we’re passionate about our solutions. Heck, I get passionate about my product ideas all the time! But the sobering truth is that it’s infinitely more important to first be crystal clear on who is your customer and what is their problem. Because the customer does not care about your product.

The LSM workshop forces you to think about the customer and their problem first. During the workshop, I saw first hand how many people struggled with staying out of the solution zone, including, I must admit, myself. By validating your customer and problem hypotheses, you’ll be in a better position to provide a real solution that solves actual customer problems.

I would definitely encourage you to attend a Lean Startup Machine workshop near you. I’ve written a recap of the one I attended on my blog and explain why I recommend product managers should attend LSM.

Have you attended an LSM workshop? What was your experience like? Have you tried applying Lean Startup principles in your work? Please share!

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.

What Lean Startup Machine Can Teach Product Managers

Update and disclaimer: I had originally attended Lean Startup Machine in October 2012, was a mentor in September 2013, and will be mentoring again this year.

If you’re a product manager or marketer, you need to attend Lean Startup Machine. Why? So you can learn to be wrong. A lot. And faster.

Lean Startup Machine is an intensive educational workshop that lasts 49 hours (yes, you read that right) where attendees learn how to use Lean Startup principles, particularly Customer Development techniques, to validate an idea for a new product or service with actual customers. So if you have an idea that’s been rolling around your head for some time, come to LSM and in 49 hours you will leave either with the real knowledge that your idea stinks (because there are no customers) or quite possibly with a commitment from an early adopter customer in the form of a purchase order, contract or credit card number, or non-cash currency in the form of time, a registration, and email submission or letter of intent. (No, I’m not making this up.)

If you’re unfamiliar with Lean Startup or Customer Development, read this, this, and this.

This past weekend I attended the Lean Startup Machine (LSM) workshop held at The Fort.vc in downtown Washington DC. It started Friday at 6pm and ended on Sunday at 7pm. About 50 people participated representing a spectrum of backgrounds and industries. The youngest attendee was still in high school while some of us, like yours truly, could be considered more “seasoned” professionals.

The basic format is this: anyone with an idea has 50 seconds to pitch it, everyone votes, and the ones with the most votes become team leaders. Everyone else then joins a team. The teams then spend the rest of the weekend validating the assumptions behind their ideas with real customers and iterating based on their feedback with the goal of getting to a point where you can claim customer validation for your product idea. Assumptions and iterations (also called pivots) are tracked via the Validation Board. Proof of validation is in the cash or non-cash currencies mentioned earlier. If you think this sounds unrealistic to accomplish over a weekend, read this.

The first thing the team does is identify who they believe is their target customer for their product idea – called the Customer Hypothesis – and what problem they believe their solution solves for these customers – called the Problem Hypothesis. The team then identifies all the assumptions underlying their Problem Hypothesis and then picks the Riskiest Assumption among all these. This is the most important assumption of all your underlying assumptions – the one that if it turns out to be false tells you the problem you thought exists actually doesn’t.

With the Riskiest Assumption identified, the team creates an experiment to invalidate that assumption. What this means is you go find real customers to talk to who can tell you you’re wrong. That’s right: the purpose is not to be proven right; it’s to be proven wrong.

What this also means is that you’re getting out onto the street and interviewing actual strangers to find out (a) if they meet your Customer Hypothesis, and (b) if they do, do they have the problem you think they do?

If you get enough potential customers confirming your assumption, you may be on to something and may have the opportunity to actually pitch them your idea in the form of a minimum viable product. It’s more than likely, though, either you won’t find any suitable customers or they’ll tell you they don’t have the problem you thought they did. And that’s when the real fun begins, because you’re then forced to pivot, which means either re-visit your Problem Hypothesis or perhaps test your hypothesis with another type of customer.

This happens over and over at an extremely rapid pace. You are in a constant flow of documenting your hypothesis, creating your experiment, listing your questions for the customer interviews, getting out of the building to go find people to talk to, capturing your findings, and then repeating the cycle. You use the Validation Board, sticky notes and markers to keep track of all this stuff. Along the way, you’re guided by extremely helpful mentors – former and current Lean Startup entrepreneurs and practitioners. There are also presentations by other lean practitioners to share their experiences and insights, and to keep you motivated.

The workshop ends with team presentations on Sunday evening and a winner is announced.

LSM was a unique and unforgettable experience that I’d recommend to anyone with a product or business idea. But I was particularly struck by how much product managers and marketers can benefit from participating in LSM and learning the Lean Startup approach. Why?

1. To get better at customer research. Product managers and marketers need to be spending their time understanding customer problems. While data and metrics can tell you a lot, nothing will tell you more than actual customer interviews. But there’s a right and wrong way to do this. LSM will give you a crash course in the right way so you can get to the true nature of the customer’s problem as quickly as possible.

2. To learn how to validate your ideas quickly. Product managers are natural problem solvers. But running with the first idea that strikes as a solution will cause you to run into problems of your own. So testing ideas is important. “Build and launch” is not the way. “Test and learn” is. LSM will force you to think critically about the most important components of your idea – who is the customer and what problem do you think you’re solving for them – and give you the tools to rigorously and systematically test these. The structure of the workshop will force you to go through this hypothesize-test-learn loop as quickly as possible so you can start discarding bad ideas quickly so as to get to the potentially good ones faster.

3. To get their teams past debating opinions and intuition, and focused on validated learning. Product managers typically work in teams whose members don’t report to them. So the ability to influence defines success or failure for a product manager. Everyone thinks their idea is the most credible and, particularly in agile teams, everyone has an equal voice. Even when data is available, it is still subject to interpretation. LSM gives product managers the tools that enable them to get past the opinions and subjectivity by capturing everyone’s point of view as a hypothesis that can be rigorously and systematically tested with actual customers. Product teams can cycle through the opinions and get to what customers really want faster while maintaining team harmony.

4. To practice your influencing skills. Related to the above. A product manager with poor influencing skills will fail. Period. LSM is a team-based workshop. You’re working with total strangers to validate an actual product idea. And you’ve got precious little time to do it. Everyone’s opinion counts. The cauldron of LSM is perfect to test and refine your ability to influence.

5. To learn the value of doing and being decisive. LSM will teach you to quickly get over your fear of having the perfect answer, being wrong or looking stupid, which often becomes a roadblock to actually doing anything. Instead, you’ll be forced to be decisive and do stuff so you can learn from mistakes quickly.

6. To learn that you’re often wrong. Some product managers fall into the trap of thinking they’re always right by nature of being a product manager. “Product management represents the customer, so of course I know best!” is how the thinking goes. This is dangerous. A product manager’s value is not in being the know-all about what’s best for his or her customers. Rather, it’s in the product manager’s ability to truly understand the customer’s problems and lead the organization to visualize and deliver a viable and innovative solution that the product manager’s value lies. LSM will teach you how to do this in a sustainably repeatable process.

7. To learn to distinguish between vision and details. Every product starts with a vision of a potential solution to a problem. Being natural problem solvers, product managers often have a vision for how to solve their customers’ problems. It’s a fine line between knowing when to keep to the vision and when to admit it just won’t work. LSM is a great way to learn how to stay true to a vision, but be flexible on details.

Check out when and where is the next Lean Startup Machine workshop here.

Have you attended LSM? What was your experience like? What were the key lessons you took away?

Lean Startup in a Large Company

I’ve started reading Ash Maurya’s book, Running Lean, and have begun educating myself on Lean Startup practices, a term trademarked by Eric Ries. It’s is a fascinating approach to launching a startup, and has a passionate cult following that’s trying to break through into mainstream practice. Being a product guy, I view startups as new product development – both require business modeling, validation with customers, investment, product build and market launch. (I’m not saying a startup is the same as NPD in an established company – I’m just saying they share similar traits.)

I like Ash’s Lean Canvas that he discusses in his book. For capturing an initial vision of a business model concept, it’s fast, concise and portable, with key building blocks identified all on one page vs. creating a 20-page or 15-slide business plan that takes too long to build and no one will ever read anyway. Multiple models or canvases can easily be sketched out in a single afternoon. It allows for fluidity, as sections can be left blank and then filled in or refined based on learnings. It also forces thinking in the present with a “get it done” attitude. Most importantly, it uses a customer-centric or “tuned in” approach. (Tuned In is another book I admire.)

Ash candidly admits the methodology he proposes in his book is for web application startups. But at the end, he throws down a challenge: “What about ‘Running Lean for X’?”

So I began to think:

  • Can Lean Startup practices be applied at an established company? At a large enterprise?
  • What about Running Lean for a B2B2C product?
  • And what if that B2B2C product wasn’t software, but a service?
  • Can Lean Startup practices be applied to Product Management?

This last question intrigued me the most, because I have always felt that Product Management could be more entrepreneurial in its approach, yet like almost all Product Managers, I’ve had Pragmatic, ZigZag, Crossing the Chasm, and other frameworks drilled into me as the gold standards for identifying, developing, positioning and launching market-driven products. If Lean Startup principles can be applied to Product Management at enterprise firms, does it challenge these tried and tested methodologies, evolve them, or – dare I say – render them obsolete?

Ash encourages his readers to field-test concepts and models first-hand. I like that approach. And because I do currently work at a large B2B2C company that sells services rather than software or tangible products, I’m doing just that. I started applying Running Lean and Lean Startup concepts on some new ideas I’m kicking around. The focus, as Ash encourages in his book, is “Validated Learning”. As I tried to capture my vision onto a Lean Canvas, I immediately ran into challenges:

Who is the real target customer? In B2B2C, consumers may be the end-users of the product, but what if an intermediary is actually the one paying for it? So do I have two target customer segments?

The first question cascades into a series follow-up questions.

Whose problems are we really solving? If I do have two target customer segments, do I have two sets of problems to address? Two sets of solutions? Different unique value propositions for each one?

How to succinctly capture the Solution? In B2B2C, doesn’t the product ultimately have to have features appealing to both the C and the B?

Revenue streams: The nice thing about B2B2C is you can get pretty creative with revenue models. In the services industry, you can get even more creative. And that’s where again I found the Lean Canvas constraining at first. How can you concisely capture a potentially complex revenue model?

And how do I capture all of this on a 1-page Lean Canvas?

In the end, I decided to focus on the C, approach it strictly from the customer standpoint, and treat the B as a channel, largely because it made the exercise easier and thinking from the customer’s perspective comes more intuitive to me. I’m not saying this is the right approach. I’m saying it’s what allowed me to get through the exercise (so far).

I’d love to hear from you. What do you think?