Working with Product¶

The engineering-product relationship is the most consequential partnership in software development. When it works, you build the right thing at a sustainable pace. When it breaks, you build features nobody uses, burn out your team on rework, or spend more time in alignment meetings than actually shipping.

This page is a practical guide to making that partnership work—not through goodwill or chemistry, but through clear structures, explicit ownership, and communication patterns designed for remote-first teams.

What Problem This Solves¶

Most engineering-product friction comes from three sources:

Unclear ownership of decisions. Who decides what gets built? Who decides how it gets built? Who decides when to cut scope? When these boundaries are fuzzy, you get either conflict or paralysis.

Misaligned expectations. Product expects a feature by Thursday. Engineering thought they were exploring options. Product thinks the scope is fixed. Engineering assumes they can negotiate. Nobody is wrong—they just never aligned.

Poor feedback loops. Engineering builds what was asked, ships it, and moves on. Nobody closes the loop on whether it worked. Product never learns what's technically cheap or expensive. Engineering never learns what users actually needed.

This page provides the operating system to prevent these failures.

Ownership Model: Who Decides What¶

The cleanest way to prevent ownership confusion is to be explicit about decision domains. Here's the model I use:

Decision	Owner	Contributors
What problem to solve	Product	Engineering, Design, Customer Success
Whether the problem is worth solving	Product + Eng Lead (jointly)	Stakeholders
What solution to build	Product + Design + Engineering (collaboratively)	N/A
How to build it	Engineering	Product (context), Design (constraints)
When to cut scope	Product + Eng Lead (jointly)	Team
When to ship	Engineering	Product (awareness)
Definition of Done	Team (agreed upfront)	N/A

This model respects the principle that Product owns the why and what, while Engineering owns the how and when. But it also recognizes that the cleanest decisions happen in the middle—where both disciplines contribute.

The scope negotiation

When deadlines collide with reality, scope must flex. This is not a failure—it's how software actually gets built. The key is that Product and Engineering negotiate scope together, with Engineering providing honest estimates and Product providing clear priorities.

When to Use This Framework¶

Use this framework when:

Starting a new product area or squad with a Product Manager
Resetting a relationship that has become contentious or unclear
Onboarding a new PM or Eng Lead who needs to understand how you work
Diagnosing recurring friction between engineering and product

Don't use this framework when:

You have a mature, high-trust relationship where these patterns are already implicit
The team is so small that one person wears multiple hats
You're in true crisis mode where formal process would slow you down (but return to it after)

The Collaboration Cycle¶

Engineering-product collaboration is not a one-time alignment. It's a continuous loop that runs through the entire lifecycle of a feature or initiative.

Phase 1: Problem Definition¶

Before any solution is proposed, Product and Engineering should align on the problem.

What Product provides:

Clear articulation of the user problem or business opportunity
Data or research supporting the problem's importance
Success metrics: how will we know if we solved it?
Constraints: timeline pressure, dependencies, business context

What Engineering provides:

Technical context that might shape the problem definition
Questions that surface hidden assumptions
Early signal on feasibility (not estimates, just "this seems possible" or "this might be hard")

Format: This can be async (a problem brief in Notion or Google Docs) or sync (a 30-minute problem framing meeting). The key is that it happens before solution mode.

Phase 2: Solution Shaping¶

Once the problem is clear, the team explores solutions together. This is not "Product designs, Engineering implements." It's collaborative shaping.

What happens:

Product proposes initial solution concepts (often with Design)
Engineering stress-tests feasibility and suggests alternatives
The team identifies the smallest slice that could validate the solution
Trade-offs are surfaced and decided: speed vs. quality, scope vs. timeline, flexibility vs. simplicity

Pitfalls to avoid:

Product presenting a fully-baked solution and asking Engineering to "estimate it"
Engineering rejecting ideas without proposing alternatives
Skipping this phase and going straight from problem to implementation

Format: A shaping session (60-90 minutes) works well for non-trivial features. For small features, async in a shared doc is sufficient.

Phase 3: Commitment¶

Before work starts, the team makes explicit commitments.

What gets locked:

Scope: what's in, what's out, what's a stretch goal
Timeline: target completion (range, not exact date)
Definition of Done: tests, documentation, feature flags, observability
First slice: what's the smallest thing we can ship to learn?

What Product commits to:

Protecting the team from scope creep
Providing answers to questions within agreed turnaround times
Not changing priorities mid-sprint without explicit renegotiation

What Engineering commits to:

Honest, conservative estimates
Surfacing blockers early
Delivering what was agreed, or renegotiating explicitly

Phase 4: Execution¶

During build, the focus shifts to progress visibility and blocker removal.

Async updates:

Engineering provides regular progress updates (daily or every-other-day)
Updates answer: What shipped? What's in progress? What's blocked? Any risks to timeline?
Product reads these and responds only when action is needed

Sync check-ins:

Weekly at most, focused on decisions and blockers
Not status updates—those happen async

Scope changes:

If scope must change, it happens through explicit renegotiation
The question is always: "What are we trading to add this?"

Phase 5: Delivery and Learning¶

Shipping is not the end. The loop closes when the team learns whether the solution worked.

What happens:

Feature ships (behind flag or to subset of users)
Team monitors success metrics defined in Phase 1
Product shares results with Engineering: did it work? What did we learn?
Team decides: iterate, expand, or move on

Why this matters:

Engineers who never see the impact of their work become disconnected from outcomes. Product managers who never understand what was expensive can't prioritize effectively. Closing the loop builds the feedback that improves future collaboration.

What Good Looks Like¶

You'll know the partnership is working when you observe these signals:

