Redesigning Product Manager for an Engineering-Led Org

A conductor does not play every instrument and does not produce the music directly. Instead, the conductor creates alignment, sets the pace, ensures timing, and brings every section together to create a coherent performance. The Product Conductor works the same way. They define the problem, set the success criteria, guide decisions, and keep the team in sync. They do not own execution, design, or delivery. They create clarity, remove friction, and shape the environment so Engineering and Design can perform at their best.

This practice is inspired from the Shape Up product methodology, which separates shaping from building and focuses on clarity, boundaries, and ownership instead of traditional project management.

Software Delivery Lifecycle

This list is an intentional simplification of how activities are shared across the Product Conductor, Engineering, and Design functions. It provides a clean way to clarify ownership without going into every exception or team specific variation. QA responsibilities are not listed separately because they are treated as part of Engineering within this model.

Problem definition

The Product Conductor owns defining the problem. They produce a tight brief that explains the user pain, the business impact, why it matters now, and the boundaries the team must respect. Engineering and Design give feasibility and experience inputs, but the Conductor is accountable for a clear, aligned definition.

Artifact: Product One Pager

Success metrics definition

The Product Conductor owns deciding how success will be measured. They define the outcome metric, the target, and how progress will be judged. Engineering and Design contribute feasibility and UX considerations, but the Conductor sets the final measurement standard.

Artifact: Success Metrics Sheet

Requirements / tickets

Engineering owns writing technical execution tasks because they build the solution. They create clear, implementable tickets tied to architecture, data, and system behavior. Design writes UX tickets that define flows or UI requirements.

Artifact: Engineering Tickets + UX Tickets

Backlog grooming

Engineering owns grooming because they control sequencing and technical dependencies. They maintain an updated, prioritized backlog reflecting engineering reality. Design adds UX items when relevant.

Artifact: Prioritized Engineering Backlog

Sprint rituals

Engineering runs standups, planning, demos, and retros because they manage execution. They produce commitments, updates, and improvement actions. Design joins where needed. The Conductor does not run these rituals.

Artifact: Sprint Plan + Retro Notes

Technical solutioning

Engineering owns how the product is built. They produce architectural decisions, solution diagrams, data flows, and feasibility evaluations. Design provides UX constraints and requirements that shape the approach.

Artifact: Technical Solution Document

UX research synthesis

Design owns synthesizing research into insights. They turn raw interviews and tests into patterns, themes, pain points, and opportunity areas. Engineering adds feasibility considerations.

Artifact: UX Research Insight Summary

UX/UI decisions

Design owns all interface and experience decisions. They define the flows, layouts, interaction patterns, and final visual direction. Engineering validates feasibility.

Artifact: Figma Flows & Final UI Specs

Competitive research

The Product Conductor owns monitoring competitors and extracting relevant signals. They produce concise summaries that highlight changes, risks, opportunities, and strategic implications.

Artifact: Competitive Landscape Brief

Decision framing

The Product Conductor owns preparing the decision frame. They outline the options, tradeoffs, risks, and a recommendation so the team can move quickly. Engineering and Design inform the tech and UX angles.

Artifact: Decision Frame (1-pager) / Product One Pager

Roadmap updates

The Product Conductor owns the narrative of the roadmap, explains the “why,” and defines the desired outcomes. Engineering owns sequencing and realistic delivery planning. Design applies UX timing when needed.

Artifact: Outcome-Driven Roadmap

Cross-team blockers

The Product Conductor owns removing cross-team friction. They escalate, negotiate, or coordinate to resolve delays. Engineering and Design only surface blockers.

Artifact: Blocker Resolution Log

QA testing

Engineering owns all QA validation, producing test results, bug lists, and functional checks. Design contributes visual and usability testing feedback.

Artifact: QA Test Report

Release readiness

Engineering owns confirming whether a release meets technical, stability, and performance requirements. Design validates UX completeness. The Conductor gives priority context but does not certify readiness.

Artifact: Release Readiness Checklist

Documentation

Engineering owns technical documentation because they describe how the system works, how services interact, and how to maintain or extend the solution. Design owns design documentation that covers flows, components, and interaction behaviour. The Product Conductor owns the release documentation, which explains the problem, the outcome, and the scope of the release.

Artifact: Release Doc, Tech Doc, Design Spec

User interviews

The Product Conductor owns the user interviews because they drive the understanding of user problems and business context. Engineering and Design provide input or attend sessions so they understand the reasoning behind decisions. The Conductor produces the final synthesis and ensures the team has clarity on user needs.

Artifact: User Interview Summary

Analytics reporting

The Product Conductor owns analytics reporting because it links product metrics to outcomes and informs strategy. Engineering provides data inputs on system behaviour. Design provides input on UX related data. The Conductor produces a clear summary of what the data means and how the team should respond.

Artifact: Analytics Insight Report

New PM’s Scope