Customer Development Posts

We teach entrepreneurship like every vertical market has the same set of rules

Nivi · April 8th, 2009

Steve Blank: “What I began to realize is that we teach entrepreneurship like every vertical market and industry has the same set of rules. So the first heuristic I want to offer is that — even in this class — there really is no common ‘these rules work’ for all vertical markets and industries.”

Listen to this excerpt from the second class of Steve’s customer development course for the rest of this wonderful lesson.




Audio: Vertical markets (mp3)

Slides: Vertical markets (pdf)

Here’s a transcript of the lesson.

We teach entrepreneurship like every vertical market has the same set of rules

Steve Blank: How many are in Web 2.0? Like the social something web. How many are in enterprise software? Anybody in semiconductors? EDA? OK. Is there a biotech guy still here? Oh!

One of the interesting things about when I put up the fact that there are different industries or markets, everybody goes, “Well, yeah. Of course.” I’m going to tell you a very funny story.

When I started teaching in the engineering school of the school not-to-be-named down south, but it starts with an “S,” I formed teams just like you guys are going to do for projects. And I’d always say, “Listen, anybody can start a company. All you need is a half a million bucks.” OK, yes, sir, a half a million bucks. Write that down.

Next week there’s always a group that looks like these three people, that says, “Startup, half a million dollars.” It’s a divide by zero problems here, because in our business they’d come back and say, “Hey, Professor Blank, in our business the common wisdom is $100 million.”

And then I’d go, “Oh, well, yes of course, you’re in the life sciences, that’s completely different.” The next week I’d say, “Except for these guys who need $100 million, you ought to get out and start selling your product on day one, because you don’t need to worry about any IP at all. Web 2.0. Just go out and get out there.”

The next week someone raises their hand and says, “Professor Blank, in our industry there’s a ton of patents and stuff and people tell us we shouldn’t be out there unless we start patent protecting all our stuff.”

And I went, “Oh, oh, oh, you’re in a different vertical market. In that vertical market you’re absolutely right. But OK, let’s keep going on with the class. The rest of you guys can keep going out because you don’t need to worry about anything, about government regulation or anything. It’s a startup. Just go out there. There’s no regulation to worry about.”

The next week it’s a group that comes up and says, “Professor Blank, we’re doing a medical device and there’s something called the 510K, and that’s a two-year process.” And I go, “Oh, oh, for those of you in medical devices…”

And what I began to realize is that we teach entrepreneurship like every vertical market and industry has the same set of rules. So the first heuristic I want to offer is that even in this class, there really is no common “these rules work” for all vertical markets and industries.

And the first heuristic I want you to think about is, when you hear common advice from friends or other people who’ve done startups, always ask what industry were they in, and was that particular advice relevant for me or not.

So for example, here’s a checklist of — I just randomly picked these. Web 2.0, enterprise software, enterprise software, communications software, communications software, consumer electronics, games software, semiconductors, EDA, clean tech, medical devices, life sciences, and personalized medicine.

I think, I’ve probably screwed up a startup in almost every one of these. That was a joke.

Did I miss anybody’s vertical market? Anybody here who I didn’t kind of get? All right. So this is not meant as a comprehensive list, but usually it takes about 95% of those students in the room.

Technical risk vs. market risk

Steve Blank: Now what’s interesting is if I ask you, Eric, in your biotech startup, what’s your greatest risk? What is it?

Eric: Our team is working on an asthma inhaler.

Steve: Right. So what’s the biggest risk?

Eric: The efficacy.

Steve: Right. The efficacy of what?

Eric: The efficacy of the drug and its impacts. That’s a big risk.

Steve: So whether the product, as envisioned, works at all.

Eric: Right. And even if it works, are the adverse effects….

Steve: Does it kill you?

Eric: Yeah. Not to put too fine a point on it.

Steve: It’s a very nice clinician’s way of saying did it kill him or did he grow a third arm. How about you guys, do you have a particular drug or product in mind?

Student: The technology similar to some medical devices, the bio-monitoring… interactions.

Steve: So whether biomarkers are predicted, for a predictor from an assay you’re thinking about making.

Student: Yes.

Steve: So it’s a technical risk, right?

Student: Yes.

Steve: How many of you are thinking about a Web 2.0 startup? Great. What’s the risk, Josh? What’s the product?

Josh: It’s a digital media company.

Steve: Perfect. What’s the technical risk?

Josh: Finding the engineers.

Steve: Right. Is that a risk in Silicon Valley?

Josh: There’s not a lot of risk.

Steve: What’s the risk?

Josh: Getting people to use it.

Steve: Interesting. If our drug works for asthma, or your friends drug, does he have a customer problem?

Josh: No.

Steve: Why?

Josh: Because there are a lot of people that need….

Steve: If you’re running out of air, you’re going to probably want your drug, right? But you have a different problem. You could almost say, unless we really are stupid, we’re not going to screw up the technology. Wouldn’t you love it, if you were these guys, to be able to say that?

Josh: Yeah.

Steve: Big idea here. It’s a big idea, one that I’ve never heard articulated before at all with startups, yet world-class VCs know this on day one. There are some industries where the risk is purely customer in market.

And by purely I just mean, in Silicon Valley we take for granted digital media and web, with all due respect, for the hard work your software engineers are going to do getting it up, it’s not invention.

It’s, gee, did, they do it efficiently or did the Oracle salesman convince them to buy half a million bucks of software they didn’t need. But it’s not invention.

There’s a whole other set of industries where it truly is invention. Where it truly is, we should be so lucky to get this product working. Because if we get an asthma drug or an oncology for cancer curing drug, our only problem is how big is the licensing deal going to be? And not whether customers are going to want this.

Is this distinction clear? When you start a company, question one to self. Memo to self. Am I in a market risk company? Or am I in an invention risk company?

