The Not-So-Easy Birth of Features and How to Raise them Properly

New features and feature improvements would only come to life in an ideal world if tied to a legit user problem. The reality is that things don't always start like this. Maybe it was a request from your most valuable clients or demand from someone in your team with enough power and influence.

Either way, you still need to tie this feature request to your users' reality if you want it to be valuable, both for them and your business. Even if you are sure about its lack of value, make it a hypothesis that implies some improvement in your users' lives.

A template like the one below, based on the jobs-to-be-done framework, should be enough:

When I... (context)
But... (barrier)
Help me... (goal)
So I... (outcome)

Let's say your CEO felt inspired by Amazon and decided that you need a 1-click buy button. Dig into the reasons for that. If it's because there's an opportunity to increase sales, especially among loyal customers, the result could be something like:

"As a long-time and regular customer who shops at least once a week, but feels annoyed by a time-consuming checkout flow, help me save time, so I can have more time to explore the store, possibly changing the way I shop."

Now that's a great map for validating some assumptions:
• Do people perceive the checkout process as time-consuming?
• If more time is available, would they use it to buy more?
• If time is not the problem, what prevents them from spending more?

And so on... Once you talk to customers and start uncovering the reality, the opinion-based request gets closer to people's lives. Besides that, you'll probably have a better sense of how appreciated the feature will be... or not.

Even if your CEO insists on adopting the one-click buy button, you'll have a great alternative, already validated and ready for implementation, when things don't go as expected. So, it always worth the shot.