Tag Archives: lean startup

The secret ingredient to getting product innovation done

So you’ve probably heard of “earlyvangelists”.

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

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

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

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

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

Now, juxtapose this with traditional product management.

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

Cool.

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

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

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

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

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

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

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

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

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

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

Good intentions.

But here’s what actually happened.

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

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

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

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

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

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

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

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

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

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

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

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

How many people does it take to change a lightbulb?

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

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

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

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

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

#3 Biggest Innovation Challenge: Resources.

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

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

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

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

We need a product to test whether customers value it…

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

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

So what’s the solution?

This brings us back to “earlyvangelists”…

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

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

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

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

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

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

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

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

Here’s an example:

Customer learning driven investment strategy

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

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

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

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

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

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

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

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

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

Create Your Business Case Using Customer Development

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

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

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

 

How A Rusting Giant Can Act More Like A Startup

This is a Q&A with Trevor Owens, Founder of Javelin, by Adam L. Penenberg originally published on PandoDaily, and re-printed here with Trevor’s permission.

Why should big companies emulate startups?

Back in the day, everyone wanted to work at a place like IBM. Today corporations are viewed as stodgy. Many of us don’t know what they do anymore and even if we did, we probably wouldn’t care. These bloated companies with their thousands of workers trapped within walls of bureaucracies aren’t growing anymore. In fact, their markets are shrinking.

The time between the birth, growth, and death of a large enterprise has shrunk dramatically over the years. Of the companies listed on the Fortune 500 in 1955, nearly 87 percent of them have either gone bankrupt, merged, reverted to private ownership, or lost enough gross revenue to be delisted. A study of the S&P 500, which ranks companies by market cap, found the average age of a business on the list was 61 years in 1958 but only 18 years in 2012. In the past, being big was in itself a defensible position. Now it’s not.

Contrast that with the frenetic growth and buzz surrounding successful startups. Instagram employed just 12 people when it sold for $1 billion. Snapchat had about 30 people when Facebook offered to snatch it up $3 billion. Whatsapp employed 50 or 60 people when it sold for $19 billion.

Big companies see this, and feel the cultural pull away from them. They’re starved for growth. If they want to compete, they have to become more like startups. Otherwise they’re in jeopardy of disappearing all together.

Why do big companies have trouble innovating?

When a company gets big, bureaucracy is layered throughout. In some ways it’s a necessary part of growth. The reason it exists is so the company doesn’t fall apart. The more people you have working for you, the more you need to manage them to ensure they get the support they need to do their jobs. Then you have whole divisions that exist simply to produce and sell, and their heads aren’t interested in new ideas, products, or ways to do things that could interfere with their bottom line, because that’s how they’re judged and compensated.

Couple all that with the main goal of a company, which is to serve existing customers. That’s where the resources go. Corporations offer an environment of execution and maintenance but not innovation, and rely on good management to target their best customers and deliver better products. That’s fine when they’ve identified and mastered their markets, but they get disrupted when a new entrant comes along that can deliver a good enough product at much lower cost of higher convenience. New entrants target low-value customers then quickly climb the value chain with a better cost structure. Think Netflix versus Blockbuster or Napster invading the recording industry.

Part of issue is there’s no management philosophy built around how to innovate within a large enterprise. With new companies we have the Lean Startup Method, which offers a framework for constantly improving a product to find the best product-market fit before you actually go into production or invest gobs of money in creating any infrastructure. This is the first time we’ve had a repeatable process. But there is no analog for large companies. They have to develop some basic structures just to deploy lean startup methods.

How are some big companies innovating like startups?

There are two parts to innovating like a startup. One is generating a flow of high-quality (i.e. validated) ideas. We call this “innovation flow” — similar to the idea of deal flow for venture capitalists. If a VC doesn’t have good deal flow he won’t get returns.  The other is the need to create a structure to incubate these ideas called an “innovation colony.”

Intuit does the first part well. It kind of copied our lean startup workshop and scaled it throughout the company. After employees have been trained in lean startup methods and know how to validate ideas, they can take advantage of unstructured time (also known as 10 percent time) to work on any project they want to validate that can potentially become a successful new product. If they find they have something they can go to their boss for funding, and this has led to some viable products, including Sparkrent.

Facebook is famous for hackathons. That’s where the Timeline was first imagined. Employees can work on anything that relates to the company’s products and deliver a down-and-dirty prototype during a 24-hour hackathon. Companies like Nordstrom are becoming sophisticated at lean startup methods. It runs weeklong experiments. One from 2011 involved an iPad app that helps users choose eyeglass frames and another addressed the physical design of its retail stores.

Companies also acquire startups to “buy growth,” although few buy at the right time. One that did was Twitter, which acquired Vine before it launched, left it alone to carry on its mission without interference, and it ended up a great acquisition. Vine clearly had product/market fit right out of the gate.

