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.