Hybrid risks

Steve Blank: And by the way, I said this in the first class, I’ll remind you again, though. I’m happy to have every one of you in the class, but if you are in an invention risk company, now I’ll talk about hybrid companies in a second. Invention risk company, this class can offer you nothing.

To the extent that, what customer development is about, is how to dramatically reduce market risk. It is not how to reduce invention risk. So if I lose three of you next week. But you’re more than welcome, I just want to understand…

Student: I’m a hybrid.

Steve: I’m sorry?

Student: I’m a hybrid.

Steve: You’re a hybrid. And I’ll talk about hybrids in a second. Is that clear so far? Memo to self, duh! Can we assume the technology works and our problem is whether the product and market fit is correct? Or is in fact, the product itself the risk factor. But I have something says both.

Give me an example of a vertical market or an industry that has both risks.

Student: Semiconductor?

Steve: Perfect. Why?

Student: Because the technology is fairly advanced. There’s a lot of new insight there. But then the customers are very finicky, maybe, in the type of devices…

Steve: Let’s get specific. What kind of semiconductors do you have in mind? That has technology risk.

Student: Say, consumer electronics or…

Steve: Give me more specific than that. Anyone else in the semiconductor business? You raised your hands in the beginning, now you’re hiding. Yes?

Student: Yes, the industry I work in, we target what the customers want.

Steve: Right, so give me a specific case of technology risk in semiconductors.

Student: Like a high speed serial interface.

Steve: Perfect. OK. Or better, a new graphics architecture, or a new CPU architecture, or you’re making a new IBM cell architecture. Yeah, that’s on the bleeding edge. We don’t even know if the architecture is going to work. Right? I just want to be clear.

Semiconductors, if you’re just making a faster version of some one else’s chip, you’re not taking too much technical risk, are you? I mean, whether you can push it faster.

But typically in semiconductors, if you’re taking architectural risk, if you really have some insight you believe, or communications hardware.

Pushing the envelope is usually about how deep you can go into packet inspection, to how fast and et cetera. Those are some pretty serious trade-offs. You don’t know if this stuff works until you get first use out of the way. Is that fair?

Student: Yep.

Steve: That’s the technical risk. What’s the market risk in that kind of semiconductor business? What’s the customer risk there? Anybody? You don’t even have to be in the semiconductor business. Yes.

Student: For example, they could really mean technology. They could build a chip.

Steve: Yes.

Student: But for some reason, in benchmarking for the system provider assistance is another. Another vendor. Or even more, the old standard just doesn’t pick up.

Steve: Right. So you could have a neat, new architecture, but your competitor could kick your butt. By convincing all the platform people who have to design your product in, “Oh, listen. That’s so incompatible. It uses 62 Hz, rather than 60 Hz of electricity. You’ll never be able to use it.” By the way, I once convinced an entire industry of that, but that’s another story.

So you could win on technical risk, and lose in market risk in hybrid technology. Give me another example. I picked Semiconductors. What’s another one?

Student: I used to do R&D groups with Blu-ray.

Steve: Perfect, talk to me.

Student: I don’t know much about it, but basically from a technical stand point, it seems like you’re pretty similar technology. But it obviously, Sony and company convinced the company prior to movie studios that they’re better off just shipping their content with Blu-ray rather than the DVD medium.

Steve: So this was the next standard for DVD’s. Right? For the last three or four years. Huge battles over who would be the supplier. Lots of chess games, lots of technical risk.

Because even at the end, they were still playing games with the spec and adding more security layer and what ever. At the end of the day, Blu-ray won. Didn’t win on technology, it won because they finally got a critical mass of people to design in the product.

Now the irony is, who do you think might actually, ultimately win? Who may undercut?

Student: Streaming Hi-Def?

Steve: Streaming Hi-Def. Right? It might be that the current DVD standard might have been the last one that sold upon these that it is. Most people, certainly my kids, don’t go out and ever buy DVD’s.

They download stuff to their iPods or Macs or some thing else, or to streaming video. Oops. They’re all an investment. You might have just built the product that no one else wants.

So I just want to point out that when you look at a startup, ask those fundamental questions on day one. What problem do we think we have besides who are we, what business are we in, and what ever. It’s like, are we going to be risking trying to understand our customers and we ought to try to focus on that.

Or is the focus truly inside the building. Because Steve, it doesn’t matter what customers think unless we really nail this technology. None of this matters.

It's very easy to underprice your product

Nivi · April 1st, 2009

What’s the right price for your product? According to Steve Blank, it’s apparently $0. And it’s also $1 million. What?

Listen to this wonderful story to learn how Steve uses these two prices to create a bounding box around the highest price customers will pay for a product. And see why he thinks “It’s very easy to underprice your product… particularly if you’re an engineer.”




Audio: It’s very easy to underprice your product (mp3)

Steve’s story is about enterprise software, but you can apply these same techniques and thoughtful approach to almost any market — including the consumer Internet.

This is an excerpt from the fourth class of Steve’s customer development course. I’ve already taken the class, but I still subscribe to the Venture Hacks podcast and listen to it on my iPhone while I’m walking home from the gym.

Here’s a transcript of the story. Also see How to Determine the Optimal Price for Your Web Service.

“And she realized… she left money on the table.”

Steve Blank: Can I tell you a pricing story? When we starting Epiphany, I had no idea how to price enterprise software. There was one small problem, I had started an enterprise software company and never been in the business.

But, I had heard, and it actually was true, there was a woman named Sandy Kurtzig, who had started ASK Softwark. She was one of the first woman entrepreneurs, woman CEOs of a large corporation. And they were making software for IBM mainframes that was manufacturing software. Something called Manman, which I used in the late ’70s, early ’80s.

