Design Outcomes Weekly reflections on the real-time work of supporting a design org.
The Small Ask Inside the Big Questions

The Small Ask Inside the Big Questions

Why this matters

Good docs often carry one small decision and several big questions. If they share a page without a label, the room debates the big ones.

The Small Ask Inside the Big Questions A review that opened with 10 minutes of silence, the one critique I had for a strong doc, and how to make sure a room knows what you need from it. Good docs often carry one small decision and several big questions. If they share a page without a label, the room debates the big ones. Tell the room what you need before it starts. Put the one decision at the top of the doc, keep the open vision questions clearly apart from it, and include one finished example of anything you want people to fill in.

A review that opened with 10 minutes of silence, the one critique I had for a strong doc, and how to make sure a room knows what you need from it.

Ten minutes of silence opened the best review I sat in this week. A PM partner started the meeting by asking everyone to turn their cameras off, read the doc, and turn their cameras back on when they’d finished. Then she spent the remaining 20 minutes on the 2 questions she needed answered. She led the room the whole way, and nobody had to pretend they’d done the pre-read.

The doc was strong, and I said so first. It was candid about what was unproven, including the information architecture, which is a hard thing to admit in a review. It set a condition up front for when the team would pause the work. And it asked where engineering capacity should go, which made the cost of not doing the work a lot easier to see.

My one critique was about structure. The team was asking for a small decision that day, something close to “let us keep going at a slightly larger scale.” That ask was mixed in with 4 large questions about the long-term vision, and the vision questions are much more interesting to talk about. So the conversation went there for a while. The small ask did get approved, and I think it would have been approved in half the time if it had sat alone at the top with the big questions marked as “not today.”

A doc can carry one small decision and 4 big questions, as long as nobody has to guess which one you came for.

I gave similar advice to one of our lead designers earlier in the week, before a review of her own. She had a clear proposal and a related, much bigger question she was tempted to raise in the same session. Here’s what I suggested, and it applies to any designer walking into a room with decision-makers.

  1. Send your 1 or 2 questions ahead of time. A short note to the people deciding: here’s what I’m hoping to leave with. It plants the seed, and they show up already thinking about it.

  2. Restate them at the top of the meeting. Out loud, before the first slide. If the conversation drifts, you have something to point back to.

  3. Keep the bigger question separate. If it deserves its own session, give it one. Raising it alongside the small ask puts both at risk.

  4. Call out your dependencies. Let the room know that you know who you’ll need to partner with. It answers the “have you talked to that team?” question before it’s asked, and it makes “yes, go start” an easy thing to say.

Some of the leaders I work with have also stopped reading anything that looks like a wall of machine-written text. I’ve had to get more succinct myself, and I never share a block of AI output without cutting it down first. If your doc is long because a model made it long, the silent read at the top of the meeting will expose that pretty fast.

The last lesson came at my own expense. I’d designed a workshop template for a gathering we’re planning, and I learned later that a few of my design leaders weren’t sure what it was for. Their ask was simple: could they see one filled out? Of course they should. I’d made the same mistake I was critiquing, which was handing people a structure and assuming the purpose would be obvious. Later that same week I was building a deck with a product partner, and we did it the other way around. I finished one slide completely, and that slide became the template everyone else worked from.

A blank template asks people to guess what good looks like, and a finished example shows them. It’s the same reason we bring a prototype to design crit in place of a description of one (I wrote about what a small detail like that promises in Issue 23). If you want something specific from a room, show them the thing, and tell them the question.

Filed under CN Crit Notes — Feedback, with the reasoning shown.