Work in small batches using small, cross-functional teams and hold yourselves accountable using continuous testing with actionable metrics.
That, to me, is the heart of Eric Ries’ excellent book The Lean Startup. Ries is himself an entrepreneur and Lean Startup methodology is derived from having applied principles of Toyota’s lean manufacturing to the issues he faced as the CTO of IMVU.
A quick Google search will show that his ideas on a Build-Measure-Learn cycle of agile project development is really catching on, and here are three things that really struck me as I read the book.
“The Minimum Viable Product is the basic learning tool that you test hypotheses on. It is the most stripped down version of the product that will help you learn what you need to know. Once you have your idea, the MVP is what you use to measure, learn and adjust.”
As I read the book, I was in the midst of a huge project (a responsive version of http://www.clermontcountyohio.gov/) and I realized that it was starting to fall victim to scope creep.
“As you consider your own minimum viable product, let this simple rule suffice: remove any feature, process or effort that does not contribute directly to the learning you seek.”
The MVP was the serendipitous kick I needed and the very next day I stripped out any planned functionality that was not absolutely needed.
Just like that, I was back on target to hit my launch date with ease.
”Success is not delivering a feature. Success is learning how to solve the customer’s problem.”
Ries explains that the goal of an MVP is to draw a line in the sand and let your users decide what they think of the new line. I had allowed myself to be lulled into creating a beautiful, idealized strategy of what the new site should be… but I was doing it in a vacuum.
The MVP will allow me to get feedback from actual users and it has already been significantly altered based on the reaction of some initial testing done with quality (meaning honest answers that I did not always like) testers. While I had a great initial strategy, it’s always helpful to look at actual, real-world results.
Simply ask “Why?” five times in order to drill down to the root cause of an issue. From an HBR article:
One such technique is called Five Whys, which has its origins in the Toyota Production System, and posits that behind every supposedly technical problem is actually a human problem. Applied to a start-up, here’s how it works:
“What began as a purely technical fault is quickly revealed to be a very human managerial issue.”
“That’s where the proportional investment tactic is so important. If this outage was a minor problem, it’s essential that we make only a minor investment.”
“At Toyota, this person is the chief engineer:
Shusha are often called heavy-weight project managers in the U.S. literature, but this name understates their real role as design leaders. Toyota employees translate the term as chief engineer; and they refer to the vehicle under development as the shusha’s car. They assured us that the shusha has final, absolute authority over every aspect of vehicle development.”
When the product or project is successful, it will need to be moved out into the main organization to allow growth. The shusha should still be in charge, given the rewards and responsibility of a larger team and successful product.