Since it was the first non-IBM enterprise software on IBM mainframes, [when] she got her first potential order, she didn’t know how to price it. It must have been back in the mid-’70s. She’s [with] this buyer, has a P.O. on his desk, negotiating pricing with Sandy.

The way she tells the story is, she didn’t know what to ask for it. But, the head of manufacturing told the buyer to go buy this damn thing. [He] didn’t care, [if] it was the world’s best piece of software. So, Sandy said she goes into the buyer who says, “How much is it?”

And Sandy gulped and picked the biggest number she thought anybody would ever rationally pay. And said, “$75,000”. And she said all the buyer did was write down $75,000.

And she realized, shit, she left money on the table. Sandy Kurtzig was awesome. And she said, “Per year.”

And the buyer wrote down, “Per year.”

And she went, oh, crap what else? She said, “There’s maintenance.”

He said, “How much?”

“25 percent per year.”

And he said, “That’s too much.”

She said, “15 percent.”

And he said, “OK.”

[Ed: This is called “flinch pricing.”]

So, enterprise software got priced at $75,000 per year, per module. Now, I have to tell you when I started at Epiphany I heard this story and someone said, “Steve, how much is your software?”

I said, “$75,000 per year, per module.”

Now, fast forward to about four years later. I’m leaving Epiphany, we’re about to go public like the next week. I did not want to be a Section 16B officer. I happened to be walking by a conference room. It must have been conference room 702B then. I think we had 800 people.

I happened to be hearing a pricing discussion. So, I kind of stand outside. And they are arguing about the pricing I had just made up as an entrepreneur, because I heard this war story. And somebody was screaming, “You can’t change the pricing. It was calculated by…”

“I was about to let it go for $75,000… By the time we walked out, we got an enterprise software order for about $1.2 million.”

Steve Blank: But the best Epiphany story, which I actually learned from a world class saleswoman named Gina Rulon-Miller. Her brother Todd was the first sales person at Netscape.

We went into Triple A, CSAA in San Francisco. It was going to be our first multi-million dollar customer. I went in with Gina. They loved our stuff, it really was going to do them a world of good. They said, how much is it?

And I was about to go, “$75,000…” And Gina goes, “Shut up I’m the salesperson.” She said, “A million dollars.”

And I went “…” Gina’s going, “Shut up. I’m the salesperson.”

And the guy looks at Gina and said, “Gina you’re out of your mind. We don’t pay more than $675,000.”

And Gina said, “All right. We’ll let you have it for $675,000.”

So, here was this software. I was about to let it go for $75,000, my first professional software salesperson had just gotten $675,000 and she did the same thing. And she said, instead of per year, she said, “But that’s for the base module. What other ones would you like?”

By the time we walked out, we got an enterprise software order for about $1.2 million. The point about pricing is, particularly if you are an engineer, it’s very easy to under price your product. Because you tend to value it on cost or need or competitive or whatever.

Bounding box pricing

Steve Blank: I, finally, in an almost every business I now work up what I call “bounding box” estimate, which is:

“How much is your product?”

“It’s free.”

“Steve, you can’t mean it. This is our fourth meeting. You know I’m serious.”

“No, no, no. It’s free. Assume it was free, how many would you use?”

“No, Steve. How much?”

“No, assume it’s free. How many would you use?”

Now, for enterprise software does anybody know how you make money in enterprise software?

Yeah. Turns out for enterprise software it’s the number of seats you actually got deployed on. Yeah, you made money on maintenance later, whatever. But, if you just got deployed on ten seats in one department, it’s not really enterprise is it?

It’s like closet software, which I used to get stuck into. You actually want to come out of the closet and be deployed broadly, as broadly as you can. And the test was if it didn’t cost anything, what would it take to deploy it?

When I used to do that they said, “Well I didn’t really tell you, but the IT guy really needs to approve this through the…”

“Well, why didn’t you tell me that before?”

“Well, the product wasn’t free before. I thought we were just going to put it on ten seats.”

My point is going to zero flushes out a whole set of issues. Other times, I’ll go say to that same question, “How much is the product?”

“It’s a million dollars.”

“Steve, we’ve been talking for three months now. You know I don’t have a budget for a million bucks.”

And you get an answer sometimes like Gina did. “The most we pay for this type of software is $500,000.” Seriously. In a startup, you will find out by asking these questions continually, what the bounding box of your potential revenue is.

Do not be bound by what other people are charging. Anybody know where that science experiment that is being run today on a much lower price? Anybody know?

Anybody have the device in their pocket? iPhone. What’s the price of an iPhone app? Anybody know?

I don’t know. There are a bunch of sites out there with some iPhone revenue charts. It’s interesting. Go take a look at what the right pricing for iPhone apps are. My observation is people are running bounding box experiments real time. Real time.

Are they free and they drive other upgrades later or they charge you $9.99 and get real value now?

Sell it before you build it

Nivi · March 28th, 2009

Fliggo does it right:

fliggo

Fliggo Pro is a minimum viable product in action. MVPs reduce time to market. It’s a good sign when people sign up to be notified. And if nobody signs up, you build the next iteration and see if that’s the minimum viable product.

How would you modify this MVP to collect credit card numbers? Could you promise to not charge customers until Fliggo Pro is delivered? Could you give customers a discount for buying early? What do you think?

Add links to your favorite minimum viable products in the comments.

Customer Development, Classes 3 and 4

Nivi · March 23rd, 2009

We’ve gotten a lot of requests to keep posting Steve Blank‘s customer development course. Thanks for the feedback, we’re glad you like the course! Here’s the audio and slides from classes three and four. And new students can catch up on Class 1 and Class 2.

Steve’s lectures usually have two parts: a group discussion of a case and a lecture. Steve sprinkles his war stories throughout both parts — those are my favorite parts of the class.

