A few days ago I read this article, that resonated a lot with my normal workday, I guess as it might happen to many other Product Managers.
We are in charge of defining a rockstar, solve-all-my-problems, win-a-lot-of-money product for the company and the users, and for some reason other people in the organization think it should be very easy to achieve it.
I remember once receiving an invitation to a product review meeting (when I’m the one supposed to organize them) where a regional sales manager brought a beautiful slide deck of screenshots of the product with notes on all the things we needed to change, asking of course to give an implementation / release schedule plan to “fix it”. I have gone through (survived?) tons of this kind of “product review” meetings, where what we discuss is how cool the features look in the eyes of other company members, instead of how are we solving customer needs or at least how metrics are going.
Furthermore, this fellow company’s members also think that it is likely that their new feature / idea certainly is at that great product goals achievement level, and we are just idiots if we don’t see it that way. While I certainly agree that product ideas can (and should!) come from everywhere, sometimes it gets ugly, as the article I mention says, to receive tons of ideas that sound like a command and are hard to prioritize and get to their true value.
So I have been thinking… how do I transmit this complexity to my peers from other areas? How do I let them know the hard work and process that lays behind product and feature discovery, understand the many steps of customer need validation, and let them know that even when an idea is good it does not have real business value for a variety of reasons like impacting few customers or not solving a real user pain.
This has been extremely hard for me. I did a presentation to colleagues with titles like “how does Product Management work”, and show them how for each new feature or idea all the work we do to make sure we are building the right product. Still, the flow of ideas come our way, and I realize it is still very good and beneficial they do! Yes sure, it’s hard to prioritize them, but if I generate a culture of “don’t bring me stuff”, it is most likely that I will miss opportunities to hear very good ones (or probably get fired at the 3rd “no” I give in response to an idea).
Focusing on features
On a parallel line of thoughts, I’ve been concerned as an established company’s Product Manager, that we focus our backlog on features and solutions to prioritize when in fact what we are trying to solve are customer pains, that many times we still don’t know how to solve.
You do your homework, research the market, and come up with a few problems that customers have (in our case using our existing product). And then… “bum”, the team comes up with a few ideas to test and that becomes the solutions backlog. I feel this is like having a bar: your customer walks in, she says is thirsty, and before asking what she wants to drink, start trying to serve her coke, beer, water in whatever order you come up with until she starts actually drinking.
So if we want so badly to focus on the customer, and want other areas or ideas that are brought to be focused on them as well, why don’t we have a “Customer Pains backlog” instead of a features / solutions backlog. What happens if for each “solution” someone brings you, you play the 5 whystechnique and try to get to the real (or not) problem they are trying to solve. It will certainly help you get a better notion of the value of that idea. You will get the other person to see it as well and to think deeply what she is trying the product to do and for what reason. And, as a bonus, if the other person do not know the answers either you dismiss the idea or have her “work for you” by going to do some research before coming back.
On the other hand from a reporting perspective I feel is much more honest to tell the company the order in which you will tackle customer pains (and easier to justify but how big those pains are), than to write down solutions that you do not know at the moment if will work and you will probably keep changing while they get closer to being developed. And as a collateral benefit, you will have everyone talking about the problem and how to solve it instead of how much they like or dislike your proposed solution.
Moving forward
How will we continue to work? Certainly for the items in the top of the backlog we already did the research to understand the customer problem and how the proposed solution will impact them. So for this “ready to produce” items it makes a lot of sense to have the solution written -even for better communication with the development team or other areas that need to know what’s being delivered. But for the items that are in lower positions in the backlog, and we do not have yet clear what is the real pain or how to solve it, I found that writing the backlog item in the form of a customer pain hypothesis would be much more beneficial and will naturally drive us to customer discovery than having a solution already written that could very likely bias the way we think about the problem.
