01
Friction
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
B2EWeb & MobileGovernanceProduct Ops
Turning delivery into a verifiable system
When Enphase acquired us in 2022, our teams had to move from startup-style delivery to a more global product organization. I structured a shared delivery system between product, design and dev to reduce interpretation, rework and design/dev gaps.
Challenge
My role
OwnedContributedProduct Ops strategyDesign systemGovernanceUX architectureQuality frameworkTeam enablementDesign mentoringDeliveryUser testing
Year
Timeline
Tools
Understanding the problem
Methodology
Workflow auditTicket analysisReview analysisArtifact mappingStakeholder interviews
Clarifications after dev start
59%Share of tickets returning to discussion after development had started.
Tickets with more than one review cycle
40%Share of tickets requiring more than one design/dev correction cycle.
Too many decisions remained open after development had started.
Implicit decisions in tickets
38%
Missing
states
31%
Ambiguous
flows
18%
Unclear
criteria
16%
No
reuse
7%
Technical
constraint
Rework mostly came from decisions that remained implicit.
61%
Cross-discipline reviews
Share of tickets receiving at least two types of feedback: product, design or engineering.
Teams did not always share the same definition of the deliverable.
How can we make decisions, criteria and responsibilities verifiable before development starts?
02
Friction
For design
Mockups showed the target interface, but not always the rules needed to implement it.
Incomplete states
Missing edge cases
Reinvented patterns
03
Friction
For developers
Developers had to guess expected behaviours, states and quality criteria.
Divergent implementations
Review loops
Implicit decisions
Exploration and Solution
01
Strengthen documentation
Centralise rules, components and guidelines in a hub consultable by all teams.
Fast to launch
Easy to consult
Little real adoption
Decisions still came late
Explored
02
Strengthen reviews
Add more controls at the end of the cycle to detect gaps before release.
Detects gaps
Improves quality
Comes too late
Adds rework
Explored
03
Create shared delivery
Align product, design and dev around shared gates, artifacts and quality criteria.
Aligns earlier
Reduces interpretation
Requires adoption
More demanding at first
Selected
Check out the 4 key decisions I made
Delivery
Move friction before development
Because decisions reopened during review cost more than trade-offs made upfront.
Workflow showing the shift of product, design and engineering decisions before development starts.
Avoided cost
- Late reopened decisions
- Post-development rework
Accepted cost
- More upfront effort
- Process perceived as heavier
Governance
Clarify who decides what
Because a single library was mixing global decisions, components, product usage and responsibilities.
Design system architecture separating foundations, components, product usage and governance responsibilities.
Avoided cost
- Scattered decisions
- Uncontrolled contributions
Accepted cost
- More demanding architecture
- More structured contribution
Quality
Make quality verifiable
Because reviews came too late and relied too often on different opinions.
Handoff package and review checklist reducing interpretation gaps during development.
Avoided cost
- Subjective validations
- Variable criteria
Accepted cost
- More complete tickets
- More demanding reviews
Adoption
Rely on technical advocates
Because a shared system couldn’t be sustainably adopted if it remained design-only.
Adoption model showing how technical advocates helped teams use the shared system.
Avoided cost
- Design-only adoption
- Superficial usage
Accepted cost
- Senior dev time
- Progressive adoption
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
59%
31%
Before / After
Fewer decisions were reopened after development had started.
Tickets with more than one review cycle
40%
18%
Before / After
Tickets required fewer back-and-forth review cycles.
Cross-discipline reviews
61%
34%
Before / After
Teams more often shared the same definition of the deliverable.
Time savings on covered screens
Before / After
3h30
1h15
12h
5h
5h
2h
Gains were mostly visible on screens covered by the system.
Retrospective
Optimize each team separately
DON’TOptimize the handoffs between teams
INSTEADFix alignment during review
DON’TCreate alignment conditions before development
INSTEADAssume a system adopts itself
DON’TBuild adoption with its future users
INSTEAD
