The Best Engineering Leaders I Work With Think Like Product Managers

[product_david]

I’ve been in product management for 12 years across Google, Airbnb, and now a Series B fintech startup. I’ve worked with dozens of engineering leaders at every level - from team leads to CTOs.

The partnerships that actually work - where we build great products fast - have a common pattern: the engineering leaders think like product managers.

Not that they do product management. But they share a fundamental orientation toward outcomes, users, and business value rather than technical solutions.

The Divide I Keep Seeing

Engineering leaders I struggle to work with focus our conversations on:

• Technical architecture and implementation details
• “What are the requirements?”
• “How long will this take?”
• Technology choices and frameworks
• Why this is technically hard/interesting/challenging

Engineering leaders I love working with focus our conversations on:

• What problem are we solving and for whom?
• Why is this the right problem to tackle now?
• What’s the business impact we’re trying to drive?
• What tradeoffs exist between approaches?
• What are we not doing because we’re doing this?

See the difference? The second group is asking product questions, not technical questions.

A Recent Example That Made This Clear

Last month we were planning a major initiative: building a real-time fraud detection system for our fintech platform.

With a technically-focused engineering leader, the conversation would go:

Me: “We need real-time fraud detection”
Eng: “What’s the technical spec? What’s the SLA? What frameworks are we using?”
Me: “Um, I thought you’d help define that based on what’s possible”
Eng: “Just give me the requirements and I’ll estimate it”

This is transactional. I toss requirements over the wall, engineering estimates and builds. We’re not actually collaborating.

With a product-thinking engineering leader (in this case, my actual engineering director), it went:

Me: “I’m thinking about real-time fraud detection as a Q2 priority”
Eng: “Interesting. What’s driving that? What problem are we seeing?”
Me: “We’re losing about M annually to fraud, and our current batch detection catches it too late”
Eng: “Got it. So the goal is reducing fraud losses. What’s the target - 50% reduction? 80%? Complete elimination?”
Me: “Realistically, if we could cut losses in half that’d be huge ROI”
Eng: “Okay, so maybe the question isn’t ‘real-time detection’ but ‘fast enough detection to prevent most fraud.’ Real-time might be over-engineering. What if we could detect within 5 minutes? Would that achieve 80% of the value?”

This question completely reframed our roadmap.

Why This Changed Everything

By questioning the what and engaging with the why, the engineering leader:

1. Clarified the actual goal (reduce fraud losses by 50%) vs the assumed solution (real-time detection)
2. Opened up solution space we hadn’t considered (5-minute detection vs true real-time)
3. Potentially saved us months of over-engineering
4. Shifted conversation from “how to build what product wants” to “what should we actually build”

We ended up building a “near-real-time” system that achieves 85% fraud reduction at 1/3 the complexity and cost of true real-time. Shipped 6 weeks faster than original plan.

That’s the strategic value of engineering leaders who think about outcomes, not just implementation.

The Pattern: Challenging Product Assumptions

The best engineering leaders I work with regularly push back on my product ideas - not because they don’t want to build things, but because they’re thinking about outcomes.

Examples:

Scenario 1:
Me: “Users want dark mode, let’s add it”
Eng Leader: “What’s the user research saying? Is this a requested feature or a nice-to-have? What’s the opportunity cost vs finishing the payment flow redesign?”
→ Realization: 50 users mentioned dark mode; 500 are abandoning during payment. We deprioritized dark mode.

Scenario 2:
Me: “We need to support SSO with all major providers”
Eng Leader: “What’s driving enterprise adoption - is it SSO variety or just having any SSO? Could we ship with Okta and Google first, see if that unblocks sales, then add others based on demand?”
→ Result: Shipped with 2 providers in 3 weeks instead of 6 providers in 10 weeks, closed 3 enterprise deals immediately.

