I once invested 35 person-years worth of effort on prototyping. From my perspective this was time and money well invested. By the end of that time we knew, really knew, what problems our customers were facing and how to solve them.
The Lean Startup movement tells us that purpose of a start up is to learn. Learn what problem our customers have and learn how to solve them. From my perspective the same applies inside an organisation when the team is tasked with some kind of organisational transformation.
I’m a big fan of prototypes. Paper prototypes, click through prototypes, high fidelity prototypes. Love ’em all. But my favourite are functional prototypes. Real functionality, knocked up relatively quickly and in use by real users.
And I’m not afraid to do prototyping at scale – for example using a team of 35 to build functional prototypes for a year. 35 person years might seem rather wasteful, or even rather big-design-up-front-ish, but nothing could be further from the truth. I wouldn’t commission a team to spend year writing a specification. Nor would I commission a design team to spend a year fiddling with paper prototypes. What I did was quite different.
We were building light weight, throw away, solutions. Our solutions, despite being rough around the edges, were in use every day. Real users using them for real jobs. We tweaked the solutions as we got feedback. We developed new solutions when a new problem surfaced. The business didn’t have to wait to get a solution – sometimes they only waited a few hours before they had new functionality to use. At other times they might wait a couple of days. In the grand scheme of things this was a very rapid turn around. The business was getting value every day – realising benefits.
It takes a certain mind set to do prototyping well, and I had a few folk that were specialists in rapid development (nods to Simon, Stu, Nik and Hannah), but the whole team were involved. Product owner, business representatives, back end devs, front end devs, ux&d people, “configurators”, testers – they were all involved in throwing these solutions together.
The rapidly built, throw away solutions were not the end of the story. After that year of experimentation we really understood our customers and the problem we were trying to solve. Only then did we build the real product. It took another year – although only six months to first launch – but we were confident that we were building the right solution.
Interesting post. What was the essential difference between the prototype that delivered benefits to users for a significant period, and the final product? I’m guessing it was lower operational risk and lower cost of operation for the final product. But is that all that separates a prototype from a the ‘real’ product?
Actually we rebuilt the core and left many/most of the small prototypes in place. The first year highlighted what to rebuild and what to leave alone. We rebuilt the core to address usability and performance and concerns. The initial prototypes were constrained in both areas.