What about skunkworks, innovation labs, and intrapreneur programs?

For large companies there are three traditional innovation structures:

First, there’s skunkworks, when you hire a bunch of smart people to work on pie-in-the-sky technologies. Motorola, for example, hired away a former head of DARPA to run its skunkworks. It only works on highly technical products with low market risk — like a faster jet plane or Amazon Web Services. It’s not good for developing, say, an app like The Daily and it won’t help you find a market or determine product-market fit.

Then there are innovation labs. Perhaps the best known was Xerox Parc, which was the original Innovation Lab. It came up with brilliant ideas but failed to commercialize them — until Steve Jobs came along and borrowed (some say stole) them. Innovation labs that focus on innovative technologies are known to struggle with commercialization.

Finally, you have intrapreneur programs, which are the latest fad: a four- or eight-week program where employees take time off, explore some ideas and a product, and have to sell it to a business unit within the company.  The issue comes back to the incentives inherent in successful business units. They resist ideas they didn’t come up with, no matter how big their potential. They favor incremental innovation that won’t cannibalize their own sales over something that could change their industry for the better.

As a corollary you can have something we recommend: innovation colonies. This is a way for companies to create a fund to invest in ideas their employees have. To participate, though, the employee has to give up the security of their jobs in exchange for equity in the venture. Microsoft, Kaplan, Nike, Barclays, and Disney are just some of the companies utilizing innovation colonies.

Here’s how they work: Employees pitch their ideas, which have been validated, get funding, and own a majority of the equity in these products in the seed stage. They work with other entrepreneurs and the company offers advisement, mentoring and other resources. They seek to develop products, take them to market, and if they gain any traction they can raise a series A with outside investors. They run the company without interference from the Mother ship. In the end, the big company can offer to buy their startups back. The magic is that the entrepreneurs are incentivized to build a real business.

Is it a good idea to offer equity stakes within corporate environments?

Oh, yes. In fact, we advocate for employees to get equity on their projects. Let me emphasize that I mean equity in the product, not the company. Equity attracts the best people because entrepreneurs are motivated by achievement and autonomy and are willing to take less in salary in exchange for more upside in their ideas. Of course, they want to see millions from their products, if they’re successful, but it’s not just about money; it’s what it represents. It’s about being recognized for your achievements. Face it: you have to be a little crazy to be an entrepreneur. This is the whole point of the innovation colony structure.

If you don’t give employees who are entrepreneurially minded equity in their projects they’ll leave to start their own companies. This happens even at innovation-friendly environments like Google: Ev Wiliams (Twitter), Kevin Systrom (Instagram), Dennis Crowley (Foursquare) all left to launch their own ventures. It’s unfortunate that Google doesn’t share in any of the billions they’ve created.

Not only do you want to hire the best and brightest, you want them to stick around and create the kinds of innovative products and services that will also ensure your company sticks around for the long term. Some large companies make the mistake of addressing a problem by simply throwing 15 developers at a problem thinking it will lead to something. Instead, great ideas come from all over an organization and may even seem like bad ideas at first until you validate them.

Once a company realizes this, anything is possible.

Trevor Owens is a thought leader on Lean Startup. He is the Founder of Javelin, a provider of tools and services to learn, launch and track new business ideas, and Lean Startup Machine, a three-day workshop that teaches entrepreneurs and innovators how to build startup products. He has a new book called The Lean Enterprise that talks about how to bring the startup mindset to larger organizations.

Yes, Startup Products Can Take A Village

Thomas Pichon is the Founder of The Collaborative Startup. He advocates building a community to gain traction for a startup, and I thought the advice could equally apply to an “internal” startup. The article below is re-posted with his permission from his free e-course.

By Thomas Pichon

I am helping an entrepreneur build a yoga retreat, and I asked her how she was going to build her project. She said:

“I guess I’m going to concretely build the service, which means finding where we’re going to host the retreat, build the program, etc… Then, I’ll try to advertise it.”

I used to build products with this kind of strategy for years. Results have never been extraordinary. However, I have discovered one which brought me much more success:

  1. Build your community. Share helpful content related to the service you want to provide in order to attract people.
  2. Ask them what is their biggest frustration. Build a service around this problem.
  3. Get pre-orders. Start collecting credit card numbers before you have built the service. If you have created trust with your community by providing helpful content from day 1, you will see that this step is much easier than it looks now.

Hope these lines help you understand how to start your business. Do not build your product, then try to sell it. Sell it, then build it. And the better way to sell it before having the product ready is by building trust within a community.

So start now! Write helpful content about your topic in order to start building trust! Share it where your target audience hangs out online.