Signal	What it looks like
Shared vocabulary	PM and engineers use the same terms for features, metrics, and priorities
Early feasibility input	Engineering is involved before solutions are finalized
Scope is negotiated, not dictated	When timelines are tight, the team finds the right trade-offs together
Engineers understand the "why"	Any engineer on the team can explain why they're building what they're building
Product understands the "how"	PM has a sense of what's technically cheap vs. expensive
No surprises	Neither side is blindsided by changes, delays, or decisions
Retros include both	PM joins engineering retros; learning is shared

Failure Modes and Mitigations¶

The Feature Factory¶

Symptom: Engineering builds whatever Product asks, without questioning value or feasibility. There's no pushback, no shaping, just execution.

Root cause: Power imbalance, fear of conflict, or lack of technical voice at the table.

Mitigation: Engineering leadership must earn a seat at prioritization discussions. Start by asking questions: "What data do we have that this is the right problem?" "What's the opportunity cost of building this instead of X?" Build credibility through delivery, then use it to shape strategy.

The Blocking Engineer¶

Symptom: Engineering says "no" to everything or buries Product in technical objections without offering alternatives.

Root cause: Lack of trust, previous bad experiences, or engineers who see their role as gatekeeping rather than enabling.

Mitigation: Reframe the role. Engineering's job is not to decide what gets built—it's to make what Product needs technically possible. When raising concerns, always pair them with alternatives: "We can't do X in this timeline, but we could do Y, which gets 80% of the value."

The Absent Product Manager¶

Symptom: Product is never available. Questions go unanswered. Decisions stall. Engineers make assumptions to keep moving.

Root cause: PM is overloaded, covering too many teams, or not prioritizing engineering collaboration.

Mitigation: Escalate to leadership. A team without PM availability is a team making product decisions without product expertise. In the short term, document assumptions and get explicit sign-off.

The Moving Target¶

Symptom: Scope changes constantly. Every sprint has new "urgent" requests. Nothing ever feels done.

Root cause: Lack of commitment discipline, external pressure, or a PM who can't say no to stakeholders.

Mitigation: Make the cost visible. Track scope changes and their impact on delivery. Use retros to surface the pattern. Propose explicit scope change protocols: any change mid-sprint requires an explicit trade-off conversation.

The Handoff Void¶

Symptom: Product delivers a spec, disappears, and returns only when the feature is "done." There's no collaboration during build, no feedback loop after ship.

Root cause: Waterfall habits, PM bandwidth constraints, or lack of established rituals.

Mitigation: Build the rituals. Weekly check-ins during build. Mandatory metric review after ship. Make collaboration the process, not an exception.

Remote-First Adaptations¶

All of the above assumes remote-first constraints. Here are specific adaptations:

Time zone overlap: If you have limited overlap, protect it for decisions and blockers. Everything else happens async.

Async problem briefs: Don't schedule a meeting to share a problem statement. Write it, share it, give people time to read and comment, then meet only to discuss disagreements.

Decision logs: Every significant decision should be documented with the reasoning. When people can't attend meetings, they can still understand why decisions were made.

Video for rapport, async for depth: Use video calls to build relationship and resolve conflict. Use async (Loom, written docs) for detailed explanations that benefit from review time.

Explicit response SLAs: Agree on how quickly questions need answers. "I'll respond within 24 hours" prevents both constant pings and week-long silences.

Copy-Paste Artifact: Weekly Eng-Product Sync Agenda¶

## Eng-Product Weekly Sync

**Date:** [Date]
**Attendees:** [PM], [Eng Lead], [optional: Design Lead]
**Duration:** 30 minutes

### 1. Last Week (5 min)

- What shipped?
- What didn't ship that we expected? Why?

### 2. This Week (10 min)

- What's the focus?
- Any decisions needed from PM?
- Any blockers that need escalation?

### 3. Coming Up (10 min)

- What's next after current work?
- Any new information that changes priorities?
- Heads-up on upcoming dependencies or risks

### 4. Relationship Check (5 min)

- Is anything unclear or frustrating?
- Is communication working? Anything to adjust?

### Action Items

- [ ] [Owner]: [Action]
- [ ] [Owner]: [Action]

Copy-Paste Artifact: Scope Change Request Template¶

## Scope Change Request

**Requested by:** [Name]
**Date:** [Date]
**Feature/Initiative:** [Name]

### What's the change?

[Describe the proposed change in scope]

### Why is this being requested?

[New information, customer feedback, business requirement, etc.]

### Impact assessment

**Timeline impact:** [None / X days / X weeks / Unknown]
**Other scope impact:** [What might we need to cut to accommodate this?]
**Technical risk:** [Low / Medium / High]

### Recommendation

[Add / Defer / Reject – with reasoning]

### Decision

**Decision:** [Add / Defer / Reject]
**Decided by:** [Name]
**Date:** [Date]
**Trade-off:** [What are we trading to make this happen?]

Copy-Paste Artifact: Problem Brief Template¶

## Problem Brief: [Problem Name]

**Author:** [Name]
**Date:** [Date]
**Status:** [Draft / Ready for Review / Approved]

### Problem Statement

[One paragraph describing the problem from the user's perspective]

### Evidence

[Data, research, customer feedback, or support tickets that demonstrate this is a real problem worth solving]

### Who is affected?

[User segment, percentage of users, revenue impact, etc.]

### Success Metrics

[How will we know if we solved this? Be specific and measurable]

### Constraints

- **Timeline:** [Any deadline pressure?]
- **Technical:** [Known technical constraints?]
- **Business:** [Dependencies, compliance, etc.?]

### Non-Goals

[What are we explicitly NOT trying to solve?]

### Open Questions

[Questions that need answers before we can proceed]

---

**For Engineering Review:**

- Initial feasibility assessment: [Easy / Moderate / Hard / Unknown]
- Questions or concerns:
- Alternative approaches worth exploring: