How senior product managers think differently

In 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, it
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:
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.
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.
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.
Just before we go, I have a quick note to add. There are two traps to fall into:
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.
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 a form of a press release, a customer thank you letter, or simply a narrative describing the problem and the solution.