A Minimum Viable Product Is Not a Product, It’s a Process

A Minimum Viable Product Is Not a Product, It’s a Process

“You know that old saw about a plane flying from California to Hawaii being off course 99% of the time—but constantly correcting? The same is true of successful startups—except they may start out heading toward Alaska.” —-Evan Williams It’s the same story again and again.

“You know that old saw about a plane flying from California to Hawaii being off course 99% of the time—but constantly correcting? The same is true of successful startups—except they may start out heading toward Alaska.” —-Evan Williams

It’s the same story again and again. First, a team comes up with an idea.

Next, they build a minimum viable product (MVP) as a proof of concept, spending a lot of time arguing about which features to include or exclude from the MVP. Finally, if the MVP works well, they plan on building the full, mature, stable product.

So what’s wrong with this picture? Why does it all go wrong for so many startups?

The problem is that these teams do not understand the point of an MVP. An MVP is not just a product with half of the features chopped out, or a way to get the product out the door a little earlier. In fact, the MVP doesn’t have to be a product at all. And it’s not something you build only once, and then consider the job done.

mvpimage2

An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.

When you build a product, you make many assumptions. You assume you know what users are looking for, how the design should work, what marketing strategy to use, what architecture will work most efficiently, which monetization strategy will make it sustainable, and which laws and regulations you have to comply with. No matter how good you are, some of your assumptions will be wrong. The problem is, you don’t know which ones.1

In a post-mortem of more than 100 startups, CB Insights found that the number one cause of startup failure (42% of the time) was “no market need.” Nearly half of these startups spent months or even years building a product before they found out that they were wrong in their most central assumption: that someone was interested in that product in the first place.

The only way to find that out—the only way to test your assumptions—is to put your product in front of real users as quickly as possible. And when you do, you will often find that you have to go back to the drawing board. In fact, you’ll have to go back to the drawing board not just once, but over and over again.

mvpimage4

This is not unique to product development. When you’re writing a book or an essay, you have to produce many drafts and spend lots of time editing. And when you’re writing code, you frequently have to refactor or even rewrite the code.2 Every creative human endeavor requires an enormous amount of trial-and-error.

mvpimage3

In a trial-and-error world, the one who can find errors the fastest wins. Some people call this philosophy “fail fast.” At TripAdvisor, we called it “Speed Wins.” Eric Ries called it Lean. Kent Beck and other programmers called it Agile. Whatever you call it, the point is to find out which of your assumptions are wrong by getting feedback on your product from real users as quickly as possible.

Whether you’re building a product, writing code, or coming up with a marketing plan, you should always be asking yourself two questions:

  • What is my riskiest assumption?
  • What is the smallest experiment I can do to test this assumption?

MVP-as-a-process, in action

Let’s go through an example.

You decide to build a product that allows restaurant owners to create a mobile app for their restaurants in just a few clicks. It’ll have a simple drag and drop interface, a bunch of pre-built templates, an events calendar, newsletter, check-ins, photo galleries, real-time chat, integration with review sites, social networks, and Google Maps. And most importantly, it’ll offer a way to make reservations, place take-out orders, and use coupons, from which you’ll take a small cut as a way to monetize your product. This is going to be awesome!

You find a few friends to join you as co-founders and, if you’re a typical startup team, you’ll raise some money, lock yourselves in a room for 12 months, and try to build all these features. If you’re slightly more savvy, you’ll cut a few features that aren’t essential for the first launch, so you’ll be able to launch your “MVP” in 8 months instead of 12.

And in both cases, you’re most likely going to fail.

Why? Well, consider how many assumptions you’re making that could turn out to be disastrously wrong:

Read the full version from the author’s website.

Insights and lessons from some of the best people in product

Insights and lessons from some of the best people in product

By John Collins  January 26th, 2017 blog.intercom.com Read the full version from the author’s website.

The foundation of our blog has always been sharing the lessons we’ve learned building Intercom.

When we kickstarted our podcast in Summer 2015, the job was to supplement this with a set of new, mostly outside voices – many of who taught us a thing or two on our own product-building journey – and create a long-form platform to share their equally valuable lessons. Intercom, after all, is about conversations.

The program started as an experiment with a Macbook Air, clunky USB mic, fluorescently lit, claustrophobic call room and a curiosity as to whether readers would actually become listeners. Fast forward 18 months, and we’ve two in-house studios (Dublin and San Francisco), a weekly publishing cadence, and more than 26 hours of content from leading thinkers in the areas of product management, design, marketing, support and the business of startups.

Together these conversations tell the full story of a product lifecycle. So to mark our 50th episode, we pulled a collection of our favorite lessons and insights to illustrate that.

You’ll hear from:

Each shares their take on a particular aspect of product, from pinpointing the Job-to-be-Done to creating successful users and deciding when to rebuild. If you like what you hear, check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed.


Bob Moesta on identifying the job of a future product