Scenario 3:
Me: “Let’s build a native mobile app”
Eng Leader: “What user needs does native solve that progressive web app doesn’t? What’s the actual usage pattern - are users accessing this daily or weekly? What’s the maintenance cost of native across platforms?”
→ Discovery: Most usage is weekly, on desktop. We built PWA instead, invested saved engineering time in improving core workflow.

In each case, the engineering leader helped me make better product decisions by questioning assumptions and focusing on outcomes.

The Shift from Feature Factory to Outcome-Driven

When engineering focuses on “what are the requirements,” you get a feature factory. Product defines features, engineering builds them, nobody questions if they’re the right features.

When engineering engages with “what problem are we solving,” you get outcome-driven product development. Product and engineering collaborate to find the best solution.

This is only possible when engineering leaders:

• Understand the business model
• Care about user outcomes
• Think in terms of impact, not output
• Feel ownership over product success, not just technical delivery

The AI Connection

With AI handling more implementation, engineering’s strategic value is shifting toward this product-oriented thinking.

If all engineering brings is “tell us what to build and we’ll build it efficiently,” that’s increasingly commoditized. AI-assisted engineering teams can implement well-defined specs faster than ever.

The strategic value engineering leaders add is in the product thinking:

• “Is this the right thing to build?”
• “What’s the simplest solution that achieves the outcome?”
• “What technical possibilities exist that product hasn’t considered?”
• “What are we not seeing about the user problem?”

This requires understanding users, business context, and strategic priorities - not just technical architecture.

What Prevents Engineering Leaders from Developing Product Thinking?

I’ve thought a lot about why some engineering leaders develop this orientation and others don’t. A few patterns:

1. Promoted for Technical Excellence
Many engineering leaders got there by being exceptional engineers. They were rewarded for technical depth, not product insight. So they optimize for what got them promoted.

2. Kept at Arm’s Length from Customers
In many orgs, product “owns” customer access. Engineering isn’t invited to user research, doesn’t talk to customers, doesn’t see the business metrics. Hard to develop product thinking without product context.

3. Treated as Delivery Function
If product treats engineering as “build what we tell you,” engineering learns to wait for requirements. The relationship becomes transactional. Product thinking isn’t expected or welcomed.

4. Comfort with Technical Certainty
Technical problems have “right” answers. Product problems are ambiguous. Some engineering leaders prefer the certainty of technical problem-solving over the uncertainty of product strategy.

What I’d Love to See More Of

As a product leader, here’s what I want from engineering leadership:

• Join customer conversations - Don’t just read user stories, talk to actual users
• Understand the business model - Know how we make money and what drives growth
• Challenge product assumptions - Push back when our ideas don’t align with user needs
• Bring technical possibilities - “Here’s what’s newly possible that you might not know about”
• Co-own outcomes - Feel responsible for product success, not just technical delivery
• Think about the ‘why’ - Question whether we’re solving the right problem

The engineering leaders who do this become invaluable strategic partners, not just delivery managers.

My Questions for Engineering Leaders

What prevents you from engaging more deeply in product strategy?

Is it:

• Lack of access to customers and business context?
• Unclear if product thinking is expected/wanted?
• More comfortable focusing on technical problems?
• Time constraints - too busy with delivery to engage strategically?
• Organizational dynamics - product doesn’t want engineering input on strategy?

And for ICs: when engineering leaders develop product thinking, does it make them more or less effective in your eyes?

I genuinely want to understand how to create better product-engineering partnerships, and I think this orientation toward outcomes is key.

[vp_eng_keisha]

David, yes! This is the “what/why” in practice, and I’m so glad you’re articulating it from the product side.

Why This Matters from Engineering Leadership

Your fraud detection example perfectly captures what strategic engineering leadership looks like. That question - “Do we need real-time or just fast enough?” - is the kind of thinking that:

1. Saves months of engineering time
2. Ships value faster to customers
3. Reduces technical complexity and maintenance burden
4. Actually solves the business problem better

