by • December 29, 2012 • Pitching & sellingComments (3)356

Deciding which features to build for a big demo

You’ve got a big pitch/demo coming up and an even bigger list of stuff you’d love to fix about the product before then.

One way to decide which stuff to prioritise is to mentally walk through the demo and just fix all the bits you find yourself apologising for. “Oh, yeah, sorry about that… just click over here. No, there. Yeah. We’ll have that fixed in the real version.”

Apologies ruin the tempo of a demo. It’s better to have a zero-apology demo (or trial) than to have some extra features. A polished core gives you a good foundation from which to tell the story of all the exciting new stuff which is still coming up. Shaky features in this context undermine your credibility.

Related Posts

3 Responses to Deciding which features to build for a big demo

  1. I couldn’t agree with you more Rob. Getting something high quality out there is better than more content with bucket loads of mistakes. I am keeping that in mind as I am working in an important piece of content for my site at the moment. Thank you for sharing this valuable information.

  2. Mark A Hart says:

    For a high profile demo, the items that should be prioritized are the items that provide the most value to the customes (the people that are in the audience).

    One way to prioritize a list is to sit in a conference room that has a white board and ask for opinions. List the opinions on sticky notes. Spend hours re-arranging the sticky notes. The problem is that the results will be based on unvalidated opinions. It is likely that the loudest voice will have too much influence. The HiPPO (the highest paid person’s opinion) will have extra influence.

    A better way to prioritize a list is to interview the potential customers and review the notes from the interviews. To prioritize a list, the team has to ‘get out of the building’ and learn and confirm what provides the most value.

    Not all of the functionality has to be in the demo. Not all the ‘important’ behavior has to be faked. The more important factors are understanding what the customers value and acknowledging that your team is working to provide this value.

    Under such a framework, the team will not have to apologize for a feature that is not implemented. The customer will be more impressed with a dialog that your team recognizes that a feature is critical to providing value for them. The customer will be more impressed that your team is continuing the dialog than a slick demo that doesn’t match their value requirements.

    For more information on ‘get out of the building’ see @sgBlank. For more information on interviewing customers see @KristinZhivago

  3. Tom Psillas says:

    Use PowerPoint slides. Keep it simple.
    The worst case scenario is, you have Kevin O’Leary and the others on Shark Tank and your website that you plan to demo goes down.
    Take snapshots of your website pages that work and paste them into PowerPoint and walk out with the cash.
    I call that my cash and carry method.