Des Traynor: How do you apply Jobs-To-Be-Done when your product does not yet exist?

Bob Moesta: There’s actually no new consumption. They’re already getting the job done one way or another through a different category. We help people find the analogous categories, products, or situations where people are trying to make progress, but they can’t. That’s where your technology would fit into it.

Part of that is figuring out what other industries to look at. We did some work for somebody who was doing a home health care product that doesn’t exist. At the end it was like, “Why did somebody buy First Alert? Why did somebody rent a home health care person to come in and see their parents?”

There’s actually no new consumption.

If we understood those contexts, because they’re trying to fit into those kinds of situations, the context wrapped around that progress is literally the same. We can then say, “Based on our technology now, what are the trade offs we’re willing to make?”

Des: When you say there’s no new consumption, how does that gel with the idea of something like Snapchat? Are you implying people always switch from something?

Bob: They always switch from something. If I mapped the day of a kid five years ago before Snapchat, it was either Facebook or Twitter. They were doing something else.

The reality is that there’s no more time in the world. You can’t create time, and so now they’re choosing to do Snapchat and not do something else. That’s what you have to be able to understand. The part of Jobs is to understand what they are firing. What did they stop doing? Did they want to stop doing it, or do they miss it?

Des: When you hear about emerging industries, a popular one at the moment in the Valley is this idea of customer success. Are people also switching to customer success from something else they thought did the same job?

Bob: They’re switching platforms. There’s a great book called How To Fly A Horse, and it talks about the evolution of innovation, and that innovation is really about creation and creating things. It’s the hard work and the fact that all things are really just evolutions of another. Though the business might call it a new category and the industry might call it a new category because of investment, most categories are created because the returns are different and the investment criteria are different. The reality from the consumer’s side is it doesn’t work that way.

Julie Zhuo on why users use a product

Adam Risman: At Intercom we talk a lot about the Jobs-to-be-Done theory and believe that people primarily use products to get a job done. They make a switch because another product will do something better, easier, faster, etc. You’ve said that in the future you think products will be used because because of style and how it makes someone feel, not because of necessarily utility. Could you explain that?

Julie Zhuo: I do think that the Holy Grail of good design is experience that’s useful, easy to use and accessible and enjoyable. To consider something really well-designed, it’s going to check all of those boxes. There is this hierarchy. I don’t think people use stuff even if it’s easy to use and enjoyable unless it’s useful to them. A lot of times when you have multiple products or services that fulfill that useful need, then the next thing you look at is, “Which one is easier or more accessible to me? Which one’s cheaper? Can it get this thing that I needed to do (finished) faster?” Then if that’s all equal, what people start to look at is like, “I’ve got all these products, they all fulfill this use case, they’re all quite accessible and easy, and now how do I differentiate?”

Julie’s “Ambition Hierarchy for Designers”. See her full post on Medium.

The way people then differentiate is through how it makes them feel. Look at clothing. Thousands of years ago, we looked at clothing simply as a function of usefulness. I need fur to keep me warm in the winter. As time passed, it’s like, “Great, now I’ve got lots of things that keep me warm in the winter.” What’s easier for me to access? Is it cotton? What’s cheaper? You get to this market where how most people pick their fashion is usually a factor of cost and then style. We spend a lot of time thinking about all of these different brands and it’s like, “If I wear this, how is that going to make me feel? How is that going to make me look?”

The competition is around that highest rung. It’s less and less about, “I have to get this thing because it’s the only thing that is going to make me feel warm and fulfill its functionality”. As products evolve and our technologies become better and it’s just easier to have more competitive products in the marketplace, the competition just moves higher and higher up in that pyramid.

Michael Pryor on how to build a pricing model that scales

Des Traynor: Our advice came from Jason Fried. He basically said, “Rule 1: start charging something for the damn product.” We started at $50 per month. You could be Adidas or you could be two people in a shed having just started your first company. We were charging you 50 bucks. What that did do genuinely was cut a lot of the “never going to pay anyway” type of customers. It gave us a bit of clarity. What did you see in your own similar experience?

Michael Pryor: We were solely focused on the product at that time. We were trying to build out the product we were making, taking the profits from FogBugz. Trello was still inside Fog Creek. We were investing in ourselves – you can think of it as we did the seed round.

We weren’t too worried about the monetization. We knew that that was going to come, but we started to see people were afraid to use Trello because they were like, “There’s no way to pay for it. They’re just going to shut down.” We were like, “We’re not charging people and that’s friction? Okay. We need to put down a dirt road for people to see how this is going to happen and we can go pave it later.”

We then started arguing about the pricing. It’s a collaboration tool. Can you charge per user? That inhibits the growth (at that time). We went around and around. Joel finally said, “It doesn’t matter. We just need to pick something, so we should do this flat rate because people will pay for it.” He was right.

