We talk a lot about lean innovation and iterative development, so I thought it would be worthwhile doing a post around how we work. Obviously each project is unique, but these are the broad guidelines that inform our development approach.
We have a number of stages a project will evolve through. For each stage we define a set of acceptance criteria that the project is required to satisfy before passing onto the next stage. These stages are:
- Proof of Concept (PoC)
- Minimum Viable Product (MVP)
- Beta iterations
Idea generation is probably self explanatory, but in many ways the most challenging piece of the process. We intentionally don’t want to put any restrictions on ideas, but sometimes it’s easier to imagine things within certain areas, rather than “anything” being possible. We were set up to experiment with ideas and new technologies, so often ideas will come about as a result of advances in telephony products – O2′s network upgrade and upcoming 4G rollout is an obvious example there. JetSetMe is a good example of where we came up with an idea as a result of a shared problem that we thought we already had the technology to solve.
Before we move in to the Proof of Concept phase, we interrogate an idea to define what we want to find out from the PoC. The questions asked include:
- What problem are we trying to solve?
- What are the business benefits or solving this problem?
- What is the PoC trying to prove?
- What (if any) time dependencies are there?
This analysis should define the criteria for the Proof of Concept, which typically takes no more than 72 hours to develop. The goal of the Proof of Concept is to validate (or disprove) our assumptions about the idea. By doing this, we should remove any unnecessary overheads when developing the Minimum Viable Product and Beta stages. The PoC phase often has the added benefit of flushing out potential issues before they become blockers, so we are ready for them when we move into a larger build.
As part of the Proof of Concept phase we make the decision about what (if anything) to build as a Minimum Viable Product. The criteria for the MVP should ensure that only core functionality specific to the goal of the project is developed. Anything that doesn’t contribute directly to the core goal/proving the assumptions around the goal is put aside for development in one of the Beta phases (at the earliest). So if we’ve established all of the above points in the PoC development, our key questions for the MVP are around how success is measured. We need to ensure we know exactly what criteria define whether the MVP goes forward into a Beta.
Once we get into the realms of a full Beta trial, individual projects can vary quite differently. Some projects will have restrictions on the number of users that can be supported, or have specific requirements users must meet. Drive to Improve for example required users to have a telematics device installed in their cars, which was only compatible with newer models.
Hopefully this helps to illustrate our approach to iterative development and gives you a better idea about how we work. We’re always on the lookout for new ideas, so if you’ve got a suggestion for a project we could work on with this approach, why not let us know in the comments?