Ok, that’s a bit of an exaggeration – but capturing imaginative & innovative ideas, and delivering the processes / information / systems that make those ideas real, is a tough thing to do.
I’ve had success using whiteboards and wireframes – simple diagrams to illustrate the underlying structure of complex ideas (or problems), and mocked-up screens and reports to help visualize what success might look like. Someone once asked me how I might do 20% of the work on a project and get 80% of the benefit – I really liked that line, I use it myself. It’s always good to have a control lever so project budgets and resource commitments don’t spin up and out of control. And I understand enough about complex projects (where complexity = many interrelated steps to get from A to B; and complexity != new and different and requires-lots-of-change) to understand the tradeoffs between Agile and Waterfall.
So when I stumbled upon this new (to me) concept of Minimum Viable Product, I liked it a lot. How do you balance between “getting everything perfect the first time out” and “just get it done – yesterday”? Eric Ries describes it succinctly (3.5 minutes!) here …
//www.youtube.com/watch?v=1FoCbbbcYT8
What is the minimum amount of functionality required to start engaging with your target audience – to get folks to understand the vision? MVP-thinking focuses your effort on the minimum amount of work required to have that next value-adding conversation, where your target audience gets it – or lets you know that this work is “good enough” – or that you are going down a blind alley. And it’s a great way to sanity check all of those “features” you have in mind for this report / program / presentation / document – maybe they are only great to you? Or maybe people don’t quite understand what you are trying to say?
This short video is a perfect example of a Minimum Viable Product – a tool to introduce the idea of “Minimum Viable Product.” And as Ries says in the video, let’s “start the learning feedback loop” …
Care to share your comments?