Tag Archives: customer development

The Top Strategies For Doing Customer Interviews That Get You Real Insights

We all know a core responsibility of a product manager is to constantly and consistently bring the customer perspective into the business.

That means customer interviewing is a critical skill for every product manager.

I must admit, earlier in my career I totally sucked at it.

I had no plan. I often just winged it. I asked the wrong questions. I was a poor listener. I talked more and listened less. I tended to get too excited about my product idea and go into pitch mode instead of focusing on the customer’s problems. And I was very guilty of confirmation bias.

Fortunately, with lots of practice, over time I got better. As I did, I accumulated a list of the best strategies that I use even today to conduct an interview that helps me extract real customer insights.

Get the Entire List of 25 Customer Interview Strategies >>

So in this video I share 5 of the best customer interview strategies:

Use these 5 powerful tips to supercharge your customer interviews to extract every ounce of goodness from them:

  1. Set an objective. Know what you want to get out of the interview — that is, what is it you want to learn and come away with?
  2. Have a script. Having a script will help guide your interview with the customer, be better prepared and purposeful in your interviewing, and make sure you achieve the objective you’ve set out.
  3. Ask “Why?” — a lot. This is by far the most important question in your arsenal. It allows you to go deep, get inside the mind of your customer, understand their motivations, get to the true nature of the problem they’re trying to solve, and how they actually value their solutions.
  4. Ask for examples. Asking for an example forces your customer to get specific rather than speak in generalities, giving you tangible evidence of a customer’s problem, and allowing you to momentarily “live in their world”.
  5. Focus on listening. Cannot stress this enough! The biggest thing you can do is to TALK LESS AND LISTEN MORE. Your purpose is to get THEIR perspective — not promote your point of view, explain yourself, defend your idea or debate. The only times you should look to speak is when you need to clarify something or need to ask a follow-up question.

Get the Entire List of 25 Customer Interview Strategies >>

Follow these strategies and you’ll become a pro at conducting truly insightful customer interviews.

Watch the video above, download the full list of customer interview strategies, and please share in the comments below what strategies you’ve developed to conduct truly insightful customer interviews.

The Secret Ingredient To Getting Product Innovation Done: “Internalvangelists”

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 these special breed of customers. Why? Because they’re the ones willing to make the initial bet on the startup, because they’ve bought into the startup’s vision and potential. They’re not just buying release 1, 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. Test customer and problem hypotheses. Test solution hypotheses. Create an MVP. Find problem/solution fit. Get true customer validation by finding a handful of customers who are actually willing to pay you for your solution — the “earlyvangelists”.

Juxtapose this with traditional product management.

Now, when I started out in product management, I was indeed 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.

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.

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.

For example, the CFO needs to be able to answer a question from the Board like, “That $250,000 in development resources you spent last year… what are we getting for that?”

So a solid business case with cost/benefit, ROI analysis, risk profile assessment, etc., would allow for objective portfolio and investment decision making.

Good intent.

But here’s what actually happened.

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

“An exercise in pretend,” the product manager grumbled.

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

“Well, you need to figure it out,” Big Exec would shoot back. “Else, no resources for you!”

And so the product manager would torture the spreadsheet more, 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/IT 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.

(Meanwhile, that Sales guy with his own “great” product idea has already sold vaporware to two customers and is magically getting resources assigned to deliver on his promise, including you, the product manager. Sales guy: hero. Product Manager: zero.)

The saddest part of all this was that every minute 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 opted into my upcoming online course, Idea To Revenue Masterclass, they listed the following as their biggest product innovation and planning challenges:

#1 Biggest Innovation Challenge: Testing product ideas without having a product. 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 light bulb?

(Or maybe the question is: how many people does it take to get approval to change the light bulb?)

This challenge is a close second to #1 above. 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 communicating 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

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).
– Henry Chesbrough, Why Internal Ventures are Different from External Startups

#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 — need a product to test whether customers value it, but 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, or “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 may not only have access to essential information and resources you may need, but also 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 creating them into advocates — evangelists — for your product initiative.

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

The good news is a lean approach that fuses customer development type methods with sound product management practices can be used to not only get early customers, but also 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. But if there is, then only 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 large bloated ones 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 To Get Quality Customer Insights (Spoiler: It’s Not About Time)

A Sales Exec and I were debating whether amount of time spent with a customer is a measure of the quality of the customer interaction.

