Think of this minimum as a sales pitch to your super-fan. What needs to be demonstrated so that they want to use it now. The detail of this minimum depends on the nature of your relationship with the super fan. At one extreme this could be done using the same artefacts as the UX prototype, at the other, they may expect to be using it the next day (see minimum 7)!
You are really after feedback that confirms you are on the right tracks for a viable business. The earlier UX test tends focus on the practicalities of using the software, but you also need to find out whether a business will find it useful. You want to leave this demo with a commitment from the super fan to use a working version of this demo. I have several personal examples where the commitment never materialised. “If it just did this one extra thing” is an easy way for someone to postpone telling you the truth that in fact they don’t want to use your product, which in its own way is hiding the real statement of “I don’t value your solution”.
If you’re confident that you know what your building, for example the previous minimum received good feedback, a very useful staging post for the dev team is to build a working version in code. Whilst it gives the team a concrete goal it is still important to agree what “works” and what is mocked? There may be no need to “login”, or data isn’t actually saved to the DB – whatever works for the dev team. This has a useful side-effect that the non-coders of the business get a handle on what really works and what doesn’t. There is often a big list of “missing items” after reaching this goal that form the basis of a priority list that will enable the next minimum to produced.
A key early goal for a start-up should be the creation of a concrete example of your “idea”. How are you actually going to solve the problem you have identified and make it a reality? You then need to get this example in front of real people (not friends!) and measure their response. This could be as rudimental as some pencil drawings (although I do like using tools such as Pop or marvelapp)
Without this key stage, there is often a lot of hot air and handwaving when the founders try to explain “how it’s going to work”. I think this goal has two outcomes… 1) it forces you to focus on the practicalities of your solution 2) it’s the first chance for real feedback about whether your idea adds any value. Previous to this, any feedback you received on your idea will have been made on their assumptions and imagination!
Don’t expect to get the first prototype “right”, but you should hope to see people confirming that you are solving a problem for them. If not, you may want to reconsider your idea!
It is key that you use this artefact to iterate your idea – it is much cheaper, quicker and efficient to change now! This minimum is also probably the first chance for you to get real feedback as to whether your core loop is right/valuable.
http://alistair.cockburn.us/Walking+skeleton
If the core loop was focused on the business aspect of your product, the walking skeleton is focused on the tech! It’s the minimum architecture that links together the key building blocks of your system. It’s not meant to be your final architecture, its meant to show that at the most fundamental level you can make a coherent working system.
I often see examples where a tiny string of data is “passed around” the system. Its advantage is that you can then build out, tackling the riskiest or most worrying architectural features – for example adding authentication/authorisation. It’s a useful first target for the dev team as is it gives you the confidence that you have “something working” very early. The problem then becomes one of prioritisation!
http://getting2alpha.com/downloads/Getting2Alpha_Breakthrough_3-Game-Thinking-Blueprint.pdf (TL;DR - At least read page 8!)This is the repeating activity that your customers carry out that creates value. It is also an activity that they can “improve at” when using your product. I would highly recommend reading / watching the extensive list of material that Amy Jo Kim has created. My only additional comments are that this “step” is focused on the business (after all it is “core”) rather than the technology. It can also be relatively tricky to pin down in start-ups, and because of this it should be tested early! It might also take several iterations to get right - in fact it might not be until several of your next minimums have been created and tested before you settle on a final core loop.