If you need any advice on this topic, or more generally about startups, you can schedule a call with me anytime, or ask your questions on my forum.

Thomas Pichon is the Founder of The Collaborative Startup, an innovative initiative designed to help entrepreneurs by leveraging the power of community development, Lean Startup and crowdsourcing.

For Corporate Innovation, Lean Startup Is Not Enough To Define Your MVP

One of the biggest challenges product innovators in established companies face in defining an MVP is getting buy-in from internal stakeholders. Be they senior executives, peers, other departments, partners, or even your boss, corporate product innovators have multiple constituents to manage. Somehow, you have to make everyone feel a part of the process without letting them run over you and having your MVP be destroyed by feature bloat right at the definition stage.

This is an area I’ve not seen the Lean Startup movement address. So let’s do that here. The way I’ve done it is by fusing Lean Startup methods with Product Management practices — specifically, by leveraging a process every Product Manager knows: roadmap prioritization.

My friend, Bruce McCarthy, has talked about the 5 pillars of roadmaps, the first 3 of which are:

  1. Setting strategic goals
  2. Objective prioritization
  3. Shuttle diplomacy

These same pillars can be used for defining an MVP and getting stakeholder buy-in.

Setting Strategic Goals

The first step is to capture your product strategy. I wrote about how you can do this quickly using the Product CanvasTM.

What’s great about the Product Canvas is it allows you to document your vision in a simple, portable and sharable way. The trick is to be concise. The intent isn’t to capture every nuance of the customer’s problems, nor detailed requirements. Just stick to the top 3-5 problems and the top 3-5 key elements of your solution.

This forces sharpness not only in your thinking, but also in your communication with stakeholders. This, in turn, encourages more constructive feedback, which is what you really need at this stage.

Objective Prioritization

You’ve probably received a lot of internal input (solicited and unsolicited) on features for your product. Most have probably been articulated as “must-have’s” for one reason or another. Of course, you know that most of them are probably not really needed at this early stage, certainly not for an MVP.

To quote from the book Getting Real by 37signals: “Make features work hard to be implemented. Each feature must prove itself.” For an MVP, each feature must be tied to tangibly solving a top customer problem.

Bruce discusses using a scorecard type system to objectively prioritize features for product roadmapping — in particular, assigning a value metric for a feature’s contribution toward the product’s business goals, and balancing it against a level-of-effort (LOE) metric. The exercise can easily be done in a spreadsheet or Reqqs, an excellent roadmapping tool he’s developing.

A similar approach can be used to prioritize the features for your MVP:

1. Rank each Problem documented in your Product Canvas in terms of your understanding of what is the customer’s top-most problem to be solved, followed by the second, etc.

2. Map Solution elements to Problems. These may not necessarily be one-to-one, as sometimes multiple elements of your Solution may work together to solve a particular customer problem.

3. For each Solution element, identify if it’s a “must-have” for your MVP. Solution elements meant to solve customer Problem #1 are automatically must-have’s. The trick is in making the determination for the remaining Problem/Solution mixes.

4. Identify all features for each Solution element. If you already have a list of feature ideas, this becomes more of a mapping exercise. The net result is every feature idea will be mapped directly back to a specific Problem, which is awesome.

5. Mark each feature as “In MVP” or not. Be ruthless in asking if a feature really, really needs to be part of the MVP. (Tip: not every feature under a “must-have” Solution element necessarily needs to be “In MVP”.)

6. “T-shirt size” the LOE for each feature, if practicable. Just L/M/S at this point. A quick conversation with your engineering lead can give you this.

Like with roadmap prioritization, this entire exercise can also be done via a simple spreadsheet. Here’s a template I use that you can freely download.

The beauty of the spreadsheet is it brings into sharp focus a particular feature’s contribution toward solving customers’ primary problems. And an MVP must attempt to do exactly that.

Shuttle Diplomacy

To paraphrase Bruce from p26 of his presentation, this is probably the most important part of the process — you need to get buy-in from your key stakeholders for your product strategy and MVP definition to be approved and “stick over time”. Bruce shares some excellent tips on how to do this on pp26-30. You need to do the same with your Product Canvas, and then with your MVP definition spreadsheet.

When you practice shuttle diplomacy:

“A magical thing happens. ‘Your’ plan becomes their plan too. This makes [review and approval] more of a formality, because everyone has had a hand in putting together the plan.”

To be clear, you’re not looking for “decision by committee”. As the product owner, you’ll still be looked upon as the final decision maker (remember to stand your ground), but you’re actively trying to bring others along by encouraging input and providing visibility.

Lean Startup purists may vomit at this, but that ignores the realities of getting things done in the corporate world. As Henry Chesbrough writes, “You have to fight — and win — on two fronts (both outside and inside), in order to succeed in corporate venturing.” This means corporate innovators “must work to retain support over time as conflicts arise (which they will).”

