Inside the mind of a product manager: How as an engineer you can convince your product manager with your awesome ideas?

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

Product Monday: How to check progress without being annoying?

I have been asked this question recently and I noticed it creates contention between product and engineering if not done properly. I thought it may sound like a stupid idea for a blog post but I also noticed for less experienced product people, this is a serious question and the things we might do on autopilot takes a lot of effort for people who are new on the job.

Typically you check progress during the standup or whatever progress tracking ceremonies you agreed on. You are not supposed to be checking every second hour unless there is a critical deadline or something urgent. Be mindful that you have finite credit with everyone around you and every time you interrupt or annoy them, it takes from this credit.

That said, things don’t always go as planned and sometimes you need a progress update in the middle of the day or want to know some specific detail for a stakeholder update. When this happens you have to interrupt someone and ask the questions.

I am a strong believer in focus and hate to interrupt people. The first thing I would do is to check the tracking boards to see if the info I am looking for is there. If not I will go to the team area and find someone to ask.

Picking who to interrupt is more art than science. Sometimes you know there is one person who will be able to answer your question and you will have to interrupt them. Other times you might pick the person who is assigned to do support and bug fixing for the sprint (not all teams do this). Engineering leads are also good interruption candidates since part of their responsibilities is to solve issues and answer stakeholder questions. Sometimes I pick the person I interrupt the least to distribute my credit consumption across the team. Other times I look for someone watching YouTube or Facebook and interrupt them. And sometimes I go wander around the team looking confused until someone stops what they are doing and ask “Can I help you?”.

If you had to interrupt someone start by apologizing for the interruption “Sorry to interrupt I have to ask a question”. If it is not super urgent you can say “Sorry, Is it a bad time?”. If they say it is a bad time, ask when can you come back.

Once you clear the way, start your question with why. Starting with why makes people more sympathetic because they understand the reason for interrupting them was worth it. After the why ask your question “I am trying to do the budget math to update the VP and one of the things I don’t know is where we are on the switch to Spot instances. What do you know about this?”

Sometimes you might get an answer that surprises you like “we deprioritized it”. Don’t react. I repeat, don’t react. Follow up by asking “What are the reasons for this?”. Don’t use “Why?”. Be careful with your tone. There is a thin line between asking to understand and interrogating.

No matter what the engineers tell you, you are not supposed to argue with them on whether the progress makes sense or not. This is the engineering lead’s responsibility. If you go in this rabit hole you do more harm because 1) you are not the engineer’s boss to argue on why they are doing something and not the other. 2) you are stepping on the lead’s toe. The discussion on whether the progress makes sense should happen between you and the engineering lead. How to discuss such conflicts with engineering leads is something for a totally different post.

To Summarize

  • Check progress during agreed upon ceremonies.
  • Check project boards.
  • If you can’t find what you are looking for
    • Pick someone to interrupt.
    • Start by apologizing for the interruption.
    • Clarify the why to your question before the question.
    • Ask the question(s).
    • Listen.
    • Don’t get emotional or react.

Product Monday: Projects Collaboration

A product work colleague asked how to measure collaboration in the context of a project. What do people mean when they say “Let’s decide how we will work together”?

As usual, I gave a lengthy answer as to what I think. Here I am open sourcing it.

I think there are two main elements to this statement “Let’s decide how we will work together” in the context of projects.

1- Communication: How frequent project members communicate and what are the ceremonies involved? Will there be a standup and planning? Will only heads/PMs sync up on certain things and everyone sync up on other things? The key is to find the balance between being informed vs distracted.

2- Decisions: How decisions are made? This is the more dangerous one that people try to hide under the rug. Most projects don’t go as planned and many times there are no clear decision makers or decision criteria. This is where conflicts arise and escalations happen. There is no single answer to what’s the right thing to do as it always depends on a big number of variables like the project, the teams, and the stakeholders. One thing that helps me always is to think ahead of problems and raise them earlier. It makes me sound pessimistic but it does no harm if I turn to be wrong. If I am right the project benefits and people would have less reaction to problems as they were already anticipated.

At the end collaboration for me is measured by how close are we getting towards the result. And I am using the word “result” because I sometimes feel people consider delivery as the goal. To me it is a mean to achieve a result. If we can achieve the result without having meetings or with having more meetings I am ok with it. If not then we are not collaborating well enough, and there is a problem.

