How is working with engineering different from traditional PM Eng relationships?

It treats engineers as collaborators, requires clear context for decisions, and avoids dictating implementation details.

What should I do if engineering pushes back on scope?

Discuss concerns 1:1, aim for the simplest viable version, and adjust the roadmap or scope to protect quality and team health.

How do I build trust and avoid the ticket machine pattern?

Communicate the why behind each request, attend design reviews, protect engineering time, and celebrate engineering wins publicly.

working-with-engineering

Scanned

npx machina-cli add skill Dragoon0x/Product-Skills/working-with-engineering --openclaw

Files (1)

SKILL.md

2.8 KB

Working with Engineering

Partner with engineers as collaborators, not requesters.

How to use

/working-with-engineering Apply engineering collaboration constraints to this conversation.
/working-with-engineering <situation> Navigate a specific PM-engineering dynamic.

Constraints

Communication

MUST communicate the why behind every requirement. Engineers make better decisions with context.
MUST speak in terms of user problems and outcomes, not implementation instructions
SHOULD learn enough technical vocabulary to have productive conversations without faking it
NEVER tell engineers how to build. Define what and why. They own the how.
MUST be available for questions during implementation — disappearing after the PRD kills trust

Scope Negotiation

MUST involve engineering in scoping before committing to timelines
SHOULD ask "what's the simplest version that solves the user problem?" before "what's the full version?"
MUST treat estimates as ranges, not commitments. Push for "1-3 weeks" not "exactly 10 days."
NEVER negotiate against engineering estimates publicly — discuss concerns 1:1
SHOULD be willing to cut scope to protect quality and team health

Technical Empathy

MUST respect tech debt as real work that prevents future problems
SHOULD understand infrastructure and platform constraints that affect product decisions
MUST factor engineering maintenance burden into feature prioritization
NEVER treat "it works" as sufficient — performance, reliability, and maintainability matter
SHOULD attend design reviews and architecture discussions to stay informed

Trust Building

MUST follow through on commitments. If you say you'll get an answer, get it.
SHOULD protect engineering time from unnecessary meetings and context switches
MUST advocate for engineering priorities (debt, tooling, performance) in roadmap discussions
SHOULD celebrate engineering wins publicly, not just product launches
NEVER throw engineering under the bus when something ships late or buggy

Anti-Patterns

The Ticket Machine: writing JIRA tickets and waiting for output without collaboration
The Solution PM: specifying implementation details instead of defining problems
The Scopecreep: adding "one more thing" after engineering has already committed
The Meeting Hog: filling engineering calendars with syncs that could be Slack messages
Ignoring Tech Debt: always prioritizing features and wondering why velocity drops

Source

git clone https://github.com/Dragoon0x/Product-Skills/blob/main/skills/collaboration/working-with-engineering/SKILL.mdView on GitHub

Overview

Partner with engineers as collaborators, not requesters. This skill covers communication norms, technical empathy, scope negotiation, and building mutual trust to keep product and tech aligned.

How This Skill Works

Engineers should be treated as collaborators through clear framing: explain the why, speak in user outcomes, and avoid dictating implementation. Build trust by involving engineering in scoping, asking for the simplest version, and treating estimates as ranges. Maintain technical empathy by understanding debt, constraints, and maintenance impact, and attending reviews.

When to Use It

PM ENG relationships feel transactional and lack genuine collaboration.
Technical decisions are made without product input and clear user outcomes.
Scope conversations become adversarial or murky and uncontrolled.
Debt, tooling, or maintenance constraints impact prioritization and roadmaps.
You want to reduce unnecessary meetings and protect engineering time while staying aligned.

Quick Start

Step 1: Use the /working-with-engineering directive to apply collaboration constraints in conversation.
Step 2: Frame requirements by why and user outcomes, not how to build it.
Step 3: Involve engineering in scoping early, ask for the simplest viable version, and set range based estimates.

Best Practices

Involve engineering in scoping before committing to timelines.
Define requirements by why and by user outcomes, not implementation specifics.
Learn enough technical vocabulary to have productive talks without faking it.
Never dictate how to build; specify what and why, engineers own the how.
Protect engineering time and factor debt, tooling, and maintenance into prioritization.

Example Use Cases

A PM and engineer team up to scope a new feature by defining outcomes and constraints, avoiding tickets that specify implementation.
During planning, the PM asks for the simplest version that solves the user problem before expanding scope.
In architecture reviews, the PM attends to understand platform constraints and adjusts the roadmap accordingly.
When a release slips, the PM advocates for engineering priorities in the roadmap and communicates transparently to stakeholders.
The team replaces unnecessary syncs with concise async updates to reduce meeting load while staying aligned.

Frequently Asked Questions

Add this skill to your agents