What do Product Managers & Engineers Dislike about each other?

+ Differences between a Tech Product Manager & Product Manager

Product Managers & engineers have a famous love and hate relationship.

What Engineers dislike about Product Managers:

👉 Leading conversations with heavy business jargon & acronyms.

👉 Asking for an estimate but then mandating a shorter deadline because the "business demands it".

👉 Expecting bug-free builds, unit testing & scalable code while rushing sprints with unclear requirements.

👉 Resisting tradeoffs when slipping in a new user story at the back end of a sprint.

👉 Imposing a arbitrary deadline on a bug that's difficult to reproduce.

👉 Asking for an extensive feature & then pulling the plug mid-way without reason.

👉 Not including developers in cementing client commitments

👉 Not involving developers early on when drafting roadmaps & refining user stories.

👉 Signing up for a tight release without dev consent & expecting them to spend nights to achieve it.

👉 Taking all the credit when engineers pull off all-nighters to launch a feature.

👉 Burying micro-updates to a spec in an email, JIRA, Slack & Google Docs but expecting developers to implement each one of them.

👉 Not making an effort to understand tech debt.

👉 Thinking that asking developers to reverse-engineer something is perfectly equivalent to a detailed spec.

👉 Considering progress only to be = what's visible to them on the interface.

Of course, developers don't always make it easy for Product Managers either. The reverse equation is equally important to resolve.

What Product Managers dislike about Engineers:

👉 Promoting what's easier to implement rather than what's right for the customer.

👉 Talking about what "they" think should be built as opposed to empathizing with the customer's perspective.

👉 Not making enough effort towards reading the documentation & skipping finer details.

👉 Thinking of meetings as a burden as opposed to an opportunity to collaborate.

👉 Leaving bugs for the QA to identify & not committing to basic testing with variable inputs.

👉 Ignoring product copy & design aesthetics, thinking function > form.

👉 Failing to clarify or articulate key assumptions during estimations.

👉 Calling out problems with specs & then sitting at an arm's length from it until a solution is spoon-fed (little participation in collaboration on a solution).

👉 Raising concerns around technical debt & recommending code refactoring but not caring to explain it to the PM in depth.

👉 Not understanding that the customer doesn't care about the underlying technology.

---

---

What are the differences between a Technical Product Manager and a Product Manager?

Disclaimer: every company has it's own boundaries & definitions, so it will inevitably vary.

Let me use a housing analogy here where a PM is architecting a residential house.

[𝟭] 𝗔 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗿 𝗱𝗲𝗰𝗶𝗱𝗲𝘀 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝗵𝗼𝘂𝘀𝗲 𝘄𝗶𝗹𝗹 𝗹𝗼𝗼𝗸 𝗹𝗶𝗸𝗲 & 𝘄𝗵𝘆

A PM will understand the buying party's needs, sketch out the blueprint, decide the size/facade of the house, instruct on the number of rooms/living areas, decide on the facilities to install & imagine the overall experience of living in the spaces. They'll then collaborate with the builders to realize this vision.

[𝟮] 𝗔 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗣𝗠 𝗱𝗼𝗲𝘀 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗯𝘂𝘁 𝗮𝗹𝘀𝗼 𝗳𝗮𝗰𝗶𝗹𝗶𝘁𝗮𝘁𝗲𝘀 𝘁𝗵𝗲 𝗯𝘂𝗶𝗹𝗱𝗲𝗿𝘀 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲𝗶𝗿 𝗲𝘃𝗲𝗿𝘆𝗱𝗮𝘆 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀

A TPM will do pretty much the same: from understanding the needs to planning out the house design & drafting the function. However, they'll also take a keen interest in the materials being used, how fixtures are installed, the tradeoffs between one piping brand vs. another etc. They will also explain these decisions & tradeoffs to the buying party in layman terms.

Notice that I didn't say that TPMs "decide" the how. TPMs assist builders to help them in decision making but don't make them on their behalf.

Another difference that is often cited:
Technical PMs spend more time with engineers vs. typical product managers who spend more time with customers.

There may be some truth to this but great TPMs I've worked with find a balance between both. A TPM that’s too inward-focused will likely struggle in drafting a balanced roadmap.

But why even have this categorization?

Why would a Product Manager need a technical aptitude? Some companies believe that it would empower them to do a better job because:

• the domain they operate in requires familiarity with technical concepts e.g. APIs, Web services, tech stacks etc.

• it will help them navigate engineering conversations with more ease

• it will allow them to carry out better feasibility analysis

• it will enable them to conduct better user research because the audience they are serving are equally technical

Image Credit: Product School

Similarities?

A Technical Product Manager and Product Manager position aren’t wildly different by any means. Both roles have a similar core and thus several overlapping activities e.g.

• customer discovery

• product vision & strategy

• feature & solution design

• prioritization & roadmaps

• backlog management

• working with engineers, developers, QAs

• data analysis & metrics

• delivering management

• stakeholder management

Thus, the base differentiator is how involved the PM will be with technical matters - both with the engineering team on how the solution is implemented AND/OR the technicalities of the domain they operate in.

Variety of TPM Jobs

After reviewing several TPM JDs, I’ve also noticed that this degree of "technicality" required varies on a spectrum.

Sometimes, a "PM" job expects a tech aptitude but the company simply chooses not to use the "technical" prefix in the job title. Ex: PM jobs at Gitlab.

In other cases, the opposite happens where a job is labelled as “Technical” but the responsibilities don’t leap out as such.

For example, here’s an excerpt from a Technical Product Manager Job description from EA Sports:

Few companies also conflate an Engineer Manager position with a Technical Product Manager by making the latter responsible for technical delivery, resource allocation and architectural design.

Here’s an excerpt for a Technical PM job from Randstad:

• Provide the required hands-on SDLC and project management cross-functional coordination, and inter/intra team communications to deliver outstanding program outcomes

• Work closely with Devs, QA, Product owners and other development teams to get high-quality products and features through the software project lifecycle (build, test and release on time)

• Manage project schedules, identify possible issues and clearly communicate them to project stakeholders

• Take responsibility for release schedules and milestones, keeping up a high velocity in a fast-paced environment

And here are some of the other typical Technical Product Manager categories I’ve seen:

Conversational TPM (most common):

This role requires the TPM to be comfortable in:

• understanding/communicating technical concepts

• conducting research requiring some technical understanding e.g. research APIs

• easily conversing with engineers & helping with architecture

• explaining these technicalities to stakeholders in simple terms

For example, here’s an excerpt from a Amazon Robotics Job description:

“We're searching for an innovative and motivated Technical Product Manager who will manage the multi-team development and operational delivery of a large portfolio of technical projects by understanding business requirements, managing changes, removing roadblocks, and communicating broadly with multiple functional groups and stakeholders.”

Domain-specific TPM

This role requires the TPM to understand industry-specific intricacies, jargon and applications of the product. It needs a deeper know-how of the domain to be able to go about prioritization, specs & vision docs.

A good example of this would be a technical product manager at Twilio.

For example, here’s an excerpt from GitLab’s Product Manager playbook for 100 days. You can see references to some technical tools & processes that may require some prior experience:

Knee-deep TPM

These are very rare but you’ll find such TPMs participating in architectural decisions & even scripting to extract analytics to make better product decisions. In this case, the expectation is to have deep familiarity with microservice architecture, backend services, APIs and migration tools.

Ex: TPM at Palantir Technologies.

Conclusion

Technical Product Management may sound ideal for people with technical backdrops but the reality is that “technicality” requirement comes in varying degrees.

My advice? Always go beyond the JD to understand what the job really entails.