I just love Kickstarter.com! For me it has become the best place to discover new stuff on the web. The creativity gathered there is simply staggering! Kickstarter succeeds in raising and focusing creativity by offering a mechanism to finance projects that is not based on risk-aversion and profit-focus, but on anyone’s dream to create something that they want to see exist in the world. This is a huge inspiration and it opens for fantastic possibilities when thinking about it in the corporate world. I will try to write a series of blog posts about Kickstarter and the lessons we can learn from it when working in software development in the enterprise. Today, I want to focus on one aspect: how Kickstarter constraints projects to think Iterative and Incremental Development (IID).
Constraints that create MVPs
The feature I find the most interesting with Kickstarter is how it helps projects to succeed by forcing them to think in term of Minimum Viable Product (MVP). Kickstarter does that by putting simple but powerful constraints on a project:
Kickstarter operates on an all-or-nothing funding model where projects must be fully funded or no money changes hands. Projects must set a funding goal and a length of time to reach it. Because funding is all-or-nothing, you can always raise more than your goal but never less.
This means that in order to be funded, a project must find the absolutely minimum amount of money that is required to create something valuable. That forces out all the gold-plating features, the nice-to-haves, the just-in-cases, the wouldn’t-it-be-greats, the alternative-usage, etc. What is left is a minimum viable product, where removing anything more would not make the product viable, i.e. the product would most probably fail. An interesting side effect is that the constraints force the people behind the project to really think about what they really want to do and, more importantly, why. As the MVP is so focused (some would say small) and as it becomes the core of the product, it really must be aligned with the expectations from the potential backers. A well formed MVP will create clarity for the potential backers: it will increase the chances of the backer “getting-it” by making the core of the project shine. This means that some effort – and sometime this can be substantial – must be put into formulating the MVP for success, i.e. thinking about what you want but also when are you done (acceptance/validation criteria). In my experience, this is quite uncommon in most of the software development projects I have been involved in.
Feedback
Under a Kickstarter campaign there are basically two ways to get feedback from the backers: the amount of money currently pledged to the project, and the forum. The amount of money currently pledge shows how well you are doing towards funding your MVP. The pledge distribution over time is not constant (it is more U shaped), but if you haven’t reached 50% by the middle of your campaign you know that you must act. The forum is simply questions or comments from early or would-be backers. Most of the projects use this feedback to re-evaluate their assumptions and correct or re-align their MVP and stretch-goals (more on that soon) under the campaign. Though, it is hard to put a campaign back on track by changing the MVP, so – again – formulating the right MVP is key to success.
Success Assured!
The interesting thing is that this MVP is probably not what the persons behind the project really want: their visions for the project is certainly bigger than the MVP. But, because the MVP is small/”lean”, the project can (should) cheaply and quickly get to a success-assured state when the MVP gets funded. That is to say that the campaign has succeeded as backers did believe in your concept, your MVP and your capability to deliver. Now it can only get better: every $ above that success-assured state can be spent on stretch-goals.
Stretch-Goals: Where the value is
Stretch-goals are really were the value-adding is. Each stretch-goal brings the project closer to its initiator’s vision. But here also, the constraints put-up by Kickstarter forces the initiator to plan the stretch-goals carefully. You are forced to prioritize all your extra great ideas and extra features and deliver them in the “right” order (“right” for your target backers) and in increments small enough to be funded with the extra money you can gather. Well-planned stretch-goals can give extra motivation to existing backers to give even more money to make sure that their “must-have” stretch-goal is funded.
It Works!
And it works: these simple constraints helped raise 470 M$ to successfully fund 39.046 projects (stats from Kickstarter as of 8 of April 2013)!
I don’t know about you, but in my experience this way-of-working doesn’t really map to the standard way to create software development project. And those are not know to succeed very often (50% success in 2011). So, the question is what can we learn from Kickstarter to succeed with our projects?
If we would cook it down to one key aspect it would be the create the right constraints.
Creating Kickstarter “at Home”
Creating an environment that recreates the constraints given by Kickstarter would require some substantial changes to the project models prevalent in most of the organizations and, depending where you work, may be difficult to achieve in one’s lifetime. There is a lot to discuss about here, and I plan to blog more about that, but for the moment I would like to share one trick. There is one thing that we can do now in virtually any project: to try to build (and follow) a release plan that mimics Kickstarter’s projects.
A “Kickstarter release plan” looks basically like this:
- (some fuzzy-start (anticipation, ideation) – out of scope for Kickstarter)
- a preparation phase (design, scoping) – what you do when you setup a Kickstarter project
- a minimal viable product (MVP) – your primary goal
- a number of stretch goals (if time and $ allow for it) – possible if you get funded (secondary goals)
Ok, great, but how do we do that?
That’s where User Story Mapping comes in.
User Story Mapping
There is one powerful tool that you can use to create or transform/re-write your release plan to fit that model: User Story Mapping.
User Story Mapping is about designing the solution to the problem as a team. The more cross-functional, the better. While designing the solution, the tool helps you visualize the different features/functions/aspects, their relative complexity/richness/risk, their value relative to your goals and any other unresolved issues/questions/etc. Using the tool you can easily identify a potential MVP (and how many increments would be needed to build it) and stretch goals. In other words, User Story Mapping helps your create a “Kickstarter release plan” even if you do not have the right constraints.
So, go check User Story Mapping. I have written some on this blog (a webinar in Swedish is available here), and plan to write more about how I use User Story Mapping for IID in the months to come (also an English version of the webinar is in the pipe). I will also explore Kickstarter further and try to map it to software/system development.
In the mean time, go try IID for yourself: check Kickstarter.
