You don’t need Product Managers. There. I said it.

If you work for a company that builds primarily consumer software¹, there are, hopefully, three groups of humans who believe they are accountable for the product. They are:

• Engineering. They build the product.
• Design. No, they build the product.
• Product Management. No, really… they build the product.

Do you see the issue? You have three different groups with different skill sets, each of whom firmly believes their decisions are the decisions that allow the product to exist. They are each directionally correct. You can build a good product in a perfect world where each constituency is equally capable of doing its job. This includes a complicated process where these constituencies capably disagree, debate, and learn from their differences.

Problem is, the world is not perfect, and you need to build great product. Now.

Disclaimers: For every hypothetical engineer, designer, and product manager that I’m about to implicate as incompetent, there is an equal number who are not just capable, they are an absolute inspiration. There are additional roles that I don’t discuss that are essential to your burgeoning product company. Quality, marketing, sales, support. They are essential, but that’s a different article.

Gosh, I want to describe all the interesting failing configurations of Engineering, Design, and Product Management that I’ve personally observed sucking the life out of a good product, but let’s start with the greatest hits:

Scenario #1: Product Managers as CEO. In this variant, your Product Managers think they are the CEO of the Product. If you think about this configuration as voting rights, the Product Managers would suggest — trying to be helpful and fair — that they’ll serve a tie-breaking vote when we can’t agree.

They honestly claim this voting structure not because they want all the power; they want to cast the tie-breaking vote when there is gridlock occasionally. And, ya’know, sometimes someone needs to decide, ya’know, just to keep moving things along.

Bullshit. They do want the power. These power structures are counter to great product design and development. They amplify individual opinions over the hard work of building great decisions. Those painful impasses where no one can agree? Those are hard-earned decisions that will make your product great. Yes, they are hard. Yes, it’ll feel like you’re wasting precious time swirling around a decision, but this is critical work. This is when you discover a feature’s truth, value, and essence.

Product Managers CEOs with the tie-breaking vote will eventually make unilateral decisions with insufficient cross-functional debate because they believe they are “moving us along”. They will do this precisely when you and your team could learn the most. They believe that because the title is Product Manager, they are the Product.

In my experience, the attributes I value in a good Product Manager are:

• Understand the current feature set deeply and how new features complement and enhance the future product.
• Can speak for the customer because they’ve taken the time to understand the customer deeply.
• Know the critical decisions that were made that resulted in the current state of the product. They know what is broken and how it became so.
• Are capable of making reasoned decisions and explaining their thinking to anyone.
• Are curious and willing to learn about anything relevant to the product whether it’s their domain or not.

Scenario #2: Uncompromising Designers. If you want to trigger a designer, here’s a simple approach. Ask them, “Why are we spending so much time on this inconsequential color, typeface, layout, or other trivial thing?” At this moment, they hear three thoughts at the same time:

1. “This person thinks my work is inconsequential.”
2. “This person doesn’t understand that small bits of work elegantly and thoughtfully combined is the big thing elegantly working.”
3. “This person believes that because the decision appears easy to make, it does not require work.”

Designers hear some small version of this critique a lot during their careers. When you combine this with the fact that Design teams are small relative to Engineering, they must choose their product design battles carefully. Often, after years of losing these battles to Engineers who belittle their craft as inconsequential or Product Managers who state product ideas as design ideas, these designers transform into the Uncompromising Designer.

These humans (or teams) politically move to an independent metaphoric island where design is produced. They then put this design on a little ship that travels to the mainland, where Engineering and Product Managers live. Designs are reviewed, commented on, and returned via the same little ship where wait for it, all feedback is ignored with the unspoken rationale, “They don’t understand what we’re trying to achieve. They aren’t on the island.” (Note: No one is ever invited to the island.)

In this nightmare scenario, Product Managers and Engineers are picking and choosing from the designs (without the Designers in the room — I’m not kidding — it’s terrifyingly common) and implementing random features based on an uninformed feel. Customers who see this haphazardly designed product think, “It looks kind’a like what I want to do, but I struggle to understand the product. I click… this?”

This is most software, I’m afraid.

Good designers I’ve worked with:

• Understand that how a user feels about a product dramatically influences their use.
• Are comfortable in the depth of their craft. They can deftly explain how their choices of layout, color, and typography affect the approachability of the product.
• Will defer to their professional peers when the time is right after everyone’s been hard and if the winning argument is sound.
• Obsesses about the details because the details work together to define how the user feels about the product.
• Are curious. Willing to learn. Doesn’t matter if it isn’t their area of expertise.

Scenario #3: Disconnected Engineers. Our final failure case is a reaction to our prior two scenarios, and this is the primary scenario I want to discuss because, as an engineer, it’s the one I want to fix.

The Disconnected Engineer has spent the last six years of her life working to become a good engineer. This started in high school when she first discovered Python and saw computers as a tool for bringing ideas to life. Four years in college, becoming a computer scientist along with two internships, and now she’s hired into her dream: a full-time software engineer. A company she respects.

Problem is: Product Management thinks they’re the CEO, are drunk with power, and are adept at tossing impressively sounded bulleted lists over the fence to Design and Engineering. These lists have no context and littered with meaningless MBA-speak designed to sound official but do nothing to explain a coherent product strategy.

Meanwhile, over on the island, Design is musing about whatever the hell because they know those bullets from Product Management are whatever occurred in their last three meetings and have no strategy or substance. Design has heard we’re going to do Feature X and has produced stunning designs in a vacuum that will be delivered whenever the next ship leaves the island. Our engineer wants to engage with this design and discuss it, but Design is on that island far, far away.

Extend this passive-aggressive product-hostile situation over a few years, and our bright and eager Engineer becomes the Disconnected Engineer. The human accountable for building the product with their hands exists as a semi-motivated engineer who is grabbing bullets as they come over the fence and combining them with misaligned and misinformed design from the island, which results in strangely constructed features that… work. I mean, they look like features, but when I asked this engineer why she chose this approach, she said the thing that crushed my soul, “They told me to do it this way.”

Unacceptable.

The Product Engineer

I am not the first person to slap these two words together, but I want to introduce a concept of a different type of engineer: the Product Engineer.

As a starting framework, a Product Engineer:

• Has a deep knowledge of how the product is built. If the product is not yet built, they can scribble how it should work on a whiteboard.
• Able to explain to anyone with the motivation to understand how each product feature works. They are likely more knowledgeable regarding certain feature sets in larger products, but their understanding of the complete product is vast.
• Actively use the product and report bugs when they happen upon them.

Do you know what bad product managers do to engineers (and designers)? They suck the air out of accountability. Their existence creates the impression that someone other than the human responsible for building the product with their hands is better at designing and building products. That someone else has a plan.

What?

Bad product managers are an active hindrance to developing software. This is the reason I’m picking on them in this piece. With no product management function, someone else must do the work, which organically falls on engineering and design. My definition of Product Engineer expands to include all the responsibilities of the Product Manager (and a little bit of Design).

A Product Engineer:

• Uses the product every day and reports bugs aggressively when they find them.
• Intimately knows how the products work and can explain any feature or inner workings to anyone. When they find a gap in their knowledge, they fill it.
• Have a deep understanding of how users perceive their features and how their changes would affect their perception. They can wear the customer mindset.
• Remember the debates around the most complex decisions and why we chose this path.
• Have living breathing code in the product — right now.
• Can effectively argue with anyone on the team regarding the product. Will defer to their team members when the argument is sound, but they will continue to argue until there is product clarity.
• Communicates well in every direction because they’ve developed professional relationships in all those directions.
• Are aggressively curious and willing to learn anything relevant to the design and development of the product, especially when it’s outside of their area of expertise.

A Product Engineer is accountable for the product.

Accountability is not responsibility. Accountability means you are required or expected to justify your actions and decisions. You are required to give an account to share the story of how we decided to build this feature, why we chose it over many other features, and how we iterated on subtle design tweaks for months to deliver what we believe is the best possible version.

Somebody Else’s Job

Any number of organizational configurations involving engineers, product managers, and designers can produce successful products. Over the past three decades, my observation is that the companies that have let the builders — the engineers and the designers — own significant parts of the role of Product Manager produce stronger products.

You want the humans building the product to have an equal voice in product decisions. You want the hard decisions to painfully earn their resolution through long hours of informed humans staring at the problem from every angle. You want humans who build.

And you don’t need Product Managers.