His argument:

Just curious — do you see 23 touches for 5 mins the same as 23 touches for 1 hour each — I think it is different and material.

From my perspective, I need to allocated a certain number of hours per week with customers, and believe that number in a normal week is likely 5 hours. I am not sure if that is right, but 5 hours out of 40 per se seems about right. To me, a 3-hour dinner with a customer will be very revealing.

Time matters… Speaks to quality, don’t you think?

His assumption here is that there’s no meaningful insight to be gained in a 5-minute conversation. He’s also arbitrarily picked 5 hours per week. (Why not 4? Or 2? Or 8?)

My response:

Here’s how we should think about it.

Why are we seeking VOC? What’s the purpose?

At the most fundamental level, in any situation, there are three kinds of customer insights we’re trying to gain:

  • Problem Discovery
  • Problem Hypothesis Testing
  • Solution Hypothesis Testing

There are many techniques to accomplishing these. The specific ones we use depends on the situation.

For problem discovery, a series of 1-on-1 interviews is best. These take time. 45-60 minutes an interview across 10, 20, 50 customers, for example.

For hypothesis testing a broad problem domain, again, 1:1 interviews may be best to start with.

So in this case, I’ll opt for 23 phone conversations of 30-60 mins each, because I know neither email nor a survey nor a 5-min phone conversation will provide me the richness of insight I need.

For solution hypothesis testing, it can vary.

If I’m validating a mockup of a potential solution the customer has never seen before, a 20-60 min interview may be needed.

In all the above situations, I want the richness of the fluidity of the conversation, have an opportunity to ask follow-up questions, and feel the customer’s emotional responses.

But let’s say I’m trying to validate the need or usefulness of a specific feature — i.e., will it or does it solve a specific, previously identified customer problem.

In this case, using an email or an automated tool would enable 23 touches in 5 minutes, and work perfectly. I could do it via phone calls, which would have taken longer, but ultimately would have given me the same quality of insight.

Another example is having weekly meetings with the Sales team.

The meeting doesn’t preclude the opportunity for a Product Manager to get on sales calls and demos. However, there’s great efficiency and value to these meetings, because in 30 mins I get buyer feedback across all our products from 9-10 folks who are making a large number of customer calls every day.

Which technique to use in any given situation depends on the type of VOC one is seeking, the purpose of seeking it, ability to access the customer quickly, the time available to seek and act on it, and of course reasonable judgment.

With respect to allocating time for yourself to obtain VOC, that’s a different thing.

You’re a busy person, so it’s perfectly reasonable you need to figure out how much time to allocate for VOC vs. other tasks.

But that’s solving your problem — your problem of time allocation.

It’s different than the how, what and why of obtaining the VOC itself.

And provides no guarantee of the quality of customer insight that you may gain.

RIP PRDs. Long Live “Agile Conversations”

I don’t write PRDs.

Product Requirements Documents.

They take too long to write and are typically outdated by the time they’re “finished”, which, it turns out, they never are.

They’re never finished because the market changes. Customers’ needs evolve. Competitors change conditions. New technology changes everything.

Worse, they typically end up creating even more documentation.

Years ago, I worked in a company that followed a pretty typical waterfall process. Product Managers produced PRDs. (MS Word docs.) Big, multi-page docs that contained sections like “Product Overview”, “Business Objectives”, “Features”, “Personas”, “Use Cases and User Scenarios”, and a detailed itemized list of “Functional Requirements”.

Then Business Analysts translated them to “Functional Specifications”. (A bigger MS Word doc.) And then a System Designer translated those to “Technical Design Specifications”. (Yet another even bigger MS Word doc.)

Crikey, we weren’t building an aircraft carrier! We were just trying to build a software app.

Imagine if something had to change in the PRD? (Which it always did, of course.) That change had to get propagated down to each document.

More writing…

But here’s the funny thing: these documents never seemed to reduce the need for the humans involved in the project to talk to each other.

Each of these documents were typically followed by meetings. Meetings to discuss the very documents that were produced. To go over them page by page, line by line.

Going over such a large document takes time. So we’d schedule 3-hour, 4-hour, 6-hour meetings. (No kidding.)

But no one likes long meetings. So after a minor outcry, these meetings were reduced to 1.5 to 2 hours tops. The result was the poor Product Manager (or Business Analyst or System Designer) was now pressured to run through the same big document in less time.

