Problem - For the product team
Product intent got lost between initial trade-offs, tickets and reviews.
- Unclear acceptance criteria
- Reopened trade-offs
- Decisions hard to preserve
A shared delivery system between teams
After the Enphase acquisition, every handoff was reinterpreted differently depending on the team receiving it.
I set up a shared delivery system between product, design and dev so that decisions were made before development, and we stopped correcting after.
Context
I led
Delivery workflowQuality gatesDesign handoffDesign system governanceCross-team alignmentProduct/design/dev ops
Team
Product - Engineering - Design - Executive
Challenge
Scale delivery without letting each team reinterpret what needed to be shipped.
Year
2023
Timeline
2 years
Tools
Figma, Notion, Storybook, Jira, Flutter
Understanding the problem
Exploration and Solution
Strengthen documentation
Centralise rules, components and guidelines in a hub consultable by all teams.
Promise
Fast to launch / Easy to consult
Reasons for dropping
Little real adoption / Decisions still came late
Strengthen reviews
Add more controls at the end of the cycle to detect gaps before release.
Promise
Detects gaps / Improves quality
Reasons for dropping
Comes too late / Adds rework
Create shared delivery
Align product, design and dev around shared gates, artifacts and quality criteria.
Promise
Aligns earlier / Reduces interpretation
Accepted risk
Requires adoption / More demanding at first
Key decisions
Move friction before development
Because decisions reopened during review cost more than trade-offs made upfront.
Avoided cost
Late reopened decisions
Avoided cost
Post-development rework
More upfront effort
Accepted cost
Process perceived as heavier
Accepted cost
Clarify who decides what
Because a single library was mixing global decisions, components, product usage and responsibilities.
Avoided cost
Scattered decisions
Avoided cost
Uncontrolled contributions
More demanding architecture
Accepted cost
More structured contribution
Accepted cost
Make quality verifiable
Because reviews came too late and relied too often on different opinions.
Avoided cost
Subjective validations
Avoided cost
Variable criteria
More complete tickets
Accepted cost
More demanding reviews
Accepted cost
Rely on technical advocates
Because a shared system couldn’t be sustainably adopted if it remained design-only.
Avoided cost
Design-only adoption
Avoided cost
Superficial usage
Senior dev time
Accepted cost
Progressive adoption
Accepted cost
The impacts
The system made delivery more predictable: fewer reopened decisions, less late rework and more verifiable quality criteria.
Decisions were less often reopened after dev start
product, design and dev alignment happened earlier
Reviews required fewer late corrections
quality criteria were made explicit before implementation
Quality relied less on informal exchanges
handoff, checklist and governance made expectations verifiable
Clarifications after dev start
Fewer decisions were reopened after development had started.
59%
31%
Clarifications after dev start
Tickets with more than one review cycle
Tickets required fewer back-and-forth review cycles.
40%
18%
Tickets with more than one review cycle
Tickets reopened for design ambiguity
Fewer tickets returned to discussion for undefined design criteria.
38%
15%
Tickets reopened for design ambiguity
Time savings on covered screens
Gains were mostly visible on screens covered by the system.
Retrospective
Optimize each team separately
Optimize the handoffs between teams
Fix alignment during review
Create alignment conditions before development
Assume a system adopts itself
Build adoption with its future users