A case is a written history of a real business problem that the students try to “solve”. For example, the E Ink case addresses “How to retain E Ink’s creativity, drive, and sense of fun while focusing the company on growth and the demands of a first-product introduction.” Exciting! Steve wisely ignores the specific problem in each case and subverts the material to foment a discussion about customer development.

The readings for each class are listed in the syllabus. And the main text for the class is Steve’s must-read book, Four Steps to the Epiphany.

This is wonderful material for entrepreneurs. I’ve already taken the class and I still subscribe to the Venture Hacks podcast and listen to the classes on my iPhone.

Class 3: Customer Development

There is no audio for this class.

Slides: Customer Development 3: Introduction (pdf)

Class 4: Customer Discovery, Part 1

The sound quality of the lecture improves dramatically after the first few minutes.




Audio: Customer Development 4: Customer Discovery Part 1 (mp3)

Slides: Customer Development 4: Customer Discovery Part 1 (pdf)

What is the minimum viable product?

Nivi · March 23rd, 2009

Eric Ries and I recently sat down to talk about minimum viable products: the product with just the necessary features to get money and feedback from early adopters.

The minimum viable product (MVP) is often an ad on Google. Or a PowerPoint slide. Or a dialog box. Or a landing page. You can often build it in a day or a week.

I recorded the interview and synchronized it with some simple slides below. That’s my favorite way to consume the audio. You can also find a transcript and stand-alone audio below. Eric also highlighted some excerpts from the conversation on Lessons Learned and put together his own presentation on MVPs. Let me know what you think — I’m especially interested if you like the synchronized audio and slides.

In Part 2 of the interview, we discuss opening board meetings to the entire company.

Slides: What is the minimum viable product? (pdf)

Audio: What is the minimum viable product? (mp3)

What is the minimum viable product?

Nivi: First of all, this is Nivi from Venture Hacks, and I’m talking to Eric Ries from… where are you from?

Eric Ries: From the Lessons Learned blog.

Nivi: From the Lessons Learned blog, formerly from IMVU, formerly an advisor to Kleiner Perkins. We’re just going to have a discussion on a few topics of Eric’s and my choosing.

Nivi: First topic: What is the minimum viable product? Talk to me about minimum viable products.

Eric: OK, well let’s start with the question. Why do we build products in the first place?

In the end, we hope to be able to launch product to lots of customers and have them give us money so that we build a great business.

One approach to solving that problem would be, let’s build a product with the maximum number of features that will maximize our chance of success in the end. But the problem with that is you won’t get any feedback until you’ve already built all those different products.

All those different features, so you ship this product with a ton of features, and generally, by the time it’s done, it’s too late to make sure that you are on the right track.

The alternative would be, let’s do the release early, release often thing, and let’s get feedback as we go. The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles, because you ship code, you get some feedback from people, you do a focus group.

Some customers say, “Give me feature X,” “Give me feature Y,” now you’re kind of like, maybe sometimes you do what they want, maybe sometimes you’re going to do what you want, and then they get mad at you, and you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.

The idea of minimum viable product is useful because you can basically say, look, our vision is to build a product that solves this core problem for customers, these kind of general feature areas, and we think that for the people who are early adopters for that kind of solution, they will be the most forgiving.

And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on.

Nivi: So there is some set of customers out there, we believe, that just with these features alone, this product is useful to them.

Eric: Exactly right. And sometimes it’s useful to them because early adopters have the same kind of visioning power that entrepreneurs do, but because they can see what the end product is going to be.

Getting developers on the IMVU platform with a MVP

Eric: There are cases where you ship them a product that actually doesn’t work very well — at IMVU, the first version of our product worked pretty terribly, but, for example, it was all about user-generated content. We wanted to get developers on the platform.

The problem with developer platforms is this chicken and egg problem. Developers don’t want to develop unless there are customers who are there to buy their products, and customers don’t want to come on the platform unless developers are there selling them something useful.

What we did is we took early adopter developers and we told them a story about how IMVU was going to take over the world and be this really powerful product for mainstream customers and we made them believe it.

And we gave them an economic incentive that said, the earlier you get on board with the platform, the bigger your take is going to be for derivative products that get created down the road.

We shipped a product that basically had almost no customers — certainly no mainstream customers, and the developer tools weren’t that great — but, because we had told that story effectively and we really understood those early adopter developers, we got a ton of them on the platform developing.

Because they felt like they were in the middle of a gold rush, despite the fact that there was really no evidence to support that belief other than their own power of imagining what this thing was going to be down the road.

Luckily, we delivered on that vision, and so they actually were — a lot of them — pretty happy.

A non-MVP: The Kerry vs. Bush avatar

Nivi: I want some examples of these crazy minimum viable products. By which I mean, for example, and you can talk about any of these, the AdWords approach, the approach you talked about in terms of dialogue boxes and just popping those up, and just trying to sell a PowerPoint slide to an enterprise customer.

Eric: Let me start with an example of a time we didn’t know the minimum viable product, to illustrate my point.

It was 2004 — you have to remember 2004, Bush versus Kerry election. At IMVU, we had this idea — it happens to entrepreneurs all the time, you wake up in the shower and you’re like, “I’ve got an idea for a killer product.”

The idea for us — this was probably September/October 2004, debates are happening, politics is in the air — our idea was, we’re going to sell presidential debate avatar set that we would either dress up like Kerry or Bush, and you’ll be able to debate with your friends in this 3-D presidential debate product.

Now, put aside for a second whether that actually seems like a good idea to anybody else. We convinced ourselves it was a great idea, and we spent two full weeks racing to get this thing built, because it was time sensitive, the election is coming, the debates are happening, every day counts.

We thought it was a great idea for that whole two weeks. We built it out and we shipped it and we spent countless hours debating exactly what features had to be in it or not in it, and we were going to sell it for $1.99.