Of course, it didn’t mean people had fewer questions, though!

So inevitably we’d run out of time and have to schedule a follow-on meeting to get through the rest of the document and answer questions we weren’t able to get to.

It’s not easy to coordinate the schedules of so many busy people…

Net was the original 3 or 4-hour meeting was now spread across multiple sessions that took place over several days or even weeks, and we ended up spending more time in total.

More time in writing and discussing documentation.

This could take weeks. Often, months.

And don’t get me started on the “change request” process!

And with so much time spent in writing and discussing the documentation, you’d think the output — the actual product that was delivered — was built as expected.

Nope.

It was amazing how often, despite all the effort invested in documentations and meetings, some particular piece of functionality wasn’t delivered as originally envisioned.

So often it would be due to some disconnect between the various documents everyone was trying so hard to keep synchronized.

I swear, it would make me want to rip my hair out (of which I seem to have less of with age!).

We spent so much time producing, coordinating, verifying, validating, and CYA-ing the documentation that we didn’t do the thing that was most important:

Delivering value to customers as quickly as possible.

Our time is better spent interacting with customers, testing solutions delivering product to them, getting their feedback, and acting on that feedback as quickly as possible.

After going through this one too many times, I vowed never to do it again. That’s when I began experimenting not only with agile software development practices, but customer development and other lean strategies to test, validate and iterate on the business planning aspects of delivering software and digital products and services.

Over time, I’ve developed a more lightweight, human-friendly, and — yes — agile approach to testing, building and launching products. One that has a proclivity toward action and conversations, is fueled by customer centricity, and is predicated on delivering business value and speed-to-market.

To be honest, this approach isn’t particularly revolutionary, and I certainly can’t lay claim to having invented any aspect of it. It’s all pretty much what’s covered in the manifesto for agile software development, and the good news is these practices are being increasingly adopted in different companies and industries for different types of software products and digital initiatives.

And yet, every week I get an email like this:

“As you preach, long MRD/PRD’s make no sense. However, there is some need to provide our business analyst with some form of requirement. What do you do in these cases? I have a Feature Requirements doc I created, but I sometimes feel it is overkill. What would you recommend?”

People are increasingly aware of agile and lean practices. The agile manifesto is in the public domain. There are books on Lean Startup and customer development practices. But what this email (and countless others I receive) shows is that it’s one thing to be aware of a thing, and it’s another to actually put it in practice.

In fairness, that’s understandable. For one, people have different learning curves, in aptitude and even willingness to change. Old habits can die hard. There are also different environments, organizational structures and cultures to consider. Innovating in a startup is different than innovating in a global enterprise company. And then there’s special snowflake syndrome.

I’m on a mission to help as many of these product managers as I can. In my reply to this product manager, I shared the specific practices, activities and tools my teams and I use to replace the overblown PRD process. And I want to share them with you.

Here’s my reply (almost entirely copy-pasted here):

  • I no longer write MRDs, PRDs, or any sort of traditional functional spec. Haven’t written one in years. I don’t have my teams write them either. They’re a total waste of time.
  • If we have time, budget and bandwidth, we’ll always get a Designer to create the screens before getting it to Engineering. Doing otherwise is a waste of Engineering’s time. Only caveat is I keep my Engineering Head / Chief Architect informed and involved.
  • Since the Designer is the initial recipient of the stories, we can write them at a fairly high level. We don’t get hung up too much on granular acceptance criteria — the use case, user goal or job story is much more important at this stage.
  • As such, at times we’ve provided just a 1-pager with bullets. Because design is iterative, we lean more heavily on interactive ongoing conversations than documentation.
  • If we don’t have time, budget or bandwidth for a Designer, PM just hacks the screens — Balsamiq, ppt, whatever. Not ideal, but sometimes you just have to make do. I’ve literally sent a photo of a whiteboard doodle, and written the story around it.
  • As much as possible, for major new features or flows, we will do customer validation. Yep: phone interviews with screen shares. 5 may be good enough.
  • We don’t have a Business Analyst, so PM writes the stories directly, including me. It’s not hard, and removes a middle man. Not saying a BA/BSA is never needed — just saying in our case we haven’t had the need for one, and have managed fine.
  • When ready to provide the stories to Engineering, we do write more granular level stories. Granularity is determined by the detail put into the screens. Let’s say we had a designer mockup every detail — every click, button placement, font, color, and even copy —then it’s just easier to add the mockup as support documentation and point to it in the acceptance criteria. If the design was more high-level, like a ppt hack or my silly whiteboard doodle, naturally I need to provide more specificity.
  • We use Aha.io to capture ideas, convert them to features, write stories, attach supporting artifacts, do prioritization, and map out an executable roadmap. It has some super cool features:
    • It will spit out a req doc from the stories you write. This is helpful if you’re using a 3rd party dev firm and need to provide them a written doc during the initial planning stages. So we no longer need to use MS Word.
    • It has an awesome Jira integration feature: I literally click a button and — boom — everything is automatically placed in the Jira backlog.
    • It allows me to publish out status on our roadmap execution to senior execs. This is extremely helpful, as it gets me away from PowerPoint and Excel crap.

