Product management is, essentially, managing chaos. The chaos could be problems faced by customers, business goals, or decisions to be taken. The chaos itself is deafening and as product managers, we’ve to filter out the noise and resonate with the signals.

To help us achieve that, I’ve identified 6 primary principles for product managers. These will help you prioritize, mentally, your next action.

The Team, referenced below, is a set of individuals involved in the building & maintenance of a product. These could involve developers, designers, marketing, and data analysts.

#1: Humility over Exactness

Picture this — in a room full of people who’ve mastered their craft for over a decade, how do you tell them what’s the best problem for them to solve? These are people who do what they do the best. Individually, they can efficiently solve the problem.

And yet, every day, 1000s of product managers ‘guide’ those with far more experience and skills to deliver a solution to the right problems.

How do these product managers do it? Simple — by being humble.

You don’t have to be right, at the cost of an individual’s ego. Being humble keeps you focused on your core function — efficient usage of the team to deliver exceptional value to your customers.

You need not dictate the right experience. Your team delivers the experience — you only identify where the holes in the experience are… the problems that need to be solved.

Think of yourself as the conductor in an orchestra — you cannot play the violin as good as the concertmaster. But you know how exactly where the concertmaster and violinist come in to create the wonderful tapestry of music.

What does this mean, practically?

In practical terms, it means saying, “I don’t know” in a grooming session and asking the team for inputs. Don’t take the grooming session feedbacks to heart — use them as a learning experience to better yourself. What you say may not be right all the time.

Sometimes, it is better to be seen as humble than to be right.

#2: Decisions over Analysis-Paralysis

Ambiguity is rampant in product management. Every day, you are faced with multiple choices, each one better than the other — each one having a rippling effect on your products’ lifecycle. It is better to take a decision now than to wait for more data.

You’ll have to stake your/your teams reputation on a decision and learn from it. Be a tie-breaker in ambiguity that may result in failure. With high risk, come high rewards. Take a leap of faith.

This also means you need to be clear and concise. Where a few lines would do, do not bring in paragraphs.

What does this mean, practically?

Filter out the noise. Differ minor ambiguity to a later time (wording on a landing page) and focus on the key decisions (having the landing page). Push for a collective decision using one of the many frameworks available (untools.co).

#3: Influence over Control

Product management is a thankless job — with all responsibility, but none of the authority. You have to build influence quickly. Your team may not approach you to solve a problem, but they should approach you for prioritizing the problem to solve.

Rallying the team towards a certain goal without exerting control (my way or the highway) is a key aspect of product management. Your experience lies in not solving the problem, but in getting the team to solve the problem.

What does this mean, practically?

This is about getting the team aligned to a goal. Developers like to solve shiny problems — the complex stuff that gets them excited. But exerting influence and the spirit of the team is critical to getting the right shiny problems solved.

There has to be a good balance between shiny and dull problems to keep the team engaged. Influence is a give and take — the team exerts equal and opposite influence on you/backlog.

This balance between your influence on the backlog v/s teams influence backlog can make or break your product. Exerting too much influence on the backlog, without taking into account the teams’ input leads to control.

Letting the team control the backlog excessively is bad product management.

#4: Done over Perfect

You can spend 3 months perfecting a solution only to find that you’ve lost 30% of your customers during that time OR you can spend 3 weeks to launch a solution that works and get an idea of what the customer needs next. It’s the stalling of the inevitable.

Remember, time is not your ally. It is better to fail and learn than to perfect and fail.

The spirit of agile dictates that getting a working solution in the hands of the customer is more important than getting a perfect solution in the hands of no-one.

What does this mean, practically?

Reduce the scope. Find the minimum viability. As an example, custom landing pages feature requires both front-end and back-end development.

It is better to have the backend configuration as simple as possible (without the fancy bells and whistles) and focus on the front end functionalities, like adding a custom carousel. Find the right number of shortcuts without greatly inconveniencing the user.

#5: Team over Individual

If you’ve succeeded in launching a great product, it is all because of the team. If you’ve failed, it’s the team. The team is the highest priority in product management, sometimes even bigger than the stakeholders.

There are no heroes in product management.

As a product manager, you make two promises. One to the business that you’ll efficiently use the team to deliver value to the customers, who’ll then deliver revenue to the business. Second, to the team that you’ll ensure that their work delivers value to the customers.

Hence, it becomes imperative that a PM convinces the team of the sprint/product goal. Every decision taken has to be agreed upon by every member of the team. However, note that total consensus is paramount, but not necessary. You’ll always have some naysayers that need convincing.

What does this mean, practically?

Organize yourself and the team to believe in the team's delivery above their own delivery. Often times developers will deliver a solution that’ll not pass basic QA tests because the story didn’t cover them. This individual over team attitude will lead to a downfall of the team. Motivate/Remind the team members that not-highlighting these issues will only lead to failure.

#6: Right problems over the right solution

Spending a few hours sharpening your ax is better than spending a day cutting away at a tree with a blunt one. Similarly, diving deep and checking if the questions you are asking are the right ones is more important than solving them.

There is an answer to every question you can ask. There is a solution for every problem your customer is facing. But are you solving the right problem?

What does this mean, practically?

Practically, your prioritization framework needs to capture the impact of the solution. I.E. Is the problem we’re solving impacting a relatively larger % of the customers compared to another problem? Spend some time in identifying the relative impacts of the problems before you solve them.

Circling back to the original concept of managing chaos: As the problems become more complex, the chaos becomes more unstable. My personal experience in the last 10 years has been to take the chaos and funnel it down a pipeline of framework and decisions that justify the management.

It’ll be tough, but definitely worth the learning you & your team gets.

Thank you for reading! I’d love to hear you thoughts on this.