AyotundeWorkResume
DESIGN LEADERSHIPOPERATING MODEL · CROSS-FUNCTIONAL PARTNERSHIP

From sprint support to product partnership.

Bringing designers into discovery and roadmap planning earlier to build domain expertise, improve decisions, and reduce rework.

DOMAIN OWNERSHIP WITH ROOM FOR FLEXIBILITY
30–40%

lower rework rate

15–20%

increase in adoption

70%

of designers domain-aligned by the end of 2025

Explore the evidence ↗

Design needed a seat
before the solution was set.

In late 2024, designers described a recurring frustration: work reached them after product managers and engineers had shaped the roadmap and framed the solution.

Discovery during a sprint left little room to investigate or pivot. Teams faced rework, delayed goals, and engineering effort spent on approaches that needed revisiting. As Product Design Manager, I wanted designers involved before those commitments were made.

MY ROLE

Product Design Manager
Establish the pilot and secure support

PILOT

2 domain-aligned designers
Zephr and Experience Builder

PERIOD

Q1 through H1 2025
Evaluate delivery and post-release experience

Start focused.
Make room for flexibility.

Product managers reasonably questioned whether every project needed a permanently assigned designer. I proposed a two-designer pilot, while retaining lightweight support for small, well-understood changes and validated problems.

One designer aligned to Zephr and another to Experience Builder, joining roadmap planning in Q1 2025. Continuity helped them build domain understanding and contribute more informed product decisions.

01

Shape problems

Clarify user needs with product and engineering.

02

Discover together

Investigate uncertainty before committing to solutions.

03

Explore options

Compare approaches while change is still practical.

04

Assess feasibility

Identify delivery risks earlier in the process.

MY CONTRIBUTION

Change the conditions around the team.

I established the pilot, secured support for earlier involvement, and evaluated how it changed the teams’ work. Designers gained continuity and greater ownership within their domains.

Look beyond the release.

AT FIRST RELEASE

What changed during delivery?

Review rework, defects, and cycle time to understand what happened as the team shipped.

AFTER 30–60 DAYS

What changed for customers?

Review adoption, task success, speed, support tickets, and team feedback after release.

30–40%

Lower rework

Reported rework rate.

30–40%

Fewer UX bugs

Per release.

40%

Fewer late changes

Design or scope changes after development began.

15–20%

Higher adoption

Reported adoption-rate increase.

20–30%

Fewer support tickets

Reported after release.

70–85%

System reuse

UI using existing design system components.

The collaboration pulse reached 4.0+, with no discipline below 3.5. The source does not specify the scale, sample, baselines, or method used to attribute these changes.

Deeper ownership.
A flexible operating model.

The pilot ran through H1 2025. Its reported results supported wider domain alignment, and by the end of 2025 the P&T organisation had placed 70% of designers in domains matched to their capabilities.

Lightweight support remained available. Work with clear requirements could move efficiently; work with greater uncertainty benefited from sustained collaboration.

WHAT I TOOK FORWARD

Change the conditions around the team.

Designers wanted to contribute earlier, but their involvement began after important decisions were made. Coaching alone could not solve that timing problem.

Start with a pilot

Address concerns and gather evidence before expanding a new way of working.

Build domain continuity

Give designers room to deepen their understanding and take greater ownership of product decisions.

Match support to uncertainty

Keep lightweight support for clear requests and sustained collaboration for work that needs discovery.

LET’S WORK TOGETHER

Good conversations.
New possibilities.

I’m always open to interesting conversations—about design or what comes next.