Early-Stage Documentation Should Communicate, Not Comply

Every project starts with an idea. It might land in your inbox, be scribbled in a hastily written document, or even slip into conversation during a casual watercooler chat. However it arrives, you process it, connect the dots, and think you understand what it's about. So, what’s next?

Most would say the next phase is to write things down—capture the discoveries, the insights, the potential pitfalls. Sounds simple enough, right? Well, here’s where things start to get messy.

Welcome to the world of early-stage documentation, where new acronyms pop up like mushrooms after rain. Depending on your company's processes, you might be required to follow specific formats, fill out templates, or craft documents with names that sound like they were invented during one of those soul-sapping status meetings. Product domain literature talks about an abundance of documents, each with its purpose. However, in the corporate world, the process has taken... a different turn.

Some processes are shaped (or distorted) by big consultancy firms crafting costly frameworks without fully understanding the company's real context (we'll dive deeper into this in a future post). These frameworks often lose meaning in translation from "ideal process" to "actual practice" resulting in documents that started with good intentions—or simply to tick a box, which nobody understands.

Now, I know the corporate PO&PM guild might gasp in horror at this confession, but here it is: I never cared about specific documents. Yes, I said it. Especially when half of the topics required in them don’t add any real value. And let's be honest, nobody reads them.

If you have to write them because "the process", then do it fast—don't lose time. Any document required for compliance, PMO reporting, or someone's KPI can be generated using AI these days. You just need the core idea. The real question is: What should you write that actually matters?

For me, if I need to write something in this early stage, I write to communicate. That’s it. While keeping technical details to a minimum, it's important to remain mindful of technical constraints that could shape the feasibility of the idea. My goal is to communicate my understanding of the idea to stakeholders, raise concerns, outline the perimeter of the solution, and, most importantly, establish a clear understanding of the desired outcome.

In my opinion, this first document has to be written based on its primary purpose: Communication.

This document should be:

• Clear: No jargon. No buzzwords unless you want people to nod without understanding. For example, some of your "readers" might have missed the big meeting where it was presented, "the DSG enforces the HMD by using HTR…" which sounds super impressive until you realize nobody actually knows what that means.
• Simple: If your grandmother can’t grasp the main point of it, you’re overcomplicating—unless, of course, your grandmother is the CEO. Then you might need a whole different strategy.
• Quick to Read: No one has time to read a novella disguised as a project brief. Aim for brevity without losing clarity.

But there is also a tricky part: In many corporate environments, these early-stage documents are seen as contracts between Tech and Business. This perception makes it even more critical to handle assumptions with care. There are always unknowns—and even unknown unknowns. It's a good practice to explicitly state any assumptions in the document, creating an 'Assumptions List' when relevant. This helps manage expectations and keeps everyone aligned. I’d advise against treating them as such, but corporate politics are real, and you can’t ignore them entirely. Be careful not to overpromise. Keep things flexible, but clear. One common pitfall in corporate settings is committing to deliverables or timelines without fully understanding all the variables, which often leads to missed deadlines and frustrated stakeholders. Always leave room for adjustments as the project evolves.

If you’re not technically inclined yet, rely on technical support. Gather feedback, but keep it high-level. At this stage, no one should care if the new REST API has 45 fields or if the system-to-system communication uses some fancy new tech. That comes later.

Once you’ve written your masterpiece and feel proud of it, do this: Go back and strip away everything that doesn’t serve the purpose of communication. Feeling tempted to add a bunch of schemas because it looks impressive? Pause and ask: does it genuinely communicate something essential? If not, save your drawing skills or fancy schema design tools for later phases where they add real value.

One of my favorite quotes fits perfectly here:

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

Keep that in mind the next time you stare at a blank document, wondering where to start. You’re not creating a monument; you’re sending a message.

• D. Scope