The 7 deadly sins of Product Management

I’ve had many coffee chats where prospective product managers obsess over the hard qualifications they think they need for the job. Technical skills, design tools, an MBA, scrum certifications, and so on.

The core of product management is very simple:
Maximize your business value by making decisions about what to build and when.

Put into a single sentence, it doesn’t seem like it should be that hard. You don’t need any special degrees or tools to understand it. You know exactly what you have to do… in theory.

The hard part of product management is understanding the soft, subtle ways that this core idea can be corrupted when applied with a real team, product, and timeline.

I’ve called these the “7 deadly sins” because they share something in common with their religious namesake… they are easy to give in to, especially in times of stress. You might not even realize that you’re susceptible to them until it’s too late. But unchecked, they will skew your product compass.

1. Focusing on the loudest voice in the room

As a product manager, you’ll often be confronted with loud voices demanding your immediate attention. These could be:

• Empathetic customer support agents, advocating for an issue they’ve observed
• Passionate teammates, sharing a persuasive anecdote
• High-level executives, giving feedback on a project for the first time

This is where data and context are critical. Is the loudest voice really advocating for work that advances your team’s goals? Does the loudest voice have the context they need to help steer your decision-making?

The top ticket for customer support may be a niche problem if your customers don’t contact support often. Your coworker may really want to see a marketing campaign executed because of a personal connection to the content, not because it’s the most important campaign you could be doing. A C-suite executive may not realize how much weight an off-the-cuff statement can carry, and may not have intended to derail your progress.

In each of these cases, it’s important to evaluate the feedback you’re receiving against your goals and verify the intent. The loudest voice in the room often points to pain that needs to be resolved somewhere in the organization (ex: better support protocols, more opportunities for creative copy, more communication with the sales team)… but doesn’t always highlight the most effective solution.

2. Focusing on the future in too much detail

Silicon Valley paints PMs as “visionaries” and “mini-CEOs” of their products… which is sometimes true. Teams do need a directional vision to build toward, and future intent often changes architectural or design decisions made in the short term. But this is a narrow slice of the overall job of a PM. It’s likely that your team needs more specific guidance on the next few months, and high level guidance on the next few years. Too much can change in your product or market for the detailed three year plan you’re making today to matter. Today, your team usually needs you to help resolve some ambiguity in the product requirements, or de-duplicate work with another team, or push a vendor for better pricing. It’s good to reserve a few hours on a regular cadence to reflect on the big picture — but it’s critical to support the team’s present needs.

3. Focusing too much on the present

The inverse is also true. It’s easy to get lost in the weeds of JIRA tickets and plod onward toward building something reactive rather than strategic. If your calendar is crawling with 30 minute syncs and fire drills, try carving out 2–3 hours a few weeks ahead of time to focus on the near-term future of the product. Make a meeting with yourself with a start and end time, and a conference room if you’re in an office space. The only way to get clarity on longer term strategy is time to think (which often unveils the need for research or supporting data, which often needs more time). You will likely need to get out of the building and talk to real users or stakeholders to validate some of your ideas.

4. Not getting the (relevant) details

Product managers are often spread thin, and are tracking multiple different sorts of tasks across interdisciplinary teams. For example, a mobile release might include dev work, compliance work, design work, updates to app store notes and screenshots. With strong interdisciplinary partners, it’s tempting to stay out of the details.

But the details are exactly where things can go wrong — if the copy in a marketing email doesn’t introduce a new feature in the right way, or to the right audience, that could damage uptake metrics. It’s often the details of the last dev task, and how it gets handed off to another team, that cause delay. PMs don’t have to know everything, but they have to develop an intuitive sense for what tasks are critical path for success metrics, and drill down there.

5. Doing instead of communicating

When you’re responsible for the outcome, and you know what you want done, it’s tempting to do rather than communicate your intent to your cross-functional partners. This is especially tempting if you have a certain type of background before becoming a PM — if you have experience writing code, or writing copy, or making wireframes, how could it hurt to hasten the project along?

Overstepping can damage your relationships with your cross-functional partners and come across as a lack of trust rather than a desire to get things done. Before stepping in to do individual contributor work, ask yourself if you’ve communicated the work, the why, and the timeline to your team member. An open conversation can help reveal whether there is an opportunity for you to step in without affecting your team member’s sense of ownership.

6. Communicating milestones rather than the business value they represent

When you’ve committed to delivering something, it’s easy to get focused on the thing. We’re working to deliver this mobile app or this feature, rather than the value those deliverables provide. It’s critical for the cross-functional team to understand the why behind what you’re delivering — it was requested by 30% of mobile users, or was a contracting requirement for a key account — so that ongoing trade-off discussions or timeline adjustments can be made in light of the larger business goal rather an isolated deliverable.

7. Missing an opportunity to experiment

When you’re running as fast as you can, details like “which user group gets to see this launch” can escape you — but they are critical for building credibility in a data-driven organization. In an existing product, if you don’t launch enhancements as an intentional experiment, it will be extremely difficult to attribute metric improvements to your work. There are other product and feature launches, new clients or users, seasonality — your product probably doesn’t exist in a vacuum. Your team will invest in the initial build, and expect (data-driven) support from you for continued growth and investment.

After years on the job, I still catch myself being tempted by these avenues to easier product decisions. With dozens of decisions to make per day, and little time to make them, it’s easy to allow subtle biases to change your roadmap. I use this framework to “check myself” and keep the team on track with decisions aligned with the business.