Fat startup: Learn the lessons of my failed Lean Startup(wordsting.com)
wordsting.com
Fat startup: Learn the lessons of my failed Lean Startup
http://wordsting.com/copywriter-blog/fat-startup-learn-the-lessons-of-my-failed-lean-startup
71 comments
Yes, yes, yes.
There are so many things they did that are obviously wrong from the Lean Startup perspective. And then he goes and blames the Lean Startup material, rather than their understanding of it.
For example, his notion that product management is supposed to be casual and erratic is not what the Lean Startup approach suggests. The essence of the approach is in proving that customers really need something before you invest in it. It's a disciplined, data-driven approach. But he says they built half-assed features that nobody needed, and somehow blames that on the Lean Startup stuff.
Also, he preaches about controlling expense. The word "Lean" in "Lean Startup" comes from Lean Manufacturing, the heart of which is relentlessly discovering and eliminating waste. How in the world did he get from that to being free-spending and wasteful?
And then this makes me crazy: "By this stage, Lean Startup theory told us we should be scaling up." No. No, no, no, no, no. No! The Lean Startup theory is that you start scaling if and only if you have achieved product-market fit and have a sustainable way to deliver. He described nothing to suggest they were close to product-market fit. Indeed he says they were limping.
Or his sudden too-late realization that software quality is important. The Lean Startup stuff is basically Extreme Programming plus Customer Development plus some Lean philosophy. Extreme Programming is one of the most quality-focused methods. At my Lean Startup, we had high unit test coverage, strong acceptance tests, lots of code review, and very high quality. 18 months ago I gave a talk on how quality practices were vital when using the Lean Startup approach:
http://vimeo.com/24843552
And it's not like I was the first, or even the 10th person to talk about this. Rather than blaming the Lean Startup approach, he should blame his poor understanding, and his cargo-cult adoption of various rituals he apparently couldn't fathom.
There are so many things they did that are obviously wrong from the Lean Startup perspective. And then he goes and blames the Lean Startup material, rather than their understanding of it.
For example, his notion that product management is supposed to be casual and erratic is not what the Lean Startup approach suggests. The essence of the approach is in proving that customers really need something before you invest in it. It's a disciplined, data-driven approach. But he says they built half-assed features that nobody needed, and somehow blames that on the Lean Startup stuff.
Also, he preaches about controlling expense. The word "Lean" in "Lean Startup" comes from Lean Manufacturing, the heart of which is relentlessly discovering and eliminating waste. How in the world did he get from that to being free-spending and wasteful?
And then this makes me crazy: "By this stage, Lean Startup theory told us we should be scaling up." No. No, no, no, no, no. No! The Lean Startup theory is that you start scaling if and only if you have achieved product-market fit and have a sustainable way to deliver. He described nothing to suggest they were close to product-market fit. Indeed he says they were limping.
Or his sudden too-late realization that software quality is important. The Lean Startup stuff is basically Extreme Programming plus Customer Development plus some Lean philosophy. Extreme Programming is one of the most quality-focused methods. At my Lean Startup, we had high unit test coverage, strong acceptance tests, lots of code review, and very high quality. 18 months ago I gave a talk on how quality practices were vital when using the Lean Startup approach:
http://vimeo.com/24843552
And it's not like I was the first, or even the 10th person to talk about this. Rather than blaming the Lean Startup approach, he should blame his poor understanding, and his cargo-cult adoption of various rituals he apparently couldn't fathom.
The problem I have is that everyone can rap the lean startup principles but when you ask who has successfully implemented lean startup, nobody says yes. How many people do you guys personally know that have successfully implemented lean startup?
I would say that I have.
It's a B2B product that has a couple substantial value adds over the competition. I created the MVP and got a core group of people in a paid beta. There were tons of bugs, but because of the unique value add I offered everyone was more than willing to put up for it and pay for it (and they knew they would get locked in at beta pricing for when it improved).
I was then able to quickly and easily iterate fixes and improvements, based on my vision as well as what I heard from my paying customers.
So on launch day I was already profitable, I knew what my users wanted, all the major bugs were completely sorted out, and I had ~100 paying beta users (all of whom were referred directly by me or by word of mouth through a beta user) who felt like they had a vested interest in the success of the product who helped me reach a critical mass.
With that being said I don't consider my company to be a lean startup (I hate labels like that), and I didn't set out to do a lean startup, but a lot of what I did is consistent with the lean startup approach.
It's a B2B product that has a couple substantial value adds over the competition. I created the MVP and got a core group of people in a paid beta. There were tons of bugs, but because of the unique value add I offered everyone was more than willing to put up for it and pay for it (and they knew they would get locked in at beta pricing for when it improved).
I was then able to quickly and easily iterate fixes and improvements, based on my vision as well as what I heard from my paying customers.
So on launch day I was already profitable, I knew what my users wanted, all the major bugs were completely sorted out, and I had ~100 paying beta users (all of whom were referred directly by me or by word of mouth through a beta user) who felt like they had a vested interest in the success of the product who helped me reach a critical mass.
With that being said I don't consider my company to be a lean startup (I hate labels like that), and I didn't set out to do a lean startup, but a lot of what I did is consistent with the lean startup approach.
Well, it depends on your value of success. At my last startup, as I explain in the linked talk above, we used Lean Startup techniques to kill a number of ideas that we would otherwise have implemented. The startup still didn't make it, so you could call it a failure, but the customer development and iterative market-testing techniques gave us many more tries for the same money, so I am very happy we used them.
But if you want a more traditional success story, I'd suggest Boxbee:
https://boxbee.com/
I was a mentor at a Lean Startup Machine event ~18 months ago where I met the founder. He had a very hazy idea, and over the course of the weekend refined it into something more focused. He then used the Lean Startup techniques to build a business that had revenue from the first month, and was quickly in the black. Relentlessly refining both the user experience and the back end, he found product-market fit and came up with a sustainable plan. And he did this all in his spare time, mainly with his own money.
A month or so ago he pitched it at Jason Calcanis's LAUNCH conference and took first place. Now he's raising money to build an infrastructure well beyond the initial MVP-grade product.
But you can also look at historical examples. It's important to note that none of the Lean Startup techniques are new. It's meant to be a crystallization of things that some people were doing before, but that had never really been talked about. At the local Lean Startup Circle event, we had the founders of Dropbox and Cafe Press talk about how they worked, and it was very much in the start-small-and-iterate-relentlessly style that the Lean Startup folks are promoting.
But if you want a more traditional success story, I'd suggest Boxbee:
https://boxbee.com/
I was a mentor at a Lean Startup Machine event ~18 months ago where I met the founder. He had a very hazy idea, and over the course of the weekend refined it into something more focused. He then used the Lean Startup techniques to build a business that had revenue from the first month, and was quickly in the black. Relentlessly refining both the user experience and the back end, he found product-market fit and came up with a sustainable plan. And he did this all in his spare time, mainly with his own money.
A month or so ago he pitched it at Jason Calcanis's LAUNCH conference and took first place. Now he's raising money to build an infrastructure well beyond the initial MVP-grade product.
But you can also look at historical examples. It's important to note that none of the Lean Startup techniques are new. It's meant to be a crystallization of things that some people were doing before, but that had never really been talked about. At the local Lean Startup Circle event, we had the founders of Dropbox and Cafe Press talk about how they worked, and it was very much in the start-small-and-iterate-relentlessly style that the Lean Startup folks are promoting.
Jason Cohen with WPEngine. Great lean startup. They rock, and are profitable.
By what measure do you want to define if startups have implemented it successfully?
I'm not the parent poster, but I'd basically say: are there any examples at all? Even if we're really loose with what qualifies as "lean startup" are there any examples anyone would be willing to share?
I don't mean to imply that there aren't any, but I just haven't heard of any.
I don't mean to imply that there aren't any, but I just haven't heard of any.
If you read The Lean Startup there are examples in there. I mentioned above WPEngine did it, but also look at Food on the Table. These stories show the lean startup done right. The story above is so riddled with holes. It's like the guys heard some buzzwords, read a wikipedia page, and ran with their limited understanding of it.
Talking about business, entrepreneurship is fun. Doing it is another. Separates the Men from the boys.
No, it's not just a question of Lean Startup education. I am questioning the rituals. The world doesn't work according to a theory, however much you might wish it does. Clients couldn't care less about Lean Startup, MVP, XP, unit tests etc. This idea that you can experiment on clients (in my humble experience) is a dangerous delusion. The comment about "couldn't fathom" is unprofessional (and ludicrous given my resume). Please: listen more, lecture less. Cheers.
What rituals? Extreme Programming and Lean are inspect-and-adapt processes. You might start with something out of the book, but then you are supposed to tweak relentlessly. If you are doing it in a ritualistic fashion, you're already doing it wrong.
The client never cares about what methods you use. That doesn't mean you shouldn't use any methods.
I agree that experimenting is dangerous: any powerful tool is dangerous. But it has worked for too many people to call it a delusion.
Regarding "couldn't fathom", I'm glad to substitute "didn't fathom". But you certainly didn't understand them, and many other people did.
The client never cares about what methods you use. That doesn't mean you shouldn't use any methods.
I agree that experimenting is dangerous: any powerful tool is dangerous. But it has worked for too many people to call it a delusion.
Regarding "couldn't fathom", I'm glad to substitute "didn't fathom". But you certainly didn't understand them, and many other people did.
Totally. Take the complaint about the mobile app. They built a mobile app that nobody wanted, and then blamed Lean!
"Nevertheless as devout Lean Startup followers, we kept building, measuring, and learning. Hidden inside our minimum viable product was a separate mobile application to gather data on logic model performance. This mobile app mystified our customers. Why didn’t we let them input data online at their desks as a starting step?"
On what planet can you be doing Lean development and get as far as building an entire app that not one of your customer wants with features that none of them needs? How can anything be "hidden"?
Wow. Was this published April 1st?
"Nevertheless as devout Lean Startup followers, we kept building, measuring, and learning. Hidden inside our minimum viable product was a separate mobile application to gather data on logic model performance. This mobile app mystified our customers. Why didn’t we let them input data online at their desks as a starting step?"
On what planet can you be doing Lean development and get as far as building an entire app that not one of your customer wants with features that none of them needs? How can anything be "hidden"?
Wow. Was this published April 1st?
It's difficult to work out if the author is saying that his startup ended up 'fat', or that it would have been better if the startup had been 'fatter'.
I'd argue the problem was the former. It sounds like they spent a large part of the runway on things that were not part of the MVP (patents, funnel, extra employees, etc). This is exactly what the concept of 'lean startup' is designed to avoid - 'lean startup' and 'mvp' means you throw out everything that isn't targeting on creating a product that people will buy. You don't throw out parts of the product itself to be lean, you throw out everything that isn't required for the core offering. By the sound of it, the author threw out the core offering and focused on the 'fat'.
EDIT: The 'viable' in MVP is a very specific word that is straight out of the dictionary definition. As from Google dictionary:
I'd argue the problem was the former. It sounds like they spent a large part of the runway on things that were not part of the MVP (patents, funnel, extra employees, etc). This is exactly what the concept of 'lean startup' is designed to avoid - 'lean startup' and 'mvp' means you throw out everything that isn't targeting on creating a product that people will buy. You don't throw out parts of the product itself to be lean, you throw out everything that isn't required for the core offering. By the sound of it, the author threw out the core offering and focused on the 'fat'.
EDIT: The 'viable' in MVP is a very specific word that is straight out of the dictionary definition. As from Google dictionary:
vi·a·ble
/ˈvīəbəl/
Adjective
Capable of working successfully; feasible:
"the proposed investment was economically viable".
Sorry, this doesn't add up. Lean doesn't mean your product breaks or is pushed out functionally incomplete. If no one wants it it's not viable.
The article says give your customers what they want. Unfortunately they thought the customers wanted a mobile app... but they didn't! Wait, what startup methodology could have prevented this...
The article is honest about their mistakes and that must have been hard to do and props for trying but don't try and pass the failure buck to a methodology you didn't even do right.
The article says give your customers what they want. Unfortunately they thought the customers wanted a mobile app... but they didn't! Wait, what startup methodology could have prevented this...
The article is honest about their mistakes and that must have been hard to do and props for trying but don't try and pass the failure buck to a methodology you didn't even do right.
Agreed (edit: though I thing the title of the post indicates awareness of not doing it right). Jumping from:
> Our inaugural customer couldn’t access the software
> the minimum viable product [...] has limited practical
> use. Customers aren’t interested in funding your “learning.”
Exactly, viable = vendible. If there are no customers, than you didn't make your homework right and built something that nobody wants. I'm affraid that this misassumtion about mobile app can be caused by the feedback from customer interviews. You shouldn't rely too much on what people say, ask them to pay for your product instead.
"The purpose of your first release (and every other release) is to give your customer immediate value."
Exactly. That's a MVP, not a crappy product which doesn't even work.
Exactly. That's a MVP, not a crappy product which doesn't even work.
There seem to be two schools of thought here, both interesting to me. The author seems to think that his failure has something to do with problems associated with the "lean startup" model and other commenters (lean startup adherents, apparently) seem to hink his failure has something to do with failing to properly follow the tenets of the philosophy.
I suspect actually that the author adhered about as closely to "lean startup" as many self-identified "lean startups" who have succeeded in the past, and made a pretty average number of mistakes in the process. I don't think of 'lean startup' as a way to guarantee success, I think of it as a way to fail gracefully if you don't succeed. The author came pretty close to this, actually - it doesn't sound like they burned through enormous piles of venture capital money, it seems like they learned a lot in the process, it seems like they didn't spectacularly fail to make payroll causing half a dozen family-bound engineers to suddenly lose their livelihoods. The only less-than-graceful element of their failure was that it took two years, which is probably a little (though not a lot) on the long side. Frankly late in the process they came pretty close to scoring what sounds like it would have been a pivotal investor, and that combined with lessons learned could have produced a true MVP, product market fit, and a viable startup...
So, I think the author successfully followed a good chunk of lean software advice, made some mistakes, got unlucky, and failed. This is what most startups do - even most lean startups - and there should be no shame in it. Paul Graham himself has remarked he wishes he were able to bring himself to invest in more likely-to-fail black swans because that's the way you get to own enough vol to have a real winner in your portfolio - we all should be more comfortable with the risk of failure.
I suspect actually that the author adhered about as closely to "lean startup" as many self-identified "lean startups" who have succeeded in the past, and made a pretty average number of mistakes in the process. I don't think of 'lean startup' as a way to guarantee success, I think of it as a way to fail gracefully if you don't succeed. The author came pretty close to this, actually - it doesn't sound like they burned through enormous piles of venture capital money, it seems like they learned a lot in the process, it seems like they didn't spectacularly fail to make payroll causing half a dozen family-bound engineers to suddenly lose their livelihoods. The only less-than-graceful element of their failure was that it took two years, which is probably a little (though not a lot) on the long side. Frankly late in the process they came pretty close to scoring what sounds like it would have been a pivotal investor, and that combined with lessons learned could have produced a true MVP, product market fit, and a viable startup...
So, I think the author successfully followed a good chunk of lean software advice, made some mistakes, got unlucky, and failed. This is what most startups do - even most lean startups - and there should be no shame in it. Paul Graham himself has remarked he wishes he were able to bring himself to invest in more likely-to-fail black swans because that's the way you get to own enough vol to have a real winner in your portfolio - we all should be more comfortable with the risk of failure.
* Development costs too much to afford iterating.
* Mobile app that customers didn't ask for.
* Language customers didn't understand.
* MVP not actually being viable.
If your development costs are such that you can't iterate on new ideas, you might not have a lean startup.
If you are presenting features that your customers aren't asking for, you might not have a lean startup.
If your customers can't understand what you are showing them and you aren't immediately changing it, you might not have a lean startup.
If you are trying to target big and little customers at the same time (or don't know who your customer is), you might not have a lean startup.
If your minimum viable product isn't viable, you...well, you don't have a minimum viable product. The point of the MVP is to provide enough value that customers see more value in using it than it costs. Anything less than that is just some features thrown together.
In the end, I'm not sure if OP agrees with me or not, but this sounds like a focus problem: trying to do to much instead of focusing in on the pain that gets you in the door.
Another note on MVP: It changes over time. Initially, an MVP may just be some powerpoint slides that show your idea. That may be enough to get you some conversations. Later, when targeting your initial customers, it may be a feature or two that helps them solve their immediate needs. Later still, when you want to start mass-marketing, it needs to be something more.
A key takeaway: Just because Lean is simple doesn't mean it is easy. It takes a lot of discipline to keep from putting the cart ahead of the horse.
What I've learned from my failed startup during 2000/2001 [1]: With enterprise software the MVP is a power point deck with mockup screen shots. You first need to validate the idea, words, concepts before you start developing. This also helps with the deep decision pipelines that enterprises usually have to buy your enterprise software.
Next time I'd start immediately going around with a powerpoint deck of mockup screenshots instead of developing software first (which we did and failed).
[1] http://codemonkeyism.com/6-reasons-why-my-vc-funded-startup-...
Next time I'd start immediately going around with a powerpoint deck of mockup screenshots instead of developing software first (which we did and failed).
[1] http://codemonkeyism.com/6-reasons-why-my-vc-funded-startup-...
I'm voting this up. It has so many problems that everybody should know and talk about them.
"...First, the minimum viable product preached by Lean Startup has limited practical use. Customers aren’t interested in funding your “learning.” They want reliable software that delivers value consistently. You must build the minimum desirable product, and if you don’t have a good understanding of what’s desirable before you start, then, don’t...."
What value and growth hypotheses are you testing? Seriously, nobody is expecting your customers to put up with crappy development. What we're saying is that you must clearly explain what you are trying to learn before each rev. Just coding up some minimalist POS and irritating a potential customer with it doesn't take you anywhere down the learning road. Pro tip: irritating people will not give you good results in your quest for learning.
Lean startup stuff says everything you do should be geared towards proving a value or growth hypothesis. You should have a disciplined way of testing, and numbers that mean success or failure -- ahead of time. Yes, you do it in loops. Yes, there's all kinds of other stuff. Yes, you're always focusing on eliminating waste. But I think this guy missed the point completely. The MVP is where two proven hypotheses are deployed in tandem to a target market.
I could go on, but I don't want to be mean. We learn much more from watching people misunderstand things than we do watching successes. Thanks to casca for posting it.
"...First, the minimum viable product preached by Lean Startup has limited practical use. Customers aren’t interested in funding your “learning.” They want reliable software that delivers value consistently. You must build the minimum desirable product, and if you don’t have a good understanding of what’s desirable before you start, then, don’t...."
What value and growth hypotheses are you testing? Seriously, nobody is expecting your customers to put up with crappy development. What we're saying is that you must clearly explain what you are trying to learn before each rev. Just coding up some minimalist POS and irritating a potential customer with it doesn't take you anywhere down the learning road. Pro tip: irritating people will not give you good results in your quest for learning.
Lean startup stuff says everything you do should be geared towards proving a value or growth hypothesis. You should have a disciplined way of testing, and numbers that mean success or failure -- ahead of time. Yes, you do it in loops. Yes, there's all kinds of other stuff. Yes, you're always focusing on eliminating waste. But I think this guy missed the point completely. The MVP is where two proven hypotheses are deployed in tandem to a target market.
I could go on, but I don't want to be mean. We learn much more from watching people misunderstand things than we do watching successes. Thanks to casca for posting it.
I have seen a lot of people who pointed out how wrong the OP had done and the OP should have done X, followed by Y, yadi yada. What I can't find is maybe a bit of sympathy, or encouragement.
Fine. It would be very useful if those smart people can share what and how they have applied the Lean Startup theory, and how successful their products/companies are. I will give most of them benefit of doubt for _reading_ that book, but applying it? I would say around 10% of them? Applying it and succeed? Even less, I just speculate it will be around the 1% mark. In other words, those who talk so loud about OP didn't get the MVP right etc etc, I will say they won't fare any better if their rubber hit the road. I am more than happy to be proven wrong.
Fine. It would be very useful if those smart people can share what and how they have applied the Lean Startup theory, and how successful their products/companies are. I will give most of them benefit of doubt for _reading_ that book, but applying it? I would say around 10% of them? Applying it and succeed? Even less, I just speculate it will be around the 1% mark. In other words, those who talk so loud about OP didn't get the MVP right etc etc, I will say they won't fare any better if their rubber hit the road. I am more than happy to be proven wrong.
I think "The Lean Startup" is a good book - it presents a model for creating a successful business which diverges from older more traditional business thinking. Some successful technology companies feel the same way. I also think books like this should be read as guideposts, not as some orthodoxy. If a suggestion from the book goes against particular circumstances or common sense, you do what your common sense tells you.
Nonetheless, they seem to have missed important lessons from the book. Or re-learned them rather. The odd thing is they then claim the book does not cover these things, and distracted them from these problems. I don't understand why this is said, since the book does cover these things.
The blog post says:
> Lean Startup principles distracted us from four livelihood-threatening fundamentals. First, you need rigorous product management. Don’t speculate. Build no feature unless you understand it thoroughly and have unshakeable evidence that multiple customers need it --urgently.
But this lesson learned is one of the Lean Startup principles.
From "The Lean Startup": "For example, how many features do we really need to include to appeal to early adopters? Every extra feature is a form of waste, and if we delay the test for these extra features, it comes with a tremendous potential cost in terms of learning and cycle time. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time."
...I quote only one paragraph from the Lean Startup, but the idea about no excessive features in an MVP is repeated throughout the book.
It's possible the Lean Startup approach has some holes in it, but warning against too many features in an MVP is not one of them.
Nonetheless, they seem to have missed important lessons from the book. Or re-learned them rather. The odd thing is they then claim the book does not cover these things, and distracted them from these problems. I don't understand why this is said, since the book does cover these things.
The blog post says:
> Lean Startup principles distracted us from four livelihood-threatening fundamentals. First, you need rigorous product management. Don’t speculate. Build no feature unless you understand it thoroughly and have unshakeable evidence that multiple customers need it --urgently.
But this lesson learned is one of the Lean Startup principles.
From "The Lean Startup": "For example, how many features do we really need to include to appeal to early adopters? Every extra feature is a form of waste, and if we delay the test for these extra features, it comes with a tremendous potential cost in terms of learning and cycle time. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time."
...I quote only one paragraph from the Lean Startup, but the idea about no excessive features in an MVP is repeated throughout the book.
It's possible the Lean Startup approach has some holes in it, but warning against too many features in an MVP is not one of them.
"Our first customer, a Canadian social services department, was led by a Deputy Minister with a fondness for a wall chart showing the logic models under his charge."
Several years ago, a friend and I started a non-profit that tried to work closely with a Canadian social services department. Consequently, when I read this sentence, I cringed. Turns out that big Canadian government departments have these massive tomes called 'procedure manuals'. These procedure manuals spell out every single activity that the department could possibly perform, seemingly in the name of getting rid of ambiguity, judgement and any sort of innovation. Consequently, trying to innovate alongside a government department is, more often than not, an extremely frustrating experience that results in a pissed off client and a stymied startup.
Long story short, just because someone comes at you with money, it doesn't mean that your demand is validated. Rather, sometimes the wrong kind of customer is worse than having no customer at all!
Several years ago, a friend and I started a non-profit that tried to work closely with a Canadian social services department. Consequently, when I read this sentence, I cringed. Turns out that big Canadian government departments have these massive tomes called 'procedure manuals'. These procedure manuals spell out every single activity that the department could possibly perform, seemingly in the name of getting rid of ambiguity, judgement and any sort of innovation. Consequently, trying to innovate alongside a government department is, more often than not, an extremely frustrating experience that results in a pissed off client and a stymied startup.
Long story short, just because someone comes at you with money, it doesn't mean that your demand is validated. Rather, sometimes the wrong kind of customer is worse than having no customer at all!
Oh, so now the whole "we fucked up so let's blame the tools/methodology" has arrived at Lean Startup?
Plus ça change...
Here's a wonderful nugget: "too often Agile development methodologies are used to excuse lack of process and planning". The irony is strong in this one.
The next book on Lean should be a dictionary with just a single word explained in way even a 3 year old can understand: "viable"
Plus ça change...
Here's a wonderful nugget: "too often Agile development methodologies are used to excuse lack of process and planning". The irony is strong in this one.
The next book on Lean should be a dictionary with just a single word explained in way even a 3 year old can understand: "viable"
Viable means, strictly, able to live at birth, especially, in relation to a foetus (but not a 3-year old?). Being born doesn't mean you will survive. So, minimum viable product is a poor term, implying disrespect for your customers. Minimum desirable product (from your customer's perspective) reflects the standard required.
I worked for a enterprise software company where we practiced incremental development. The quality of software was hardly stellar but they had a great sales team. By the time I left, they had 6000 customers, lot of them Fortune 500. It is also worth mentioning that they were completely bootstrapped until recently.
Our customers were always ok with us informing them that features will be in x.0, as long as we delivered on them.
Maybe, it was your market that prevented the lean startup methodology from being applied?
Our customers were always ok with us informing them that features will be in x.0, as long as we delivered on them.
Maybe, it was your market that prevented the lean startup methodology from being applied?
Wow. Reading these comments makes me think that the whole Lean Startup thing is more of a religion than a methodology.
Fist of all, it might be not the right choice of methodology as government and non profit clients are not the best audience to apply "lean". These guys are very conservative, especially in Canada.
Second, it appears a lot of problems appeared because founders didn't know what they are building or what they want to build and relied on "lean" as a magic bullet to help them figure it out.
Third, it's hard to believe but I've met people who applied "lean" and other methodologies without actually diving deep and at least reading the underlying manifesto books thoroughly. Lean methodology is so easy, isn't it? Build an MVP and then iterate.
To sum it up, there's nothing wrong with lean methodology. These guys first failed at understanding it. Then no wonder that they double failed at execution.
Second, it appears a lot of problems appeared because founders didn't know what they are building or what they want to build and relied on "lean" as a magic bullet to help them figure it out.
Third, it's hard to believe but I've met people who applied "lean" and other methodologies without actually diving deep and at least reading the underlying manifesto books thoroughly. Lean methodology is so easy, isn't it? Build an MVP and then iterate.
To sum it up, there's nothing wrong with lean methodology. These guys first failed at understanding it. Then no wonder that they double failed at execution.
As someone who works in the Canadian Government I'm not surprised at all that a deputy minister would have no interest in helping you iterate your product, at that level it's all about politics and to have a product fail in front of them and their coworkers is a big problem it makes them look bad which could have a negative effect on their job.
I sympathize with the author. Lean Startup is a very good tool that should be in your toolbox, but it's being sold and resold as "the way". It's not the only way, and it doesn't guarantee success, not more so that knowing the scientific method guarantees you a Nobel prize, or a published paper.
Lean methods make some implicit assumptions about the cost of finding early adopters and building MVPs, and each entrepreneur should figure out the costs of such activities and determine if they are worth pursuing provided the potential benefit. In enterprise software settings, for example, an MVP might mean 2 years of work, that means you have only one iteration if you follow the lean methods by the book. Does that mean that you can't successfully build enterprise software? Of course you can. You can work with a customer for 2 years, deliver this product to them, and then market it to other similar companies, and then, only then, iterate. Is this still Lean? I don't know.
Also, I can't fail to see Lean as an optimization method, similar to gradient descent. With gradient descent, each iteration you inch up in the direction that seems to bring the highest reward. When using gradient descent in real world you realize that where you start matters, and the function you are exploring also matters, a lot. You can start iterating near a minimum, and have a straight descent line, but you might iterate on a plain, and basically be lost forever. Of your function might have many local minima. You have to first explore the problem space and make sure you where you start iterating close enough to the minimum, or that a good solution can be found by iterationz. Where you start, or when you decide to restart, is what the Entrepreneur's vision provides.
Gradient descent is also quite blind, and the fact that the last 20 iterations in one direction didn't bring any success provides no insight on what is going to happen if you iterate once more. The function you're exploring might just have a sharp drop one iteration away, or it might continue to be flat for 100 more steps.
If your MVPs can be built quickly, or if you are close to the optima, or you have unlimited cash and time to explore, the lean method is the way to go. For other cases, you might have to weigh in the pros and the cons.
Lean methods make some implicit assumptions about the cost of finding early adopters and building MVPs, and each entrepreneur should figure out the costs of such activities and determine if they are worth pursuing provided the potential benefit. In enterprise software settings, for example, an MVP might mean 2 years of work, that means you have only one iteration if you follow the lean methods by the book. Does that mean that you can't successfully build enterprise software? Of course you can. You can work with a customer for 2 years, deliver this product to them, and then market it to other similar companies, and then, only then, iterate. Is this still Lean? I don't know.
Also, I can't fail to see Lean as an optimization method, similar to gradient descent. With gradient descent, each iteration you inch up in the direction that seems to bring the highest reward. When using gradient descent in real world you realize that where you start matters, and the function you are exploring also matters, a lot. You can start iterating near a minimum, and have a straight descent line, but you might iterate on a plain, and basically be lost forever. Of your function might have many local minima. You have to first explore the problem space and make sure you where you start iterating close enough to the minimum, or that a good solution can be found by iterationz. Where you start, or when you decide to restart, is what the Entrepreneur's vision provides.
Gradient descent is also quite blind, and the fact that the last 20 iterations in one direction didn't bring any success provides no insight on what is going to happen if you iterate once more. The function you're exploring might just have a sharp drop one iteration away, or it might continue to be flat for 100 more steps.
If your MVPs can be built quickly, or if you are close to the optima, or you have unlimited cash and time to explore, the lean method is the way to go. For other cases, you might have to weigh in the pros and the cons.
It's slightly more than than hill climbing. More like simulated annealing.
I think you guys misunderstood the purpose of MVP, since your lessons learned part explains pretty much what we can find in Lean approach books. MVP is not a product, it's a learning process. Bugs have nothing to do with being lean (or not), it's sloppy developers.
Not trying to be a wise-ass, but I still think your mistakes are avoidable while still following lean principles. Good luck on your next venture!
Not trying to be a wise-ass, but I still think your mistakes are avoidable while still following lean principles. Good luck on your next venture!
It's great you're openly talking about this! We need more people with stories on failure, because we learn more from that than success stories.
There is a lot of stuff in the post and the comments about Lean Startup, but I want to jump in on this the wish expressed 'The Jason Fried Fantasy'. Specifically this:
We would combine simple, opinionated software with crisp software copywriting and a low-touch online sales model.
This limits your options. I think the product was too niche to be a 37signals 'sell to the fortune 5 million' product. I'm passionate about 37signals, but it might be difficult to apply to niche markets that require aggresive sales / long deal flows.
Now you also point out:
For every customer or prospect we talked with, the risks of innovation (failure and losing their job) far outweigh the hypothetical benefits we proclaimed. Customers just want reasonably priced software that does its job, not helping you launch your Lean Startup adventure.
Now assume you've already validated the problem. Probably you were getting the wrong people in your sales funnel. Basically if people fear to lose the job, you need to move up in the companies hierarchy. Look for the manager above him and keep going. Or start at the top and work down if possible. But keep talking until someone keeps calling you back to have their problem solved. Steve Blanks Customer Development talks about this as well.
About the quality of the MVP. It's better to ship a half product than a full featured half working product. From what I read in your post a lot of people weren't feeling safe to introduce this in the organization because it was an immature product. You solve this by narrowing down the featureset or display 'upcoming features' and involve people in developing further. But this is different per market, B2B (as mentioned in another comment) is different than consumers.
Edit: fixed markup.
There is a lot of stuff in the post and the comments about Lean Startup, but I want to jump in on this the wish expressed 'The Jason Fried Fantasy'. Specifically this:
We would combine simple, opinionated software with crisp software copywriting and a low-touch online sales model.
This limits your options. I think the product was too niche to be a 37signals 'sell to the fortune 5 million' product. I'm passionate about 37signals, but it might be difficult to apply to niche markets that require aggresive sales / long deal flows.
Now you also point out:
For every customer or prospect we talked with, the risks of innovation (failure and losing their job) far outweigh the hypothetical benefits we proclaimed. Customers just want reasonably priced software that does its job, not helping you launch your Lean Startup adventure.
Now assume you've already validated the problem. Probably you were getting the wrong people in your sales funnel. Basically if people fear to lose the job, you need to move up in the companies hierarchy. Look for the manager above him and keep going. Or start at the top and work down if possible. But keep talking until someone keeps calling you back to have their problem solved. Steve Blanks Customer Development talks about this as well.
About the quality of the MVP. It's better to ship a half product than a full featured half working product. From what I read in your post a lot of people weren't feeling safe to introduce this in the organization because it was an immature product. You solve this by narrowing down the featureset or display 'upcoming features' and involve people in developing further. But this is different per market, B2B (as mentioned in another comment) is different than consumers.
Edit: fixed markup.
> the minimum viable product preached by Lean Startup has limited practical use. Customers aren’t interested in funding your “learning.” They want reliable software that delivers value consistently. You must build the minimum desirable product, and if you don’t have a good understanding of what’s desirable before you start, then, don’t.
Oh, how I wish I could tell myself this five years ago. Maybe it's the industry I do most of my development for, but users I interact with very rarely want to hear "that will be in 2.0!" The ones that even let you finish the sentence before hanging up/walking out usually respond with "That's great. Let me know when it's done, then we can talk about signing up."
MVP and incremental development is great when you're a VC-funded startup in Mountain View, but when you're a real business you either have a working product that people want, or you don't.
Oh, how I wish I could tell myself this five years ago. Maybe it's the industry I do most of my development for, but users I interact with very rarely want to hear "that will be in 2.0!" The ones that even let you finish the sentence before hanging up/walking out usually respond with "That's great. Let me know when it's done, then we can talk about signing up."
MVP and incremental development is great when you're a VC-funded startup in Mountain View, but when you're a real business you either have a working product that people want, or you don't.
Wow, I wasn't sure if that blog post was some sarcasm from some trolls or a real article.
I could quote lots of parts, but here's one of the funniest ones:
>> But intelligent iteration wasn’t possible because of our obese development costs, which left us without any funds to product iterations.
>> We wasted money democratically across developers, patents, e-mail platforms, and a sales pipeline tool
>> Hidden inside our minimum viable product was a separate mobile application to gather data on logic model performance.
The sad part in it is how they blame the process for their failure when they got it all wrong.
However, one thing I've got from this article is how hard it is to create a good mvp. The balance between Quality vs Learning vs Minimum is tricky and highly dependent of your customer. I.e. You create MVPs to learn fast so you can iterate faster.. but since you're still trying to validate your hypothesis, it's hard to decide what is really minimal or valuable.
I guess MVPs is an over-used word.. I prefer prototype: A first or preliminary model of something, esp. a machine, from which other forms are developed or copied. Basically, you use prototypes to iterate really fast and test your assumptions, and then, you build a mvp from what you've learned.
I prefer prototype because it's clear on both side that it's not the real product. It's a temporary phase to test the ideas. But again.. way easier to say than to do. I'm currently in that "prototype vs MVPs" phase and I'm struggling on determining the best next step. The fact that I'm working with health professionals with sensitive and highly important information clearly doesn't help.
That would be amazing if a lean expert reading this would feel generous enough with their time to help me with that "next important step" (phzbox at gmail).
Anyhow, thanks to Casca for sharing his experience.. Learning from failures is more often than not better than trying to copy a successful strategy.
I could quote lots of parts, but here's one of the funniest ones:
>> But intelligent iteration wasn’t possible because of our obese development costs, which left us without any funds to product iterations.
>> We wasted money democratically across developers, patents, e-mail platforms, and a sales pipeline tool
>> Hidden inside our minimum viable product was a separate mobile application to gather data on logic model performance.
The sad part in it is how they blame the process for their failure when they got it all wrong.
However, one thing I've got from this article is how hard it is to create a good mvp. The balance between Quality vs Learning vs Minimum is tricky and highly dependent of your customer. I.e. You create MVPs to learn fast so you can iterate faster.. but since you're still trying to validate your hypothesis, it's hard to decide what is really minimal or valuable.
I guess MVPs is an over-used word.. I prefer prototype: A first or preliminary model of something, esp. a machine, from which other forms are developed or copied. Basically, you use prototypes to iterate really fast and test your assumptions, and then, you build a mvp from what you've learned.
I prefer prototype because it's clear on both side that it's not the real product. It's a temporary phase to test the ideas. But again.. way easier to say than to do. I'm currently in that "prototype vs MVPs" phase and I'm struggling on determining the best next step. The fact that I'm working with health professionals with sensitive and highly important information clearly doesn't help.
That would be amazing if a lean expert reading this would feel generous enough with their time to help me with that "next important step" (phzbox at gmail).
Anyhow, thanks to Casca for sharing his experience.. Learning from failures is more often than not better than trying to copy a successful strategy.
Right off the bat, it looks like the problem lies in 'we built a software product that simplified how nonprofits plan and measure their social and environmental impact.'. It just seems nothing was built that people wanted to pay for. The product wasn't marketed to people that have the money to pay for it and see the value in doing so. Also they got confused by thinking 'viable' is different to 'desirable'. It's the exact same thing. MVP doesn't mean what's the smallest piece of junk you can throw together and call it software. It means if you strip everything out of your idea and product, what is the one feature that customers would find useful and pay for.
I like the term "minimum desirable product". Minimum viable product suggests something that barely works, while minimum desirable product alludes to something people actually want.
> I like the term "minimum desirable product". Minimum viable product suggests something that barely works, while minimum desirable product alludes to something people actually want.
I think "minimum viable product" works, and is better than "minimum desirable product" at describing the goal, since to be viable as a product something must not only be desired, but be desired by customers willing to pay for it sufficiently to meet the marginal costs of delivering it.
Of course, an MVP can fail to be viable as a product and still deliver validated learning (as I understand, the original definition of the purpose an MVP) that progresses you toward something viable as a product, but the goal at each iteration should be to have something valuable as a product (and this is consistent with the more general lean methods which lean startup draws on, where each iteration aims to do the minimum work that will produce independent business value.)
I think "minimum viable product" works, and is better than "minimum desirable product" at describing the goal, since to be viable as a product something must not only be desired, but be desired by customers willing to pay for it sufficiently to meet the marginal costs of delivering it.
Of course, an MVP can fail to be viable as a product and still deliver validated learning (as I understand, the original definition of the purpose an MVP) that progresses you toward something viable as a product, but the goal at each iteration should be to have something valuable as a product (and this is consistent with the more general lean methods which lean startup draws on, where each iteration aims to do the minimum work that will produce independent business value.)
Minimum Delightful Product is the variant that I like best.
I upped you on that one - good call on the clarity of desirable over viable.
Critical Point: Viability is judged by your customer.
Developers are comfortable with dealing with some quirks in software. They typically use some of the fastest computers and the most up to date browsers. They live in and build the world of software.
It is very difficult for a developer to understand the mindset of a non-technical customer and see their software from the customer's perspective and experience-base. It's not impossible to do this. But if you don't try hard enough your project will fail.
Developers are comfortable with dealing with some quirks in software. They typically use some of the fastest computers and the most up to date browsers. They live in and build the world of software.
It is very difficult for a developer to understand the mindset of a non-technical customer and see their software from the customer's perspective and experience-base. It's not impossible to do this. But if you don't try hard enough your project will fail.
Lean Startup theory can be pain in the ass for many kind of startups. I think it's wrong that Lean Startup doesn't encourage sales from the very beggining. Sales are the best validation of your idea, not feedback from customers who doesn't pay for your MVP anyways. Build a product for people who pay for it - that's my advice. It's not universal eighter, but more than 50% of startups can start sales before coding anything.
"Early adopters” and “earlyvangelists” are certainly not fictional characters. They exist, but are rarely found working in government ministries.
Great share to hear the more realistic side of some of the MVP pieces.
Certainly one of the biggest challenges I hit almost daily with my saas is what feature is critical to success, and which can be 2.0, especially in light of the comment than they might not want to wait for a 2.0. Customer research only gets you so far.
It's not enough to simply survey people on whether or not they have a problem and then go build. Building good software means building something that people want to use. If you fail to properly dive into customer development and learn about your customers base (what tools do they currently use, who are the early adopters, what are the existing barriers to entry) then you will likely not succeed.
Simply reading one book and some blogs on Lean (or any other methodology) also does not make you an expert. You should read about many different business strategies to understand the key parts of them and how they are similar and different. It's a bit naive (arrogant?) to think you can just read a book and then go conquer the world without having to constantly learn and adapt during the process.
Simply reading one book and some blogs on Lean (or any other methodology) also does not make you an expert. You should read about many different business strategies to understand the key parts of them and how they are similar and different. It's a bit naive (arrogant?) to think you can just read a book and then go conquer the world without having to constantly learn and adapt during the process.
Sorry to add to my rant but I get really tired of hearing the "X methodology killed my business" story. There have been hundreds of thousands of successful businesses created and operated by people without formal training in any strategy so why should having read about a business strategy destroy your business? Did it remove your ability to talk to customers and respond to their concerns?
People often fail to address internal issues like limited domain expertise or limited business skills. It's not enough just to see a problem and be excited about solving it, you need some skills (either present or learned) and you need resources.
Lean is focused around learnings. If you had focused on learning rather than whether or not you completed a task (MVP, demo, etc), you'd realize that you've gained a lot from the experience but it wasn't until you reflected that you realized you failed to incorporate those learnings back into the business.
Also, failure to understand that your first customer wasn't an early-adopter really hurt you. If someone isn't willing to jump through hoops to use your product, it either 1) doesn't solve a big enough problem or 2) they aren't an early-adopter.
People often fail to address internal issues like limited domain expertise or limited business skills. It's not enough just to see a problem and be excited about solving it, you need some skills (either present or learned) and you need resources.
Lean is focused around learnings. If you had focused on learning rather than whether or not you completed a task (MVP, demo, etc), you'd realize that you've gained a lot from the experience but it wasn't until you reflected that you realized you failed to incorporate those learnings back into the business.
Also, failure to understand that your first customer wasn't an early-adopter really hurt you. If someone isn't willing to jump through hoops to use your product, it either 1) doesn't solve a big enough problem or 2) they aren't an early-adopter.
It may well be that your product just wasn't needed or that your focus was wrong, for instance customers might have wanted feature y before feature x: It is not uncommon to find it difficult to work out what customers want in isolation.
(Shameless plug alert!)We encountered this several times in our own failed startups where we have built the best software the world has never seen and decided to create WillThisFly? to address these issues: It allows you to develop your product with feedback from day one, validate ideas and features, iterate and develop before committing time and resources to it or indeed, find out that it's a non-starter.
Our MVP is online now at http://willthisfly.net/projects/1/
(Shameless plug alert!)We encountered this several times in our own failed startups where we have built the best software the world has never seen and decided to create WillThisFly? to address these issues: It allows you to develop your product with feedback from day one, validate ideas and features, iterate and develop before committing time and resources to it or indeed, find out that it's a non-starter.
Our MVP is online now at http://willthisfly.net/projects/1/
But since anyone hoping to make a new product should be talking to his real potential customers, why would he not talk to them directly, instead of say, trying to get them to use WTF?
Anyone other than his real-life potential customers giving him feedback is.. well, not going to give him the feedback he needs, no matter how well-intentioned he is.
Then there's the issue of someone potentially stealing your idea, etc.
Anyone other than his real-life potential customers giving him feedback is.. well, not going to give him the feedback he needs, no matter how well-intentioned he is.
Then there's the issue of someone potentially stealing your idea, etc.
What WTF provides is the ability to come up with an idea and get a quick gauge as to whether it has merit (it works with projects at various stages from new ideas to coming up with new features for existing projects and anything in-between).
For example, you have likely heard of "Facebook killer" apps and "New way to organize your inbox"-type ideas in the past and the general reaction is "Oh ffs, not another <insert product here> clone" but most ideas still have some merit even if their initial briefs are rather ambitious and somewhat tenuous.
Your Facebook killer may be too ambitious but with a bit of focus you may be able to come up with a smaller, more niche product that benefits a particular demographic given feedback and some direction.
This is what WTF provides: Sure, it will not give you a definite "If you build it, they will come" answer but it might just be able to help you salvage something that doesn't look like it is going anywhere.
In addition to helping you shape a project, it may also prevent you from spending time and money on something that just will not work as a result of feedback so you will know fast if it has any potential before spending time and money on it.
AS to stealing your idea, this is rarely the case. The thing that sinks most projects is lack of focus and aiming in the wrong direction - something WTF is designed to help prevent.
Thanks very much for your insight... this is exactly what WTF was designed for.
Mick
For example, you have likely heard of "Facebook killer" apps and "New way to organize your inbox"-type ideas in the past and the general reaction is "Oh ffs, not another <insert product here> clone" but most ideas still have some merit even if their initial briefs are rather ambitious and somewhat tenuous.
Your Facebook killer may be too ambitious but with a bit of focus you may be able to come up with a smaller, more niche product that benefits a particular demographic given feedback and some direction.
This is what WTF provides: Sure, it will not give you a definite "If you build it, they will come" answer but it might just be able to help you salvage something that doesn't look like it is going anywhere.
In addition to helping you shape a project, it may also prevent you from spending time and money on something that just will not work as a result of feedback so you will know fast if it has any potential before spending time and money on it.
AS to stealing your idea, this is rarely the case. The thing that sinks most projects is lack of focus and aiming in the wrong direction - something WTF is designed to help prevent.
Thanks very much for your insight... this is exactly what WTF was designed for.
Mick
Well, if I have a good idea, post it there and get a lot of positive feedback, wouldn't that downright encourage someone to implement the idea now that it's (supposedly) been validated?
Don't get me wrong, I'm not hoping WTF will not succeed. It's just that as someone who's just wasted several years of his life on products that went nowhere, I'm a bit skeptical.
"The Lean Startup" seems like the way to go, but that involves speaking directly to your potential customers, because they're the only ones who know what they really need. Apparently it's really freaking difficult to confirm that you've really got a product-worthy idea on your hands, even if you're talking to potential customers.
Don't get me wrong, I'm not hoping WTF will not succeed. It's just that as someone who's just wasted several years of his life on products that went nowhere, I'm a bit skeptical.
"The Lean Startup" seems like the way to go, but that involves speaking directly to your potential customers, because they're the only ones who know what they really need. Apparently it's really freaking difficult to confirm that you've really got a product-worthy idea on your hands, even if you're talking to potential customers.
I think the author hits the nail on the head with the term "minimal desirable product" rather than "minimum viable product".
Many of the commenters here are replying with things like, "Dude, you don't understand the meaning of the term 'viable'." I can say that I've worked with plenty of developers who think of MVP as "the minimum amount of shit I need to build to ship this thing" rather than "this is the minimum that needs to be developed to make something that someone would be happy to use."
With all that said, I think changing the term to "Minimum Desirable Product" would be something that helps get everyone involved with a software product on the same page.
Many of the commenters here are replying with things like, "Dude, you don't understand the meaning of the term 'viable'." I can say that I've worked with plenty of developers who think of MVP as "the minimum amount of shit I need to build to ship this thing" rather than "this is the minimum that needs to be developed to make something that someone would be happy to use."
With all that said, I think changing the term to "Minimum Desirable Product" would be something that helps get everyone involved with a software product on the same page.
Not specifying what browser/versions you would be supporting - when dealing with anything remotely government is a mistake. Having an access denied error message right after signing up means your basic happy path wasn't working correctly and neither were your development and QA processes. Testing features in production is different than testing logic in production.
Your blog looks like it's owned by Twitter. The twitter logo is in the usual location of the owner's logo. I suggest you repair this. Among other things, it's probably against their policy.
Also, I had exactly the same experience, but the difference here is the enterprise nature of the startup. Enterprise demands power, and investment, and capital. You can't do it lean.
Also, I had exactly the same experience, but the difference here is the enterprise nature of the startup. Enterprise demands power, and investment, and capital. You can't do it lean.
Many people i talk make the same mistake with lean and custdev.
And i have to say i did the same mistake.
We try to things the lean way and hope therefore we do it the right way. Eg. building an MVP that should validate our business assumptions.
All of the methods around lean and custdev sound perfect in theory. But validating that you do the right thing (apart of a super obvious strong market pull) is extremely hard.
A common mistake i see is when people speak about 20 different hypotheses or experiments - and usually none of them is related to a real make-or-break risk of their company.
They try to validate that they do the right thing. Which is extremely hard.
As entrepreneurs we are in charge of a strong product/customer vision. Any method we use is only in charge to check if we are lying to ourselves.
But many of the techniques used in custdev/lean are very strong tools for minimizing the downside.
And this is (imho) where we should use them.
Our main goal is not upside optimisation (waiting for the go) but downside minimization (avoiding the no-go)
Or differently put: They are very good to double check if you aren't doing the wrong thing, if we aren't lying to ourselves.
The other main mistake i see is "trying to do it the lean way":
There is no "lean" way. Lean is a reverse engineered model largely based on survivor bias and wrong self-reflection. But that's completely ok. We must not forget how young fast-growth oriented product-centric entrepreneurship is. Even custdev which is more fullstack than lean is mostly academic and best used only as a frame of thought. Not as a blueprint model. Lean will be replaced by other models using the same or improved stack elements.
Just like me, too many people are obsessed with the theory behind lean and see it as fullstack solution.
Instead of looking at lean as a fullstack, we should pick parts of that stack that make sense for our business - as we do eg in software engineering or ux.
E.g. MVPs tend to be a problem with b2B relationships. Agency like concierge code-for-hire models tend to work better. Also customer interviews work gold for B2B - by far better than for b2c models.
Simply put: We need to pick stack elements of lean and custdev as we would pick elements of software stacks, depending on our business's risks and challenges.
If you are interested what i mean with stack elements, take a look at - customer interviews http://www.slideshare.net/andreasklinger/actionable-customer... - metrics in early stage http://www.slideshare.net/andreasklinger/metrics-for-early-s... - jobs to be done http://hbswk.hbs.edu/item/6496.html - and several other aspects: http://www.hackertalks.io/robfitz/why-bother-talking-to-cust...
And i have to say i did the same mistake.
We try to things the lean way and hope therefore we do it the right way. Eg. building an MVP that should validate our business assumptions.
All of the methods around lean and custdev sound perfect in theory. But validating that you do the right thing (apart of a super obvious strong market pull) is extremely hard.
A common mistake i see is when people speak about 20 different hypotheses or experiments - and usually none of them is related to a real make-or-break risk of their company.
They try to validate that they do the right thing. Which is extremely hard.
As entrepreneurs we are in charge of a strong product/customer vision. Any method we use is only in charge to check if we are lying to ourselves.
But many of the techniques used in custdev/lean are very strong tools for minimizing the downside.
And this is (imho) where we should use them.
Our main goal is not upside optimisation (waiting for the go) but downside minimization (avoiding the no-go)
Or differently put: They are very good to double check if you aren't doing the wrong thing, if we aren't lying to ourselves.
The other main mistake i see is "trying to do it the lean way":
There is no "lean" way. Lean is a reverse engineered model largely based on survivor bias and wrong self-reflection. But that's completely ok. We must not forget how young fast-growth oriented product-centric entrepreneurship is. Even custdev which is more fullstack than lean is mostly academic and best used only as a frame of thought. Not as a blueprint model. Lean will be replaced by other models using the same or improved stack elements.
Just like me, too many people are obsessed with the theory behind lean and see it as fullstack solution.
Instead of looking at lean as a fullstack, we should pick parts of that stack that make sense for our business - as we do eg in software engineering or ux.
E.g. MVPs tend to be a problem with b2B relationships. Agency like concierge code-for-hire models tend to work better. Also customer interviews work gold for B2B - by far better than for b2c models.
Simply put: We need to pick stack elements of lean and custdev as we would pick elements of software stacks, depending on our business's risks and challenges.
If you are interested what i mean with stack elements, take a look at - customer interviews http://www.slideshare.net/andreasklinger/actionable-customer... - metrics in early stage http://www.slideshare.net/andreasklinger/metrics-for-early-s... - jobs to be done http://hbswk.hbs.edu/item/6496.html - and several other aspects: http://www.hackertalks.io/robfitz/why-bother-talking-to-cust...
Thanks for summarizing. It seems like you have a lot of useful info here and I appreciate your contribution. However, I'm really having a hard time parsing this; it seems like you're repeating the same thing several times. Any additional effort you can invest in further editing your post would be greatly appreciated!
Edit: Might look at a higher sentences-per-paragraph ratio, I think that's what's throwing me off.
Edit: Might look at a higher sentences-per-paragraph ratio, I think that's what's throwing me off.
You are completely right. Sorry i just wrote it in one go.
I tried to restructure it. Hope it is now a bit clearer.
I tried to restructure it. Hope it is now a bit clearer.
Organizationally, non-profits are a special beast, requiring very different handling than corporate IT buyers. I don't think the Fat Startuppers grok'd their customers at all.
Honestly, I don't think they learned very much - their "four fundamentals" are just platitudes. There must be more to this story - I wish they could unearth it within themselves.
Honestly, I don't think they learned very much - their "four fundamentals" are just platitudes. There must be more to this story - I wish they could unearth it within themselves.
I always find it interesting when a methodology XYZ is critiqued its adherents invariably claim "that's not really XYZ."
> I always find it interesting when a methodology XYZ is critiqued its adherents invariably claim "that's not really XYZ."
If the example given to justify the criticism isn't actually applying what XYZ calls for, its a perfectly legitimate response. Often, the problem may still be with the methodology, and it may just be that the methodology isn't practical to implement because it makes unrealistic assumptions, but the evidence needed to support that goes beyond a examples of incomplete attempts to implement it not producing the desired results, and requires something to show why attempts to implement it are doomed to be incomplete.
If the example given to justify the criticism isn't actually applying what XYZ calls for, its a perfectly legitimate response. Often, the problem may still be with the methodology, and it may just be that the methodology isn't practical to implement because it makes unrealistic assumptions, but the evidence needed to support that goes beyond a examples of incomplete attempts to implement it not producing the desired results, and requires something to show why attempts to implement it are doomed to be incomplete.
The problem is, you can discredit any failed startup by saying their MVP just wasn't viable enough. Well, duh. Knowing what's viable and building it is the difficult part, but isn't that what lean methodology is supposed to help with to begin with? Lean methodology inadvertently makes it seem like the hard part is the easy part, and therefore confuses people.
> Knowing what's viable and building it is the difficult part, but isn't that what lean methodology is supposed to help with to begin with?
Lean approaches (including, but not limited to, lean startup) provide basic rubrics about where to focus your efforts to optimize return for effort. They aren't, however, a magic wand that substitutes for skill, judgement, and domain expertise (well, perhaps a little for the last, since inherently lean uses the scientific method to grow domain knowledge in a highly-focussed way, but unless you've got a deep reserve of resources to fund failures that you learn from, or get really lucky, you are still likely to fail without domain expertise going in.)
The biggest problem with lean now is it is being treated as if it were a formulaic, recipe-driven methodology that substitutes for specialized skill, when lean is pretty much an anti-recipe approach that is all about everything you do being part of a continuous hypothesis-test-review improvement cycle, including the kind of things you might get from a book discussing practices that others developed via lean, which may provide a starting point for your practices, but not a fixed methodology.
Lean approaches (including, but not limited to, lean startup) provide basic rubrics about where to focus your efforts to optimize return for effort. They aren't, however, a magic wand that substitutes for skill, judgement, and domain expertise (well, perhaps a little for the last, since inherently lean uses the scientific method to grow domain knowledge in a highly-focussed way, but unless you've got a deep reserve of resources to fund failures that you learn from, or get really lucky, you are still likely to fail without domain expertise going in.)
The biggest problem with lean now is it is being treated as if it were a formulaic, recipe-driven methodology that substitutes for specialized skill, when lean is pretty much an anti-recipe approach that is all about everything you do being part of a continuous hypothesis-test-review improvement cycle, including the kind of things you might get from a book discussing practices that others developed via lean, which may provide a starting point for your practices, but not a fixed methodology.
Ship early, ship fast, ask questions, write down answers, run tests. That's what "lean" is all about.
Ironically, the first two of the "four livelihood-threatening fundamentals" that the Lean Startup methods distracted them from are pretty much verbatim parts of the Lean Startup method.
What is the difference between a software startup and a small company that writes custom software?
Some markets just don't self serve.
Segue to edit of my standard rant on this subject: (originally posted on: http://news.ycombinator.com/item?id=3429906)
MVP != half assed, cheap, shitty product. It is exactly what it says: a minimum viable product, key word being viable. An MVP for a mission critical application or a cutting edge piece of research isn't going to be cheap or easy, because it needs to be viable.
Because of the name, many people make the assumption that doing a Lean Startup means not taking the time or money necessary to execute properly, this is not the case. Lean means conserving capital by focusing on iteration until you each product market fit, and only then ramping up sales or marketing, but again, if you're cracking a new market, untested technology, or going up against mature competition, even that phase of conserving capital and focusing in product may require a lot of capital.
Your product, when released to customers, needs to be usable, and needs to scratch an itch for them, otherwise it is inherently not viable. That's why customer development is so essential, it prevents you from making the worst mistake possible-- building a robust product no one wants. Even if you have the best product idea in the world, the only way to know if the features you add are having a positive impact is to measure the behavior of real, live, human users.
That being said, it's still your responsibility to stay relentlessly focused in your core value proposition. You can't build every feature you're customers ask for, only the ones that make sense for your product.
What we're seeing now is the lean startup backlash where people use the terms but don't really take the time to understand what they mean,.
The Lean startup movement is a powerful set of lessons that can empower entrepreneurs and save us from wasting our time and effort building the wrong things and chasing the wrong metrics, but I guess some of the lessons just have to be learned painfully through experience (it was certainly true for me).