I remember seeing someone posted their “shaping document” on Twitter the other week, but I must have forgotten to bookmark it. Interested in seeing example of shaping docs if anyone wants to share (as in output of shaping work collected in a document).
I haven’t created one before so nothing to share yet, but would appreciate any examples that can be shared in public. Thanks 
I’m not sure I saw that tweet you mentioned but I did see one awesome doc here in the forum by @mattdonovan
Hey, I’m happy to share a few examples of ones I’ve written in the past if it helps anyone 
They’re not amazing or anything and I’m always tweaking the layout and approach based on learnings & feedback. Anyway, feel free to check them out here…
Older version of our docs - https://public.3.basecamp.com/p/rYdSj5UGhQL6zDnzEaBuTh8j
Here’s a bit more recent - https://public.3.basecamp.com/p/YZWdQFyrsk66hd7n7VJuktxV
Thoughts/feedback welcome!
Nice work. Do you even include sketches of what you’re describing in your pitches?
Yes, sometimes we include fat market sketches or breadboards. These two projects just didn’t need them.
Any chance these could be made viewable again?
hi @Aylon - I saw some links, but cannot access them now.
can you make them available? or what should I do to get the content?
thank you
Hey, I’m really sorry, but those were for a company I don’t work at anymore and it seems they turned off the public sharing on that Basecamp account. Unfortunately I don’t have access, so I’m unable to do anything to make the content available again. Sorry that’s happened, but nothing I can do if my old company decided to stop sharing these 
Thank you @Aylon for your prompt reply
Avacode has templates but no examples.
Here are a couple I’ve done recently at varying sizes:
Sometimes, as we’re quite a small team, shaping can be more about nudging things forward a little at a time until a viable solution presents itself. In this example the original suggestion (“something like the request categorisation game but for missing email addresses”) is quite a bit of work. Not something we had appetite for.
We’ve thought about it off and on over the years, but a few months back we had an idea for hacking some version of it with some existing capability – 80% as good for 20% of the cost. As the hack uses a few existing and well known application concepts, I only spiked out the novel parts enough that I’d understood the unknowns and that I was confident that it would work and be doable in the small amount of time I wanted to spend implementing it properly.
The pitch doc is a means to an end. The thing that matters is being able to say “I know what I’m supposed to be doing, and I’m confident that I can do it within the amount of time I have to spend on it”.
Here’s another example. This one ended up being quite a big project and on reflection I’d have tried to split it up into entirely different projects and pitch documents, rather than presenting it all as one thing.
Hi @garethrees. Thank you for sharing! What tool are you using to fat markering?
Ha, nothing fancy really. Most of those in the links above are Pilot G2 on plain A4 printer paper or a DotGrid notebook, scanned with TurboScan. While not technically “fat”, I don’t like the bleed of Sharpies through to the other side of the paper. It’s more about the spirit of “fat”, IYSWIM 
. I’ve recently bought an iPad and have been using Freeform in a really similar way.
I’ve vaguely settled on a style of using blue ink for explanatory notes, and red for interaction/animation, but I don’t really give it much thought in the moment.
It’s not the only technique though.
Sometimes I’ll use draw.io where I feel that the sketch style would get in the way of explaining a more complicated piece, where the UI text matters and helps convey the key concepts better.
Sometimes I’ll just hack something into an existing UI using the browser web inspector. While it’s not “fat marker”, it’s often scrappy enough that it’s clearly not going to be exactly what gets shipped; it’s just the quickest way to convey the gist of a possible solution in the context.
Hope that helps 
.
Budget: 15 days | Timebox: 6 weeks
interesting distinction between the Budget (billable/work time) and Timebox (calendar time).
It’s a standard thing for Consulting SoWs (Scope of Work), but it’s the first time I see it in the context of Shape Up.
I think Shape Up 1.0 has only the Apettite with a Circuit Breaker (usually the same 2wks or 6wks + 2wks cooldown to finish stuff in case overrun the build cycle). I understand in Shape 2.0 the build cycle can be of an arbitrary time, e.g. the actual length of the cycle is less important than the concept of fixed time / variable scope.
Is this your own customization of Shape Up?
Any examples of hand-off / scoping, i.e. decomposing a Shape Up pitch into lists of Scopes with optional TODOs/tasks?
In your examples there are mostly comments with GitHub issue taskslists and/or merged PRs.
Is this your own customization of Shape Up?
Though much of my thinking and direction of travel has been inspired by Ryan over the years, we have very different constraints to Basecamp (funding model, team size, success factors, etc). Some projects will suit themselves more to “Shape Up by the book”, some won’t, so I just pick and choose depending on what we’re doing at any given moment.
interesting distinction between the Budget (billable/work time) and Timebox (calendar time).
IIRC, at the time we had some tricky scheduling issues, so it was trying to account for doing a few different projects at the same time with the same people. It may have been a mechanism for easing us in to thinking about hard cutoffs for work (circuit breakers), too – I can’t really remember. I don’t think I’ve used this since, but that’s not to say I wouldn’t in future.
In your examples there are mostly comments with GitHub issue taskslists and/or merged PRs.
Yeah, these are real projects and what you see on GitHub is what actually happened. There’d have been a fair amount of verbal communication as the project went on and we demoed progress in video calls, which wouldn’t necessarily have been documented.
Any examples of hand-off / scoping, i.e. decomposing a Shape Up pitch into lists of Scopes with optional TODOs/tasks?
I try to write the “pitches” (“packages” in more recent language) in such a way that makes it clear what we’re aiming at achieving, but I’m handing off to a senior programmer who’s been in the team for 5+ years, so I can write them knowing there’s a lot of contextual knowledge that I don’t have to cover.
Hand off is essentially just assigning the work in a planning session. He goes away and reads it, and then we usually talk through any questions and the outline of how to scope (though not necessarily in direct “shape up” language) in our regular 1:1.
The team will have an awareness of projects well before they’re shaped, so they won’t be seeing it for the first time at this handover stage. They’ll have seen the pitch/package being developed as I’ll be talking about progress from my ~“product management” perspective in our regular updates, catchups, etc.
While I’d like us to be a bit better at documenting scope decomposition, it’s not that it doesn’t happen. The order of the commits/PRs is the result of the programmer figuring that out.
In terms of recorded todos/tasks, sometimes we do this, sometimes it’s more informal and verbal. “What do you think about X? Does it need a bit more? Later? Okay, will come back to that if we get time”. Given we’re such a close, small team, we don’t need as much formality there.
Here’s another that Basecamp made public in conjunction with a design review screencast:
