Is That What They Really Want?
Few posts back, we learned how to make sure you fully understand the ‘why’ and the pain it represents when users, customers or other stakeholders are asking you to work on a feature for them (you can read the post here).
So you did that and now you fully understand why they were asking you to build something. Now what?
Well, some features, as noted in the past – are quite trivial to design (not necessarily to implement though). An ‘export to CSV’ option in a dashboard, an input validation filter in a web form, adding an additional logical rule to an existing workflow, and so forth – those are all examples of features which are trivial to spec out without much challenge in explaining why they are needed or what needs to be done.
I guess you know what you need to do in such cases so I won’t delve on those.
From time to time, though, and depending on your seniority and experience – once you understand what the problem is – figuring out how to tackle it, and what exactly needs to be built – may not be so trivial. Since the use cases and examples here can vary greatly depending on the industry you are in and specific departments (security, IoT, automotive, digital media, etc…) – I will provide a couple of real life examples and focus on the general guidelines you need to keep in mind when trying to figure out ‘what’ you need to build.
With that in mind – let’s proceed to the first real life story:
When I was in Newfusion – we dealt with news feeds (news stories that were delivered and consumed within a feed, on mobile apps). We gathered stories from all over the web and arranged them in prioritized feeds according to the topic/passion they were addressing. The goal was to help users cope with information overload by providing them with digestible feeds.
One of the big challenges we had to tackle back then was how the algorithm should order the ‘latest feed’ (there were several time perspectives users could consume the data, the ‘latest perspective’ aimed to show stories which were more recent). Originally, we decided to order the stories in this feed mainly by the prominence of the stories (we had such a capability) and not necessarily by the time of their publication. Sadly though, this decision resulted in many complaints from our users who stated that the order of the stories doesn’t make sense to them.
There were several approaches we could take in order to address this pain:
The trivial approach was to order the stories in this feed by the time of their publication. In fact – many users asked for this. Yet, we decided eventually to go with a more sophisticated approach of ordering the stories according to a unique formula that combined both the time of publication and the prominence of the stories in the feed.
Why did we decide to go with an approach that no user explicitly asked for?
That’s a good question and the answer is that we were positive that even though our users suggested a concrete and simple solution, the resulting feed would not provide them with the experience they wanted. You see – we aggregated news stories from dozens of news sites, and hence – a feed ordered solely by publication time would cause more information overload rather than solving it.
Just to make sure we were not executing based on false assumptions – we produced in the lab a feed which was ordered by the publication time and indeed it was totally indigestible as expected.
What is the takeaway then?
Your users may try to help you by offering various solutions to their pain. Put those solutions aside for the time being and focus on how you believe this pain needs to be solved. Only after you have a concrete solution in mind, go and review the other suggested solutions and compare them to your own.
Sometimes, though, you need a wider perspective to come with the right solution.
In one of my previous roles in a B2B company we managed, processed and stored some of the customers’ big data on our premise. One day a customer was asking if we can develop an integration with their analytics tool so they can have some BI analytics about the data we manage for them to view in their own system, and thus sparing them the need to go to our dashboard or importing it each time.
It was a big customer so we seriously considered working on such an integration. But then, luckily for us, another customer has reached out – this time asking for an integration for a different analytics tool – but for the exact same reasons.
Identifying this arising pattern – instead of prioritizing these integrations right away – we decided to learn more about the pain. We went and interviewed these customers and a bunch of others. What we discovered is that the pain was common to all of them. However, they all had different analytical solutions, so it didn’t make sense to start developing an integration for each. Instead, we decided to work on making their data accessible through standard ETL solutions (data migration and transformation standards) so the customers could virtually treat this data as part of their own databases, even though it was physically stored by us. This solution enabled them to seamlessly connect to their data and use their analytical tool of choice.
The customers were excited with this solution and we spared the need to develop 5-6 integrations. All that was needed was seeing the big picture.
Assuming you did all of the above – you believe you now got the right solution. Great! You then spec it out and hand it over to the R&D to implement. Are we done here?
Nope.
The feature is concluded only after it was delivered to the users/customers and you receive enough feedback that it indeed addressed the pain.
I’m not going to cover right now the internal product delivery process (product, UX/UI design, R&D, QA and the whole chain). This pipeline deserves at least one post of its own.
I do want to say a few words about the feedback I mentioned above, though. What feedback am I referring to here?
This depends mainly on the type of business you are on, but essentially it drills down to meeting a success criteria or KPIs that you decided upon in advance and before you handed the feature to the R&D to work on.
For instance – on the Newsfusion example above – we could follow the usage patterns of the users such as how much they scroll down the feed, or how many stories they click, and compare it to the period before the feature was released.
The second case is harder to measure, but you can still tell that you did well by measuring the usage of this feature, and by following the volume of complaints about the topic (which should be reduced to zero).
Later on, I’ll devote some dedicated posts about KPIs and what a great product specification must include, but for now, let’s just say that as part of the product specification – you must include a section which is dedicated to how you are going to measure that the feature addresses the pain and what’s your success criteria.
This will help you in setting expectations with everyone who is involved with this feature, as for what is the desired outcome. But more important than that – it’s a commitment you are doing with yourself about how you will know that you did a good job. It will keep you honest and prevent you from later ‘bending the reality’ to falsely declare that the feature is performing well, by focusing on the metrics which are strong… but… wrong! (and I’ve seen this happening before more than once).
So, to conclude, here is a summary of today’s takeaways:
After figuring out the pain, and starting to look into the ‘what’ and how the solution should look like –
- Don’t run and implement the solutions suggested by the users or customers right away.
- Dig into how ‘wide’ the pain is and how many customers/users it touches
- Based on the two above – design a solution that will address the pain of as many customers and users as possible
- Before implementing it – decide in advance how you are going to measure that you did a good job
- Release the feature and measure. Make adjustments if your success criteria is not met
That concludes our post for today.
If you found it helpful – don’t forget to ‘like’ it. If you think others can benefit from it – feel free to share it with them.
Thank you and until next time!