Scrolls
9 min read
On this page

PM vs Engineer Mindset

The best products come from teams where PMs understand engineering and engineers understand product. The worst products come from teams where PMs throw requirements over a wall and engineers build exactly what was asked for, no more, no less. The gap between these two mindsets is real, but it is bridgeable, and bridging it is one of the highest-leverage things either side can do.

This is written for both audiences. If you are a PM, the engineering sections will help you understand your counterparts. If you are an engineer, the PM sections will help you understand why your PM keeps asking "but why."

How Engineers Think

Engineers think in systems and constraints. When you describe a feature, an engineer's brain immediately starts decomposing it into components, data flows, edge cases, and failure modes. This is not stubbornness or negativity. It is how systems thinking works.

Engineer hears: "Let's add a collaborative editing feature."

Engineer thinks:
  - Conflict resolution: what happens when two users edit the same field?
  - Real-time sync: WebSockets? Polling? CRDTs?
  - Data model: do we version every edit? How do we store history?
  - Performance: what's the latency budget for sync?
  - Scale: how many concurrent editors do we need to support?
  - Failure modes: what happens when someone loses connectivity?
  - Migration: how does this affect existing documents?

This cascade happens automatically. Engineers are trained to find the hard parts, because the hard parts are where projects die. When an engineer responds to a feature pitch with "that's going to be really complicated," they are not saying no. They are saying "here is the complexity you may not have accounted for."

Google Docs did not become great collaborative software because someone said "make it collaborative." It became great because engineers deeply understood the distributed systems problem of real-time editing and built operational transforms (later CRDTs) to solve it.

How PMs Think

PMs think in users and outcomes. When confronted with a technical challenge, a PM's brain asks whether the challenge matters. Not every technical problem needs to be solved perfectly. Some can be approximated. Some can be deferred. Some turn out not to be problems at all once you understand what users actually need.

PM hears: "Supporting concurrent editing requires CRDTs, which
          will take 3 months to implement properly."

PM thinks:
  - How many users actually edit simultaneously? Check the data.
  - Could we start with locking (one editor at a time) and ship in 2 weeks?
  - What's the user's actual job-to-be-done here?
  - Is "real-time collaboration" the feature, or is "shared access" the feature?
  - What does the competitive landscape look like? Do we need parity?
  - Can we ship a simpler version, learn, and then invest in the hard version?

This is not laziness or cutting corners. It is resource allocation. PMs are constantly weighing the cost of building something against the value it creates. A technically inferior solution that ships in two weeks and solves 80% of the problem is often better than a technically elegant solution that ships in three months.

Slack's early approach to search was famously mediocre. It did not have full-text search across all message history at launch. The PM decision was deliberate: search was important, but getting teams to adopt Slack and send messages was more important. They shipped basic search, learned what users actually searched for, and improved it incrementally.

Where the Mindsets Clash

The friction points are predictable.

Scope Conversations

Engineers want to understand the full scope before committing. PMs want to ship something quickly and iterate. Both instincts are correct in different contexts.

The clash:
  PM: "Let's ship the basic version in two weeks."
  Engineer: "But what about edge case X, Y, and Z?"
  PM: "We'll handle those later."
  Engineer: "If we don't handle them now, we'll have to refactor."
  PM: "We might not need to handle them at all."

The resolution is not for one side to win. It is for both sides to get specific. Which edge cases are genuinely dangerous (data loss, security, corruption)? Which are unlikely or low-impact? Which can be handled with an error message instead of custom logic? When Airbnb built instant booking, engineers flagged dozens of edge cases around host availability, time zones, and cancellation policies. The PM and engineering lead triaged them together, shipping with explicit handling for the dangerous ones and graceful degradation for the rest.

Technical Debt

Engineers see technical debt as a real cost with compounding interest. PMs often see it as an abstraction that does not directly serve users. Both are partially right.

Engineer perspective:
  "This code is getting harder to change. Every new feature takes
   longer because we're working around the same architectural problems.
   We need to refactor before adding anything else."

PM perspective:
  "We have a quarterly revenue target and three features promised to
   enterprise customers. I understand the code is messy, but 'refactor
   the backend' is not something I can put on a roadmap for leadership."

The bridge: frame technical debt in product terms. "If we don't address the payment service architecture, adding multi-currency support (which 40% of prospects ask about) will take 4 months instead of 6 weeks." Now the PM has something to work with.

"Simple" Features

PMs sometimes describe features as "simple" or "just a small change." Engineers hear this as a dismissal of complexity. It is one of the fastest ways to destroy trust.

Things PMs say that make engineers wince:
  - "Can't we just add a toggle?"
  - "It's basically the same as the existing feature, just for groups."
  - "This should be straightforward."
  - "How hard can it be?"

If you are a PM, never estimate engineering effort. Describe the problem and the desired outcome. Let the engineer estimate the effort. If the estimate surprises you, ask questions to understand why. You will learn something.

How to Bridge the Gap

For PMs: Learn Enough Engineering

You do not need to code. You need to understand systems at a conceptual level.

What PMs should understand:
  - How APIs work (request/response, REST basics, rate limiting)
  - What a database does and why schema changes are expensive
  - The difference between client-side and server-side logic
  - What caching is and why it introduces consistency problems
  - Why distributed systems are harder than single-server systems
  - What "deployment" means and why rollbacks matter
  - The concept of technical debt and why it compounds

Stripe's PMs are expected to understand APIs deeply because their product is an API. But even at a consumer product company, a PM who understands that "adding a field to the user profile" might require a database migration, a cache invalidation strategy, and backward-compatible API changes will make better scoping decisions.

