MVPs and "Mid" Documentation Drafts
Before a project ever reaches the MVP Doc Stack stage, there’s a mindset: make the work visible early. This post is about how that plays out in real-world documentation.
When I’m working in a messy system, where the process is unclear or things are changing quickly, my goal is to reach a minimum viable product (MVP). Waiting to perfect something at the start can be an utter waste of time. You end up polishing details that don’t matter or solving problems that are already irrelevant.
I’ve built out a reference set, The Docs Every Startup Product Needs, to show what this looks like in practice.
Clarity comes from building, and feedback comes from showing the work. Ultimately, the goal should be to make the work visible.
That first version might be a walkthrough that only covers part of the flow, an outline that’s rough around the edges, or a draft with open questions still hanging in the margins. It’s not polished, and it doesn’t need to be. What matters is that it points in a direction people can respond to.
In practice, it shows up in many ways. Sometimes I sketch out a Google Site and build it layer by layer until it starts to make sense. Other times I share a rough Camtasia walkthrough before the voiceover is ready, just to check the flow. I’ve sent draft docs with comments pinned to specific spots, asking things like “Does this match what actually happens?” or “Is this the right term?” I’ve even built a first-pass client site with placeholder text so they could see what worked for their audience and what didn’t.
What all of these early versions had in common was that they created a reaction. They pulled feedback while the work was still flexible and easy to adjust.
The diagram above captures the idea in four steps: define, build, share, and iterate. Each one moves clarity forward through action and visibility.
The catch is that it only works if expectations are set. If someone is expecting a polished deliverable and you hand them a scrappy outline, the response won’t be helpful. That’s why I always frame things up front: a kickoff call, a short recap email, or even a quick note that says, “Here’s what this version is meant to do, and here’s the kind of feedback I’m looking for.”
Without that framing, even smart teams can get stuck on fonts, colors, or word choice while bigger structural issues slip by. With it, people know to focus on the shape of the work instead of the polish.
Not every team is comfortable with this. But the ones that move quickly understand the value of momentum. They’d rather respond to something rough and help shape it than wait for a version that looks finished but misses the point.
The takeaway is simple: start with what you know, make your work visible, and give people the right lens for responding. That’s how you get movement instead of silence.
If you’d like to see how this mindset translates into building a real product site, check out Building the Starting Over Site.
Next steps? Try sharing something one step earlier than you usually would. A rough outline, a partial walkthrough, or a visual draft. You’ll be surprised how much faster feedback (and clarity) comes when the work is visible.
