One thing I've learned over the years is that you can't take it as gospel when a customer says "I want X". When following a customer request to the letter, most times you'll end up regretting the decision.
For us, the better way to handle when the customer asks for X, is to sit down and create a persona and ask ourselves why they are asking for it, and who else would want it.
I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usability by avoiding confusion over additional features and functions.
Then again, in a startup environment this is a tricky balancing act. You can't forsake sales for a drawn out product management/development process, but you also can't just add every customer feature request either.
Totally agree - I always try to focus on requirements, not features. It is really hard for some people to speak in requirements, and the only way you can get them out often is with frank discussions. Second guessing can work if you know your customer really well, but asking people to talk with you works amazingly IF you can help translate for them.
A while back I was rebuilding a larger kids site and in a meeting I was told the site needed a 'big red button on the homepage, that makes a funny noise when you press it' - everyone in the room agreed it was a great idea, and the editorial team tried to push it onto my requirements list. I explained that it was a feature not a requirement (to which they stated that 'well I require it to be on the homepage, so it's a requirement') but I explained what I meant and after a bit of talking we came up with a whole requirement set that we were then able to set off and build to.
The original 'feature' became:
As a user I want to be excited
As a user I want to be surprised
As a user I want to feel I need to see what happens next
As a user I want to never know what might happen
As a user I want to have some thing 'physical' to play with
As a user I want to feel like I've done something to affect the site
(and many many more)
We ended up with a fun widget on the home screen, and could well have even made a big red button, if that was what would have best met the requirements (it didn't btw). It ended up user testing really well, kids now love it and it enhances 'accidental' journeys across the site (triggering it now fires you off to a randomly selected page from a list of the 20 coolest pages).
But any time you can successfully translate 'features' into 'requirements' you are on to a winner.
(Widget is here [lower right corner of the screen], and kids still love it!: http://www.bbc.co.uk/cbbc/ )
Thanks, it was one of many internal battles, and I think we won those that mattered. Working somewhere like the BBC is great, but as you are part of such a huge machine you have to know when to fold, or you will never get anything done!
>I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usability by avoiding confusion over additional features and functions.
Exactly. The starting question that you ask the customer shouldn't be "What do you want?". That is far too open ended, and the end result is that you'll get a solution to a perceived problem instead of an actual, workable solution. It's not the client's job to solve their problems. It's your job, otherwise they wouldn't be contracting you to do it.
The proper question is, basically, "What problems do you want us to solve right now?". You want to start with the problems that the client actually has, instead of the problems that they are anticipating. This helps keep the client focused on their current issues, rather than problems that either don't exist, or may exist in the future(but don't right now).
For us, the better way to handle when the customer asks for X, is to sit down and create a persona and ask ourselves why they are asking for it, and who else would want it.
I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usability by avoiding confusion over additional features and functions.
Then again, in a startup environment this is a tricky balancing act. You can't forsake sales for a drawn out product management/development process, but you also can't just add every customer feature request either.