From Idea To Business In Three Days Using Minimum Viable Product

I have been reading a lot of Steve Blank articles at the moment and I was really looking for an opportunity to experiment with his idea of Minimum Viable Product, so we invented an internal project to work on over a long weekend. What could we achieve in just three days and how would the process work? It was a pretty crazy experience and this is a quick overview of what we did and how we did it.

You can see the final product here: http://hosting.djangofoo.com/ not bad for three days work!

The idea

We are a Django shop and find it hard to get simple hosting for clients. What we needed was a simple point and click solution for people with no technical knowledge at all, so that is what we built.

Planning

The first step was the planning phase which took an hour and we did this one week before we started the project. Each person in the team was assigned an area of responsibility and the planning was around the high level design, features, investigating the technology and the existing competition. Then for the next few days we all did some thinking about our areas and let the ideas distil in our sub conscious.

Day 1: High level structure

The first day started at a crazy pace as the enthusiasm was at its highest. We had a quick briefing session in the morning and then we all set off to our assigned tasks. We had documented the high level features in advance so we all knew which tasks were our responsibility.

We were a three person team, split into three areas:

• Liza (an incredible designer) worked on the brand and the global styles of the interface
• Davo (super coder) worked on solving the huge technical problems of how to set up the server, permissions, limited file space, writing bash scripts to create accounts
• Me, I designed the data model, bootstrapped the project, wrote the models and set about coding the application

We communicate mostly by IM even though we were all in the same office, this helped us keep focused and keep our concentration.

Defining the features, proposition, wireframe and setting up the server, bootstrapping the code base, code snippets

By the end of day one we had completed:

• A rough interface and brand
• Wireframed all the pages
• A feature list assigned with priorities
• High level marketing messages
• The skeleton code structure
• The data model
• Server set up and configuration
• The ability for users to change Django version
• A basic auth systems for users to sign up and login

Day 2: The detail

The day started with the same amount of energy and we spent the first part of the day validating the logic we had come up with on day one.

We also made some changes to the data model based on the design decisions we have made whilst coding. It felt like more of a details day, there were lots of questions that came up and lots of small issues needed to be addressed.

A large part of the day was spent working on the visual style and making sure that the right messages and visual cues were delivered to the user.

By the end of the day we had completed:

• A more polished design, visual identity and brand
• All the text pages content
• All the user login pages, recover passwords etc
• The content and elements for the logged in user pages
• The ability for users to sign up and create their hosting environment, logins, FTP passwords etc
• Bash scripts to create new users and folders
• The base HTML and CSS styles
• Mod WSGI reload when changes are made to the source code

Day 3: The launch

In true MVP style we have not yet implemented the payment system, we merely get an email if someone attempts to pay.

Throughout the project we decided that we wanted to be the “easiest Django hosting in the world” so this totally guided our decision making. For every feature we asked ourselves if that will help to make the app the easiest Django hosting in the world. I think the project was defined by what we did not include rather than what we included.

By the end of the day we had completed:

• All the HTML and CSS for all the pages
• Integration into PayPal
• Admin functions
• Manage.py tool
• View live logs
• Security patches

Lessons learned

I think the main lessons learned were actually nothing new but they re-affirmed a few things:

• Be ruthless with your features if it is not essential then move it to the wishlist
• If a feature is taking more than about 2 hours then find another way or abandon that feature
• A framework is a must, you do not have time to reinvent the wheel
• Small team (ideally two developers and one designer)
• It is very important for someone to co-ordinate the project
• Don’t worry about not meeting all your users needs you can always add things later
• Think of clever ways to get feedback and save time. When we looked at our tasks and times we thought payment integration would take quite a while so we skipped it and simply have an email alert if someone tries to upgrade

One of the biggest lessons I learned was to build your decision making around your core proposition, for us it was “The easiest Django hosting in the world’s”, anything that did not fit into this philosophy was removed, even at the cost of alienating more advanced users. Be bold and focus on your core customers don’t worry about being the solution for everyone. We knew from early on that people who wanted a high level of customisation and were advanced users would not want to use our service, that is ok we are not building a service for them.