7 Characteristics of Weak Product Management

Scrum Teams will never reach their highest potential without solid Product Management practices.

Why do companies hire highly qualified professionals? The answer should be straightforward, but what happens, in reality, is complex. I’ve observed many talented people trapped in the business world from doing what they are capable of. The reasons are endless, but some common ones are:

• Unskilled managers limit talents by telling them what to do.
• Complex processes and bureaucracy impede talents from doing what should be done.
• Obsession for certainty blocks talents from discovering what could work better for the company’s business.
• Unwillingness to embrace the unknown leads to sub-optimal incremental improvements.

I feel like many companies trap people instead of empowering them. As a result, talents are wasted, and sooner or later, they become unmotivated and search for new opportunities, where often the same cycle repeats itself. Then, the turn-over rate grows, and companies ignore it because they cannot accept that the problem lies with them.

During this post, I will share what I perceive as the signs of weak product management. After reading this content, I hope you can find opportunities to strengthen product management skills in your situation.

1. Solutions over Problems

In weak product management environments, solutions are the focus of everything. For example, roadmaps contain only solutions to implement, the Product Backlog Items refer to solutions, during refinement sessions, developers discuss the solution implementation, etc. The point is, implementation of the solution correctly is what matters. Yet, the problem the solution should solve is often ignored.

Some days ago, I stumbled upon a question from John Cutler, he said:

It would be odd for someone to say “bring me answers not questions.” We seem to value “good questions”. Yet somehow “bring me solutions not problems” is common. Why?

Why do we ask for solutions instead of problems? For me, it’s meaningless talking about solutions without knowing the problem.

2. Output over Outcome

Which of the following questions do you hear more often?

• Which features should we deliver next?
• Which impact do we want to generate?

From my experience, the first one is the most common. Most conversations happen around features, what to deliver, what not to, and so on. Unfortunately, this is a pitfall. When we focus on features, we miss the most critical part, the outcome.

All features are irrelevant until they can generate value for the end-users and business.

3. Roadmap over Goals

Let’s start this part by understanding what a roadmap is. For me, a roadmap is a time-based strategic plan that defines goals or desired outcomes. A meaningful roadmap provides guidance; teams know where to land. Therefore, on the way, they can make decisions on how to get there.

Roadmaps are vital to set focus, yet often misused. In environments where product management maturity is low, the roadmap becomes a set of features to deliver with a tight deadline. Also, to make matters worse, the goal is absent. Unfortunately, the Scrum Teams have no choice but become feature factories and rush to deliver what was promised.

I like what Maarten Dalmijn said about roadmaps: it defines the agility maturity of companies. Here is a piece of his post:

Delivering features doesn’t mean you are delivering value, just like telling a joke doesn’t mean people will laugh. It’s all about how customers receive your feature and if it helps them to meet their goals.

Maarten Dalmijn, Why roadmaps reflect the level of Agile inadequacy

4. Immortal Features

Let me ask you two questions:

• When was the last time you discontinued a feature?
• How often do you review the relevance of your live features?

If you struggle to answer any of these questions, it’s a sign of weak product management. Features are just a means to an end; the only thing that matters is to deliver value. If the feature doesn’t help with that, it should be discontinued. But why do teams struggle to remove features? Well, nobody likes the feeling of wasting something; putting a feature live requires effort and time. For me, the first loss is always the smallest.

When you identify a feature that doesn’t deliver value, ask yourself, what’s the benefit of leaving it in the product? What would happen if we keep? I can help you with that, maintenance, support, rework in the future. In short, you will eventually spend time on pointless features. So why not remove them and using your time where it generates value.

5. Stakeholders’ Wishes over User Feedback

What defines the product direction: wishes from business stakeholders or feedback from end-users? If wishes speak louder than feedback, you have a problem.

It’s hard to believe, but user feedback is often ignored. I’ve seen many Scrum Teams blindly working on products. Sprint in, sprint out, stakeholders get new features, the machine keeps running, but nobody evaluates whether that makes a positive change on end-users lives.

For me, something is massively wrong if users’ feedback doesn’t force us to adapt our directions. End-users are surprising; no matter what you think you know, users will always shock you. Over ten years of product management experience, I’ve never seen anything matching users’ needs directly. Inspection and adaption are always crucial to success.

6. Certainty over Assumptions

Overconfidence in product management leads to reckless practices. In product management, accepting our ignorance is vital to thrive. When companies are overconfident, they force teams to build products without validating with real users. The result is well known; companies waste money by doing something nobody needs.

Companies with solid product management skills know that there’s no certainty when building a product. Therefore, they strive to validate what they don’t know. The faster they can validate their assumptions, the easier they can create a relevant product.

I am the wisest man alive, for I know one thing, and that is that I know nothing.

Plato, The Republic

7. Two Drivers: Product Owner and Product Manager

What’s the difference between a Product Owner and a Product Manager? This is a question hanging around for years now. Like Marty Cagan and Melissa Perri, references in the Product Management world tried to answer this question. I will not add my five cents to this question, but I will share my perspective on weak product management.

For me, the title doesn’t matter, but a product should have only one person responsible from end to end. Adding more people increases complexity and creates silos. Confusion is the only possible result when responsibilities are shared between two people. For example, one person is responsible for finding the right thing to do, and another person responsible for implementing the thing right. This is a perfect recipe for disaster.

It’s indeed a lot of responsibility for a single person, but it’s better to carry a heavy burden than being trapped in a land of confusion. When product management maturity is low, companies solve complexity by adding more people into the game. In this case, shared responsibilities lead to a lack of commitment and watered-down results.

One bus, one driver.

What Is a Strong Product Management Scenario?

I’ve just shared with you what signs I look for to evaluate the product management level of a company. Now, let me summarize what the symptoms of solid product management are:

• Everything happens around problems instead of solutions. Until the problem is understood, solutions are not part of any conversations.
• The outcome is the focus. Teams have clarity on the impact they want to generate.
• Roadmaps define goals to pursue instead of features to deliver.
• Features are often removed from the product because they don’t deliver value.
• User Feedback has a strong influence on the product direction. If it’s not suitable for the user, it’s not right for the company.
• The company spends time evaluating what they don’t know, and then they are eager to get answers to those questions.
• One person is responsible from end to end. Sometimes the title is Product Owner, sometimes Product Manager. But both roles are never together.