This means Stakeholder Development. And that requires shuttle diplomacy.

Here again is the link to download my MVP definition template. Let me know what you think!

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


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.

“Stakeholder Development”: Using Customer Development on Internal Stakeholders

In my last post, I introduced the Product Canvas — my iteration of the Business Model Canvas — as a simple and quick way to capture my idea for a product. I’ve also used it as a communication tool to share my product vision and get early feedback, which is critical in the beginning stages of exploring a new product opportunity.

I’ve been sharing the Product Canvas with anyone who’s asked, and early feedback has been encouraging. One of the biggest things that seems to be resonating with folks is the Key Stakeholders box.

Product Canvas - Key Stakeholders

Look, I’ll admit, managing stakeholders is cumbersome, tiresome, and at times a pain. There, I said it. Admit it: you’ve felt that too. In my research on the business case process, a large majority stated that maintaining stakeholder support and alignment is important, but a challenge.

But I’ve learned the hard way that identifying and aligning stakeholders is really important for any initiative. So that’s why I put it in the Product Canvas. The reality is lack of stakeholder support can kill any brilliant idea at any stage.

When I came across Steve Blank’s Customer Development methodology, I wondered if its principles could be applied to internal stakeholder support. In other words, I wondered if it was possible to “develop” stakeholders too?

Here’s the Customer Development process. Steve’s bottom-line advice is to “get out of the building”.

Customer Development

So if apply this to “Stakeholder Development”, I’m thinking the process would look something like this:

Stakeholder Development

In this case, the bottom-line activity is to “walk the building”!

I figured this provided me as good a workable framework as any to identify, build and grow stakeholder support, and then I decided to put it to the test.

Through much trial and error, here are some tactics I’ve applied to Stakeholder Development. I’ll admit I haven’t fully cracked the code, and continue to experiment and learn. By sharing here, I’m hoping others may try as well and share their feedback.

I try to follow a systematic process for identifying my stakeholders, sharing my vision, capturing their feedback, and creating traction. I’ve been experimenting with applying Lean Startup’s Build-Measure-Lean loop for the purposes of doing this, and over time, I’ve developed a basic meta pattern:

stakeholder_dev_loop

So now that I’ve got a workflow I can follow, my first step is to identify who I think are my primary stakeholders, and I capture this in the Key Stakeholders column of my Product Canvas. Sometimes I already know ahead of time. In that case, I simply list them in the Product Canvas. But I have been in situations where I wasn’t entirely sure who were my key stakeholders. In this case, I capturing my hypothesis for who they may be.

I also try to identify a possible executive champion or sponsor – something I’ve learned is practically a requirement in a larger organization to ensure the success of any initiative.

So my Product Canvas could look something like this:

Product Canvas - Key Stakeholders example

I’d have actual names in the box, of course. If I don’t know who my executive sponsor will be (insider’s tip: it’s not always your boss), I don’t put a name, but I definitely call it out so it’s always at the forefront.

Next, I formulate hypotheses to approach my potential stakeholders. Going back to the Stakeholder Development flow above, notice a key question is “What are their agendas?” Remember: everyone has their own set of priorities. Some are visible, like a project deliverable; but some are invisible, like organizational political pressures. (Like it or not, these exist.) The more knowledgeable I can about their priorities, the better I can position myself to either gain their support or counter their arguments. At worse, I’ll have identified a potential detractor early on.

I then “walk the building”, reaching out and setting up meetings. For stakeholders with whom I don’t have a close relationship, who barely or don’t know me, I try to figure out ways to get an intro, just like one would do with customer interviews.

Setting up and conducting these conversations may be time consuming, but they are invaluable to validate who are my real stakeholders, and what I’ll need to do to get their buy-in.

I maintain a simple log to track my progress that I call my Stakeholder Development Tracker:

Stakeholder Development Tracker

There have been times I’ve discovered that someone who I thought would be an important stakeholder, actually isn’t. Great: I just mark their Role and Status as as N/A, and move on. Other times, I discover that someone I originally hadn’t identified is actually going to play a significant role in the approval and/or execution of my project.

Stakeholder Development Tracker Example

As I validate who are my true stakeholders, I update my Product Canvas.

product-canvas-key-stakeholders-iteration

These stakeholders are the ones I really want to focus on, the ones with whom I want to create traction. If I play my cards right, I can convert them from supporters to advocates to where they are actually personally vested in the success of my initiative.

As I said, I’ve been experimenting with this as a framework. It’s a work-in-progress, and I’ve enjoyed some success. Give it a whirl yourself, and let me know what works or doesn’t. If you have an approach to Stakeholder Development that’s worked for you, please share.

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.