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.
If you have had the (mis)fortune of working with me on any product development projects you’ll know that I’m quite a fan of Amy Jo Kim (http://amyjokim.com/) and her approach. Her “core loop” can be considered the minimum structure that the user needs to feel satisfied they have completed their task. The focus on identifying core loops is more than just the starting point for your product, it should be the key insight that you return to throughout the lifecycle of a product’s development. This article builds on this and tries to look at how the whole team walks through the subsequent building blocks that ends with a fantastic product.
The end goal of a development project is obviously to release a product, but there are key stages on this long route that should be considered as project goals in themselves. To take a leaf out of the Lean StartUp book, there should be a series of tests with the aim of each one to capture some specific learning goal.
I like the idea of developing a “minimum” item to test. It implies that it is the smallest item needed and should therefore be easier to make than anything bigger thereby reducing wasted effort. This is only true if you know the purpose of what you are making – and then test that it satisfies this purpose! Too often I hear the term Minimum Viable Product being used when it’s inappropriate. It gets used as a catch all statement to replace the work necessary to define the sub-project or the test’s goal. Different people will have different definitions of an MVP, and worse, they will internally change their definition over time. As is often the case, there is a lack of communication. The definition should be made public and be clearly defined for the whole team to agree on. With that in mind I will be writing an article a week (ish) with each one being an example “minimum”. I hope this list of sub-projects or tests will act as examples and replace the catch all MVP. Each has a purpose; each provides a specific learning objective or function. As is the nature of a list this is going to look like a waterfall project plan – please do not take is as such! The definitions on the list are to provide a series of defined targets that can be used as tests. Use them as guidelines to make your own – just make sure it is clearly written down and agreed by the team.
