How senior product managers think differently

I often got asked how a product manager could get promoted to a more senior level. The truth is, getting a promotion is often a complicated game. Yes, your skills and achievements play a role, but so do other factors such as how much your manager cares about developing talents, how good and tenured your peers are, how political the company is, etc.

So this article isn’t about how to get promoted to senior PM, but about how to advance your thinking and become a better PM. Anyone can think like a senior PM regardless of their title — and just because one has the senior PM title, doesn’t mean they truly deserve it.

The diagram below shows different ways you can “do product”, depending on how clear you are about the problem and the solution. To advance your product craft, you have to be comfortable operating at all levels of clarity, and learn the different tools you can use in each situation.

How do you know whether a problem is clear? Some indicators of a clear problem:

• You can articulate the impact on the business and the users,
• You understand the root cause of the problem well,
• You have decided that this problem, and not other problems, should be addressed now.

And you can say that a solution is clear if:

• You’re confident that this solution can solve the problem,
• You’ve considered an array of solutions, and this one wins in terms of cost/benefit,
• Your team knows how to deliver the solution.

In this article, we’re going to cover the tools you can deploy in different situations, and at the end, let’s talk about the pitfalls to look out for.

Nailing the basics: Excellent execution

When the problem has already been well-defined and the solution has been agreed upon, your focus is to execute it really well. This is usually the main playing field of a more junior PM. Senior PMs have to master this aspect too, of course, but they could choose to be less hands-on.

“How can we ship this quickly?”

This is all about managing the backlog: Make sure the tickets are clearly written, rightly sized, correctly prioritized, and efficiently worked on. It might also include running the ceremonies that enable the team to achieve the above, such as sprint planning, refinement, and retro.

In a traditional Scrum team, this is the Product Owner's responsibility. In more established organizations, I often see this being run by the tech lead. If you’re lucky enough to have a good tech lead on your team, don’t fret! As a PM, you bring your unique value by:

• Making sure the engineers understand the vision & context of the work and how it contributes to business goals
• Helping them to vertically slice the work into independently shippable chunks.

Depending on how complex the feature is, shipping the whole feature can take months. If you could find a way to slice the feature into smaller chunks that can still bring value to the users, that’s a win. Shipping quicker also means getting feedback from the users faster, i.e. reducing the risk of spending months building the wrong thing.

“How can we ensure we do this well?”

This is where testing and experimentation come in. You might want to do usability testing using a prototype before asking the engineers to write any code. You might choose to roll out the feature incrementally or do an A/B test before rolling out the winning version.

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

— Prototype usability testing

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

This is how it goes: You show a clickable prototype, and ask somebody to complete a task related to your solution, e.g. “Could you show me how you would upload a photo?”

Your job is then to observe silently and take notes. Do they know intuitively which button to click? Do they understand what’s going to happen when they do a certain action? Is the copy confusing them?

This test is a quick and low-cost way to make sure you don’t waste valuable engineering resources. You can use a platform like usertesting.com which allows you to set up a test just before you log off for the day and voilà!, the results are there the next day!

Usertesting.com might be a costly option if you work for a very small startup — in that case, you can test the prototype with virtually anyone except for the people who are already too familiar with the product.

— Rolling out a feature incrementally

This means instead of rolling out the feature to 100% of your users immediately, you do it incrementally. There are a few use cases where this is useful:

1. You want to make sure that this feature doesn’t break anything. As a PM, you have to understand what your ‘control metrics’ are. Control metrics are the things you don’t want to harm as you’re releasing new things, such as app crash rate and the number of customer complaints.
2. You want to measure the impact of your feature. By rolling it out only to a subset of users (or you can also do the opposite, keep a small holdout group who doesn’t get the feature) for a period of time, you can showcase the impact your feature brings to the metric you want to move. Just make sure that you distribute the users evenly.
   PS: Technically this also counts as an A/B test, but for the sake of this article, I use the term A/B test exclusively for two or more different solutions.

When to not do this: When your users are screaming for a solution and the one you’re about to ship can’t make things any worse. I would even sacrifice the ability to measure the impact when things are that bad.

— Do an A/B test

