Search This Blog


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 ' 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.