Ultimately what matters most is joint understanding between Product Management and Engineering (and Design, if you have it). If there’s a good relationship, all sides can come to an agreement on how the reqs should be delivered. And remember: regardless of how the reqs are documented, ongoing conversations between PM and Engineering is the key.


Are you still writing PRDs/MRDs? Or have you moved on to more effective processes? Share in your experience in the comments below.

Using Customer Development To Create The Business Case For Your Product Idea

Many of my product help calls are from folks frustrated with being able to pursue a new product in an existing company.

They complain about how difficult it is to secure resources and garner internal stakeholder buy-in.

If you find yourself in this position, congratulations!

As painful and frustrating as it is, many successful product people I’ve met have gone through exactly what you’re experiencing — including me!

The problem is the way we’ve been taught to pursue this — to first write a business case, business plan or MRD — just doesn’t work. The fact is, people think writing a business case is a waste of time and hate it.

And no where are we taught how to cultivate stakeholder support.

Like it or not, every project in an existing company, regardless of the size of the company, needs an internal champion or sponsor.

Lack of stakeholder buy-in can be the biggest impediment to your product no matter how good your product idea may be.

So it’s no surprise really that product people are frustrated.

 

So here’s a new process I’ve been following that’s worked much better for me:

Using Customer Development To Create The Business Case For My Product Idea

In a nutshell, I deferred asking for major dollars and resources until I absolutely needed to. I used a series of validated learning milestones to build momentum internally and to build the case for investing in my product idea.

Here’s what I did:

1. I quickly sketched out my product strategy on a 1-page Product Canvas. No wasting time writing a multi-page document no one is going to read.

2. I decomposed the product strategy into critical learning milestones meant to answer the most important questions in my product strategy:

  • How does our target customer describe the problem?
  • How are they solving it today?
  • Why is that solution not working for them? In other words, why is the problem still a pain for them?
  • How can we know before we invest a lot in development, sales and marketing that the solution we’re thinking of building really solves the problem?
  • How quickly can we get our first customer?
  • What are the most important features we need to have in our go-to-market product?

3. I figured out what’s the least amount of work I need to do to maximize my learning for each milestone.

4. I broke down my investment need into these milestones, showing how ROI could be tangibly achieved based on measurable results.

Here’s what the investment plan looked like:

validation_workflow

In the past, I would have asked to spend money on 3rd party market research (four to five figures), a design agency to craft the user experience (five to six figures — ugh!), a usability study (five figures), and a large development team (many figures).

This would be costly and take a long time before I would have delivered the product to a single customer.

And it’s a tough business case to make.

Instead, because I had broken down the plan into these learning milestones, I was able to easily accomplish the first two milestones by spending little to no money at all.

The first was simply my time, so required no money.

To validate our solution hypothesis, I used Balsamiq to sketch a handful of the key screens of our solution. Total cost was $79 for the tool and my time.

When we were ready to design the user experience, since we didn’t have an in-house designer, we commissioned a cracker-jack freelance designer — way cheaper than hiring an expensive design agency, and way faster. It got the job done.

(If you happen to have an in-house designer or design team, awesome — use them. Your investment “ask” may only be some of their time.)

In this way, I was able to use the resources I had at my disposal for as long as I could to create traction.

This approach not only allowed me to conserve precious funds and resources, but also allowed me to be less assumptive and more data-driven in identifying my investment ask at subsequent stages.

It also enabled me to not only build early traction with customers, but also have them help me define the minimum feature set we’d need to develop to go to market — labeled as the Minimum Sellable Product (MSP) in the picture above.

