Product management is basically about identifying user pain points and creating solutions in a way that generates value for the business.
One of the most exciting elements in this role is working with the product team to come up with great ideas. Like all businesses, plans are plentiful but only a few are valuable.
To ensure our ideas are going to provide value, my team and I focus on the user to identify the pain points they may have when using our site. When we understand our user better, we can create an innovative solution we expect to have an impact on user behaviour, and in turn help us hit our objectives and key results (OKRs), generating more revenue for the company. Users will benefit and stakeholders will be happy too – win-win!
I’ve learned from experience that without taking this approach you risk falling into various traps, all of which end up wasting valuable time and resources. Even with the most careful wireframing, and then creating an amazing UI and testing it, we can still find ourselves with a feature that didn’t actually have the impact we were hoping for.
Why? Because often in the end, the feature didn’t add any value to the user and didn’t address any pain points. Results end up in a place where user behavior doesn’t change and the reaction to our “amazing” new feature is simply “meh.”
Not only does this curb the team’s enthusiasm but over-estimated results are likely to have the rest of the business asking, “Exactly what are you guys doing over there?!”
So how do we prevent this cycle and start delivering better products?
The first step is backwards. Or rather, we take a step back from the product delivery schedule and instead of asking what we should build, we ask ourselves why should we build?
Here we can embark on our product discovery phase. Instead of trying to solve our problems; for example, users aren’t clicking out where we want them to, we try to identify the user’s problems.
It could be that as a user there’s nothing I want to click on, or I don’t have enough information to make a purchase decision. Once we really understand the user’s problems, we can start to formulate ideas on how to solve them.
Some of these ideas might be great, but realistically only a tiny percent are actually going to work. Before committing to building anything, as a team we try to prove or disprove our theory. This is basically to sanity check the concept and understand scientifically the formula of – does solution X actually solve the user’s problem in a business viable way? Or in other words, why should we build it?
Within product management we have a range of tools and frameworks available to help with the idea generation process. I find the Opportunity Solution Tree to be particularly helpful, but other PMs find different methods work better for their teams. We have the autonomy to use the tools that work best for us.
Using an idea generation framework involves fully understanding our users’ problems, coming up with several ideas to solve them and aligning them with a business outcome (our OKRS).
Once we have a rich list of potential solutions, we validate which ones are most likely to be viable solutions using surveys, split testing, and user feedback before we move the feature to our product delivery phase. The significance here is a validated idea is more likely to bring value to the user and to the business.
The key is quick learning. We test, we fail, we learn. To ensure we are in a constant state of learning and delivering, we run our discovery and development cycles continuously.
It is not easy to build better products, but the good thing is with every learning, including every fail, we are getting better and quicker at delivering a product that our users actually want.