Product Monday: Screenshots

I test many products and take screenshots all the time. This is helpful as it serves as a reference when you want to design something similar.

Timing is key. Some experiences like onboarding or messages only happen once. You need to screenshot before you react.

Here are some examples of screenshots I took recently.

YouTube has different pricing for premium depending on whether you buy the subscription from the web or the app.

During summer, Google changed the font, spacing, and animation of displaying the stops on Maps for iOS. What I felt would’ve been useful was making the S icon to the left move as your location changes to the next stop. This would have been better to tell me where I am.

LinkedIn has a well designed onboarding experience to its mentorship program.

YouTube tries to measure the effectiveness of its ads on your buying behavior. Here it is asking which toothpaste I bought recently. The one I checked is the one I saw an ad on YouTube.

WhatsApp asks you if you want to change your number once you insert a new sim card. I like the copy that explains everything will be migrated. Smooth.

Take screenshots. It is a good habit for free education.

Product Monday: The meetings music

Managing by influence is not easy. One way to ease your job is to be likable. It is an art more than science.

One small trick I learned from a fellow product manager was that he always played music at the beginning and end of team meetings. It was a nice gesture creating a friendly atmosphere. This was his track.

I don’t do it all the time, but if you do, be careful if you have overly serious attendees. They won’t like it and might have opposite effect.

What would be your track?

Product Monday: The Product Manager Insecurity

Product managers are insecure about their perceived impact if they don’t interfere in the team’s work. Mastering the right level of interference makes a difference between success and failure.

This is harder when the product manager has experience in the product domain. A developer PM working on developer tools, a designer managing consumer product, or a marketer managing growth.

This leads to PMs pushing their ideas hard to teams, creating unnecessary tension. On the flip side, not showing that you have ideas might be perceived as lack of providing value, creating the insecurity I mentioned earlier.

A product colleague recently asked me about this problem. My answer to him was that you have to admit your limits, create success structures, and reinforce positive outcomes.

As a product manager your job is to manage by influence. Your impact is based on how much value you bring to customers, the team, and the business.

Because you manage by influence you have no control on most of the variables. That’s why you have to be mindful about which levers you choose to pull. Because each of them will move some parameters by some value. Your goal is to pull the highest value levers to achieve success.

We all have ideas we are passionate about, thinking they are silver bullets. The truth is most ideas don’t work or have moderate success. Few ideas work greatly.

You shouldn’t be too attached to your ideas. Because the number of times you are right are far less than the times you are wrong. And if you are in an organization where you are liable for your decisions, pushing your own ideas and them not working will have consequences.

Being humble and admitting your own limits is the first step to achieve success even in a domain where you have previous experience and knowledge.

The good news is that there are few principles if you follow you increase your – and the product – chances of success. Among the top being customer centric, and iterating fast. No product or product manager failed because they did the right thing for customers or were testing ideas quickly*.

While things like being data driven and doing user research may be common sense to you, the biggest mistake product managers make is to isolate the team from those insights and becoming a router between the insights and the team. This decreases your believability. Because they always get from you that customers want this or that. It makes it hard to distinguish between what you want, and what customers really want. It makes you a blocking factor, making the team dysfunctional when you are not there. And most importantly, detaching the team from the insights makes them non-convicted in doing what’s right for the customer.

That’s why structures matter. You need to be transparent about the process by which insights are generated, and invite team members to be part of it. Take engineers with you to user research. Make them moderate sessions. Review the scripts you prepare with them. Coach them on asking open ended questions and not leading customers in a certain way. Show them how you look at the data to derive decisions. When they have an idea tell them how you would assess it and guide them on how to validate it. Do this without asking them to do your job. Do this because you want them to be engaged and get better at it.

The previous two steps are not complete without reinforcing positive results. Positive results normally come when the team members including yourself admit your limits, you have the right structure that allows you to generate proper insights and decide where to hit, and you have an objective way to measure success.

When this is all done, you need to reinforce those results by reflecting with the team on how those results came. They need to continue listening to the customer and becoming better at this. They need to keep an open mind and iterate fast. And they need to correct each other when someone wants to do something that doesn’t provide value to customers.

If you do this, your impact will be felt, your team will be happy, you will have successful results, and you won’t be insecure any more.