Here are the benefits that resulted:

  • Instead of writing a massive business case based largely on guesswork, I needed only to sell a bunch of mini-business cases. Way quicker and easier to do.
  • Each mini-business case was informed by the learnings from the previous stage, making each subsequent mini-business case better informed, more robust, and an easier sell.
  • The product strategy was informed by real market insights. (What a product manager needs to do anyway!)
  • I had a customer driven product roadmap that was tough for anyone to dispute as it was informed directly by tangible customer insights, which defined what went in our MVP vs. MSP vs. roadmap vs. nice-to-have.
  • This enabled our product development efforts to be more focused, as I had all the ammunition I needed to fend off arbitrary new feature requests that risked derailing our product development.
  • Because of our “co-innovation” approach with our customers, we were able to get “earlyvangelists” that we could leverage to generate momentum for our broader market launch. Customer Development in concert with Product Development!
  • All of this made it much easier for me to garner, maintain and accelerate buy-in from my internal stakeholders, because:
    1. My plan showed a clear milestone-based investment plan with the ROI to be gained at each phase.
    2. Smaller continual investments are easier to digest and support than a large upfront one.
    3. Each investment stage was grounded in real customer data, increasing confidence in pursuing the product.
    4. My stakeholders felt involved in the process, as I made sure to keep them informed and provide them an opportunity to provide feedback.
    5. This, in turn, kept me one step ahead of any potential concerns they may have had, and I could make sure to address them at a future stage.

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.

4 Key Tips For Attracting A Non-Technical Co-Founder

Recently Michael Hughes of CoFoundersLab wrote a nice piece on how a non-technical founder can attract a technical co-founder. I’ve read many similarly written blogs and presentations. Most all say the same type of thing: build a prototype, learn to write code, talk to customers. So I thought it would be interesting to look at the opposite situation: how can a technical founder attract a non-technical co-founder?

It strikes me that you could take many of Michael’s points and apply them equally to attracting a non-technical co-founder. Especially the ones about focusing on attracting a co-founder as opposed to finding one, getting into the right mind set, and a co-founder wanting to work with you instead of for you.

In fact, you could take many of his sentences and simply turn them back around to a technical founder. For example: “Repeat this to yourself until you believe it in your bones”: your idea isn’t the best idea, and a non-technical co-founder doesn’t want to work for you on simply selling your idea.

I’ve come across too many technical founders who see the problem as simply a question of sales. In their minds, they of course have the most brilliant product idea, and they may even have spent weeks or months building a product with slick features. Now, all they need is a “sales guy”, “marketing guy” or “business guy”, and of course the money will come rolling in.

If the product doesn’t sell, it’s easy for the technical founder to simply blame the sales guy or marketing guy. After all, clearly the product is great, so if it’s not selling it’s obviously sales or marketing’s fault!

Michael rightly says: “You may very well have the next game changing idea, but that’s missing the point.” The missing point in this case for the technical founder is market validation.

With all of the education out there about customer development, talking to customers, “get out of the building”, etc., I still meet many technical founders who are so completely convinced of their product idea, and they’ve spent months and even lots of money to build a product, yet have no proof whatsoever that a single customer would actually be interested in, let alone buy, their product. That’s because they’ve spent zero time in the marketplace actually trying to identify who their target customer may be and whether these customers actually care. Often times their market research has been limited to a few conversations with trusted friends and family, or they rely on broad industry research or market trends. But unless friends and family are your target customers, their opinions, while interesting and ego-flattering, are utterly irrelevant.

Technical founders are sometimes surprised when non-technical co-founders start providing input into the product features. Reality check: if they’re out there talking to prospective customers, they’re absolutely going to come back with input on features and capabilities that they feel need to be developed to satisfy your customers.

So how do you attract a potential co-founder? You can start with these four tips:

1. Make sure you’ve identified a real problem.

An idea is worthless unless you can clearly articulate who is your potential customer and what problem it solves for them. And you need to be able to state the problem from the customer’s point of view.

If a technical co-founder looks to a prototype or code as a form of commitment from a non-technical founder, a non-technical co-founder is looking for work done to obtain actual market validation as a form of commitment from a technical founder. Currency here is in the form of actual customer interviews.

2. Learn to do customer development.