The literal meaning of A/B test is just testing solution A and solution B and seeing which one performs better. You can A/B test a prototype, or you can A/B test in a live environment. You can make it an A/B/C/D test, or you can use a combination of different components in each version, etc.

The goal here is to identify the winning version of a solution. You might have heard a famous example of how Google experimented with 41 shades of blue and gained a US$200 million revenue increase. But unless you have millions/billions of users and a tiny % increase equals a huge $$$ value, I wouldn’t recommend going overboard with A/B tests. There are user journeys that you would want to improve until you’re sure you‘ve nailed them, such as the acquisition and activation journeys. Those touchpoints are where you convert a visitor into a paying user, and the $$ impact is easily measurable. But in other parts of the journey, such as where users actually use your product to complete a task, a simple A/B test usually does the job.

Critical evaluation (and thoughtful pushback)

From this point onwards, I would say that this is the differentiator between a product manager and a digital project manager. A project manager’s job is to deliver a project successfully. Somebody else has defined the problem, decided that it’s worth solving, and has figured out a solution that needs to be delivered.

Critically evaluating a solution (“Is there a better way to solve this problem?”) and evaluating a problem (“Is this problem worth solving?”) are what take your product thinking to the next level. It might also mean saying no, or pushing back at your stakeholders.

And in some cases, it could also be the difference between an in-house PM and a PM working in an agency. An agency is usually hired to execute a particular project. I imagine the agency won’t be very amused if their PM concludes that the project is not needed at all.

“Is there a better way to solve this problem?”

There are different ways you can define a “better” solution. “Better” could mean faster to build, cheaper cost of integration, more valuable for the business long-term, or more effective in solving the short-term problem.

As a PM, it’s your job to understand the strategic importance of the problem you’re building, which enables you to put the right constraints for the solution. You should then amass the expertise of the people in your team (i.e. engineers, data scientists, and designers) to figure out different solutions that satisfy the constraints.

— Understanding the strategic importance of the problem

I’ve seen PMs stuck with just one principle when giving directions to the team. This principle could be speed (“I just want this out of the door ASAP”) or the best user experience possible (“Our product has to be world-class”), or whatever. The downfall here is that they fail to recognise that not all problems and solutions are created equal.

As a PM, you have to be able to articulate:

• Which company objective are you trying to address by working on this?
• What user problems are you tackling? (And my favourite follow-up question: How do you know that it’s a problem?)
• How do you know if you’ve solved the problem? Which outcome metrics will be impacted? What output metrics will you be measuring and how will they influence the outcome metrics?

— Providing the context and constraints to your team

I’m not a fan of pages and pages of PRD (product requirements documentation), and definitely not a fan of “handing over” the PRD to the engineers to build. You should provide the context (as we discussed just now — company objective, user problems, metrics, etc) and the constraints. Constraints could be:

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

Remember that the goal isn’t always to build something perfect for everyone. It’s fine to say that “We just want a quick and dirty solution for user segment X, and we don’t care about edge cases Y and Z,” assuming that you’ve considered them carefully and you’re happy with the tradeoffs.

Over-specifying isn’t good, but make sure you understand it well.

— Amassing their expertise to figure out the solutions

Now it’s your time to take a step back and let your team shine. Give them time to do their own thinking, technical spike, and wireframing. You should still be there to provide guidance, nudge, and clarification. At the end of this process, if there are multiple possible good solutions, it’s your job to make the call.

A design sprint is one format that you can use to do this process. Another way is to bake this into your regular sprint, sometimes also referred to as dual-track agile. The former is nice for a big or new project that requires you to shake up the team’s old way of thinking and working. The latter is usually more convenient and less disruptive, especially if your team has a delivery goal to meet.

“Is this problem worth solving?”

Now depending on how product-led the company is, questioning whether a problem is worth solving might not be easy. Product requests could come from very senior stakeholders, even the CEO, and the PM might need to pick their battle.

If we “assume good intent, if not competence” (as we liked to say at Meta), all product ideas and requests have some level of merit. Maybe none of them is truly rubbish — which makes it harder to push back.

Let’s equip you with some tools that can help you do that.

— Quantifying impact

It’s the most obvious one but I thought it’s worth repeating. You can quantify impact by considering these factors, which then translated into dollar value:

• Reach: the number of users impacted
• Intensity: how painful the current state is for these users
• User segment: how valuable the user segment is for your company (i.e. the reach could be minimum, but this handful of users might be bringing half of your revenue)

As much as possible, bring hard data and numbers to reduce subjectivity.

— Understanding the true cost of a feature

It’s usually pretty straightforward to estimate how much is it going to cost you to build a feature. Take a time estimation from the engineers, and multiply it by their salary. But you have to remember that there are other types of costs, apart from the cost of building:

• Cost of maintaining. Once the feature is live, your team is also responsible to maintain it and fix any issues that arise.
• Cost of bulking up. Your codebase will be more complex thanks to this feature, and building anything else will take slightly longer due to the extra complexity. A new joiner will take longer to understand the codebase.
• Cost of improving. You can pray that the feature will perfectly solve the problem once it’s released, but that’s rarely the case. You might have to tinker around with it, change the copy, tweak the setup, etc.
• Cost of coordinating. You and your team will have to join meetings, write emails, present an update, give a heads-up to related teams, etc.
• And obviously, you also have to consider the opportunity cost: How else could we have used our time? What’s the potential loss from a missed opportunity?

— Understanding time sensitivity

The question is not always “Is this problem worth solving?” — it could also be “Why now?”

A tiny crack in the wall might not have an impressive impact number now, but ignoring it might cause you a huge problem down the line. Understanding the cost of doing nothing and the cost of delay will help you frame the problem and its urgency. Quoting myself from this article:

Some problems are like a fire — you either have to solve them now or rebuild later. Other problems are like a leaking roof — it gets worse and worse slowly until the whole roof falls down. Some other problems are like a puddle of water — it’s annoying but it doesn’t harm anyone as long as everyone knows to walk around it.

— Pushing back thoughtfully

Now, you’ve done all the exercises and you’re convinced that this problem is not actually worth solving, at least for now. Pushing back is a necessary part of the job — as Warren Buffet said, “The difference between successful people and really successful people is that really successful people say no to almost everything.”

My principles in pushing back:

• Don’t beat around the bush. If you’re not going to deliver their request, say it early and straight.
• Show that you’ve considered their requests carefully. Talk about the thought process that leads you to this conclusion.
• Showcase what the team is doing instead. They’re building something more valuable and you have to be able to articulate that.

— Committing even after disagreeing

We’ve all been there — the HiPPO has spoken (Highest Paid Person’s Opinion) and you have to deliver something you disagreed with. It’s tempting to grunt and vent to the team.

Jeff Bezos from Amazon popularized the concept of disagree and commit which I personally love. (I’d totally recommend reading the whole letter if you haven’t already.) You might have disagreed in the background, but as a PM and the leader of the team, you have to present a united front with the leadership and evangelize for this work.

Sourcing strategic opportunities

Now we’re talking about the highest level of ambiguity: both the problem and the solution is unclear. It’s a great opportunity to take a step back and see the bigger picture.

What’s the highest value problem we should be looking at?

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

— Understanding the users’ jobs to be done (JTBD)

The main tenet of JTBD is understanding what the user is trying to accomplish when they “hire” your product. The answer is usually deeper than the obvious. Imagine that the product you manage is an MBA program. People do an MBA for a variety of reasons: to switch careers, to advance in their current career path, to start their own business, etc.

You can dig deeper into those reasons. E.g. for people who said they’re doing an MBA to advance in their current career path. What does it actually mean? What’s blocking them right now? Are they lacking confidence? Do they have knowledge gaps? Do they just need the degree to prove their credential?

Understanding the deeper reason will enable you to identify improvement opportunities you could implement in your product to serve your user needs better.

— Understanding your user’s switching factors

When users decide to use your product, they switch from what they were using before. This is true even if they weren’t using any ‘product’ previously — doing nothing is a legit alternative.

There are four forces playing in somebody’s decision to switch:

• Push factors: Pain points and dissatisfaction around the current solution
• Pull factors: Advantages or benefits of the new solution
• Anxiety: Concerns and worries about the new solution
• Inertia: Comfort and familiarity with the existing solution

Your job as a PM is to uncover these switching factors from your users so you can proactively reduce the barrier to switching. Let’s look at the four factors using the MBA example again.

Example: Four factors influencing somebody’s decision to do a part-time MBA