Our theory was, pricing won’t get in the way of anybody buying this thing. We want to make it cheap and easy and it will make lots of buzz and Wall Street Journal and New York Times are going to cover this thing; it’s going to be awesome.

I remember for us in those days, two weeks of development was a lot, because we were a pretty fast team. We did that, we shipped it — cut to the chase, nobody bought it. We sold exactly zero copies of the Kerry vs. Bush avatar.

We tried a bunch of different permutations and different variations of it and added features, and we changed the price, and eventually we gave it away for free, and even at free we couldn’t sell any copies.

Nivi: Well how many bought it for free?

Eric: None.

We literally couldn’t give this thing away. This thing was a dead weight money loser. There was actually nobody in AmErica interested in having a presidential debate avatar.

How to turn the Kerry vs. Bush avatar into a MVP

Nivi: How would you have approached this exact same product by taking the minimum viable product approach?

Eric: Well it’s interesting. We thought we were taking the minimum viable product approach because we had only spent two weeks on it. Right? Where we had made a very early prototype and put it out there.

But, if you think about it, going back to the definition of the minimum viable product, which is the minimum features that are required to learn what customers want, we had spent way too much time on it.

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.

The first page is so bad, not because it is badly designed, but because the features are wrong that you don’t need to go through the effort of building out the product. So we wished we had done that, and we did make that mistake really.

Nivi: How would you have marketed that minimum viable product to your existing customers?

Eric: When you already have customers you need to have some way to experiment with making them an offer. In a lot of cases the minimum viable product really is just that offer.

You can crisply articulate to customers what they’re going to get and how much they’re going to pay for it. You can learn a lot by just popping up a dialogue box that says, “Hey, would you like this new feature?” or showing them a banner ad for that feature.

For example, on IMVU we would have a system setup so that we could arbitrarily from the server select a small percentage of customers and make them an offer by inserting a dialogue box into their conversation, and basically it’s a simple “Yes” “No,” would you like this thing, “Yes” or “No?”

When they say “Yes,” we take them to a landing page where we try to sell it to them. Eventually if they really did want it, we would have to make up some excuse why we couldn’t give it to them like, “We’re experiencing technical difficulties right now.” “We’re not quite ready to give it to you. Give us your email address and we’ll email you when it’s ready.”

Again, you’ve got to remember that 99% of the time nobody wants it. Most offers that appear to an entrepreneur as a good idea are actually horrible, horrible ideas. By making the offer and having it be rejected by customers, we learn not to waste time building stuff that nobody wants.

Nivi: Right. Maybe the right definition of a minimum viable product, like you were saying, is, essentially a test to see whether people will actually want the product that you’re imagining in your head.

Rejecting false negatives: “But my customers don’t know what they want!” #

Eric: That’s right. The reason why this is an art and not a science is, I’ll have entrepreneurs come up to me and say, “But hold on, my customers don’t know what they want. If I ask them ‘Do you want this thing?’ They might say no when the answer is really ‘Yes.'”

Unfortunately, that’s an excuse that is used way too often, but there are situations where it’s true. The judgment call is; what really is the minimum set? In some cases like in entertainment products it might actually require you to build an early prototype, or a mockup, or even version one of the product with the minimum possible set of features that you think could go.

The nice thing about minimum feature set is you can always try intermediate points to ask yourself, “Am I at the minimum feature set yet? Am I at the minimum feature set yet?”

As long as you’re not afraid of the false negative, that is, if you don’t get discouraged because you’ve built your first paper prototype of it and shown it to people and nobody wanted it. That can’t mean that you give up because, “Oh, forget it, we’ll never make it.” You’ve got to say, “OK, well then let’s iterate some more.”

If you keep iterating at it, you keep making it a little bit more sophisticated, at a certain point after you’ve been through 10 iterations, that you still got no uptake whatsoever, and the feedback you’re getting from customers is still a yawn, you might say to yourself, “You know what? We’re not moving in the right direction. In fact, we’re past the point of minimum viable product. This just isn’t a viable product.”

Nivi: Right. Back to your point about entertainment, in Hollywood they start off in scripts. If the script looks good, then they will make a pilot. If the pilot looks good then they might order a few episodes from the first season. After the first season, then they make from there. They don’t build all three seasons, and then try to ship them.

Eric: Yeah, which means that some great shows never get made, because the early tests look negative and the people involved don’t have the courage or stamina to see it all the way through.

On the other hand, sometimes people have the courage and stamina to see through a really bad idea. That’s why the concept of learning is so important. This cannot be done on a spreadsheet. You have to keep training yourself on multiple iterations and multiple attempts to start to develop good instincts for it in your particular domain, your particular market space, what’s likely to work and not work.

Then you can do that as an entrepreneur, but even more powerful is if you can get your whole organization, everybody, training themselves constantly to do that kind of learning, so that good ideas will be passed around the whole organization.

Building products like packets get routed on the Internet

Nivi: Also minimum viable product ties into the concept of “build it before you sell it.” Are there any other out of sequence things that you guys did at IMVU or elsewhere that you found helpful? For example; you guys probably wrote tests before you coded to some degree as well, didn’t you?

Eric: Yeah, that’s right. I mean test driven development is the same principle.

Nivi: I’m wondering if there are some other things that you guys have done.

Eric: If you think about the full range of the product development life cycle; from specification to design, to implementation to testing, to maintenance to sales to deployment.

Nivi: Deployment and all that stuff.

Eric: I now think about that rather than as a linear sequence, I actually think about it as a big network. The question is; just for any given feature, in what path should you route it through that network? Different features should be routed differently, just like on the Internet we route packets differently as necessary.

Nivi: I’m wondering if you have some specific examples of paths you’ve taken.

