Decoding what customers really WANT
At startups, we are constantly racing against deadlines to eternity. We are all here to create something new or better, that will make our customer’s life easier. The Product managers are always trying to make this happen as they manage their own battles with sales, support and customers. They collate all customer’s want and keep the product backlog updated. When time comes, items from backlog are prioritised and the product team is on it’s toes.
And this keeps happening often …
Our customers want what works for them, and it is fair from their point-of-view. Listening to our customers is very important; It gives us pulse of the product. When PMs get on a call with customers, they return back with lot of WANTs or feature requests. But, there is a fine line between what a customer “WANTs” and what their actual “NEED” is. Deciphering the NEED helps in framing the right questions to address the users’ problem.
An UX designer’s mind works very differently. As UX designers we are known to be problem solvers, but how good is a solution if it does not address the the right question? In most instances, our stakeholders come with a pre-defined solution in mind :). Being biased by a solution, is the biggest blocker to creativity.
PMs and UX designers should share their vision in building a useful product. As the designer you carry the baton to deliver the best user experience that the product has to offer. Not always do we all understand what our customers actual NEED is. Sometimes to decipher it, UX research can be a good tool.
Building a small feature might not require UX research, nonetheless building a product sure needs one. Highlighting the ROI of doing UX research, helps in getting the necessary buy-in you need. Make the process more inclusive, let your team know how they can benefit from this process; Include them from the beginning. Some of the outcome of good research might be saving development time, easy prioritisation of roadmap items, focused marketing strategies, increased transparency in product building, etc.
There are different type of UX research methods, but most of them fall under qualitative or quantitative research techniques. A combination of techniques always work better, as this will help you present your findings in an objective manner.
If your team is data driven, hunt for patterns that help you understand the user behaviour and NEEDs better. If data is not available, why not take that the opportunity to talk to the user who wanted the feature. Remember to spend time and prepare your script before you go for the user interview session. Have good conversation with the user. “LISTEN” to them, understand their drives, motivation, pain points and their suggestions as well. Sometimes not all that user say, makes sense. Nevertheless users always love to be heard, use that to your advantage to get more data and figure out the actual NEED. Remember, in user interviews never try to sell or reason, because that might stop the user from sharing honest feedbacks. Also try avoiding question like “what kind of interface they want?”, because answer to this is never really helpful. Quoting Henry Ford here, “If I had asked people what they wanted, they would have said faster horses”, but we all know what happened :).
Qualitative data sometimes helps you nail down the users problem far more accurately, than the assumptions made from quantitative data. It helps you frame the right question to answer the users problem.
As UX manager at Freshdesk, it took sometime to win the trust of business to show the value that UX research can offer. There have been instances when product went ahead and built features to compete in the market and I guess that happens a lot. Our own support had a lot of problems with the new dashboard. But as an UX evangelist you can take that as an opportunity to showcase how UX research can add value. Recently we conducted user research on how our admins use our current dashboard. PMs trusted us with the user interview process. We did not sell the new concept to the users here, rather had interactive sessions that had a combination of interview questions & some early mocks. Among these session, 5 were conducted remotely. Some of our users asked, if they could be part of more sessions like these.
Insights from this research, helped the product team scope and prioritise what to build in the new dashboard. One key aspect was, the amount of development time that could be saved by retaining already existing code and still address our customer’s actual NEEDs.
When you follow the UX process, It might take a week or more to deliver the solution but in the end, it is far more accurate and permanent. It avoids unnecessary back-and-forth. Share your findings with the whole team, include them in the discussion about the finding so that they trust the process. After all you don’t want your team to realise that they had put lot of effort to build a feature and it was all in vain, as the solution never addressed the customer’s actual problem.
I would end by saying, as UX folks you might have to acquire precise articulation and good negotiation skills to effectively communicate what the users actual NEED is.
Remember, YOU are the USERs voice.