For Engineers: Learn Enough Product

You do not need to become a PM. You need to understand why decisions are made the way they are.

What engineers should understand:
  - How the business makes money
  - Who the target users are and what problems they have
  - How features are prioritized (the trade-offs, not just the output)
  - Why shipping speed matters (competitive pressure, learning velocity)
  - What metrics the team is trying to move and why
  - How stakeholder pressure works (sales commitments, investor expectations)
  - Why "the right technical solution" sometimes loses to "the faster solution"

At Spotify, engineers on the Discover Weekly team were deeply involved in understanding user listening behavior. They did not just implement recommendation algorithms. They understood why users abandoned playlists, what "freshness" meant to different listener types, and how the feature connected to retention metrics. This made them dramatically more effective because they could make good micro-decisions without waiting for PM input.

Shared Practices That Work

The best PM-engineer relationships have a few things in common.

Joint discovery sessions. Bring engineers to user interviews. Not every interview, but enough that they hear users describe problems in their own words. Engineers who hear a user say "I spend 20 minutes every morning copying data between spreadsheets" will build a better import feature than engineers who read a user story.

Technical design reviews with PM present. Not so the PM can weigh in on architecture, but so they can hear the trade-offs engineers are making and provide product context. "We're choosing approach A because it's simpler, but it means we can't support feature Y later." The PM might say "we'll never need feature Y" or "actually, feature Y is critical for Q3."

Shared metrics dashboards. When PM and engineering look at the same numbers, conversations get more productive. Instead of "users don't like this feature," it becomes "the completion rate for this flow dropped 15% after the last release."

Regular Pairing Sessions

Dedicated time where PM and engineer work through a problem together. Not a meeting. Not a review. An actual working session where the PM shares user context and the engineer explores technical approaches in real time. These sessions build mutual understanding faster than any document.

At Airbnb, PMs and engineers regularly pair on data analysis. The PM brings the question ("why did bookings drop in this segment?") and the engineer brings the query skills. Both leave with a shared understanding of the problem and the data behind it.

Shared On-Call Rotation Exposure

Some companies have PMs shadow engineering on-call rotations periodically. Not to fix incidents, but to understand what breaks, how it affects users, and what the real operational cost of certain product decisions is. A PM who has seen a database migration go wrong at 2 AM has a very different perspective on "just add a new field" than one who has not.

Real-World Examples

Notion's Block Architecture

Notion's engineers built a block-based architecture that treats every piece of content as a composable unit. This was an engineering decision with massive product implications. The PM understood that "flexibility" was the core value proposition and worked with engineering to ensure the block model supported it. The engineer understood that users wanted to remix content, not just write documents. Neither side could have made this product alone.

Figma's Multiplayer

Figma's real-time multiplayer was an engineering bet that the PM championed because user research showed designers were spending more time on version control and handoff than on actual design. The engineer (Evan Wallace, who was also the CEO) built a custom rendering engine in WebAssembly because existing approaches could not handle the performance requirements. The product insight ("designers need to work together in real-time") and the technical insight ("we need a browser-based renderer that's as fast as native") were both essential.

Linear's Opinionated Design

Linear is a product built by engineers who deeply understood the PM perspective. They made deliberate product decisions that reflect both mindsets: keyboard-first navigation (engineer mindset: speed), opinionated workflows that reduce configuration (PM mindset: reduce decision fatigue for users), and performance as a feature (both mindsets: respect the user's time). The founding team's ability to hold both perspectives simultaneously is why Linear feels different from tools built by pure PMs or pure engineers.

The Conversation Template

When PM-engineer conversations get stuck, a simple template can unstick them.

PM starts with:
  "Here's the problem we're trying to solve: [problem].
   The users affected are: [who].
   Success looks like: [metric].
   I'm thinking about [approach], but I'm open to alternatives."

Engineer responds with:
  "Here's what I see technically: [constraints, risks, options].
   Option A takes [time] and gives us [trade-offs].
   Option B takes [time] and gives us [trade-offs].
   My recommendation is [option] because [reason]."

Together they decide:
  "We'll go with [option] because [shared reasoning].
   We're accepting [trade-off] because [product rationale].
   We'll revisit if [condition changes]."

This template works because it starts with the problem (PM's domain), moves to technical options (engineer's domain), and ends with a shared decision. Neither side dictates. Both contribute.

Common Pitfalls

  • PMs treating engineers as implementors. If you hand engineers a fully specified solution and say "build this," you are wasting half their brain. Engineers often see simpler, better solutions to the same problem.
  • Engineers ignoring business context. Building the technically perfect solution that ships three months late and misses the market window is not good engineering. It is engineering without product awareness.
  • Lack of shared vocabulary. If the PM does not understand what "latency" means and the engineer does not understand what "conversion rate" means, every conversation will be slower than it needs to be.
  • Proxy wars over tools and process. Arguments about Jira workflows, ticket formats, and estimation methods are usually symptoms of a trust problem, not a process problem.
  • Assuming the other side is not thinking. PMs who think engineers are just objecting to everything. Engineers who think PMs are just making things up. Both sides are doing real, difficult intellectual work. Assume good faith.

Key Takeaways

Engineers think in systems and constraints. PMs think in users and outcomes. The friction between these mindsets is productive when both sides engage with curiosity rather than defensiveness. PMs should learn enough engineering to understand constraints and trade-offs. Engineers should learn enough product to understand why decisions are made. The best products emerge when both sides are involved in discovery, scoping, and trade-off decisions together. Never call a feature "simple" if you are not the one building it.