Eric: Yeah, we just talked about writing tests first. We’ve talked about selling first. We’ve talked about deploying first.

Deploy first, code later

Nivi: When do you deploy a product? When have you deployed something before you built it?

Eric: All of these forms have offers of products. For example in a lot of Internet products, how does the customer know that the feature exists? Yes, there might be 100 pages of fancy stuff, but how do they even know that stuff exists?

Generally, it’s because there’s a link in the header. There’s one link on one key page that notifies them that they can go do this other thing or at a key moment they receive an email, even though the feature might be wide and complicated.

Generally, access to the feature is controlled through a simple choke point. We would often add those choke points in a split test just to see first of all, did anybody click on them? So we could look at the click-through rate of people that now believe there is this feature.

We would also see an interesting phenomenon, sometimes the presence of a feature, even if nobody clicks on it, still impacts their behavior in other ways.

For example — I can’t remember the data, we saw an experiment where, this isn’t exactly right but something to this effect, we added a link to the header notifying people that there was a VIP Club for special people only to get access to on IMVU.

Now, it’s not the same as what we have now. IMVU does have a VIP club today that is not anything related to this. But, in those days, the idea was, we were trying to test whether people wanted to have some kind of premium experience.

What happened was few people actually clicked on that link to go find out about the VIP club, but in the experimental cohort for people who were shown that header, their average spending was higher.

By constantly reminding them that there was such a think as a premium experience, we primed them to want to do more spending on IMVU. It was a very unexpected result.

And it’s a good example of why you always do full cohort-based split tests. Always test for the macro effect, don’t look at the micro effect. That’s a case where deploying a feature before we’ve built it actually can give you an insight that maybe you don’t need to build a feature after all.

Nivi: Interesting. Yeah. That reminds me of an example that one of our friends told us about where they couldn’t get people to sign up for a free product, so they put a paid version of the product right beside it, and I don’t think anybody signed up for the paid version…

Eric: It made the free version look a lot more…

Nivi: Yeah. It made the free product look legitimate. And they started to actually convert on that basis.

Design first, code later

Eric: There are also cases where you want to design a product last, rather than design it first.

We would often ship things in a schematic form with horrible design to see if we’d gotten the information flow and information architecture right, and really good interaction designers, if they’re being honest, will tell you that that’s always the sequence.

You always re-factor your design out of specific use cases and out of specific uses, rather than starting with the broad vision of what it’s like.

Nivi: Basically the trails where the people walk, you pave those?

Eric: Exactly right. And you could do that — I remember one time we used to use paper prototypes where you have designers sit down with a focus group of people and show them a fake screen shot that they came up with in Photoshop.

And then the customer says, “I want to click that button,” and you go grab the piece of paper that represents what happens when you click that button, you show them another prototype, and we used to do them that way.

We actually built a paper prototyping website into our website where, for certain customers, the designer could come in and actually replace sections of the website with full-on mockups from Photoshop that were sort of clickable and sort of functional.

Then we would bring a customer in and have them register an account; we would specify that that account should see the paper prototype, and then we would go through with them, do the focus group.

But the customer doesn’t know they’re seeing something that’s a mockup. They think they’re using the product.

And, yeah, the product is a little weird, because sometimes they click things and nothing happens, and sometimes things won’t look a little right, but customers think that about your product anyways, so it’s not particularly abnormal for them to see a product that looks completely incoherent to them. That’s the state-of-the-art for most customers and those products.

That was another case where we would — and we would, occasionally, come up with some prototype that that functioned well enough that we would ship it to real customers while we’re working on the full on, blown, beautiful version of it.

Sometimes customers would see a schematic version from which we would gather more information about whether we’re on the right track, and put things in the right place.

Where did you get the money to experiment?

Nivi: What allowed you guys to do all of this experimentation? Specifically from a financial point of view? Not about the mentality behind it and so on. Time is short and money is running out, or were you basically break-even this whole time, or how did you work that?

Eric: No, we believed in a concept we called “bridge to profitability, ” which is, whenever we raise money, we always raise money on the basis of a plan that we honestly believe, would get us to profitability on just that round.

If you notice, that doesn’t mean that we actually got to profitability on that round. In fact, we kept raising more rounds because we kept believing that we had the opportunity to pursue a bigger opportunity by raising money, but we never had to raise money. We always felt like we could get there on our own.

But that meant that we were constantly a dollar short, because plans to get to profitability on a round generally involve you going negative and then catching up before the money runs out, so we were not eager to learn, eager to experiment.

We did not love metrics. We were very scrappy and very afraid of running out of money, so we only ever adopted practices that we thought would have a high ROI.

The issue is that these practices do have a high ROI, and we got to them because we kept following the traditional model and failing and feeling like, God, we are burning money like there is no tomorrow. We keep building features that nobody wants. We literally don’t have the time and we can’t afford to keep doing the same old thing over and over again.

I don’t know if we were just lucky that we had that mindset, but, for whatever reason, even though at some level we always believed the next feature we shipped was going to save the day and have a step change in our profitability and take us to the moon, because it’s just the best feature since sliced bread.

Because we were so desperate to actually make money, we — I’m trying to think of how to put this — we became obsessively committed to actually being right rather than just believing in the next thing to save us.

If you look at the traditional hockey stick shaped curve, it’s flat for an awful long time. We had been in a company previously where we were always promised, “Yeah, it’s flat now, but we’re on the verge of the hockey stick.”

The problem with the hockey stick plan, when that’s your plan, is you just work for a year and then the 13th month you’re going to go to the moon. For the 12 months, you don’t know if you’re making progress or not, because you’re following the plan.

Everything is flat like it’s supposed to be, because when the final feature comes into place, you’re going to go to the moon.

We just didn’t believe that was going to happen. So we forced ourselves to actually test each feature to see if it was going to be successful.

