Feasibility problems keep appearing mid-sprint after designs are final. What do you change?

Involve engineering from the start as part of a product–design–engineering trio, review rough designs early, and shape solutions and slices together before committing.

What does it mean to define 'done' as an outcome?

Agreeing before building what change in user or business behaviour the work should produce (e.g. +2 points mobile conversion) and checking it after release, in addition to the usual quality criteria.

How do you keep accountability clear in a trio?

Product owns what and why, design owns the user experience, engineering owns how — while all three share responsibility for the outcome and shape the solution together.

Working with Product and Design — The Team Lead Handbook

Scenario

Example team: the checkout team receives finished designs and detailed tickets from product. Engineers discover technical problems mid-sprint; designers see the result only at release; product complains engineering "always pushes back". Everyone feels the others don't understand their constraints.

What you see on the team

Hand-offs instead of collaboration: specs "thrown over the wall".
Feasibility problems found late, after designs are final.
Arguments about scope at the end of a cycle instead of the start.
No shared view of whether a feature actually worked for users.

The common mistake

Running product development as a relay — product writes, design designs, engineering builds — instead of a trio that shapes problems and owns outcomes together.

Why it happens

Functional boundaries are clear and comfortable; each discipline optimises its own part. Early involvement feels like extra meetings. But most expensive surprises come from decisions made without one of the three perspectives — feasibility, usability or value.

The playbook

Work as a trio (product, design, engineering lead) from the start of each initiative:

product brings the problem and the outcome to move;
design explores user experience options;
engineering brings feasibility, cost and technical opportunities;
all three shape the solution and the slices together.

Define done as an outcome, not just a release: "conversion on mobile checkout +2 points", agreed upfront, checked afterwards. The Agile Alliance's definition of done is about shared quality criteria; extend it with the outcome you expect.

Review designs early with engineers — rough sketches, not final mock-ups.

Share the same rituals: product and design attend planning and demos; engineers join user research sessions occasionally.

Disagree early and privately, align publicly.

What to say

At the start of an initiative:

"Before designs go further, can the three of us spend an hour on the problem? I'd like to bring two technical options — one of them could let us ship in half the time with a slightly different flow."

Agreeing success upfront:

"What would tell us this worked, three weeks after release? Let's write it down now and check it together."

Trade-offs

Trio work takes time early and saves rework later.
Engineers in research sessions cost capacity; rotate and keep it occasional.
Shared ownership can blur accountability; keep decision owners clear (product: what and why; design: experience; engineering: how).

Signals it's working

Feasibility issues surface during shaping, not mid-sprint.
Designs change based on engineering input — and vice versa.
Each initiative has an agreed outcome that's checked after release.
The three disciplines describe each other as partners.

Key points

Work as a product–design–engineering trio from the start of each initiative.
Agree the outcome before building; check it after release.
Review rough designs early with engineers; share rituals and research.
Keep decision ownership clear while sharing responsibility for outcomes.