At Pollenizer, we drink frequently from the fountain of Lean.
One of the principles of Lean development, particularly as it applies to software, is that of Minimum Viable Product – the absolute bare minimum you can get away with in order to determine if your idea will be successful or not. The idea is that an MVP should take as little investment as possible to build, because the sooner it is up the sooner you can validate if your brilliant world changing idea actually makes sense as a business.
Also, as you discover that perhaps your idea didn’t stand up in the real world as well as you’d like, or perhaps wasn’t adopted in the way you expected it would be, you will be less recitent to throw away misconcieved early ideas if they didn’t take too much energy to build them in the first place.
This model works well for many web-based businesses – your MVP can be as simple as a building a brochureware website (perhaps with a limited degree of interactivity), add in some tracking, throw some limited marketing at it and seeing if it will fly.
But what about those truly innovative ideas, the ones that require a substantial investment in research and development before even you can be convinced if you have a product that has traction? Something that might take millions of dollars in research and development, specialised teams, and months or even years. How do you execute on a project like that while remaining true to the principles of Lean?
One such project where we encountered was Friendorse.com – a great little service that helps you find information from local experts in your area. Users visit the site, connect with Facebook, ask a question, and a few minutes later get e-mailed an answer from an independent local expert.
It sounds simple, but as we fleshed the idea out it became clear that the technology required to run a business like Friendorse at scale is actually pretty complicated. Questions must be tokenised, term vectors extracted, categories clustered, taxonomies developed, users social and spatial distances must be calculated and indexed, and all this data would need to be fed into a fairly sophisticated machine learning algorithm.
Such technology would require a significant investment – many months of development by skilled engineers – as well as a significant amount of data in order to build and verify a working product. That’s if it could be done at all. All in all – a pretty big barrier just to test if the idea even worked. Furthermore it was recognised that the Friendorse matching algorithm, like the Google search algorithm, would never be truly ‘finished’, but would have to continue to evolve as the product matured.
Our solution to this was simple – don’t build an algorithm. Inspired by a great discussion from the founders of Aardvark.com, we realised that to test if the product worked in the market – all we really needed to do was create a site in which people could ask and answer questions. But behind the scenes the crucial step of ‘routing’ a user’s question to a local expert would actually be handled by a person (working under a strict confidentiality clause) rather than a machine. The Aardvark guys call this the ‘Wizard of Oz’ approach, and we think it’s a pretty apt term for the process. Behind the shiny stage and the fancy lights, it’s actually a person pulling the strings.
Building this project ‘Wizard’ style allowed us to deliver a product much faster, cheaper and with greater certainty than we otherwise could. It also allowed us to experiment and pivot more quickly – dropping those ideas which didn’t work in the wild and iterating towards those that did.
From a technical perspective, it had another significant benefit – having a live project in-production, taking queries from real users that were being manually routed and managed by human operators, gave us a significant cache of training data with which to embark on the next stage of the project.
We know now for example that people don’t typically ask questions like “What’s the best pest controller in Melbourne?”, they ask “How do I get rid of these damn cockroaches?”. We know that coffee suppliers in Brisbane don’t know all that much about the cafe scene in Sydney. And so it goes.
Having data like this before seriously sitting down and figuring out the internals of the algorithm is immensely valuable and a huge competitive advantage for the Friendorse team.
By following a Lean approach, Friendorse has charged into it’s first battle (market acceptance) as a lean and agile creature. Not only did it survive, but it will face it’s next battle (fund-raising and scale) better equipped and far more informed than it otherwise would have.
Trackbacks/Pingbacks