Then we just stopped being able to drink our own Kool-Aid, because we were just wrong so often, it became harder and harder and harder for us to convince ourselves that it was a good financial investment to just randomly try the next new thing versus actually trying to say, “Hey, is there a way that we can increase the probability of having a successful feature.”

Nivi: Yeah, and I think, there are probably two other things here, right? You charge from day one, so basically every experiment you ran was an experiment to make more money, right?

Eric: That’s right.

A preview of part two

Nivi: Why would you not run experiments if you’re charging from day one. And then, the second thing is — this gets us to the second topic, which is: You guys weren’t doing any of this really in public because you had not launched the product, right?

Eric: Amen.

Nivi: Nobody knew who you were. But people, at the same time were using the product, so how did you do that?

The king of customer development starts a blog (and tweets too)

Nivi · March 20th, 2009

Steve Blank, the king of customer development, has started a blog at steveblank.com. And he’s on Twitter too: @sgblank. Steve is one of the great startup mentors of all time and he is using his blog to share 30 years of Silicon Valley war stories. Start at the beginning, and read every word he writes.

According to his book, Four Steps to the Epiphany, Steve is a “retired entrepreneur who… has been in 8 startups in operational roles from CEO to VP of Marketing… These startups resulted in five IPO’s, and three very deep craters.”

Marc Andreessen calls Steve “one of the most strategic thinkers you will find on the topic of starting high-tech companies… buy [his book], read it, keep it under your pillow and absorb it via osmosis.”

Steve’s theories are elaborate, thoughtful, and thorough. Most important of all, they’re based on 30 years of success and failure — they’re tested, not hypothetical.

A few people in the world have built big companies. Even fewer have done it many times. And even fewer can teach us how to do it. Now it’s up to us to learn.

Here’s a snippet from one of Steve’s posts, There’s a Pattern Here, to get you started:

“So what is it that makes some startups successful and leaves others selling off their furniture? Simply this: startups are not small versions of large companies.  Yet the processes that early-stage companies were using were identical to that of large corporations. In hindsight it appeared clear that startups that survive the first few tough years do not follow the traditional product-centric launch model espoused by product managers or the venture capital community. Through trial and error, hiring and firing, successful startups all invented a parallel process to product development. In particular, the winners invent and live by a process of customer learning and discovery. It’s a process that doesn’t exist in large companies with existing customers and markets.  But it is life and death for a new venture.

“I call this process “Customer Development,” a sibling to “Product Development,” and each and every startup that succeeds recapitulates it, knowingly or not.

“The “Customer Development” model is a paradox because it is followed by successful startups, yet articulated by no one.  Its basic propositions are the antithesis of common wisdom yet they are followed by those who succeed.”

Don't launch? But the New York Times is on the phone!

Nivi · March 19th, 2009

Before you continue, read Eric Ries’ excellent Don’t launch, where he questions the assumptions behind most marketing launches.

If you ask most entrepreneurs why they want to launch, you’ll get an answer like, “So people find out about my product — are you stupid?” But a thoughtful founder who read Eric’s article recently asked me,

The New York Times wants to write about my company. It will take me no time or money to get this press. What should I do?

You should still consider the downsides of launching:

  1. Launching a product that doesn’t solve a real customer problem establishes the wrong positioning in the minds of customers.
  2. You can only launch once. If you launch the wrong product or you have an un-optimized funnel when you launch, you just wasted a one-time opportunity to harvest and generate demand.

Launching isn’t the only way to harvest demand. You can reach customers through customer development: AdWords, search engine marketing, online ads, contacting prospective customers through LinkedIn, et cetera — get creative. Don’t launch just because everybody else is doing it — be thoughtful.

Generally, you don’t want to launch until,

  1. You’ve verified a customer’s problem by taking money out of her pocket.
  2. You’ve optimized your funnel so the money you spend on the launch yields the highest possible return on investment.

But doesn’t the traffic we get from customer development have the same problem as the traffic we get from a launch?

positioningYes. In both cases, (1) you’re going to mis-position our product, (2) you’re going to sell a product that probably doesn’t solve a problem, and (3) you’re going to have a funnel that’s sub-optimal.

The leads you get from customer development and the leads you get from a launch are going to have the same problem. But when you launch, there’s a difference in what you do to the customers who don’t become leads.

When you harvest demand through customer development, every consumer you contact is engaged with your product — for example, they visit your landing page. So you can learn from them. If you observe these customers and execute a feedback loop, you can improve your product, positioning, and funnel. It’s okay to expose these customers to the wrong product, positioning, and funnel as long as you learn from them. In fact, that’s the only way to test your hypotheses.

But when you harvest demand through a launch, you position your product in the minds of many customers who don’t engage in your product. They’re not interested in your product yet; perhaps they’re later adopters. But they still read your New York Times article and remember that “Technorati tracks blogs.” They don’t come to your website or call you, so you can’t learn from these customers. You’re imprinting the wrong positioning in the minds of these customers, but you’re not learning anything from them.

You can learn from the leads you get from the press and you can learn from the leads you get from customer development. But when you launch, there’s a difference in what you do to the customers who don’t become leads.

And by the time you do want to launch, you may be the business that “collects, organizes, and distributes the global online conversation.” But everyone who read your article in the Times still thinks you’re in the blog tracking business. It’s tough to change your positioning in their minds and the Times won’t be interested in helping you fix your positioning because they already “launched” you. Do you have a clear idea what Technorati does anymore?

How did people come up with the idea of a launch in the first place?

Before the Web, it was a lot harder to harvest demand for products. Distribution channels like the shelves at K-Mart were locked up by big companies. Television commercials were expensive. Large newspaper ads were expensive. It was hard to set up and track small ads in newspapers and the Yellow Pages.