That’s strategic impact. That’s what engineering leadership should be doing.

How I Developed Product Thinking

You asked what prevents engineering leaders from developing this orientation. Let me share my journey because I had to actively develop this muscle.

At Google - I was insulated from business context. Product defined requirements, I built scalable systems. Never talked to customers. Never saw revenue metrics. Never thought about “why this feature.”

At Slack - Shift started happening. My director explicitly said: “You need to understand our users and business.” Started:

• Attending user research sessions
• Reading business reviews and metrics
• Joining customer calls with enterprise accounts
• Understanding our sales cycle and what blockers existed

This was uncomfortable at first. I felt like an imposter in product conversations. But it completely changed how I thought about engineering work.

Current Role (VP Eng at EdTech) - Product thinking is now core to how I lead:

• I spend 3-4 hours weekly in customer conversations
• I can articulate our business model and unit economics
• I understand which user problems drive retention vs growth vs expansion
• I regularly challenge product assumptions based on user insights

The result: Product trusts me as a strategic partner. We co-create solutions instead of product throwing requirements over the wall.

To Answer Your Question Directly

You asked what prevents engineering leaders from engaging in product strategy. From my conversations with peers:

1. Never Invited
Many product orgs explicitly keep engineering out of customer conversations and strategy discussions. “We’ll define requirements, you focus on technical delivery.” Can’t develop product thinking without access.

2. Cultural Expectations
In some orgs, engineering challenging product decisions is seen as “not staying in your lane” or “being difficult.” If product thinking isn’t welcomed, it won’t develop.

3. Time Constraints
Many engineering leaders are underwater with delivery pressure, operational issues, and hiring. Strategic product thinking feels like a luxury they can’t afford.

4. Lack of Training
Nobody taught me how to develop product intuition. I had to figure it out through osmosis and deliberate practice. Most engineering leaders never get that opportunity.

What Product Can Do

David, here’s what I’d love from product partners to enable this collaboration:

Invite Engineering to Strategy Discussions
Not just sprint planning - actual strategy. Market analysis, competitive landscape, user research synthesis. Help us develop context.

Share Business Metrics
Help engineering leaders understand the business. What’s our CAC? LTV? Churn drivers? Revenue per user? Conversion funnel? When I understand the business, I can make better technical decisions.

Welcome Technical Pushback
Create culture where engineering questioning product assumptions is valued, not seen as obstructionist. Your fraud detection example worked because you welcomed the question.

Include Engineering in Customer Conversations
Let engineering leaders attend user interviews, sales calls, support ticket reviews. Direct exposure to users builds empathy that requirements docs can’t provide.

The Question I Have for You

When engineering leaders engage in product thinking, how do you prefer we show up in those discussions?

Specifically:

• Should we wait to be invited or proactively engage?
• How much technical detail do you want when we’re exploring solutions?
• When is engineering input helpful vs when does it feel like we’re overstepping?
• How do we balance “challenging assumptions” vs “being obstructionist”?

I want to be a good product partner, but I don’t always know the line between helpful strategic input and stepping on product’s toes.

For ICs: Why This Matters

Alex asked if product thinking makes engineering leaders more effective. From my perspective: absolutely.

When I understand the business and user context, I can:

• Give my team better context about why work matters
• Make faster decisions on technical tradeoffs
• Shield the team from low-impact work
• Connect their daily work to meaningful outcomes

Engineers consistently tell me they value understanding the “why” behind their work. Product thinking helps me provide that.

[eng_director_luis]

David, I appreciate this perspective, and I agree in principle. But I want to push back on something that might get lost here.

The Risk: Product Thinking Without Technical Depth

There’s a balance that I think is important to maintain. Engineering leaders absolutely should think about outcomes and business value. But we shouldn’t lose our technical depth in pursuit of becoming pseudo-product managers.

Let me share where I’ve seen this go wrong.

When Product Thinking Becomes Product Management

I worked with an engineering director at a previous company who took “product thinking” too far. They:

• Spent all their time in customer meetings and product strategy sessions
• Lost touch with technical reality of what the team was building
• Made commitments about timelines without understanding technical complexity
• Couldn’t engage meaningfully with the team’s technical challenges
• Essentially became a product manager without the title

The team lost respect for them. When engineers escalated genuinely hard technical problems, this director would respond with business context instead of technical guidance. “Think about the user impact” doesn’t help when you’re stuck on a thorny distributed systems problem.

Technical Depth IS Strategic in Some Domains

Your fraud detection example is great, but let me offer a counter-perspective from financial services.

When we’re building fraud detection, the how isn’t just implementation - it’s core to the product:

• Which algorithm we choose affects precision/recall tradeoffs that directly impact user experience
• How we handle latency determines whether this works for real-time transactions
• How we ensure compliance with financial regulations is a product requirement, not just a technical detail
• How we prevent bias in the model is both a technical and ethical product concern

In these cases, product thinking requires technical depth. A leader who questions “do we need real-time” but doesn’t understand the technical implications of near-real-time vs batch processing can’t actually make good product decisions.

The Balance I’m Trying to Strike

Here’s how I think about it:

Product thinking helps me:

• Understand what problems we’re solving and for whom
• Prioritize technical work based on business impact
• Question whether we’re solving the right problem
• Connect technical decisions to user outcomes

Technical depth helps me:

• Understand what’s actually hard vs what’s easy
• Recognize when product requirements have expensive technical implications
• Identify technical opportunities product hasn’t considered
• Maintain credibility and trust with engineering teams

I need both. If I only have product thinking, I become a less effective product manager who can’t actually lead engineering. If I only have technical depth, I become what you described - focused on requirements and implementation without strategic context.

Where I Agree: The Question-Asking

Your fraud detection example resonates because of the questions your engineering leader asked:

• “What’s driving that?”
• “What’s the target?”
• “What if we could detect within 5 minutes?”

These are great questions that come from understanding both product and technical context. The engineering leader could ask about 5-minute detection because they understood the technical feasibility.

This is different from a pure product manager asking those questions. The engineering leader can immediately assess technical tradeoffs.

My Approach to Product Thinking

I do engage in product thinking, but through a technical lens:

I attend customer calls - but I’m listening for technical pain points and opportunities, not trying to do product management

I understand the business - so I can make good technical prioritization decisions, not to define product strategy

I challenge product assumptions - specifically when I see technical approaches that could achieve outcomes better/faster/cheaper

I bring technical possibilities - “Here’s what’s newly feasible that might open up product opportunities”

The framing: I’m an engineering leader who thinks about product context, not a product manager who happens to know technology.

The Question About Where Product Depth Is Strategic

David, here’s my question back: does the need for product thinking vary by domain?

In consumer products where technical implementation is largely solved problems, maybe product thinking dominates.

In deep-tech domains - financial systems, biotech, infrastructure, security - technical depth seems more strategically critical.

Or am I making excuses to stay comfortable in technical territory?

For ICs Reading This

When I bring product context to my team, it’s to help them understand:

• Why their work matters
• What constraints we’re working within
• How to make tradeoff decisions when implementation choices affect user experience

But I also bring technical depth:

• Helping with genuinely hard architectural decisions
• Understanding when technical challenges are real vs solvable
• Maintaining standards for engineering excellence

Both matter. I’m skeptical of the idea that engineering leaders should abandon technical depth for pure product thinking.

[maya_builds]

Coming from the design side, I have such mixed feelings about this because my startup failed partly because I didn’t have enough product thinking - but also maybe because I had too much design thinking without enough business sense.

The Design-Eng-Product Triangle

David, you’re describing what I wish had happened at my startup. We had:

• Design (me): Focused on beautiful UX and user delight
• Engineering (co-founder): Focused on scalable architecture and clean code
• Product (also me, poorly): Trying to figure out what to build

