Happy New Year.
In the last month of 2012 (also known as December, I’m told) I tore through a number of books I had on my reading pile. This dovetailed nicely with an approach from someone I know (an old client) to start up a joint venture.
As I get older, I am less and less surprised by the workings of serendipity. As luck would have it, the books I was reading were perfect for helping me think about what needed to be done to get this new venture up and running. This month I will be setting things in motion and I hope to be able to talk more about the new business soon. I am excited about it.
Here are some of the books in question:
- The Lean Startup – Eric Ries
- The Impact Equation – Chris Brogan and Julien Smith
- Made To Stick – Chip Heath and Dan Heath
- Writing That Works – Kenneth Roman and Joel Raphaelson
The first of these was a refreshing read for someone that, when an IT staffer (and contractor) chaffed against the corporate software development process. The large scale projects I worked on for a long time were developed according to the ‘waterfall’ process. That meant spending many months gathering requirements from what are politely termed stakeholders. In reality, stakeholders tend to be people with a greater sense of the political benefits of a new IT system than the practical business benefits. (I may be unduly cynical.)
After the requirement were gathered and a long and meaty requirements specification written to prove that we had understood what was being asked for, it was time to write a functional specification, which was meant to show how the requirements would be turned into screens and buttons and database actions and reports and all the usual large IT system guff. The stakeholders would see that some of their requirements were missing. We would explain that if they wanted the system to be live while humans still roamed the planet, there would have to be some compromises.
Then the system was built. In many cases, we were now a year or so down the line from the project start date. Some of the stakeholders may have retired or moved onto new jobs or new companies. We worked on. System testing. Then user testing. A new set of users and stakeholders, on receiving the system, wondered what is was for. We had solved a problem that was two years old. Maybe three years old. Way to go.
What was missing in this process was what Eric Ries calls the build-measure-learn feedback loop. Well, not exactly missing but when the learning comes so far after the start of the project, it’s as good as being useless. There is no way to change the build: the options are to scrap it and the millions invested in the project so far or to force end users to change the way they work to justify the millions invested in the work so far. That might work in a corporate environment for internal systems. It doesn’t work in the world of new products and services aimed at customers, be they retail or business.
The Lean Startup (see above – and that’s an affiliate link, by the way) is an excellent application of lean manufacturing (as practised by Toyota, for instance) combined with agile programming techniques and using the potential of internet technologies for garnering feedback on a minimum viable product (another Ries term that is inherently useful).
Best of all, the approach works equally well with products or services, so whether your startup is a consultancy or is building a physical product for online sale, The Lean Startup is a perfect guide for making sure you have something that your potential customer base might actually want.
There is a web site (and movement) associated with the book at The Lean Startup (surprise, surprise).
And a hat tip to my old business partner Adam Austin of The Better Web Co for aiming me towards the book in the first place.
I’ll give you my take on the other books from my December list over the next few days.