Forget workshops and sticky notes. The fastest way to better product delivery is designing for deliverability — with empathy, not ego.

---

This one’s for Ed Everett — because I promised I’d write it. Here’s the original conversation that kicked it all off. Hope it helps, Ed.

If you’ve worked in product for more than 5 minutes, you’ve heard the chorus: "Design, product, and engineering need to collaborate earlier." It’s a nice idea. But here’s the problem:

Design thinking, in its workshop-heavy format, won’t get us to designing for deliverability.

Not because collaboration isn’t valuable — it’s essential — but because the real-world behavior of teams doesn’t match the theory. Especially when you’re trying to build and ship fast.

Let’s be honest. Most PRDs are trash.

I’ve had engineering leads ask for a Product Requirements Document (PRD). Totally fair. But I’ve also seen PRDs written entirely by AI, with zero input from the customer, the business, or even the technical team. The result? A document no one trusts, uses, or even reads.

Designers often get blamed for designing things engineering can’t build. But in truth, most design teams want to help — they just don’t always know how. That’s why designing for deliverability should become our default mindset.

Here’s the contrarian take: Design should make the first move.

Why? Because designers have a secret superpower the others don’t: empathy. We’ve been trained to understand human needs — so let’s use it internally too.

That means:

• Reaching out to engineering first
• Asking how they want to work
• Adapting to their processes — not forcing them into ours

Designing for deliverability begins by understanding how delivery happens.

Here’s a case I love, from the team at Sure:

"We recently paired with project managers and engineers to learn about pain points specifically related to our Figma files… We sent out a Notion doc that allowed the entire team to add anything — from issues with copy updates to needing more annotations… It led to some great conversations, refactoring our documentation, and creating a more meaningful, efficient way to work together."

Read the full quote here →

This is what real collaboration — and designing for deliverability — looks like. No post-its required.

What worked for us at bp

At bp, I ran into a head of engineering who didn’t want to attend a 3-hour alignment workshop. Fair enough. So we did five 30-minute sessions instead — just mapping issues, one by one.

What we found:

• Tech was worried design was working in a black box
• They feared we were designing something they couldn’t build
• They didn’t want another new process — just integration into the one they already used

So we changed. Here’s how we started designing for deliverability:

1. Document everything – We shared messy notes, AI summaries, diagrams, photos of whiteboards — anything that helped engineers follow the thinking. We dropped it into Confluence and committed to replying to any comments within an hour. Importantly, we also included AI summaries of user testing. Hearing the customer’s voice — their pain points, frustrations, and real-world context — helped engineers reconnect with why we were building something in the first place. It moved conversations from "how do we build this?" to "how do we best solve this customer pain?" That’s the heart of designing for deliverability.
2. Show sketches early – We brought rough sketches to weekly meetings and daily standups. Engineers gave feedback immediately. They loved it. It reduced waste and helped ensure we were designing for deliverability, not just desirability.
3. Keep the door open both ways – We regularly pinged engineers to gut-check ideas. And soon, they were doing the same — sending rough builds our way for design feedback. This reciprocal rhythm is key when you're designing for deliverability in a fast-moving team.

The magic isn’t in the method. It’s in the mindset.

Design Thinking, Scrum, Agile — they’re just methods. But the real trick?

Use the designer’s empathy to shape collaboration that fits human behavior — not the other way around.

Designing for deliverability isn’t about perfection. It’s about progress. It’s about empathy over ego. And it’s about getting the right thing shipped at the right time — even if it’s not your “A+” solution.

Don’t force a workshop if a message thread will do. Don’t build a new meeting if a 5-minute sketch review in the standup gets faster alignment. And don’t aim for perfect — aim for shippable.

Because here’s the truth:

A shipped experience is better than a perfect one that never launches.

Let’s start designing for that. Let’s start designing for deliverability.