If you want to gain respect from a non-technical co-founder, learn to how to find and interview customers, identify early adopters, understand your market, and get buyers. This will show that you haven’t formed your idea or developed your product simply in your head, but you’ve done so in response to the demands of your market. Nothing is more impressive than being able to clearly articulate who is your early adopter customer, and better yet, show that you have a paying early adopter customer.

3. Start talking about your product in terms of benefits, not features.

When describing their product ideas, many technical founders describe a laundry list of features. While some of your features may actually be pretty cool, the reality is no one actually cares. What customers really care about is how your product solves their problems, and that means being able to communicate in benefits, not features.

If you’ve done #1 and #2, #3 becomes easier to do. If you’re able to speak in terms of benefits, you will demonstrate to a non-technical co-founder a grounded, realistic understanding of your market.

4. Stop saying “There is nothing like this out there” or (worse) “There is no competition.”

Sorry to burst your bubble, but odds are very high your idea is not that unique. Repeat this to yourself: There is always competition for my product.

Keep in mind the competition may not always be another company or product. Your competition may very well be how customers are solving their problem today. A great example is Quicken. One of the biggest competitors Quicken was competing with when it first launched was the paper checkbook and pen. Your biggest competition is often current customer behavior.

Just like Michael says in his article, remember to treat your non-technical partner like a true partner, not just the person who will “get sales”. The key to attracting world talent here is to show commitment to obtaining real, tangible progress in your target market. Best of luck!

Why Product Managers Need To Get Out Of The Office

By Kevin Dewalt

For the past few months I’ve been doing Customer Development on product managers to explore their viability as a customer segment for my new startup, sohelpful.me. I’ve been asking them about their challenges in getting insight to customer problems. I haven’t had a job as a product manager in over 15 years, but if you’ll forgive my naivety, I would like to offer a few observations on how the role of product managers has to change, at least if their employers want to survive the coming onslaught of worldwide competition from startups.

The Best Product Managers are Learning from Entrepreneurs

The management science of entrepreneurship has changed more in the past 5 years than in the previous 500. Through Eric Ries’ Lean Startup movement and best practices like Steve Blank’s Customer Development, we are finally seeing the emergence of repeatable patterns and best practices for mitigating the risks of product failure. Prescient product managers — often former entrepreneurs themselves — are seeing these best practices emerge and looking for ways to bring them into their own organization. Unfortunately, many are describing practical challenges with getting their employers to embrace this change.

No Established Processes for Connecting Product Managers & Customers

Unlike entrepreneurs, product managers are beholden to an organization’s behavior, rules, and roles. These structures often create practical barriers between product managers and the very tedious process of developing problem-solution assumptions and testing them with customers.

Customer Input Filtered by Other Stakeholders

Many are frustrated with what they describe as filtered customer input — often by sales or marketing teams who are focused on the most recent customer conversation. They recognize the importance of this feedback,  but feel that it needs to be considered in a larger strategic context.

Overwhelmed with “Inside the Office”

Product managers tend to be multi-skilled, dynamic people — those who are already overwhelmed trying to get an organization to execute. Many describe themselves as spending way too much time focused on day-to-day fires or “project management”.

Your Employers Need to Wake Up: The World Wants Your Customers!

Forget Silicon Valley. Through my free startup help sessions, I’m giving advice to entrepreneurs worldwide – Beijing, Bangalore, Singapore and Manila. They’re often 3-5 person teams trying to build highly customized solutions to micro-segments of your customer base — for a lot less. At least 50% of my discussions are about doing Customer Development on the American market. Their biggest challenge is “getting out of the office” — talking to customers to get insights. They’ve read Ash Maury’s Running LeanEric Ries’ The Lean StartupJeff Gothelf’s Lean UX, and watched Steve Blank’s (free) Udacity CourseI try to help them find your customers to get better insight using lower-cost techniques like recruiting them over Craigslist for problem-solution interviews. For the moment, your employer has some practical advantages over these new competitors – language, time zone, trust, experience, and relationships. In the long run it won’t be enough if your employers don’t wake up to the reality that your job has to change. But, alas, they probably won’t change. Most likely you’ll realize it before they do, but by that time you’ll already be gone — you”ll be “getting out of the office” building your products in your startup. Perhaps after they acquire your startup — for 1,000x your salary — they’ll listen.

Kevin

Kevin Dewalt is an American entrepreneur & investor currently living in Beijing, China. He writes about his experiences building products at his blog and on Twitter.