How senior product managers approach challenges differently

I'm often asked how product managers advance to higher levels. The truth is, getting promoted is often a complicated game. Yes, your skills and accomplishments matter, but so do other factors, like how much your manager cares about developing talent, how talented your colleagues are, how long their tenure is, what the political climate of the company is, and more. So this article is not about how to advance to a senior PM, but about how to advance your thinking and become a better PM.

Anyone can think like a Senior PM, regardless of title, and just because a person has the Senior PM title, doesn't mean they truly deserve it.

The diagram below shows different ways of “making a product” depending on how clear you are about the problem and the solution. In order to improve your product craftsmanship, you must be able to work comfortably at various levels of clarity and learn the different tools you can use in each situation.

How do you know if the question is clear? Some indicators of obvious problems:

You can articulate the impact on the business and users,
You have a good understanding of the root cause of the problem,
You have decided that this problem should be solved now and not the others.

You can say that the solution is clear if :

You are confident that the solution will solve the problem,
You considered a range of solutions and this one won on a cost/benefit basis,
Your team knows how to deliver solutions.

In this article, we'll cover tools that can be deployed in different situations, and finally, let's discuss the pitfalls to be aware of.

01. Lay the foundation: excellent execution

When the problem has been clearly defined and the solution has been agreed upon, your focus is on executing it really well. This is often the primary playing field for less senior PMs. Of course, senior product managers must also have this knowledge, but they can choose to be less hands-on.

How can we ship so quickly?

It’s all about managing the backlog: making sure tickets are clearly written, appropriately sized, prioritized correctly, and processed efficiently. It may also include holding rituals that enable the team to achieve the above goals, such as sprint planning, refinement, and retrospectives.

In a traditional Scrum team, this is the responsibility of the Product Owner. In more mature organizations I often see it being run by a technical lead. If you're lucky enough to have a great tech lead on your team, don't worry! As a product manager, you bring unique value by:

Ensure engineers understand the vision and context of the work and how it contributes to achieving business goals
Help them split their work vertically into independently deliverable chunks.

Depending on the complexity of the feature, delivering the entire feature can take months. If you can find a way to split functionality into smaller chunks that still bring value to the user, that's a win. Faster delivery also means getting feedback from users faster, i.e. reducing the risk of spending months building the wrong product.

How can we make sure we get this right?

This is where testing and experimentation come in. You may want to use a prototype for usability testing before asking engineers to write any code. You can choose to roll out the feature gradually, or conduct A/B testing before rolling out the winning version.

Different types of tests and experiments are like tools in a toolbox. You have to understand what each tool does so you can pick the right tool for the right situation.

— Prototype usability testing

What it does : Test whether users know how to use your solution.
What it doesn't do : Test whether users want to use your solution.

Here's what happens: You show a clickable prototype and ask someone to complete a task related to your solution, such as "Can you tell me how to upload a photo?"

Your job then is to observe silently and take notes. Do they intuitively know which button to click? Do they know what will happen when they take a certain action? Does the copy confuse them?

This test is a quick and low-cost method to ensure you don't waste valuable engineering resources. You can use a platform like usertesting.com which allows you to set up a test before logging out for the day and voila ! , the results will be available the next day!

Usertesting.com can be an expensive option if you work for a very small startup – in which case you can test prototypes with almost anyone except people who are already very familiar with the product.

— Gradually roll out a feature

This means you don't have to roll out the feature to 100% of your users immediately, but rather do it gradually. This is useful in some use cases:

You want to make sure this feature doesn't break anything. As a product manager, you have to know what your “control metrics” are. Control metrics are metrics you don't want to compromise when launching a new product, such as app crash rates and the number of customer complaints.
You want to measure the impact of your feature. By rolling it out to only a subset of your users (or you can do the opposite and keep a small group that doesn't get the feature) for a while, you can show the impact your feature has on the metrics you want to move. Just make sure to distribute users evenly.
PS: Technically, this counts as A/B testing, but for the purposes of this article, I’m specifically using the term A/B testing to mean two or more different solutions.

When not to do this : When your users desperately need a solution, and the solution you're about to release won't make things worse. When things get this bad, I even sacrifice my ability to measure the impact.

— Conduct A/B testing

A/B testing literally means testing plan A and plan B to see which one performs better. You can A/B test prototypes or A/B test in a live environment. You can make it an A/B/C/D test, use a different combination of components in each version, etc.

The goal here is to identify the winning version of the solution. You may have heard of the famous example of how Google experimented with 41 shades of blue and achieved $200 million in revenue growth. But unless you have millions/billions of users and a tiny percentage increase equals huge $$$ value, I wouldn't recommend overdoing A/B testing. You may want to refine certain user journeys until you're sure you've completed them, such as acquisition and activation journeys. These touchpoints are where you convert visitors into paying customers, and the dollar impact is easy to measure. But in other parts of the journey, such as where users actually use your product to complete tasks, simple A/B testing can often get the job done.

02. Critical evaluation (and thoughtful counterattack)

From now on, I would say this is the difference between a product manager and a digital project manager. The project manager's job is to successfully deliver the project. Someone else has defined the problem, deemed it worth solving, and found the solution that needs to be delivered.

Critically evaluating solutions (“Is there a better way to solve this problem?”) and evaluating questions (“Is this problem worth solving?”) can take your product thinking to the next level. It might also mean saying no, or boycotting your stakeholders.

In some cases, this can also be the difference between an in-house PM and a PM working for an agency. An agency is usually hired to carry out a specific project. I imagine the agency would not be happy if their Prime Minister concluded that the project was simply not needed.

Is there a better way to solve this problem?

You can define a "better" solution in different ways. “Better” might mean faster to build, cheaper to integrate, more valuable to the long-term value of the business, or more effective at solving short-term problems.

As a product manager, your job is to understand the strategic importance of the problem you are building on, which enables you to set the right constraints for the solution. You should then bring together the expertise of the people on your team (i.e. engineers, data scientists, and designers) to figure out different solutions that meet the constraints.

— Understand the strategic importance of the issue

I've seen PMs stick to just one principle when giving instructions to their teams. This principle could be speed ("I just want to launch as quickly as possible") or the best user experience possible ("our product must be world-class"), or something else. The failure here is that they fail to recognize that not all problems and solutions are created equal.

As a product manager, you must be able to clearly express:

What company goal do you want to achieve with this job?
What user problems are you solving? (And my favorite follow-up question: How do you know this is a problem?)
How do you know if you've solved the problem? What outcome measures will be affected? What output metrics will you measure and how will they impact outcome metrics?

— Provide context and constraints for your team

I don't like pages and pages of PRDs (Product Requirements Documents), and I don't like "handing" PRDs to engineers to build. You should provide context (as we just discussed – company goals, user problems, metrics, etc.) and constraints. Limitations may be:

Resources (time and number of engineers)
User segmentation
Edge cases that should/should not be covered

Remember, the goal isn’t always to create the perfect product for everyone. It's okay to say "we just want a quick and dirty solution for user group

Over-specification is bad, but make sure you fully understand it

—Build expertise to find solutions

Now is the time to take a step back and let your team shine. Give them time for their own reflections, technical spikes, and wireframing. You should still be there to provide guidance, push, and clarification. At the end of this process, if there are multiple possible good solutions, it's your job to make a decision.

A design sprint is a format you can use to complete this process. Another approach is to incorporate it into your regular sprints, sometimes called dual-track agility . The former is ideal for large or new projects that require you to change your team's old way of thinking and working. The latter is often more convenient and less disruptive, especially if your team has delivery goals to meet.

Is this problem worth solving?

Now, depending on how product-led your company is, it might not be easy to question whether a problem is worth solving. Product requests may come from very senior stakeholders, even the CEO, and project managers may need to pick their battles.

If we "assume no ability but good intentions" (as we say here at Meta), all product ideas and claims have some degree of merit. Maybe none of them are truly garbage - which makes the rebuttal even harder .

Let us equip you with some tools that can help you do just that.

— Quantify impact

This is the most obvious one, but I think it's worth repeating. You can quantify the impact by considering the following factors and then converting it into a dollar value:

Coverage: Number of users affected
Intensity: How painful the current state is for these users
User Segmentation: How valuable a user segmentation is to your company (i.e. reach may be minimal, but these few users may bring in half of your revenue)

Provide hard data and numbers whenever possible to reduce subjectivity.

— Understand the true cost of features

It's often easy to estimate how much it will cost to build a feature. Get a time estimate from the engineer and multiply it by their salary. But you must remember that in addition to construction costs, there are other types of costs:

Maintenance costs . Once the feature goes live, your team is also responsible for maintaining it and resolving any issues that arise.
Inflated costs . Your codebase will become more complex due to this feature, and building anything else will take slightly longer due to the additional complexity. Newcomers will take longer to understand the code base.
Improvement costs . You can pray that the feature will work out perfectly once it's released, but that rarely happens. You may need to modify it, change copies, adjust settings, etc.
Coordination costs . You and your team must attend meetings, write emails, present updates, send reminders to relevant teams, and more.
Obviously, you also have to consider opportunity costs : how else would we use our time? What might a missed opportunity cost?

— Understand time sensitivity

The question isn’t always “Is this problem worth solving?” – it could also be “Why now?”

A tiny crack in your wall may not have an impressive impact now, but ignoring it could cause you huge problems. Understanding the cost of inaction and the cost of procrastination will help you identify the problem and its urgency. To quote this article of my own:

Some problems are like fires—you either fix them now or rebuild them later. Other problems are like a leaky roof—it slowly gets worse and worse until the entire roof collapses. Some other problems are like a puddle of water - it's annoying, but as long as everyone knows to get around it, it doesn't hurt anyone.

——Retorted thoughtfully

Now you've gone through all the exercises and are convinced that this problem isn't actually worth solving, at least for now. Fighting back is a necessary part of the job—as Warren Buffett says, “The difference between successful people and really successful people is that really successful people say no to almost everything.”

My principles for fighting back:

Don't beat around the bush. If you're not going to accommodate their request, say so directly as early as possible.
Show that you have carefully considered their request. Talk about the thought process that led you to this conclusion.
Show what the team is working on. They are building something more valuable, and you have to be able to express that clearly.

- Make commitments even after disagreeing

We've all been there - the HiPPO has given its opinion (the opinion of the highest paid person) and you have to make some points that you don't agree with. It can be tempting to whine and vent to the team.

Amazon’s Jeff Bezos popularized the concept of “disagree and commit” which I personally love. (If you haven’t read the entire letter, I fully recommend that you do.) You may disagree behind the scenes, but as a project manager and leader of the team, you must maintain a united front with leadership and commit to this Work to promote.

business growth innovation

View the plan now >

What are the challenges for business growth after the epidemic? How can reinventing growth get it right? Plan new strategies for growth, formulate a North Star for growth, establish an agile growth team and mechanism for promotion, and start a process of sustainable innovative growth operations.

03. Look for strategic opportunities

Now we are talking about the highest level of ambiguity: neither the problem nor the solution is clear. This is a good opportunity to step back and look at the big picture.

What are the highest value issues we should be focusing on?

Answering this question requires a deep understanding of why and how users use your product, as well as the factors they consider when switching to or away from your product. Harvard professor Clayton Christensen first introduced the framework in 2016, and since then it has become one of the most respected product development frameworks.

— Know what users have to do (JTBD)

The main purpose of JTBD is to understand what users want to achieve when they "hire" your product. The answer often goes deeper than the obvious. Imagine that the product you manage is an MBA program. People pursue an MBA for a variety of reasons: changing careers, advancing in their current career path, starting their own business, and more.

You can dig deeper into these reasons. For example, for those who say they are pursuing an MBA to advance in their current career path. What does it mean? What's holding them back now? Do they lack confidence? Do they have knowledge gaps? Do they just need a degree to prove their qualifications?

Understanding the deeper reasons will allow you to identify improvement opportunities that can be implemented in your product to better meet user needs.

— Understand users’ switching factors

When users decide to use your product, they abandon the product they were previously using. This is true even if they haven't used any "product" before - doing nothing is a legitimate option.

There are four forces at play when someone makes the decision to switch:

Drivers : Pain points and dissatisfaction with current solutions
Pull factors : the advantages or benefits of a new solution
Anxiety : Worry and apprehension about new solutions
Inertia : Comfort and familiarity with existing solutions

As a product manager, your job is to discover these conversion factors from your users so that you can proactively reduce conversion barriers. Let's look at these four factors again, using the MBA as an example.

How can we future-proof our products?

Improving a product is not always limited by the current competitive environment. Radical innovation often comes from looking outward rather than incremental improvements.

— Understand the competitive landscape for your product

As we discussed in the previous section, your product’s competitors are more than just the obvious ones. University

When mapping these alternatives and comparing them to your product, you can use customer needs as the other side of the axis and evaluate how well each product meets the need. Here's a simple example:

PS: It is also useful to do supplementary exercises: (1) Map your user segments, because each segment has different needs, and not all segments are equally valuable to your business; (2) Map the needs to hygiene, performance and pleasure, aka the Carnot model. This post was already too long, so I deleted them! If you want to know more, let me know in the comments section and I will write an in-depth article about them.

Now imagine that as an MBA program product manager, you are tasked with finding a new product that will disrupt MBAs. You can take a picture of your customer needs, determine which needs are not being met by currently available solutions, and create unique new initiatives with a strong value proposition.

—Looking for opportunities to expand the product value chain

It's not just competitors or new entrants that could disrupt your product. There are other factors at play, as Michael Porter depicts in Five Forces Analysis. In his framework, Porter talks about recognizing the bargaining power of customers and suppliers. If your supplier can raise prices and you have no choice, you're screwed. If your customers can leave you without a problem, or can negotiate the price down to zero, you're in trouble.

Therefore, if you want to increase the likelihood of your product's long-term success, you must reduce their bargaining power by increasing your bargaining power.

Now, he has a point, but this way of framing it makes me uncomfortable. This means a power game in which one side must lose. I prefer to think about it another way: How do we extend the value chain of our products?

Let's take Shopify as an example. It started out as an online store builder: small business owners could configure their branding and store theme, add their merchandise, and voila, they had their own online store in 15 minutes. Their target customers are people who already have a business and items to sell, they just need an online presence.

Then Shopify spotted an opportunity: Those aspiring entrepreneurs who want to start their own online business, but don't know what to sell yet? They expanded their product range to the wholesale market and direct sales business.

The next step in managing an online store is to fulfill orders by sending them to customers. Shopify has also decided to expand into this area by offering its own fulfillment network.

Shopify makes itself valuable and non-displaceable, making it harder for customers to leave, or for new entrants to steal them away. This is a win for Shopify and a win for customers.

Your takeaway: Try to map out the process your client will go through to complete their JTBD. Is there a way to extend your value by helping them before or after they use your product?

04. Put it all together: Use tools

If you can only take away one thing, it's this: no tool works all the time. You can improve your product management skills by 1) increasing the number of tools in your toolbox and 2) knowing when to deploy each tool.

Summary of this very long article. These tools are not exhaustive.

Before we leave, I have a quick note to add. There are two traps it is easy to fall into:

Questioning problems and solutions too much. You don’t always have to use the latest tools just to look smart, or to prove that you operate like a senior product manager. If it costs more to think than to build, then build and deliver it. The market will tell you whether your idea is correct.
Too few question problems and solutions . This is usually the case with a very new PM (who thinks others have already done the work of clarifying the problem and solution) or a very old PM (who is so familiar with the company, users, and domain that they take things for granted) mistake. By "new" and "old," by the way, I mean their tenure with the company, not their age.

If you're not sure how clear you are about the problem or solution, I have a tip for you: try writing it down. You can write it in the form of a press release, a customer thank-you note, or a narrative that simply describes the problem and solution.