About ten years ago there was a rumour. If you want to get things done, and if you want to get them done fast, go for PHP. Yes, it’s been like a badly done perl ripoff with even worse object orientation and inconsistent apis, but somehow the people creating in software in PHP were able to deliver. And they were able to deliver fast, open for changes in the last 24 hours and they fixed bugs in production fast. From a software engineering professionals point of view this sounded risky, unprofessional and dangerous. This could only lead to crappy code. A proper software engineer would never use this language, and he won’t ever accept changes in the last minute nor work with a customer that does not know exactly what he wants.

The business people with a track record of practical web application experience on the other hand side were happy. They knew that even an extensive – and expensive – specification won’t deliver something the customer actually wants nor a reliable rollout. They already experienced that there were always failures, and a lot of them. And that these failures were ok, because they helped to change the product they created to the product the customer actually needs.

And this was exactly what PHP was created for, or, to put it in rasmus lerdorf words: „Fail early and fail cheap„.

So we PHP people are good at failing early, fast and cheap. If you want enterprise grade fail, ask the java guys, if you want scalable fail, ask the c guys. If you want smart fail, ask the clojure guys. But early and cheap, ask us.

Some years later, about 2008, something bad happened to us online application developers. Suddenly the venture capital companies stopped throwing money at us for visionary and funny ideas with a rounded corners portal site. They figured out that „visionary and funny“ was good for that 3-am-and-pretty-drunk moment at a campus party, but, in most of the cases, did not earn any money, even with rounded corners.

So we tried our best to change their mind and came up with really large letters and even larger buttons. But they didn’t believe that this would help. We repackaged the whole dirty-early-cheap-fail product, labeled it „Ruby on Rails“ and tried to sell it as something completely different and new. They did not believe that this would help. We even got our stuff running on the jvm for the enterprise-grade-fail guys, but they just said „Hey, it’s still not earning any money, it’s just more expensive.“

So if you wanted to create a startup in 2008, you had to do it with your own money. And there wasn’t a lot of it.
We knew that we could be pretty efficient. The average number of lines needed for a successful portal site could be done in 3 months with 2 or 3 really smart devs.
On the other hand side we knew that around 60% of the projects we do fail in time or budget. We knew that roughly 66% of the features we created were never or seldomly used (Check the standish group chaos report if you don’t believe me). We knew 90% of all startups never earned the money spent. We knew only 2% of all startups really created a big amount of money. Damn.

So the startups back than changed their strategy:
If they are so fast at doing stuff, how about learning faster? They could make more failures, and they could make them early and cheap. And they could validate if the customers really needs what they offered. They could make deployment cheaper and faster. They could make quality assurance cheaper and faster. They could make the validation itself faster and cheaper.

Since they knew that their assumptions are probably wrong, they didn’t create a „correct“ product. They just created „enough product“ to figure out what the customer needed. It did not matter if it makes him happy, it did not matter if they could already earn any money with it. But they could learn if the basic idea is ok enough to go on, or if they had to change it (remember: statistically, within 50 ideas there is one that really works out :-) ) .

With this basic (let’s call it „minimum viable„) product they tried to get hold of any customer feedback they could get. They interviewed them, they created an online (i.e. twitter / facebook) community, they created an user group meeting. They wrote down all the ideas, additional features, changes and improvements the customers wanted and created an prioritized feature backlog.
But they did not implement every feature like the customer said he wanted it: they stripped it down to have just enough feature that some users could test it and give feedback about it. This smallest possible featureset was called minimum marketable featureset. But they did not only ask the user for feedback – they asked the software itself, too. Everything was monitored, so they knew if the overall user behavior actually changed with the new feature. And if there was more money to be earned with this feature activated. If the feature did not work out, it was changed. When they changed it for several times and they recognized that the feature would not work out they abandoned it.

This feature development cycle is where optimization happens in the lean startup. Each cycle should be as fast and as cheap as possible. If the collected data shows that even with a lot of feature improvements and changes a profit-making state won’t happen, the product needs to pivot to a new basic idea.

Most lean startups are coordinated by kanban because scrum is simply not fast enough. Since an average cycle from idea to measured data can be down to 2 days, a sprint is too long to realize fast learning.

So that’s what happens in every days business:
Your customer has a rather raw feature idea. He is not really sure if it is going to work out. He wants it in production within 2 days. You strip the feature down to what you think is actually needed, and put it into production, however you know it is going to change anyway. Your customer gets a call by one of his clients that the feature should be changed, and he calls you that he wants it in production in 2 days. One week later both of you figure out that the feature did not make any sense, and it’s remove completely.

Sounds familiar? Yep, that’s how we did PHP development ten years ago. The only difference is that today it’s organized, tested and validated.

Lean startup is about failing early and cheap in an organized way. It’s what we always did in php, just with an outspoken knowledge of producing failure and the will to learn.
There is a lot more the be found in lean startup – check out Eric Ries google tech talk or his book „lean startup„.