It’s Thursday afternoon. John, a Product Manager at an e-commerce platform, is preparing for tomorrow’s grooming session with the design & engineering team. One of the features that he wants the team to deliver is to allow users to compare different models of the products they’re looking for.
As the customer expert, John has spoken to his online buyers and he’s done the necessary research before he came to the conclusion that users want this feature. The evidence is there. Users want to compare products. The team’s going to deliver and the users are going to love them for it. Innovation is John’s middle name.
And so John starts writing the user story:
As an online e-commerce portal user, I want to have a Compare Features button in the product details view, to compare the specifications of the product with another product that I select, Such that I can choose the best product for my needs.
And so, on the following day, the designers and the engineers are discussing how to best implement a:
- “Compare Features” button
- In the product details view
- To Compare the specifications of the product
- Comparing the product with another product that the user wants to compare with
The problem with the example above, is that John has prescribed the near-exact implementation of the feature to the designers and engineers, without going through the thought process that designers and engineers would have gone through themselves. And since the thought processes of designers and engineers are very specialised and focused on their areas of expertise, it is highly likely that the product manager will have missed out on asking crucial questions that would have led to a much better and more innovative product to be built.
John has inadvertently turned the designer into a design secretary and the engineers into programmers. Innovation is no longer his middle name.
Instead, if John had focused on providing the crucial context about the customers and their objectives, the engineers and designers would not have been immediately biased towards the prescribed solution, but instead would have explored other possible solutions to the problem that John might not have thought of.
Let’s look at an example of how this user story could have been positioned a bit better:
As an online e-commerce portal user who is overwhelmed with the choice of products, I want to understand which products best fit my needs, Such that I can decide which one to purchase.
Already, this is a much broader story that reflects the users’ actual objectives, which will start triggering questions from the design & engineering team around the implementation possibilities to ship a product that makes it easier for portal users to decide on which product to purchase.
Instead of a “Compare Feature” button the team could end up discussing adding a “Similar Products” view, or alternatively highlighting the key differentiators of each product in the search results screen. You get the gist.
Focus on what you should be focusing on
I believe that as Product Managers, we should focus our efforts on understanding our users and customers inside out. When we are handing over the work to our designers and engineers, we need to make sure that we’re providing complete, accurate and up-to-date information on our users and their success measures, so that together we can explore innovative solutions that deliver the highest amount of value to our customers.
Engineers & Designers are hired to engineer and design solutions. As Product Managers we should leverage this to unite the team and together reach our ultimate objective – building products that people love.