On today's lecture, we're going to cover value proposition. What is it you're building and for who? What pains and gains are you creating for what customer segments? And more importantly, what's the minimum viable product that results from all this knowledge? So you're all familiar with the business model canvass and hopefully by now you've actually taken a shot and tried to fill out the canvas for your own idea and your own startup. But today, we're going to talk about the first box, value proposition. Value proposition is just a fancy word in the business model canvass for what is it that you're building. What product or service are you building? And by the way, we're going to ask later for who are you building it and what exactly does it solve for those people? So let's take a look at value proposition. As I said, it's not just about your idea or product. One of the things that's hard for founders to realize is there's actually a customer at the other end and so while you're thinking this is the greatest thing since sliced bread the whole idea about customer development is to get you out of the building and tell me whose need or problem you're solving. It's about satisfying a customer need and not just you thinking what a great idea. And that can't be repeated enough. So today, while we're talking about value proposition, value proposition works hand in hand with who your customers are, which we'll be talking about in the next lecture. Understand that this relationship between what you're building, the value proposition, and the customer is what makes startups succeed or fail on day one right there. And we give those two boxes, those two relationships, a special name. We call that product market fit. And when you hear the phrase product market fit, just simply visualize the canvass and go, "Oh that's another fancy word that says is what I'm building needed or wanted or passionately desired by a set of customers on the other end? And if I don't have that, then the good news about the customer development process is it allows us to keep searching without going out of business and so what you'll find is we'll be iterating back and forth doing things called pivots and iterations as we kind of discover what customers really want versus what we think we're building for them.
Looking at the Business Model Canvas, fill in the box where your product would go and then fill in the box where your market would go.
Where the product goes and see the box labeled value proposition. As was simulated, the value proposition includes all the features of your product but also the pains and gains you're solving for the customer segment and that's where the market goes. The market includes where your customers are and what problems you're solving for them.
What name do we give the relationship between the value proposition and the customer segment?
The answer is product market fit--finding the right balance between the minimum level of viable product and the customer archetypes.
Let's take a look at value proposition. Value proposition is not something you're building in isolation. While the value proposition is about solving a customer problem or need, it really consists of 3 components. The easy one for most entrepreneurs to talk about is what product features you have or what product services you're providing. But there's actually 2 more important components to value proposition: What gain are you creating for customers? And what pain are you solving for them? Alexander Osterwalder, when he drew the business model canvas, really emphasized this. It's not just about your product. And especially if you come from a technical background, it's really easy to say, "Oh, look at all these features." And if you find yourself doing that, you need to complete the sentence and say, "Yes, but here's what we make people be able to do better, "and here are the problems we solve for them." So the real goal of you figuring out the value proposition is understanding what we call the minimal viable product. You're trying to figure out, "Now that I kind of understand my product and service "and what I'm gaining for customers and the pain I'm solving, "what's the smallest possible feature set I could be shipping on day 1 "that solves these pains and creates gains for them?" And this really is an interactive process because there is no way, no possible way, sitting in your office you could figure this out. And the default for great engineers and great entrepreneurs is, "Oh, I understand customers' problems and needs, "so don't worry about it. We'll just spec the entire product on day 1." Your real goal here is to figure out what's the smallest thing you could build and develop that actually gets you users or sales or whatever and get out to market as quickly as possible. And so the goal of you getting out of the building for value proposition is understanding gains and pains so you can figure out what's the MVP, or minimum viable product.
When planning an initial product, which is the most important? Choose from the list below.
The answer is when you're planning an initial product, the most important is finding sufficient features to solve the problem for a known group of customers. Matching competitive features is what we used to do and actually is a going out of business strategy. And unless you're in an existing market and you happen to know which features the customers have told you are more important. Having sufficient features to meet all of customer needs, startups just don't have the resources to do every possible wish that a customer has at least on day 1, and so really what you want to do is focus on enough features to solve a problem important enough for a known group of customers.
That's kind of wonderful, but we keep talking about the customer. Let me remind you what it looks like from their side and we'll be talking about customers in more detail in the next lecture, but why don't I just give you preview. In customer segments, we are also also looking for three things-- one is we are still trying to understand from this side what are the gains, what are the pains, but also what are jobs that customers want you to do. What are the functional or social jobs, what are the emotional jobs, what are the basic needs that you're going to be solving or problems. And the goal of all these is not just to understand this but to understand it in enough detail that you could actually draw the persona or archetype of those customers and put them on the wall of your engineering department because now they could stare at faces that you'll clip out and specs of how old they are, where they were, what job they're trying to get done, and what pains and gains your value proposition is trying to solve for them. And until you do that, you're just going to be making products in the dark.
Why is having a customer archetype important? Choose all that apply.
The answer is--is having a customer archetyping might is really important for all of these-- To know who to talk to during customer development, to determine how to actually sell the market to these customers--they'll tell you if you ask them. To guide how you form hypothesis during product development, and to help define the minimum viable product. Know your customers and who they are will be immensely valuable.
So as we said, understanding these 3 components of value proposition work together with understanding the 3 components of customer segments. And in value proposition, the goal of this is to find out that minimum viable product. And in customer segments, the goal is to understand in detail the customer archetype or persona. And again, this equals product market fit. I can't emphasize enough that the business model canvas is just a start. It's great to strategize and think about who customer segments are and value proposition and channel, but remember all you're doing is writing down hypotheses. Your job is to turn those hypotheses into facts. And there are no facts inside your building. So your job is to get outside and test them personally in a physical channel by talking to hundreds of customers; in a Web and mobile channel by talking to thousands virtually and some portion physically. You need to watch people's pupils dilate when they actually see and like your product.
So let's take a look at the value proposition in a little more detail and expand on those three components. The first one is your product, and as we said earlier, "You need to understand which are part of your value proposition." Is it just hardware or software or books or are there really some manufacturing goods, some commodities, are you going to have intangible products that are part, copyrights and licenses that are part of your value proposition or are your going to have any financial products that is guarantees or insurance policies or maintenance contract or you're going to add some digital features to it as well. What we point here is that you realize that your product and service is not just the bits or hardware,
The value proposition for a company that's selling services is kind of the same. You just need to ask--what are core services that are part of your value proposition. Consulting, a haircut, investment advice, and if you're selling whether it's software or hardware, you could have separate services that are part of this whole product-- pre- and post-sales services, finding the right solution, financing, free delivery. Amazon makes a great business because in fact they could do 1-day delivery or they could do 2-day Premier Service. That is--service is sometimes, well, might seem to be ??? or kind of add ons actually making your products work better than the competitors. And then what are after-sales services--free maintenance, disposal, etc. And so all these add up again to what is it that your product features do.
Looking at the Amazon website for books, which of the following are part of Amazon's products, and tick all that apply
Well, if you look at the Amazon website and now that you can go AWS but just a traditional bookselling website, you'll find that all of these things are part of their product. The website for allowing users to find and buy products, a review system and rating system for products, protection against fraud for marketplace sellers, and the content itself--movies, books, music, etc. The sum of all these are what makes up Amazon's complete product.
But as you remember, I said it's not only about your product or service features, it's also about pain killers. That is, what are you going to reduce or eliminate for the customer? So here's a couple hypotheses of what some pain killers might be because pain killer until now might have sounded like, "Well, wait a minute. Do I hand the customers aspirin?" And the answer is yeah, you're really going to solve a pain for them, but the pain might be is your product going to produce savings-- that is, in time or money or efforts? Is it going to make them feel better? That is, entertainment products don't solve a problem but they solve a need. Does it kill frustration, annoyances, or things that give them a headache? Does it fix solutions they already have but are underperforming because you have new features or you're better or faster? Or does it end difficulties and challenges that customers encounter every day? Does it make things easier or help them get things done or eliminate resistance? Does it wipe out or add to negative social consequences-- loss of face, power, or trust-- or add to social status like Facebook and Twitter, etc, or even LinkedIn? Or does it eliminate risk? Is it financial, social, or technical risks? Or what could go very wrong? So pain killers, your hypotheses, should include which one of these or some others because this list is finite. There might be other things you're solving and taking away pain from customers. But you need to be able to articulate, based on your interactions outside the building with customers, "Here's what they said." "And when I bounced our product off of them, they said, 'Yeah, yeah, yeah.'" "'That really solves this pain and, more importantly, is an important pain.'"
By the way just as on the side, I've been talking about problem or need as part of the product. And I just want you to remember it's kind of interesting to differentiate between solving a problem or if somebody who has an accounting problem or a word processor or they can now use Google docs versus Microsoft Word versus a need. What's a need? Well, a need might be a need to be entertained or a need to communicate. Needs are something that are universal across all 7 billion people on the planet. Your total available market plus or minus a couple of billion. Maybe kids 0-5 don't have those needs but eventually you will find market sizes for needs to be multiples by orders of magnitude above solving problems. And so, I'm not suggesting that you don't solve problems. I'm not suggesting that you try to turn every problem into a need. But let me suggest the one company in the 21st century that did this better than anybody else in the planet was Apple and the iPhone. They took a communications device and made it a status symbol, and they transitioned from a product that solved a problem, integrated web browser, e-mail, and phone into something that people now every year obsolete their own products by wanting to get the next one because it's now a need rather than a product.
Just some tactics in figuring out pains, how to rank each pain that your products and/or services kill, according to the intensity for the customer, and what you are looking for is trying to understand--"Is this a lifesaving pain" or "Yeah, you know I'd live with this for years-- we could live with it for another couple of years." How important is it in the list of pains that customers have in the area that you're serving. And the other thing you want to think about is not only how intense is the pain but how often does it occur. If it occurs just once a year, people might live with it, but if it's occurring daily or hourly, you are maybe solving something pretty important.
And so we're in the last piece in detail is what gain are you creating. What are the benefits the customer expects, desires or surprise about. So again you're going to start with your hypothesis--"What makes the customer happy," or is that you're going to create savings and time or money and effort. Is this a product that delights them because the outcome is better than you could even imagine, better quality, or more of something or less of something they're going to like. Does it just simply outperform current solutions that delighted customer. Does it make your job or life easier, or does it create positive consequences that a customer desires. Again, it could be a social consequence for a need or it could be a business consequence-- they get more sales, etc. And so much like thinking through pain, you'll start with a set of hypothesis, but the only way to understand this is outside the building in front of lots of customers.
Much like ranking ranking pain, I want you to think about ranking gains. And so, think about it and make a list of what each gain your products and services create according to its relevance to the customer. This is the big idea--the relevance to the customer because much like in pain, you're going to make your first list thinking you got it. Here is what I'm going to solve for pain and here is what I'm going to create for gain. I absolutely know this--"Why?" because it's my opinion or I might have been a domain expert, but you know what at the end of the day your business isn't about your opinion. What you need to do is now hear this from customers who say, "Here is why it's relevant." And much like pain, you want to understand--is this a substantial or insignificant gain created and again understand the frequency that it occurs.
This is where the difference between physical and web/mobile channels first come into play because the MVP for a physical channel that is something you sell directly through stores under the direct sales force is very different than something that you might be building for the web or even more so for a mobile channel. So in a physical channel, what you really want to have is something that customers can touch and feel because you're going to be out talking to them and while you could certainly go out with a PowerPoint deck with a photo of what the product's going to look like, etc., my advice always is invest a day or two in building something even if it's out of Styrofoam and cardboard or if it's something as small as a chip or a microphotograph or a microphotograph of a proposed die layout. That is almost for any physical product you should probably be going out and trying to get some reaction based on something that people could see and touch. And in doing that, you're going to test your understanding of the problem, test your understanding of the solution, and when you do that it's going to prove that it solves the core problem of the customers. And you're going to learn what the minimum set of features are from the early evangelists. In a physical channel, this requires lots of interviews, demos, and prototypes and lots of eyeball of contacts.
In a web or mobile product, instead of building a physical prototype, you need to have a low fidelity app or website available for customer feedback. What does low fidelity mean? Well that's just kind of my description of you don't need an entire finished website but you should at least have a wireframe. And if you don't have a wireframe, you should at least have a PowerPoint of mockups or a flash demo or something so people could see not only what you're describing in words but actually could say, "Oh I get it!" Now remember, don't demo that first. Your goal here is to first understand the problem. And I make people sometimes who would like to give demos to leave all that stuff home when you're first having the problem discussion. But the minute you get into well would something like this solve your problem for a web/mobile app you really want to get feedback on a low fidelity app as quickly as possible. And when we teach this as a class, literally by the second week of the class, if you're building a web and mobile app you have to have your site or wireframe up and running so people can actually see it and give you feedback. Later on, you're going to build what I call the high fidelity app and that tests your understanding of the solution. This actually has most of the features. It might not have health files. The graphics might not be complete but a high fidelity app gives you more resolution and we really didn't like that color, the button was in the wrong place, etc. This helps you avoid building products no one wants, and it maximizes the learning per time spent on the product and on customers.
Why you're doing all this is to define the minimum viable product, or sometimes called the MVP for short. The MVP basically is what product or service you're building in your first instance that's delivered to customers. And the MVP is not an alpha or beta. This is a big idea. In the old days, the product development process would go from seed funding to concept to a market requirements document to an engineering requirements document and blow out into an entire waterfall development process. And part of those steps were alpha test, beta test, and first customer ship, and you'd be shipping and telling customers, "Here's a buggy, unfinished product." "Why don't you test it for me?" And then you'd always argue with sales about whether you should charge for it or not. But the MVP is actually quite different. The MVP says, "No, no, no. We're not spec'ing a version 1.0 product "that has a spec 18 pages long." "We're actually doing the work outside the building first "and trying to understand what's the minimum version of a version 1.0-- "not what engineering or the founders thought "but what is it customers are going to tell us they'll pay for or use now?" And while it might be, quote, a beta product, we never use that word. We actually tell customers it's a minimum viable product.
What's the purpose of the minimum viable product? Take a look at the list and pick the appropriate answer.
So the question is, what's the purpose of the minimum viable product? It turns out that the answer is pretty specific. You want to test the ability of some portion of your product and meet minimal customer needs and that might change over time but as the MVP slowly grows as your confidence in what the customer archetype is. It's not how to get as much as revenue as you can as early as you can. You might decide that's a strategy but that's kind of a counter in learning from an MVP. You typically only make this choice when you actually feel pretty certain that you understand product market fit. And while we certainly want to identify bugs in a product hopefully if we've been using an agile methodology, we kind of squash most of them before they've gone out the door. Explicitly the goal of an MVP is not an engineering alpha or beta test. The goal was not to use this process to find all the bugs though they might come up. The goal of an MVP is to actually test the ability of the product to meet minimal customer needs as in choice one.
Now for both physical and mobile channels, there's an art to building a minimum viable product. Just think about this, an MVP is not a minimal product. An MVP is not like, well, we only have three weeks so we cut off the featured list here. That's not what an MVP is--an MVP is based on interaction and iteration in understanding customer's needs and pains and gains. And if all you're doing is cutting off the featured list, then you clearly haven't run the process. Sometimes we get, but my customers really don't know what they want. I'm creating something so new and getting out of the building is just a waste of time because if I show them my solution, they're not even going to know what problem I'm talking about. We're going to be talking about the problem of market type in a subsequent lecture but there's a case called the new market where you're right, customers have never seen an iPhone before or never seen a new product before. In that case, you still want to get out of the building, but instead of asking them about features, you actually want to understand how are they spending their time now and what solutions are they using to solve their pains and gains. And so we'll talk about market type later but when you hear people say, but my customers don't know what they want, just park that for a while, because that's not an excuse to stay in the building and keep adding features.
There's a couple mistakes when you're thinking about value proposition. One is that what you're building might just be a feature of someone else's product. You might have a good feature extension, but it might not be a business, or it might be a business for about 9 months till the incumbent just adds that in their next release. As I said earlier, these prioritizations of pains and gains sometimes helps you avoid the "it's nice to have" problem. Sometimes it's very easy for founders to say, "Well, they all liked it." Well, okay. What you really want is they didn't like it; they've got to have it. In fact, they didn't let me leave until they let me use the prototype. That's when you know you have a business. It has to be something that people demand, and there have to be enough of them to demand. You might find, yeah, I found the 5 people in the entire world that love the product, but that might not be a large enough market.
Some of the questions you might want to be asking as you're outside the building now talking to customers is competition. Competition kind of exists outside the business model canvas. Think of the canvas now floating in a world where other people's business model canvases are floating as well. And so just kind of take a step back and go, "Well, who else is out there and what are they doing?" The next thing you want to be asking, again outside the canvas, why is this problem so hard to solve, or why is this service not being done by other people? It might be that, hopefully, you really do have an insight or breakthrough. Or it might be you're hallucinating. And so you really do need to keep asking that question not only to yourself; go ask it to the people you're talking to. Ask them, "Has anybody done this?" and if they go, "Yeah, we've never seen this," ask them why. "Why do you think?" You might get some insight, like, "Oh yeah, there have been 9 vendors "in the last 3½ years who tried this, and they all failed." Warning: You might want to investigate why that happened. Hopefully you have a different approach or different insight than anybody else. As we kept talking about earlier, market size. We're going to be talking about how to size the market at the end of this lecture. But you really do want to understand how big is this problem, and is this what we want to spend our next couple years doing? And then finally, as we said, how do you do it once you understand the customer needs?
So an additional help in thinking about your value proposition comes from a great VC, Ann Miura-Ko, at Floodgate. Ann said, "We can think of startups' value propositions of having 2 forms." "Do they have technology insight, or are they market insights?" And typically, technology insights come for technology-driven products. Are you building chips that follow Moore's Law-- that is, they're now doubling in density every year and therefore new functions can be embedded in them? Are these based on new scientific discoveries or new algorithms? Typically, this applies to hardware or clean tech and biotech, but it also could be big data algorithms, etc. Do you have some insight about technology and, again, the gains and pains that that will provide for customers? Or do you have some insight about the market or consumer behavior? Are you going to disrupt the value chain because you now understand how to do something overseas where you could slash the cost by 80%? Is there something that government regulation or deregulation is going to change and now make an entire industry available in a way it never was before? So these are about changes in how people work and live and interact and what they expect, and these are very different than technology insights. But remember they both need to solve pains and gains for your customer.
There's another way to look at this types of value propositions, kind of as a Venn diagram. What comes from technical insights are making things more efficient or smaller or faster and sometimes lower cost and simpler. What comes from market insights are better distribution and bundling and branding. But sometimes what you have is this sweet spot in the middle that actually is a combination of technical and market insights that makes for a killer value proposition.
Let's take a look at some value proposition examples. I've selected some to just give you an idea of how other startups have approached articulating their value proposition. Here was a company that was actually trying to develop a bio-based replacement for surfactants. They actually went out and understood the problem, came up with some solutions, and were trying to explain the pains and gains of their value proposition. Another example was a robotics agricultural weeding device. You notice here they're not talking about their device at all; they're talking about the problem. Hand weeding of farm fields for organic crops is a nightmare. Another example: a company that was actually trying to figure out a better way to do cancer tests. They actually tried to understand what the problem was. And the problem was that cancer cells get detached and are circulating in the bloodstream, and oncologists and pathologists are trying to figure out whether their patients have circulating cancer tumor cells. And their features match the pain and the gain. The rest of the slides give you some examples of value propositions in medical devices, in dental care, etc. You can click on the link below for additional examples.
Now that you've completed Lecture 2 on the value proposition, here's the optional reading for next week. In Business Model Generation it's pages 146 to 150, 161 to 168, and 200 to 211. And in the Startup Owner's Manual read pages 85 through 97, 112 to 125, But the homework is now you actually are getting out and talking to customers to explicitly find out details about your value proposition-- not only your product and features, which is fairly easy, but what are the pain relievers and gain creators along with the key features? What do customers really think? Are people excited because it solves a problem? Do they like your solution? And when you do enough of this, what's the resulting minimum viable product? And again, you need to propose experiments to test your value proposition along with pass/fail signals. The link below has some examples of teams that have done that. Update your business model canvas with changes and optionally use the LaunchPad Central software and post this week's discovery narratives.