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.