Fat startup: Learn the lessons of my failed Lean Startup
wordsting.com
wordsting.com
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).
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:
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.
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.
But if you want a more traditional success story, I'd suggest Boxbee:
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.
I don't mean to imply that there aren't any, but I just haven't heard of any.
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.
"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?
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".
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.
> 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. That's a MVP, not a crappy product which doesn't even work.
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.
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-...
"...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.
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.
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.
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!
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"
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?
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.
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.
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!
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.
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.
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 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.)
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.
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.
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.
(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/
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.
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
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.
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.
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.
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...
Edit: Might look at a higher sentences-per-paragraph ratio, I think that's what's throwing me off.
I tried to restructure it. Hope it is now a bit clearer.
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.
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.
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.