Demo Driven Development
Filed under: Crazy, End User, Product Management, Project Management, Small Company
• 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:
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.
Best … Demo … Ever …
Filed under: Big Company, Crazy, Development, End User, Small Company
There are certain aspects of a good demo, but it all comes down to practice, practice, practice.
Lets set the stage. After starting coding four month ago, we were running out of cash. There was a potential VC deal on the horizon, but it wasn’t going to happen until we had a sale. This was `the demo` to our only real customer in the pipeline. We had all the right people in the room for the demo. The customer had made it clear in our last demo what the sales objections were going to be, and that they had to be resolved for this next demo. It was a hail mary pass with two seconds left on the clock.
Lets dissect the days before the demo.
Day: t – 14
We gave a demo to our early adopter evangelist on the inside. He provided valuable feedback and pointed out the areas which will be the objection points. We scheduled the demo two weeks from that day. Several show stopper bugs, but we have two weeks to fix them.
Day: t – 13 to t – 3
Code like you’ve never coded before. Keep cranking it out. Don’t stop. Fix all those bugs.
Day: t – 2
We created the demo script. Although the meeting was to be 1 hour in length, the demo part was scheduled only to be 10 minutes long. The script covered all the users important pain points along with the requested objection points. All of the show stopper bugs were resolved except for one. We still have one day till code freeze to fix that nasty bug.
Day: t -1
24h before the demo was to begin, we froze the code. From now on, it was nothing but practice. That nasty bug is still there.
Now, about that bug. If an item was dragged in our interface, it would crash the entire application. Think BSOD. The only way to prevent the crash was to drag it to an exact pixel co-ordinates. Think of having a 1280×1024 resolution screen and having to drag to an unmarked x,y co-ordinate. If you missed, the application could crash and the company could fail. No pressure.
Day: t – 0
After our demo’er practiced nearly for a day, we were ready. He typically was able to hit the pixel about 50% of the time. Hedging our bets, I made sure we had two applications running at the same time, with the second setup to be at the exact point right after the crash should occur in the script. If a crash should occur, hopefully we can <ALT-Tab> before anyone notices. The demo went perfectly. He hit the pixel right on, no crash!
Best demo ever!
