How Much Tech Does a PM Need to Know? From Engineers to Designers: How Different Backgrounds Can Thrive as PMs

As a former software engineer turned product manager, and someone who has worked with PMs from diverse backgrounds, I’ve noticed something interesting:
Everyone asks, "How much tech should a PM know?" but rarely, "Is my background a good fit for PM?"

Rather than obsessing over technical depth, perhaps a better question is:
What strengths do people from different backgrounds (design, QA, sales...) bring to the PM role, and what should they watch out for?

But before diving in, let's first define what PMs actually do.

---

Two Main PM Roles: Product vs. Project

In most companies, PMs generally fall into two categories:

Product Manager

• Defines product vision, direction, and goals
• Writes specs, defines requirements and acceptance criteria
• KPIs often focus on product performance: retention, conversion, business outcomes

Project Manager

• Ensures projects are delivered on time
• Coordinates across departments, syncs updates and progress
• Manages risk, allocates resources, controls schedules

While many companies don’t draw a strict line between the two (and I personally don’t recommend doing so rigidly), this framework helps us understand which background might suit each role better.
This article focuses primarily on Product Managers.

---

Strengths and Watchouts by Background

Every background comes with natural strengths — and transition challenges.
The following "watchouts" aren't flaws, but common hurdles you’ll encounter and grow through. Becoming aware of them is the first step toward mastery.

PMs from Engineering Backgrounds

Strengths:

• Quickly understand system architecture and estimate dev effort
• Can deeply engage with engineers on solutions
• Great fit for technical products like APIs or developer tools — often being the user themselves

Watch out for:

• Tendency to get lost in implementation details and lose sight of user or market needs
• Pursuing the perfect architecture can delay validation and time-to-market

→ Tip: Start lean, validate fast, then scale. Tech excellence should support the product — not replace market fit.

Scenario:
An engineer-turned-PM spends weeks designing a clean microservice architecture before launching a dashboard. But later realizes a simpler solution would have let the team test the market much sooner and adjust accordingly.

PMs from Design Backgrounds

Strengths:

• Strong user empathy and intuitive understanding of UX
• Advocates for thoughtful flows and delightful product experiences

Watch out for:

• May underestimate implementation cost, leading to over-engineered details
• Can overly compromise when facing technical pushback, even when their design had merit

→ Tip: Proactively engage with engineers to clarify constraints and find balanced solutions.

Scenario:
A design-focused PM spends two weeks perfecting onboarding transitions and animations. Later learns those touches had minimal impact on conversion, while the core flow needed more attention. A reminder: polish ≠ value.

PMs from QA Backgrounds

Strengths:

• Naturally detail-oriented and skilled at identifying edge cases
• Excellent at defining clear quality standards and testable requirements

Watch out for:

• Can create overly long, complex specs that dilute team focus
• May prioritize completeness over clarity and delivery speed

→ Tip: Start from core user stories, then layer in exceptions — not the other way around.

Scenario:
A QA-turned-PM writes a 50-page requirements doc covering every possible condition. Engineers feel overwhelmed and lose sight of the main goal. Later, switching to concise user stories with supplementary notes helped everyone align faster.

PMs from Sales Backgrounds

Strengths:

• Great market sensitivity and direct knowledge of customer pain points
• Comfortable navigating internal business priorities and stakeholder expectations

Watch out for:

• Risk of over-prioritizing one client’s feature request, leading to technical debt and bloated products
• May overlook product consistency or maintainability

→ Tip: Always ask, “Do multiple customers need this?” and work with tech/design to find reusable patterns.

Scenario:
A sales-driven PM fast-tracks a custom feature to close a deal. Months later, it’s barely used and adds complexity to the codebase. The lesson: explore the underlying need before building the surface request.

---

The Essence of PM: Becoming a True T-Shaped Contributor

From the examples above, it’s clear that PMs need to juggle:

• Technical feasibility and architecture
• User experience and logical coherence
• Customer needs and business value
• Go-to-market and positioning

It’s rare for one person to master them all — and that’s okay.

What matters most is that you:

• Have a solid domain you’re confident in — your vertical depth
• Are curious and open enough to learn the rest — your horizontal breadth

That’s the essence of a T-shaped person — and a great PM.

This is why people say “PMs are like product CEOs.”
But in reality, PMs don’t have formal authority. They lead through influence and collaboration. Your expertise gives you credibility, and your cross-domain understanding allows you to work effectively with others.

---

Keep Growing: Embrace Discomfort, Stay Curious

So, can anyone become a great PM?
Yes — if you're willing to keep learning beyond your comfort zone.

Try these to stretch yourself:

• Try on different hats:
  Before handing things off, run your own test cases like a QA, or sit in a customer demo like a sales rep. You’ll learn where your product really shines — or breaks.

• Read outside your field:
  Engineers can read business strategy books; designers can explore backend logic basics. You don’t need to master everything, but exposure leads to faster growth.

• Ask questions — a lot:
  Talk to teammates from other roles. Ask: “How do you usually approach this?” or “What’s challenging about your process?” This accelerates your learning and builds trust.

---

Quick Self-Check: Is PM Right for You?

If you’re considering a transition to product management, ask yourself:

1. What’s your current area of strength?
   → That’s your foundation for initial credibility and influence.

2. Are you willing to learn new skills outside your domain?
   → PMs are cross-functional by nature.

3. Can you make decisions in uncertain, messy situations?
   → Clarity is rare — PMs often work in ambiguity.

4. When things go wrong, do you step up or deflect?
   → PMs don’t always have power, but they’re still responsible.

5. Do you enjoy continuous learning?
   → Tech, business, design, comms — it never ends.

If you answered “yes” to most of these, you’ve already got the mindset of a great PM.

---

Final Thoughts: Being a PM Is Like Living a Full Life

People say a PM is like a product’s CEO — but to me,
Being a PM is more like living a full, intentional life.

You start with a vision, limited time, and incomplete resources.
No one tells you exactly what to learn or how to proceed.
You make choices, face trade-offs, take ownership.

That’s what makes this role beautiful — and hard.

You don’t need to know everything.
But you do need to take responsibility, stay open, and keep growing.

When you do, you’ll start seeing connections others miss.
You’ll bring people together.
And you’ll build things that truly matter.

---

In the next article, I’ll talk about the Project Manager role — and why I believe folks from engineering or QA backgrounds are especially suited to it. Stay tuned.