19 November 2011

Product pitching vs software requirements

I was recently in a competition which involved doing a 60 second elevator pitch to a panel of judges, and learnt more than I expected from the experience.

My first main takeaway was the amount of effort required to really crystallise into just a few words the problems which I was proposing to solve. Expressing the problem is the absolute kicker in a product pitch, but it also made me reflect on my BA work. The standard requirements template I work with every day has a 'business need' section under the title. It can be easy to get lazy with that and just basically restate the requirement title in more words, rather than go that step further to actually capture the essence of the problem.

Likewise within the standard user story format, what follows the '...so that' component should really hit home to help everyone understand the value of what we are setting out to achieve. A nice metaphor that was passed on during one of the competition pitching workshops was "put your listener/reader 'out in the hot desert' with your problem description, so by the time you propose your solution they are so thirsty they're willing to pay $1000 for the glass of water you are offering!".

The second takeaway stemmed from standing in front of actual investors and feeling the potency of the situation - I'm asking these people for cold hard cash and they need to be convinced of the financial return they'll receive on the basis of this idea/solution!

This experience has given me a new perspective. Sure, my project stakeholders aren't usually dipping into their personal finances, nor are the risks as high as funding a startup idea. But still, there are stakeholder's professional reputations and real money on the line. As a BA I need to play my part in making sure that the problem actually exists, it has been properly analysed and captured, and that measurable value is delivered at the end of the day.


  1. Sounds like it was a rewarding exercise. At the big picture level you're telling us to have our elevator pitch ready and make it compelling.

    At the detail level you're reminding us to maintain focus and manage waste. At that level I always felt justifying every single requirement line item was worth while.

    Thanks for sharing.

  2. Anonymous2:25 am

    An approach used in the US Defense business is the state what "capabilities" are needed.

    "We need the capability to:
    (1) Process transactions for $0.07 each rather than the $0.11 each we do now.
    (2) We need the capability to remove 1½ hours from the retail ordering process once the merger is complete.
    (3) We need the capability to change the Wide Field Camera and the internal nickel hydride batteries, while doing no harm to the telescope.

    These capabilities describe the beneficial outcomes the buyer. They are not the technical requirements, but those requirement can be derived from these.

    Capabilities Based Planning is the basis of complex system development and clearly defines "why" I need the system. It answers the question, "if I had this thing on Monday, it was free and it worked, what would I do with it?"

    The answer to this is many times missing when you start with requirements.