How can we future-proof our product?

Improving your product is not always constrained within your current playing field. Radical innovation usually comes from looking outwards, not incremental improvement.

— Understanding the competitive landscape of your product

As we’ve discussed in the previous section, your product’s competitors are not just the obvious. University X is not just competing against University Y and Z in promoting its MBA program; it’s also competing against bootcamps, online courses, podcasts, executive coaching, and even Netflix.

In mapping these alternatives and comparing them with your product, you can use customer needs as the other side of the axis and assess how well each product is satisfying the needs. A simple example below:

PS: It’s also useful to do the complementary exercises: (1) Mapping your user segments, as each segment will have different needs, and not all segments are equally valuable to your business and (2) Mapping the needs into hygiene, performance, and delighters, aka The Kano Model. This article is already getting too long so I’m cutting them out! If you want to learn more about those, let me know in the comment section and I’ll write a deep-dive article on them.

Now imagine, as an MBA program product manager, you’re tasked to figure out a completely new product that disrupts an MBA. You can take the customer need map, identify which needs are unmet by currently available solutions, and create a unique new program with strong value propositions.

— Identifying opportunities to expand your product’s value chain

It’s not just a competitor or a new entrant that could disrupt your product. There are other factors at play, as famously mapped by Michael Porter in the five forces analysis. In his framework, Porter talked about recognizing the bargaining power of your customers and suppliers. If your suppliers can jack up the price and you are left with no other option, then you're screwed. If your customers can switch away from you with no problem or can negotiate the price down to nothing, then you’re in trouble.

So if you want to increase your product’s likelihood of long-term success, you have to reduce their bargaining power by increasing yours.

Now, he had a point, but that way of framing made me feel uncomfortable. It implies a power play where one party has to lose. I prefer to think about it another way: How might we expand our product’s value chain?

Let’s take Shopify as an example. It started as an online store builder: a small business owner can configure their brand and store theme, add their items, and voilà, they have their own online store in 15 minutes. Their target customer was the people who already had a business and items to sell, they just needed an online presence.

Then Shopify identified an opportunity: what about aspiring entrepreneurs who want to start their own online business, but don’t know what to sell yet? They expanded their offerings to the wholesale market and dropshipping.

Oversimplified value chain of managing an online store

The next step in managing an online store is fulfilling the order by sending it to the customer. Shopify also decided to expand to that area by providing its own fulfilment network.

Shopify makes it harder for customers to switch away, or for a new entrant to take the customers, by making itself valuable and not easily replaceable. It’s a win for Shopify but also a win for the customers.

The takeaway for you: try to map out the process that your customers go through to accomplish their JTBD. Is there a way you can expand your value by helping them in the process before or after they use your product?

Putting them all together

Phew, that was a long article. Thanks for making it this far.

If you can only take away one thing, here it is: there’s no single tool that works all the time. You can improve your product management craft by 1) increasing the number of tools that you have in your toolbox, and 2) knowing when to deploy each one of them.

Summary of this really long article. The tools are not exhaustive.

Just before we go, I have a quick note to add. There are two traps to fall into:

1. Questioning the problem and the solution too much. You don’t always have to use the most advanced tool just to look smart, or to prove that you operate like a senior product manager. If the cost of thinking is higher than the cost of building, just build and ship it. The market will tell you if you’re right.
2. Questioning the problem and the solution too little. This is usually the bug of a very new PM (they thought somebody else has done the job of clarifying the problem and the solution) or a very old PM (they are too familiar with the company, the user, and the domain, so they took things for granted). By “new” and “old”, I was referring to their tenure in the company, by the way, not their age.

If you’re not sure how clear you are of the problem or the solution, I have one trick for you: try to write it down. You can write it in the form of a press release, a customer thank you letter, or simply a narrative describing the problem and the solution.

👋 Hi, I’m Debbie. I’m a product operator with 12+ years of experience building products. Currently CPO at Zero Gravity, previously at Shopify and Meta. You’ll hear me talk about bringing the product craft back to its first principles: building something that delivers value to the users and the business. Bonus point if that value also translates to a positive social or environmental impact on the world. Stay ahead of the game and get insights delivered straight to your inbox — subscribe to my newsletter today!