In my last blog post we talked about the different types of software requirements. But how do you generate them, in the first place? What about practical strategies? How do you find out if you are hallucinating or if you really stumbled upon something the masses might want? And how do you find out about those hidden requirements?
Let’s roll!
Humble Inquiry
It might almost sound too simple. One of the best strategies to find out what users want is to actually ask them and then listen carefully. If you have existing customers and run an online company you will surely already get feedback via email, forums or other social media outlets. So all that is left to do is listening.
There is one very interesting point to consider why people fail to ask a (future) customer questions: Because they are scared of not delivering a perfect solution the very first time around. Scared that it puts them in a bad spotlight, because they are supposed to be the all-knowing specialist – but suddenly they have to ask for feedback/information/advice!
Do not make that mistake. Your users appreciate if you ask them for their feedback and if you make their lives better. It is not about you magically knowing everything all the time.
So which type of requirement is the humble inquiry best suited for: Yes, the natural one.
Sitting with the user
What about hidden requirements though? What if the user does not really know what he wants?
Simple: You need a technical outsider to sit with the user for a certain amount of time, observe him, understand the existing workflows and then try to make improvements to that workflow. This needs a certain amount of trust from the person being observed and the willingness to have a “follower” for larger parts of the day and explain things to them.
Additionally you need a technical person who is willing to not only talk “tech”, but also domain and user experience and who is sharp enough to see those improvements in existing workflows and translate them to software requirements.
You will be surprised about how much you can learn observing someone and how many improvements could be made to everyday business workflows.
The Lean Start-Up
But what if there are no existing users, no existing workflows and you are building something from scratch?
Actually you can and should always learn something about your users, because they probably post about their software experiences and pains in forums or on social media. But if you are really talking about brand-new innovation, then the only reasonable way to find out if users want your software is to build it (or rather the smallest viable version of it), put a price on it and then sell it.
Sales are going to be your user feedback. And for this to work out, you need to build small bits and pieces of your software, have short iteration cycles, go live often and NOT try to build the magic, can-do-everything for everyone type of software.
Software developers often are in feature-berserk mode, because that is what they are used to do: Build stuff. The more, the better. But instead of saying yes to every feature and build as many as possible, you should say NO to every feature by default and only commit to those features that have an immediate impact on your users. (This is a huge topic however and I cannot do it justice in one paragraph. If you have any thoughts or questions, shoot me an email.)
| Reference: | Software Requirements: How to find out what users want | Part 2 from our JCG partner Marco Behler at the Marco Behler blog. |
