Demo Driven Development

• Your company is living paycheck to paycheck.
• No one has actually paid for your product.
• Product direction changes each time sales visits a lead.

Given the above situation, it is time to plan a software release. The PMBOK doesn’t cover this kind of project. There is no chapter for near Armageddon events. Planning a software release for a company which is just starting out or in a death spiral is not covered in classical project management literature.

The development plan will be:
StartupProcess
The name of the game is to make it looks like you have what the customers needs as quickly as possible. You do not know your market, you do not know your product, you know nothing. Through many failures, the company will discover the market. The hope is that there is enough time and cash to realize this goal.

Someone on the sales team manged to get on the calendar of someone with budget and a pain large enough that they will spend 1 hour to see if you can help them. The sales team has provided you with the release date, and a feature set.

As usual, break down the tasks, figure out what is possible, drop everything that is not (ensure that you record what was not done, and that it came in from sales, not the customer directly). Then get started. While developing it is important to remember that if you are successful, this demo will most likely become the foundations of your code base. Also, this software on demo day will not be touched by anyone outside of your company (in its current form), it just need to be good enough that they believe you can deploy it when they purchase it. I am not saying to fake the demo, I’m saying that you need to focus on the core pain points and that you can illustrate the solution to the potential customer. Many times, before the demo, the requirements will shift when the sales guys enlightens you more on the problem that the potential customer has. Those changes need to be incorporated. You are trying to demonstrate that your product can satisfy their needs. Do the changes as best as you can. Refusing to demonstrate a product which can help a potential customer is a waste of both your time and theirs. No one loves the churn, but you need to suck it up and do it.

During the demo, ensure that you are able to listen to the feedback while it is happening. This is the closest thing to users you have. They will provide you with the next set of work you need to do on your program. Record all their feedback (product ideas and bugs). Discuss internally all their ideas and make a plan for addressing the issues. Start working on them as soon as possible because you have up until the sales team schedules the next demo.

Once the next demo is scheduled, all of the focus shifts towards it. When demo goes well, but the potential customer is not interested (this is the most likely outcome), record all the feedback. Triage all of the features (including the previous demos) and begin work immediately based on what appears to be the most important in your potential customers eyes which is blocking the sale. Hopefully after several demos you will begin to see pattern and specific items and themes which re-occur. The future of the company depends on if you can solve the customers problem before the company closes shop.