So I think young companies routed around these channels by going to the press, which consisted of a small number of influential newspapers. Startups harvested demand for their products by getting the press to write about them.

These days, we can harvest demand through customer development — we don’t need to launch. So we usually reserve a launch for (1) generating demand from people who have a problem but don’t know they have the problem and (2) harvesting demand from people who know they have a problem but aren’t actively looking for a solution.

How do I deal with a reporter who wants to write about our company?

First, the press will often approach you for a comment. Second, we’re no experts on working with the press, but here are some untested hypotheses.

Try saying, “We’re not ready for press yet. We would prefer if you didn’t write a story about our product right now. In exchange, let me tell you about what we’re ready to have you print right now. And we’ll put you on the very short list of people we contact when we launch.”

If that doesn’t work, try giving them a teaser, “In exchange, we’ll give you exclusive information about the company that you can write about…” The exclusive shouldn’t imprint your positioning in the minds of readers. Try something like, “we just hired Bill Gates.” The exclusive might generate too much hype but, at this point, you’re controlling the situation as well as you can.

If that doesn’t work, try showing them something that no one outside the company has seen, “This is off-the-record, but I want to show you this cool demo, and we will give you an exclusive when we launch it.”

Where can I learn more?

Read Sean Ellis’ blog on Startup Marketing. He has launched two companies that have filed for IPOs and he now works with Dropbox, Xobni, and other startups. Sean says, “I am insane enough to believe that I can change the way most VC backed startups are launched.”

Here’s a presentation from Sean to get you started:

Slides: Startup Marketing (ppt)

The Venture Hacks Podcast

Nivi · March 6th, 2009

A lot of people have asked us to post the rest of Steve Blank’s customer development classes. Thanks for the feedback  — we’re glad you like the course and we’ll post more classes over time.

Podcast-lovers can also receive Steve’s course as a podcast. Just use your podcasting client to subscribe to our feed:

feeds.venturehacks.com/venturehacks

If you use iTunes, this link should work automagically. If it doesn’t, cut-and-paste the URL above into iTunes like this:

Step 1

Step 2

The podcast also includes any audio or video we post on Venture Hacks, such as Eric Ries’ presentation on lean startups.

Class 2: Three types of markets

Our first post about Steve’s course included two classes (and two MP3s). Some podcasting clients can’t handle two MP3s in a single post. So we’ve moved the second class and its MP3 here.




Audio: Customer Development 2: Three types of markets (mp3)

Slides: Customer Development 2: Three types of markets (pdf)

Take a course from the king of customer development

Nivi · March 3rd, 2009

If you want to learn customer development, you can take Steve Blank’s course at Stanford, Berkeley, or Columbia. Or you can take his course right here on Venture Hacks. I’m taking the course right now and I’ve posted the audio and slides from the first lecture below.

Steve Blank

According to his book, Four Steps to the Epiphany, Steve is a “retired entrepreneur who… has been in 8 startups in operational roles from CEO to VP of Marketing… These startups resulted in five IPO’s, and three very deep craters.” Marc Andreessen calls Steve “one of the most strategic thinkers you will find on the topic of starting high-tech companies… buy [his book], read it, keep it under your pillow and absorb it via osmosis.”

The course

In a nutshell, customer development teaches you how to sell a product before you build it (or while you build it). Unlike a lot of advice from entrepreneurs, customer development isn’t based on Steve’s experience in a single market — it’s based on his experience in a broad set of markets. His companies have made semiconductors, workstations, enterprise software, supercomputers, computer peripherals, military intelligence systems, and video games.

Customer development also works on the consumer Internet. In 2005, Steve funded IMVU on the condition that its founders take his class. We recently wrote about the results of the founders’ experience in How IMVU learned its way to $10M a year.

Each lecture is two hours long. Steve’s war stories alone are worth the price of admission. Let me know if you like these lectures and I will post the rest.

Class 1: Introduction




Audio: Class 1: Introduction (mp3)
(Note: I only recorded the last 20 minutes of this class.)

Slides: Customer Development 1: Introduction (pdf)

Syllabus

The syllabus lists the readings for each class. The primary text is Four Steps to the Epiphany. Buy it.

Document: Customer Development Syllabus (pdf)

How IMVU learned its way to $10M a year

Nivi · February 24th, 2009

“Lean startups are built from the ground up for learning about customers.”

– Eric Ries

I recently sat in on Eric Ries’ presentation on lean startups at Berkeley. The slides and audio are below. The presentation is about one hour long and it is gold.

Audio: The Lean Startup (mp3)

Slides: The Lean Startup (pdf)

The audience consisted of students from Steve Blank’s course on customer development. So you will hear an occasional remark from Steve or his students. When Eric refers to a “case”, he is talking about this Stanford GSB case about his company, IMVU, and his previous company, there.com.

Built to learn

Many founders believe that early stage startups are endeavors of execution. The customer is known, the product is known, and all we have to do is act.

Eric takes a different approach. He believes that many early stage startups are labors of learning. The customer is unknown, the product is unknown, and startups must be built to learn.

IMVU learned its way to product/market fit. They threw away their first product (40,000 lines of code that implemented an IM add-on) as they learned customers didn’t want it. They used customer development and agile software development to eventually discover customers who would pay for 3D animated chat software ($10M in revenue in 2007). IMVU learned to test their assumptions instead of executing them as if they were passed down from God.

Learning to learn

This is the scientific way of building startups. It requires a commitment to learning and thoughtfulness. It is being documented in books like Steve Blank’s Four Steps to the Epiphany and blogs like Eric Ries’ Startup Lessons Learned. It represents the triumph of learning, over the naive startup creation myths we read about in the media. 

IMVU learned to learn. This process can be replicated at your company. Please do try this at home.

Update: Eric writes a follow-up to this post on his blog.