Killing Your Startup By Listening to Customers(steveblank.com)
steveblank.com
Killing Your Startup By Listening to Customers
http://steveblank.com/2012/02/27/killing-your-startup-by-listening-to-customers/
10 comments
Totally agree - I always try to focus on requirements, not features. It is really hard for some people to speak in requirements, and the only way you can get them out often is with frank discussions. Second guessing can work if you know your customer really well, but asking people to talk with you works amazingly IF you can help translate for them.
A while back I was rebuilding a larger kids site and in a meeting I was told the site needed a 'big red button on the homepage, that makes a funny noise when you press it' - everyone in the room agreed it was a great idea, and the editorial team tried to push it onto my requirements list. I explained that it was a feature not a requirement (to which they stated that 'well I require it to be on the homepage, so it's a requirement') but I explained what I meant and after a bit of talking we came up with a whole requirement set that we were then able to set off and build to.
The original 'feature' became: As a user I want to be excited As a user I want to be surprised As a user I want to feel I need to see what happens next As a user I want to never know what might happen As a user I want to have some thing 'physical' to play with As a user I want to feel like I've done something to affect the site (and many many more)
We ended up with a fun widget on the home screen, and could well have even made a big red button, if that was what would have best met the requirements (it didn't btw). It ended up user testing really well, kids now love it and it enhances 'accidental' journeys across the site (triggering it now fires you off to a randomly selected page from a list of the 20 coolest pages).
But any time you can successfully translate 'features' into 'requirements' you are on to a winner.
(Widget is here [lower right corner of the screen], and kids still love it!: http://www.bbc.co.uk/cbbc/ )
A while back I was rebuilding a larger kids site and in a meeting I was told the site needed a 'big red button on the homepage, that makes a funny noise when you press it' - everyone in the room agreed it was a great idea, and the editorial team tried to push it onto my requirements list. I explained that it was a feature not a requirement (to which they stated that 'well I require it to be on the homepage, so it's a requirement') but I explained what I meant and after a bit of talking we came up with a whole requirement set that we were then able to set off and build to.
The original 'feature' became: As a user I want to be excited As a user I want to be surprised As a user I want to feel I need to see what happens next As a user I want to never know what might happen As a user I want to have some thing 'physical' to play with As a user I want to feel like I've done something to affect the site (and many many more)
We ended up with a fun widget on the home screen, and could well have even made a big red button, if that was what would have best met the requirements (it didn't btw). It ended up user testing really well, kids now love it and it enhances 'accidental' journeys across the site (triggering it now fires you off to a randomly selected page from a list of the 20 coolest pages).
But any time you can successfully translate 'features' into 'requirements' you are on to a winner.
(Widget is here [lower right corner of the screen], and kids still love it!: http://www.bbc.co.uk/cbbc/ )
Kudos for having the stomach to listen to them and not simply cave in and build that dumb red button. This is why I loathe client work.
Thanks, it was one of many internal battles, and I think we won those that mattered. Working somewhere like the BBC is great, but as you are part of such a huge machine you have to know when to fold, or you will never get anything done!
>I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usability by avoiding confusion over additional features and functions.
Exactly. The starting question that you ask the customer shouldn't be "What do you want?". That is far too open ended, and the end result is that you'll get a solution to a perceived problem instead of an actual, workable solution. It's not the client's job to solve their problems. It's your job, otherwise they wouldn't be contracting you to do it.
The proper question is, basically, "What problems do you want us to solve right now?". You want to start with the problems that the client actually has, instead of the problems that they are anticipating. This helps keep the client focused on their current issues, rather than problems that either don't exist, or may exist in the future(but don't right now).
Exactly. The starting question that you ask the customer shouldn't be "What do you want?". That is far too open ended, and the end result is that you'll get a solution to a perceived problem instead of an actual, workable solution. It's not the client's job to solve their problems. It's your job, otherwise they wouldn't be contracting you to do it.
The proper question is, basically, "What problems do you want us to solve right now?". You want to start with the problems that the client actually has, instead of the problems that they are anticipating. This helps keep the client focused on their current issues, rather than problems that either don't exist, or may exist in the future(but don't right now).
This reminds me of the Simpsons ep. where they had an Itch & Scratchy (and Poochie) focus panel--
Man: How many of you kids would like Itchy & Scratchy to deal with real-life problems, like the ones you face every day?
Kids: [clamoring] Oh, yeah! I would! Great idea! Yeah, that's it!
Man: And who would like to see them do just the opposite -- getting into far-out situations involving robots and magic powers?
Kids: [clamoring] Me! Yeah! Oh, cool! Yeah, that's what I want!
Man: So, you want a realistic, down-to-earth show... that's completely off-the-wall and swarming with magic robots?
Kids: [all agreeing, quieter this time] That's right. Oh yeah,good.
Man: How many of you kids would like Itchy & Scratchy to deal with real-life problems, like the ones you face every day?
Kids: [clamoring] Oh, yeah! I would! Great idea! Yeah, that's it!
Man: And who would like to see them do just the opposite -- getting into far-out situations involving robots and magic powers?
Kids: [clamoring] Me! Yeah! Oh, cool! Yeah, that's what I want!
Man: So, you want a realistic, down-to-earth show... that's completely off-the-wall and swarming with magic robots?
Kids: [all agreeing, quieter this time] That's right. Oh yeah,good.
Did he actually look at the startup? It's also possible that it was just bad -- lacking in usability, useless features that cluttered up the UI, poor aesthetics, etc.
Customer feedback only gets you so far. Often times people don't know what they want or what the core problem they're having is.
Customer feedback only gets you so far. Often times people don't know what they want or what the core problem they're having is.
I thought the same, the entrepreneur told him that both free and passing users weren't coming back. Doesn't that sound like a problem with both customer segments? How does the advice of listening to only one of them helps him any way, if he's not delivering what neither of them wants?
It seems that the proper advice would be to read through feedback and understand what they really want then make sure you have that. Instead of advising to ignore free customers.
It seems that the proper advice would be to read through feedback and understand what they really want then make sure you have that. Instead of advising to ignore free customers.
Is it just me or is this kind of an obvious (first) thing one should ask themselves when starting a business - "How will you make money?"
I don't think it's obvious at all. Because the question of how to make money was implicit in the mind of Satish:
(1) build beta version and get some users, (2) improve product based on user feedback, (3) charge money for the product, (4) watch revenues increase
It sounds so simple. It's essentially the 37signals way, right? Build a product. Charge for it. It's so simple -- how can you possibly mess that up? And yet, the model above is simple, intuitive and wrong.
I think one of the key insights here is that you can have two groups of people who use your product: those who are enthusiastic about your product, give feedback and report bugs, and those people who are actually willing to pay for your product. In an ideal world those two groups overlap and it's easy to make money. What's often the case is that the two groups don't overlap very much, and if you listen to the wrong people you end up making a product that appeals perfectly to those people who have no intention of ever becoming paying customers.
It took me years to really learn this lesson, even though it was completely obvious in retrospect. In order to make a better product I should be talking primarily to my best customers (those who have subscribed to the bigger plans for an extended period of time), because the goal is to find more people like them and to keep 'em happy. If I listen primarily to the most vocal users the implicit assumption is that the most vocal users also happen to be the best (potential) customers. And that's a huge assumption that in my case turned out to be false.
(1) build beta version and get some users, (2) improve product based on user feedback, (3) charge money for the product, (4) watch revenues increase
It sounds so simple. It's essentially the 37signals way, right? Build a product. Charge for it. It's so simple -- how can you possibly mess that up? And yet, the model above is simple, intuitive and wrong.
I think one of the key insights here is that you can have two groups of people who use your product: those who are enthusiastic about your product, give feedback and report bugs, and those people who are actually willing to pay for your product. In an ideal world those two groups overlap and it's easy to make money. What's often the case is that the two groups don't overlap very much, and if you listen to the wrong people you end up making a product that appeals perfectly to those people who have no intention of ever becoming paying customers.
It took me years to really learn this lesson, even though it was completely obvious in retrospect. In order to make a better product I should be talking primarily to my best customers (those who have subscribed to the bigger plans for an extended period of time), because the goal is to find more people like them and to keep 'em happy. If I listen primarily to the most vocal users the implicit assumption is that the most vocal users also happen to be the best (potential) customers. And that's a huge assumption that in my case turned out to be false.
Thank you, that's a very helpful analysis. It's just that between the raccoons and walks in the garden, I totally missed it in the original post.
Depends on the business. I'm willing to bet that neither Google nor Facebook had a concrete idea of how they were going to make money when they started up.
And lots of sites seem to work on the principle that "First we get _all_ the users. Then something mysterious happens. Then we're all rolling around in cash."
And lots of sites seem to work on the principle that "First we get _all_ the users. Then something mysterious happens. Then we're all rolling around in cash."
Google and Facebook are often cited in this regard because they are _exceptions to the rule_. It's bad practice use them as the example.
However, Fred Wilson (Venture capitalist) does advocate something of the sort:
"You can't monetize web services very well until you have an audience of scale. Jason Calacanis suggests that 10mm monthly uniques is where you have scale. I think it can be less in some cases (highly targeted services) and more in some cases (social nets). But every ounce of time, energy, money, and brainpower you spend on thinking about how to monetize will take you away from the goal of getting to scale. Because if you don't get to scale, you don't have a business anyway. "
http://www.avc.com/a_vc/2008/01/twitters-busine.html
"You can't monetize web services very well until you have an audience of scale. Jason Calacanis suggests that 10mm monthly uniques is where you have scale. I think it can be less in some cases (highly targeted services) and more in some cases (social nets). But every ounce of time, energy, money, and brainpower you spend on thinking about how to monetize will take you away from the goal of getting to scale. Because if you don't get to scale, you don't have a business anyway. "
http://www.avc.com/a_vc/2008/01/twitters-busine.html
Just out of curiosity, can anyone give an example of a company had massive scale (10m mau), but then ultimately failed because couldn't convert them into payers? There are probably some, but I can't recall any. So I'd love to study them.
I guess we should define failure here. Is it basically bankruptcy, where the startup couldn't survive(or could barely survive) even after several rounds of funding? Or are we talking about situations where the startup is bought out, but just continues to lose money for the new parent company?
Digg comes pretty close to the first definition. They had around that number of monthly uniques, and have pretty much lots most of the visitors(and therefore ad revenue) in the last few years. They hemorrhaged money and weren't able to find a buyer.
It hasn't completely failed, especially after the reorg they did a couple of years ago, but it's definitely a shadow of it's former self.
As for the second, I guess Youtube around 2009 might count, considering that they were still losing money for Google at that point(Credit Suisse's analysis said that they were losing around $475 million, and RampRate's analysis said $174 million). However, this is pretty much only a business failure, not mindshare, and Google was still willing to drop money into them to get them to profitability.
Digg comes pretty close to the first definition. They had around that number of monthly uniques, and have pretty much lots most of the visitors(and therefore ad revenue) in the last few years. They hemorrhaged money and weren't able to find a buyer.
It hasn't completely failed, especially after the reorg they did a couple of years ago, but it's definitely a shadow of it's former self.
As for the second, I guess Youtube around 2009 might count, considering that they were still losing money for Google at that point(Credit Suisse's analysis said that they were losing around $475 million, and RampRate's analysis said $174 million). However, this is pretty much only a business failure, not mindshare, and Google was still willing to drop money into them to get them to profitability.
XMarks is a classic example -- in 2010 they announced that they would be shutting down because their user base (2m mau or so?) did not bring in revenue to support operations.
In the aftermath of the announcement they sold, presumably at a fire sale price.
In the aftermath of the announcement they sold, presumably at a fire sale price.
Maybe not 10m, but Kozmo comes to mind. They raised $250mm They had huge demand but expenditures were too high (doing stupid stuff like delivering packs of $0.50 gum)
Also, Groupon? :D
Also, Groupon? :D
+1 And these companies have big hockey stick curves and the right amount of funding
It is a high risk trajectory.
It is a high risk trajectory.
If there are exceptions, then there isn't a rule.
Everything we do is best practices and guess work, there isn't a scientific formula to being successful, what works with X, probably won't work with Y. It's just a probabilities game, and by and large, 99% of companies can't approach it the same was that Google and Facebook did. (FWIW I agree with you, just not the way you phrased it).
Everything we do is best practices and guess work, there isn't a scientific formula to being successful, what works with X, probably won't work with Y. It's just a probabilities game, and by and large, 99% of companies can't approach it the same was that Google and Facebook did. (FWIW I agree with you, just not the way you phrased it).
That's just nitpicking, though. Here, "rule" means "what happens 99% of the time".
True, and they fail to realize that this rarely happens most don't have Facebook/Google type growth and need to generate enough revenue to at least finance operations before they get to the end of the runway.
It's just you. And me. And a few others.
I mentor occasionally at Lean Startup Machine events. I would say that more than half the teams that get up and pitch don't mention a business model. Last time I asked the question, "And how will you make money?" so many times that it became a joke.
To be fair to them, it's a question almost nobody has to ask at work. We think a lot about products. We think a lot about users. We certainly think a lot about features and implementations. But most people work at places where the business model is so well established and stable that it becomes the background. For a lot of people it's like asking, "Will the sun come up tomorrow?" Sure, it might not, but it's just not something you worry about.
I mentor occasionally at Lean Startup Machine events. I would say that more than half the teams that get up and pitch don't mention a business model. Last time I asked the question, "And how will you make money?" so many times that it became a joke.
To be fair to them, it's a question almost nobody has to ask at work. We think a lot about products. We think a lot about users. We certainly think a lot about features and implementations. But most people work at places where the business model is so well established and stable that it becomes the background. For a lot of people it's like asking, "Will the sun come up tomorrow?" Sure, it might not, but it's just not something you worry about.
You are new to this "startup" scene, aren't you?
Building everything a customer asks for and following the "customer is always right" mantra doesn't seem like a good idea.
As Steve points out in his article, customer development is about better understanding your customer, their needs, and how to sell effectively to them. It's not about giving away software consulting services for free-- it costs a user nothing to ask for a feature/solution, but it costs you quite a bit to build it for them and even more if they're the only user that wants this particular feature or if they're unwilling to pay for it.
Tough to know where the balance is sometimes though.
As Steve points out in his article, customer development is about better understanding your customer, their needs, and how to sell effectively to them. It's not about giving away software consulting services for free-- it costs a user nothing to ask for a feature/solution, but it costs you quite a bit to build it for them and even more if they're the only user that wants this particular feature or if they're unwilling to pay for it.
Tough to know where the balance is sometimes though.
We literally get 100's of customer suggestions a week - what you have to decide is which of these are popular and worthwhile additions to the product and which are the niche, not worth the time features.
Don't ask your customers what to build. That's lazy.
"Listening" is the wrong word to use when it comes to feedback. You need to engage customers about their pain points. Your customers understand their problems but not the solution.
It's worth repeating--don't ask them for the solution. Ask them for the problem.
"Listening" is the wrong word to use when it comes to feedback. You need to engage customers about their pain points. Your customers understand their problems but not the solution.
It's worth repeating--don't ask them for the solution. Ask them for the problem.
look at how much money I spent on my back yard?
It's not exactly the _intended_ topic of the post, but I had the same reaction. The author seems to want to evoke a sense of calm or slowing down, but the transition between the scene and the diagram-laden advice is really pretty jarring. The weak transition reminds me of the E-Myth, a book which grafted a gratuitous, saccharine narrative onto its small and fairly obvious thesis.
Whatever the calming potato pond is supposed to do here, the subsequent jargon storm undoes it. If "The Startup Owner's Manual" reads like this article (a weird mix of narrative and startup-ese with italics strewn about like a Christopher Walken monologue), I'd be hesitant to spend 40 bucks on it.
Whatever the calming potato pond is supposed to do here, the subsequent jargon storm undoes it. If "The Startup Owner's Manual" reads like this article (a weird mix of narrative and startup-ese with italics strewn about like a Christopher Walken monologue), I'd be hesitant to spend 40 bucks on it.
Perhaps Blank is just testing a new model for his blog. He created an MVP and is now testing it with us users to see what the reaction is.
I wouldn't be surprised if he just wants to play with his style a little bit, particularly if he has just spent the last year writing a very technical book.
I'll wait for a pattern to emerge and in the mean time I will agree that the style was very unrefined.
I wouldn't be surprised if he just wants to play with his style a little bit, particularly if he has just spent the last year writing a very technical book.
I'll wait for a pattern to emerge and in the mean time I will agree that the style was very unrefined.
Good point, there's nothing wrong with playing with style on a blog. Few better places to test, practice, and refine.
Customers tend to ask for features that makes the product incrementally better and often stuff that is visible e.g. "A button that does X". They don't ask for "better usability" or "performance improvements" unless it is very bad. Also, I have never heard any users asking for a feature to be removed (even though it might make the product better).
Build what your customers want (and will pay for), not what they say they want. These can be the same thing, but often are not.
For us, the better way to handle when the customer asks for X, is to sit down and create a persona and ask ourselves why they are asking for it, and who else would want it.
I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usability by avoiding confusion over additional features and functions.
Then again, in a startup environment this is a tricky balancing act. You can't forsake sales for a drawn out product management/development process, but you also can't just add every customer feature request either.