Calendar

October 2014
M T W T F S S
« May    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Links


Categories


Archives


Building a Minimal Viable Product: How Lean Can you Go?

February 2, 2013

The essence of the Lean Startup Approach is to start off with unknown customers and and an unknown product and to converge on a successful product offering and customer definition by carrying out “validated learning” on who the customers are and what they want. There is no mathematical certainty here, it is definitely an exploration. And it is a messy search since there is no well-defined parameter space that we can search through using numerical methods like hill-climbing or steepest descent. On the face of it, it is undisciplined, since there is very little planning. But it can be argued that the lean startup approach is far more disciplined than traditional business planning because of its relentless pursuit of the customers and their needs, and the avoidance of fantasy projections and vanity measures. There is little point in detailed planning and implementation when we don’t really know what the requirements are. And we are better of focusing our time and effort on understanding the customer than we are on impressing and pleasing investors whose money we are busy spending on premature implementation.
images
Why is it a “lean” startup approach? One answer is that it is designed to avoid waste. So many startups consume large amounts of cash developing things that customers don’t actually want, or are not willing to pay for. The temptation is to write a clever plan, raise a bunch of money, and then do a lot of implementation and execute the plan. One can make a lot of impressive slide presentations with this approach. Once the stuff is built you see if customers will actually use it and if they don’t then you raise more money and try again. But according to the lean approach the traditional method does things back to front. Before raising the money and doing the implementation you should first find out what the customers want. And it’s not just finding out what customers want, it is also a matter of testing out various assumptions that are part of the proposed offering.
Some years ago I had the idea of a system that would record meetings and make those recordings indexable and searchable. In principle you could have used the system to check all the meetings where the current topic had come up, and what people had said at those different times. If it had worked as advertised it should have been a real boon for business. I titled the project  “Memories of Synchronicity” and raised half a million dollars from a large company to work on it. I matched that half a million dollars with another half million dollars from federal and provincial government agencies and I collaborated with two very skilled young researchers, one an expert in text retrieval and the other an expert in user interface design. The project produced some interesting research and great research collaborations, but it didn’t succeed in it’s main goal because speech recognition technology simply wasn’t up to the task. Speech recognition works pretty well if you have a good idea about the sorts of things a person is likely to say (like booking a flight reservation), or if a person trains the recognition system on the sound of their particular voice, but the available technology simply cannot figure out who is saying what in a room full of people. We tried everything, including putting highly directional microphones in front of each person in a meeting, but it wasn’t practical. We also tried using the method with voice over IP calls so we knew exactly who was saying what, but the problem of not being able to achieve good quality speech recognition never went away. Bottom line, if we had tested the assumptions right at the beginning we might have found (in spite of all the hype about speech recognition at the time) that what we were trying to do simply wasn’t possible with the available technology.
So every assumption has to be tested and perhaps that is the core of the lean approach along with the idea of continuous improvement or Kaizen, that has been associated with the “Toyota Way”.
PastedGraphic-2
If the essence of the Lean Startup is continuous learning, then how can we make each cycle of learning as efficient as possible? This is where rapid prototyping comes in. You don’t need to implement things to test them, you just need to give users enough of a taste of the real experience for them to judge whether they find it interesting, useful, and potentially usable. And it’s not necessary to test a full suite of functions, you just have to test enough so as to learn useful information that will guide further testing and development.
There are a ton of ways to build rapid prototypes (there’s a classic technical report on this topic at http://eprints.cs.vt.edu/archive/00000179/01/TR-89-42.pdf). You can build paper and pencil prototypes, or you can use rapid prototyping software tools, such as Balsamiq, Mockflow, Axure, or ForeUI. But you can also start learning in focus groups, interviews, with questionnaires, or by repurposing an existing product.
paperprototype
Say, for instance, that you had an idea for a new kind of gift exchange for young mothers. When kids grew out of clothes and toys they could be placed on the gift exchange and other mothers with kids of suitable age could then acquire them. Maybe the new angle of this system would be that no money changes hands (people just get credits that they can use to get other products( and that the whole thing is financed by advertising and selling new gifts to this well targeted group. There’s a lot of functionality here and to do it well there would probably be a lot of software development involved.
But can we test some of the basic assumptions without doing any software development? Well of course we can! One idea is simply use some discussion forum software and invite young mothers to post offers and requests on the discussion board. Then we keep track of everything manually using people to do what we would ultimately envision software doing. Now this is obviously impractical and expensive in the long run, but in the short run, and with a relatively few people it’s the most practical way of finding out if people want this service and what kinds of features they would like to have.
Bottom line, Starting a business is a learning process. Learn lean, and learn quickly. Don’t take other people’s money until you have to. Having to impress other people gets in the way of learning. And from the very beginning cobble together a minimum viable product and get some users. And I would also add, if you have some core assumptions, test them!
I remember once I had a visit from a major corporation that was sponsoring our work. One of my students was a fantastic cook and she used to bake wonderful cakes. So she made a glorious poppy seed cake. My mouth still waters at the memory. But unbelievably, our visitor had a seed phobia. Now  I’ve never been able to find a lot of information about what seed phobia is, but this person obviously had it. She was looking at that cake like all the seeds were going to jump into her throat and choke her. Well, we got through the meeting but I can’t help feeling that it might have gone better if we had baked fudge brownies instead. Bottom line, don’t assume that someone else is going to like the tasty cake that you made. Don’t assume anything. Test.
PastedGraphic-1
Posted in: Events | Tags: , , , , , , , , , , ,

Leave a Reply

Follow Us!



Latest Posts