Its Time to Stop Following the Lean Startup Movement
Twenty years ago (in 2002), I read a story about how software is so bad that it kills people, and the story has stuck with me since then. The article ended with a naive notion that the future is bright and "… soon, we'll innovate, litigate and regulate them into reliability" even Bill Gates declared that "reliable and secure" computing is "highest priority." Well, nothing like that ever happened, but luckily the revolution to fix bad software started elsewhere.
In 2001, a bunch of people who were also concerned about the frustrating state of software went skiing together. They came up with the Agile Manifesto to fix all that, and becoming agile has been a Sisyphean task for companies big and small since then. A few years later concept of lean (adopted from manufacturing) was popularized in software development when Mary and Tom Poppendieck published their famous book "Lean Software Development". Followed by The Lean Startup movement with a myriad of The Lean XYZ books. We got a lexicon of new terms, such as MVP-s, lean startups, validation, iterations, lean UX etc. The buzzwords are not inherently wrong things themselves, they help with communicating concepts. It would be tedious to explain to your team that we need to build a version of a new product that allows us to collect the maximum amount of validated learning about customers with the least effort (MVP definition from Lean Startup by Eric Ries). The problem is that buzzwords' initial goals and intentions tend to fade or turn into something completely different. And the MVP is one of the most misused.
Originally (most of) the software and product development revolutions were introduced to improve quality. Although "building quality in" is one of the seven principles in lean, the focus shifted from "how to build quality products" to "how to build viable products". Don't get me wrong, building viable products that people need is of utmost importance for the success of any company. Just, it seems the quality aspect has been downplayed. It has been replaced with fast and cheap.
The issue with the lean software development methods is that you are supposed to ship something, learn fast if that works and then continue building on that knowledge (Build-Measure-Learn loop, right). To ‘test the market’. The problem with this advice is that it's only half of the story. Build-measure-learn suggests that you should start with building and then think later. What happens is that you ship something that sort of 'solves the problem' in a quick and possibly hacky way. There is always a backlog of very important problems™ waiting solving. As soon as the ugly hack solves the initial problem, it's no longer a time-critical or business blocker. It's now low priority technical or UX debt, and the team moves on to another high priority problem. Dealing with the dept needs additional effort to fix. That's wasteful and the opposite of lean. After a year, you have turned your product into a monster. Customers hate it, and nobody wants to work on it because it's a shit sandwich. If the initial goal was to test the market then the result is usually just a barely working product or feature.
Doing what the lean startup preaches makes total business sense in the short term. Just get something out fast that you can sell, fix issues later if customers complain. "It's a nice problem to have" because you have customers, as opposed to creating elegant polished products that nobody needs. But bad news travels fast — people who have negative experience vent it to more than ten people vs people who have something positive to say tell fewer than three (CES 2013). I also know this from my experience of fixing broken legacy telco self-serve environments. When we started talking with customers, we learned that they had had a lousy experience years ago, and it was very difficult to turn around. They were reluctant to try the new, improved self-service even when we told them we had resolved all the issues.
It's not that using the lean methods has increased the odds either. 90% of startups still fail; I haven't seen any data indicating that startups employing lean techniques have a higher success rate. I'm not arguing that the whole concept is terrible, just some parts of it. What I'm claiming is that the "If you're not embarrassed by the first version of your product, you've launched too late." mindset is outdated; even the coiner of this aphorism has had to explain years later that he didn't mean that literally. If you are embarrassed by what you launched, you should feel embarrassed.
It does not make sense to quickly build ten features just to learn that only one of them is viable. Your product has now 9 poorly built features that nobody needs and one viable that might lack usability because you just shipped it without any regard to good UX. Letting developers build quick hacks to test your hypothesis is just lazy product managers' work. Finding out what customers need to be viable is the product manager's responsibility. This is literally the most important role of the product manager; the UX designer is responsible for usability and good UX. Doing research, interviews, usability testing is more akin to science than just something trivial. While just talking to your customers is better than not talking at all, if you want to build a quality product with good UX you must have a decent UX designer in your team.
Don't just solve the problem. Solve it so that your product is at least 10x better than the alternative. Don't make your customers' lives miserable because you want to learn whether you should invest some more so your customers don't feel stupid. Don't just hope that if your product sucks, your customers will tell you. They will, and they will do that with their wallets, and they warn their friends. Instead, plan more time into UX research (and hire a UX designer), build prototypes, test prototypes, learn and iterate without pissing off your customers. Don't ship your half-assed MVPs. The only thing you will learn is that people hate buggy and confusing products. Once you are confident that you have got the solution right — you can invest a tiny bit more into ensuring it doesn't suck. If you have done a decent job with the research and testing your MVPs, this investment does not go to waste.
For further reading, I recommend this article by Debbie Levitt. She does a fantastic job pointing out all that’s wrong with The Lean Startup.
