What's the right level of detail when shaping?

I get this question all the time.

Look at whatever doc you're making in the shaping phase (eg a "pitch" per the book or something else)...

Ask yourself: What am I trying to do with this doc? Am trying to get approval with this? Or am I trying to create clarity and confidence with the build team?

When it's more about approval, the doc can be higher level and focus more on problem/outcome. It's more about why we should do this instead of other things. It's about the value, what we get out of it, and the basic idea. More about the business/customer case. To distinguish, call this a frame instead of a shape. This is the shorter thing to bring to the table to get buy-in to spend further time going deeper.

If the frame is approved, then it becomes more about "can we actually execute on this?" and "what exactly does it involve?" Now diving down into the mechanics is more important. That's what shaping is about vs. framing. So you should see more diagramming, more dataflow, how this connects to that, etc. How it works. Prove it out and nail down what we're doing and not doing.

Teasing these two purposes apart helps the team understand better what they're trying to accomplish and when. The detail question seems hard to answer when it's one doc for multiple purposes. Split it into different work steps. Framing for choosing what to work on and getting buy-in. Shaping for spelling out the mechanics so people are confident to start implementing.