Initial Business Model Canvas

Last week I wrote about “Eating Your Own Dog Food” as a mentor at an incubator. We have taken the next step and created an initial business model.

There are different options for creating and representing business models. At the eCentre we use business model canvases. This idea originates from an initiative that resulted in a book titled “Business Model Generation”. Alexander Osterwalder and Yves Pigneur wrote it with hundreds of contributors. Online tools are available from several places but a good source is the site for the book.

In the meantime some variations exist. As with other topics there are defenders of the “only truth” who believe that changing the original idea destroys it. To me that type discussion reminds me a little bit of the discussion which programming language is the best. I think it is important that a tool works for you. And if it doesn’t try something else.

In our case we decided to try out a variation called Lean Canvas. Some of the elements are changed over the one created by Osterwalder et al. I want to mention only the differences that are most interesting for our case: Problem, Existing Alternatives and Solution.

As recommended we created the initial canvas in just about 20 minutes. In the past week we then had a more detailed discussion about the canvas and refined a few items.

The basic idea is that everything that you put into the canvas is basically a hypothesis about some aspect of your business model. You then validate each of the hypothesis. The outcome can be either that a hypothesis is upheld or it is wrong. How do we find out?

Steve Blank suggests as part of the customer discovery activity: None of the facts you need exist within the building (see “Four Steps to the Epiphany”). You have to get out of the office and talk to people. Who would you talk to? Your canvas helps you as you will have identified target “Customer Segments”. That’s who you talk to.

So, in our case we have an initial business model canvas. Now we need to validate each hypothesis in it. We are prepared to revisit the canvas as often as needed based on the feedback we get. We have started to generate a list of people who we want to speak with. This will take a few weeks.

Books mentioned in this post:

Example of Expensive Software Project Gone Wrong

Novopay is a payroll system for school and school support staff in New Zealand. It’s development started in 2005, was planned to cost 30 million NZ dollar and take 2 years to develop. As of 01 February 2013 staff are owed an estimated 12 million NZ dollar due to errors in the software. As of writing it is still possible that it may be switched off.

While I can’t speak as an expert for this particular project, the newspaper articles reveal some interesting facts. For example the first emergency meeting apparently was conducted only after 5 years. Note this project was planned to take 2 years. The system was signed off based on the recommendations of four advisers, one of them PWC. Then it went life despite almost 6,000 payslip errors.

One actual result of the live system was a payslip sent to a caretaker who was awarded a 102 million dollar holiday pay packet. Unfortunately for him, he won’t be able to keep the overpayment.

The deputy education secretary reportedly said in April 2012 that “there was a need to run a total of 270 test scripts”. Frankly, I’m hoping that they had more than 270 test scripts and I hope they were all automated.

More details can be found in articles here and here. I’m mentioning this project here as quite obviously something went terribly wrong. Is there something that can we learn from this? Can we do better? Are we doing better?