We were missing the central question you’re highlighting: What problem are we solving that people will pay for?

I designed beautiful interfaces for features nobody needed. Engineering built elegant systems that were over-engineered for our actual scale. Neither of us was thinking like product managers - focusing on outcomes, business value, and user problems worth solving.

Where I Agree: Question the What and Why

Your fraud detection example is perfect. The engineering leader asking “What’s the actual goal?” and “What if 5 minutes is fast enough?” - that’s exactly the thinking we needed.

Design version: I spent 6 weeks perfecting an onboarding flow for our startup. Beautiful animations, delightful interactions, pixel-perfect execution.

If I’d asked product questions:

• “What’s the goal of onboarding - get users to first value or showcase all features?”
• “What if we just got them to the core workflow in 30 seconds instead of a guided 5-minute tour?”
• “What does success look like - completion rate or activation rate?”

I would have built something completely different. Probably uglier. Definitely more effective.

Where I’m Uncertain: The Boundaries

But Luis’s concern resonates too. When does product thinking help vs when does it mean we’re abandoning our discipline’s expertise?

I’ve seen design leaders who were so focused on “business outcomes” that they stopped caring about craft. The product worked but was ugly and hard to use. They’d justify bad UX with “it hits the metrics.”

Similarly, I wonder: can engineering leaders be so focused on business outcomes that they neglect engineering excellence? Ship fast but accumulate crushing technical debt?

The question is: How do you maintain your discipline’s standards while thinking about product outcomes?

The Story That Still Haunts Me

My startup’s biggest failure wasn’t that we built the wrong thing (though we did). It was that we didn’t ask the right questions.

We built a B2B SaaS tool for marketing teams. We asked:

• “How do we make this beautiful?” (design)
• “How do we make this scalable?” (engineering)

We didn’t ask:

• “What problem are marketing teams actually willing to pay to solve?”
• “Why would they switch from existing solutions?”
• “What’s the minimum we need to build to test if this problem is real?”

Those are product questions. And neither design nor engineering brought them.

If we’d had an engineering leader like the one David describes - asking “What’s the target? What if we ship something simpler faster?” - we might have learned we were solving the wrong problem before burning through our funding.

The Question I Have

David and Luis both: where’s the line between healthy cross-functional thinking and losing your disciplinary depth?

Because I think:

• Engineering leaders should understand users and business (product thinking)
• Product managers should understand technical constraints (engineering thinking)
• Everyone should understand good design (design thinking)

But also:

• Engineering’s core value is technical excellence and system thinking
• Product’s core value is market understanding and prioritization
• Design’s core value is user experience and craft

How do we have enough overlap to collaborate without losing what makes each discipline valuable?

For the Cross-Functional Teams

I think the best teams have:

• Engineering leaders who ask product questions AND maintain technical standards
• Product managers who understand technical constraints AND focus on outcomes
• Design leaders who care about business impact AND maintain craft excellence

The magic is in the “AND,” not choosing one over the other.

At my current design systems role, I’m trying to do this:

• I ask product questions: “What capability does this enable? Why does this team need it?”
• I maintain design standards: “This component needs to meet accessibility requirements and fit our design principles”

Both matter. If I only think about enabling product teams (product thinking), our design system becomes inconsistent. If I only think about design perfection (design thinking), I don’t ship what teams actually need.

[alex_dev]

As an IC, I find this entire conversation fascinating because it’s giving me language for something I’ve been feeling but couldn’t articulate.

What I’ve Experienced from Different Leaders

I’ve worked under three different engineering managers in my 7 years. The difference in how they approached product thinking was dramatic:

Manager 1: Pure Technical

• Focused entirely on code quality, architecture, technical decisions
• Never questioned product requirements
• Would say “Product wants this feature, let’s build it well”
• Never connected our work to business outcomes or user value

Manager 2: Attempted Product Thinking (Badly)

