Everyone talks about thinking like an engineer but no one talks about thinking like a product manager. One common misconception developers think is that we just block their ideas. While there is an element of truth to product managers saying no a lot, maybe it would make sense to clarify why this happens and how can you get around it.
As with all humans, you should start by understanding product managers’ desires and incentives. Product managers are driven by building products used by the target users that lead to driving business results. The more the users and the bigger results, the more they are happy (As long as it is being perceived internally/externally as driven by the team with this PM). This leads to a certain way of thinking whenever PMs hear new ideas, regardless of where they are coming from.
The first thing that pops into a product manager’s brain when someone pitches an idea is who is this for? The reason to this is because if the idea targets a segment of users the product manager cares about, the more likely they would be open to listen more. To know where this segment lies in priority is more art than science. It requires a mix of asking the product manager who does she care about and the developer having some sense of which user segments are more important. Data is your friend. The bigger the segment, the better.
Then comes the problem. The reason product managers annoyingly ask what is the problem we are trying to solve (other than trying to appear smarter in meetings) is because by understanding the problem, the better they can assess whether it is worth solving. You should also be prepared to answer why is it a problem? Because many times it can be a problem just for you, or it can be not painful enough that it is worth solving. Sometimes the pain is obvious, other times you have to be persuasive enough to convince others. You can do this by looking into the data and showing how it leads to users churning because of the problem, you can demo how shitty it is to get something done, or you can use one of the customers to lobby for you. The bigger the pain, the better.
Ok, you have made it this far. There is a good user segment that has a pain that needs to be addressed, now let’s talk about your awesome idea. Many times developers think that the product manager should have a strong opinion about the best solution, and many times product managers think they should have a strong opinion as well. The truth of the matter is there are only three things that matter when discussing a solution: 1) Does it solve the problem? 2) Is it feasible? 3) When can it be achieved? If the answer to 1 and 2 is yes, and the answer to 3 is soon enough, then you are too close to getting your idea through.
Last but not least, what is the business result? You can sell a dollar ($1) for eighty five cents ($.85) and I guarantee you, you will have a big enough segment that strongly feels the pain of wanting more money, it would be feasible and within reasonable time to solve it by giving them $1 if they give you $.85, but the result is the company will go bankrupt. You don’t want this to happen and therefore you want to make sure that your awesome idea will deliver positive business results, even if you don’t care about business. The simple way to think of it is imagining writing a report to the big bosses after this is released, what would the PM wants to write there? Think of the company and team objectives and what needs to be achieved. The bigger the results, the better.
All of this you need to apply while being aware of the current priorities. At the end there is a finite time and infinite number of items the team has to work on, the stronger the arguments on each of the previously mentioned points, the higher it ranks in the list of priorities.
In a nutshell: Big pain, to big number of users, with a feasible solution, within reasonable duration, that leads to a business result, and you won the product manager’s heart.
Thanks to Muaaz Saleem and Vicky Gkouta for reviewing drafts of this
