Posts Tagged ‘mvp’

From Idea To Business In Three Days Using Minimum Viable Product

Wednesday, May 19th, 2010

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

Day 1 Design. The first iteration of the design has all the elements and a global design but the messaging hierarchy does not flow, it appears too jumbled.

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, spilt 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 communicated 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

Day 2: A more polished design with better message hierarchy. There is a real visual style that can be carried across the rest of the site.

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

Caption here

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.

Explosive Development – From Idea To Protoype In One Week

Wednesday, March 24th, 2010

A couple of years ago I heard Obie Fernandez (from Hash Rocket) talking about rapid prototype development and that sparked a huge interest in me. Ever since I have been investigating and involved in rapid software prototyping and have learned a lot of lessons through experience, trial and error.

In the last year I have been working with various companies and projects to deliver working prototypes of software in one week! It can be done and in fact I argue should be done. I love the work that Eric Ries is doing with lean start ups. I share his opinion that you need to increase the learning of the organisation and test all your assumptions quickly so you do not waste resources.

Preparation, preparation, preparation

Everyone needs to be prepared in advance of work starting. Ideally a kick off meeting is arranged about a week before the start date and the whole team needs to be present. This should be a short meeting and will cover:

  • team introductions
  • the problem you are trying to solve
  • the scope of work (feature set)
  • the process for the week
  • the roles of the team members

What I have found is that after this meeting the rest of the week before development starts your subconscious mind will start to generate ideas, start solving problems and make sure you are ready when development starts.

Everything needs to be ready when development starts, the room you are using, meals, communications, servers etc. These items can eat into your valuable time.

Focus and prioritise

The only way to get to a finished product in one week is to make sure that you only build the bare essentials. This means heavy prioritisation and focus on what is important.

First focus on the problem you are trying to solve and then make sure that you product solves that problem elegantly. Every feature should solve the customer’s pain or it should be removed from the feature list.

This is the idea of the minimum viable product (MVP), the smallest feature set you can get away with to solve problem. You are not looking to the world here and there will be plenty of time in the future to add features and polish the tool once you know you are on the right track.

This is where the project manager needs to really steer the ship and make sure that progress keeps to the agreed tasks and features.

30 minute meetings

If you must have meetings they should be kept to 30 minutes maximum, this will keep everyone focused and prevent people going off topic. It is important that someone chairs the meeting to make sure that the schedule is kept to and that the focus on meetings is making decisions and moving forward.

Most of the time we have the rule that once a decision has been made in a meeting then it is final, you do not have time to constantly debate the options and waste precious brain power pondering if you have made the right decision.

Mixed team of experts

In order for the this process to work you have to only have experts in the team, people who know the tools and processes that you are using like the back of their hand. It is also helpful if the team have worked together before so they know each others working practices and styles of working.

It is also essential to have a mixed team ideally consisting of:

  • 1-2 developers (who build the code)
  • 1-2 designers/ front end developer (to design the screens and build front end)
  • 1 project manager (manage communication, brainstorms and tasks)
  • 1 client (at least one member of the client team)
  • 1 customer (at least one customer)

Feedback loop

The whole objective is the make sure that all that the product you build solve the needs of the user. This can only be done if you have end customers in the room working with you to give you feedback.

It makes no sense to write hundreds of lines of code only to find that the customer is actually indifferent about the feature. This feedback loop can be short circuited by using wireframes, html mock ups and design screens to make sure the interface meets the customers needs before you spend time building it in code.

No distractions

This seems like an obvious one but in practice is hard for people to do. Ideally no emails, phone calls or other communications outside the project. You need the team to be totally tuned in to the project so that all their conscious and sub conscious thoughts are tuned into making progress and moving forward.

Automation tools and frameworks

You do not have the time or the energy to re-invent the wheel, so you need to automate and remove common or repetitive tasks. This is where a good framework like Django (or Rails) can make a big difference.

We also have a library of code we can call on, CSS snippets, user authentication, common JavaScript libraries that also reduce repetition and give us a huge head start.

Where possible use web services or common webservices such as Amazon S3 or the Yahoo developer tools to offload some of the development.

Don’t work all night

Initially we thought that it would be a lot better to work every hour of the day as time was so limited, but we soon found that actually that was not the case. Having time off in the evenings and getting a good nights rest meant that you could actually do more with less time. Now that does not mean that sometimes you will not have to work long hours especially if things are not going to plan but it should not be the norm.

Conclusion

Building a prototype in a week can be done but it requires a lot of discipline, focus and an amazing team to make it happen.

The only way to make sure your company succeeds is to make sure that you are making products that solve your customer’s need. The faster you can get feedback from the customer the better, don’t spend months writing code only to find it actually is not fit for purpose. Get something basic product to your customer, learn from their feedback, refine your product and then continue this cycle.

As I said at the beginning you need to increase the speed of your company’s learning, the faster you can learn and make adjustments the more relevant your product will be to your customers.