• Spent all their time in product meetings
• Lost touch with our technical challenges
• Would commit to timelines without understanding technical complexity
• Couldn’t help when we hit genuinely hard technical problems

Manager 3: Balanced (Current)

• Asks product questions: “Why this feature? What problem does it solve?”
• Also deeply technical: Can engage with our architecture decisions when needed
• Connects our work to user impact and business metrics
• Challenges product when their asks don’t make technical sense

Manager 3 is the model David and Luis are describing - product thinking WITH technical depth.

Why Product Thinking Makes Leaders More Effective (from IC Perspective)

David asked if product thinking makes engineering leaders more effective. From my view: absolutely, when done right.

What it gives me:

1. Context for Decisions
When my manager explains the business goal, I make better technical decisions.

Example: We were building a reporting feature. Manager explained: “This is for enterprise sales - they need to show compliance audit trails. It’s blocking 3 deals worth K.”

Suddenly my tradeoff decisions were clear: Prioritize completeness and auditability over performance and elegance. Ship fast because business impact is high.

Without that context, I might have spent weeks optimizing performance nobody cared about.

2. Protection from Busy Work
A manager with product thinking can push back on low-value work.

Example: Product wanted us to add 15 customization options to a feature. Manager asked: “What’s the user research? Which options actually matter?”

Turned out 2 options covered 90% of use cases. We shipped those, saved weeks of work.

3. Meaningful Work
Honestly, knowing WHY I’m building something makes the work more satisfying. When my manager connects my code to actual users solving real problems, I care more about the quality.

Where Technical Depth Still Matters

Luis’s concern is real though. I’ve seen what happens when managers lose technical touch:

Bad scenario:
Me: “This will take 3 weeks - we need to refactor the auth system first”
Manager: “Product needs it in 1 week for a demo, just get it done”
Me: “That’s technically impossible without cutting corners that’ll cause security issues”
Manager: “Think about the user impact, we need to ship fast”

When managers don’t understand technical complexity, their product thinking becomes pressure to cut corners.

Good scenario:
Me: “This will take 3 weeks - we need to refactor the auth system”
Manager: “Walk me through the technical blocker. Is there a way to achieve the user outcome without the full refactor?”
Me: “Well, we could add a temporary workaround that handles 80% of cases…”
Manager: “Let’s do that, ship it, then prioritize the refactor. I’ll make sure product understands the technical debt we’re taking on.”

The difference: Manager 2 uses product thinking to pressure. Manager 3 uses technical depth + product thinking to find creative solutions.

What I Actually Need from Leaders

Synthesizing this thread, here’s what I want:

Product Thinking:

• Help me understand why my work matters
• Connect technical decisions to user outcomes
• Push back on low-value product requests
• Explain the business context for priorities

Technical Depth:

• Understand when technical challenges are real
• Help with genuinely complex architectural decisions
• Maintain standards for engineering excellence
• Protect the team from unrealistic commitments

Both Together:

• Ask “What’s the outcome we need?” AND “What’s technically feasible?”
• Challenge both product assumptions AND technical approaches
• Help find solutions that balance user value with technical sustainability

The Question I Have

For the leaders in this thread: how do you decide when to engage in product discussions vs when to trust product’s judgment?

Because I imagine there’s a version of this where engineering leaders question everything product proposes and it becomes obstructionist rather than collaborative.

What’s the line between healthy product thinking (“What’s the goal? Is there a simpler approach?”) and overreach (“I think we should build a different product entirely”)?

Why This Matters for Career Growth

This conversation is making me realize: if I want to move into leadership someday, I need to start developing product thinking now.

Not to become a product manager. But to be the kind of engineering leader who can:

• Have strategic conversations with product
• Connect technical work to business value
• Make good prioritization decisions
• Be more than just a really senior implementer

That’s intimidating because it’s not what I’m optimizing for today. But it seems essential for effective leadership.