It was a good solution for that moment in time. We left it for way too long before coming back to it. That was the problem.

You want to align your pricing with the value that you give people.

We settled on per-user pricing eventually because that was just understood by a lot of people. We weren’t going to invent a funky pricing scheme based on the number of boards or lists or cards. You want to align your pricing with the value that you give people. Bigger companies pay more and smaller companies pay less.

That’s one axis that we have, and we have different plans. If you’re just a solo user you can use Trello Gold, which is for superfans of Trello. For business-type use we have Business Class. For large organizations we have an enterprise version of Trello that has enterprise-type features.

In the future I could see a world in which you’re basically solving a very specific use case with a board by turning on a couple Power-Ups and essentially turning Trello into a lightweight CRM, or maybe a lightweight applicant tracking system. There would be a Power-Up that does that and maybe you pay extra for that. There are a lot of different axes that we can do. We’re expanding with that and learning.

Des: Would you consider specific revenue share with Power-Up developers?

Michael: I’m open to that. There’s already people building tools on top of Trello and charging for those tools. We don’t collect the money. People go to the other website and sign up for that. I already see a market for that kind of thing.

Des: If you could roll back and have this pricing pattern from the start, would yo do it?

Michael: I don’t know that I would’ve done the flat rate thing. I would’ve skipped that. We’ve raised our price a couple times and learned things. We also did a thing that Slack did – we call it smart billing they call it fair billing – where if you’re not using the product, we stop charging you for the person automatically.

We did that a year ago, and it’s been a burden. It just makes our recurring revenue look really weird. People get all these 4 cent charges or credits. It creates a lot of confusion. It turns out that most people don’t really care too much about this.

Des: I’ve always thought it’s clever to have smart billing or fair billing. It’s a marketing solution to a participation tax problem.

Michael: That was the idea, that if you say this to people then they’ll just add everyone in their company and not think about it. It turns out that I don’t see that actually happening in the numbers that much. We’re seeing a lot more cost associated with it instead of the perceived benefit.

Des: I can imagine there’s all sorts of messy complexity in your billing logic there, where you’re charging people for partial prorated months, because they logged in and clicked a link or something.

Michael: Yeah, it’s very confusing to them, and it’s confusing to us. If I went back in time that’s another thing I probably would do differently.

Matt Hodges on telling your product’s story

Matt Hodges: There’s a very powerful quote that I like from Simon Sinek. “People don’t buy what you do. They buy why you do it.” It’s really important to focus on the why. What are you delivering to the customers? That comes through storytelling. People don’t typically come and buy a product just because of its features. They buy a product because of the value it delivers, so it’s really important to think about the end-to-end story you need to tell.

It’s important to start with that at the very beginning because it’s going to guide the solution you build. You should obviously focus on building a solution that solves the problems of your customers and the Job Stories that your product team has outlined, but if you can’t tell a cohesive, compelling story, it’s going to be very hard to sell that to people when you actually do take it to market.

Des Traynor: Is that because it just won’t resonate? What makes it hard to sell?

Matt: It definitely depends on the magnitude of the thing you’re taking to market or announcing. There are simple features that don’t require you to tell a story. There are things that people know that they need. A good example might be automatically assigning conversations to a particular team or teammate. People know that they need that. You don’t really need to tell a story around it. You can benefit from telling a story, but people know that they need that particular feature.

When you ship new inventions or a completely new take on solving a problem that people have, you do need to tell a story to help people understand why they need it and why your solution is a better approach.

Des: In the case of those features where people basically want them and you’re not necessarily changing behavior, then you don’t need to tell a new story in a sense. It’s like, “Hey, that thing you thought we’d have, we now have it,” or, “Hey, that thing you thought would work, now works.” Whereas when you’re actually looking to change customer behavior, that’s when you need something stronger.

Matt: Exactly. You need to convince people why they should invest the time changing their behavior. As we know, changing people’s behavior is incredibly hard. You need to convince them that the way they’ve been doing things is either wrong or is actually not the best way the could be doing it. That’s why storytelling is important to capture their attention and encourage them to invest time in learning more.

Des: How does it work when you have a concept of a story and you’re trying to keep that consistent while also developing the product? Product development isn’t linear. You learn new information, you adapt, you change things, you scope in more stuff, you scope out some stuff. Are you constantly rewriting the press release?

Matt: It’s important to define what we mean by the story, and there are two different stories in my mind. There’s the story that the media and the press are going to latch onto – a particular or narrative that they’re going to find interesting and they’re going to want to write about. Then there’s the story that you’re actually going to tell the people who are going to buy this thing, and that’s what you should be focused on from the very beginning.

At Intercom, we’re fortunate to have a pretty good process in place for building product, and everything that we build starts with what we call an Intermission, which is our quirky name for a project brief. Its goal is to give the product team and, in our case, the marketing team, a shared understanding of what we’re building and why.

More recently….

Read the full version from the author’s website.