The diligence answer should be shorter than the question

Why founders over-answer

The instinct is reasonable and it's wrong. When an investor asks a question during diligence, it feels high-stakes, so the founder tries to be thorough. Thorough feels safe. Every caveat you add is a follow-up question you've pre-empted, every definition is a misunderstanding you've headed off. More words feel like more diligence-readiness.

The reader experiences the reverse. A diligence question is a request for a specific fact, framed by someone building a model of your company in their head. They want to slot your answer into that model and move to the next line item. A long answer doesn't help them build the model faster. It forces them to extract the fact from a paragraph of context they didn't ask for, then guess which caveats are load-bearing and which are nervous throat-clearing. You've moved your work onto their desk.

There's a worse second-order effect. Length compresses signal. When you give a two-line answer to an easy question and a six-line answer to a hard one, the investor reads the contrast: this founder knows which questions are hard. When every answer is six lines, the contrast is gone. You've flattened your own emphasis, and the reader can no longer tell from your answers which parts of the business you understand cold and which ones you're papering over. The over-answerer hides their strengths inside the same fog as their weaknesses.

And the long answer is usually a tell that the founder hasn't decided what the answer is. If you know your NRR is 118% on a logo-weighted basis across 40 accounts, you write that. If you're not sure which definition makes you look best, or whether 40 accounts is enough to claim a number at all, you write six paragraphs and let the reader sort it out. The padding is the sound of an unmade decision.

The framework: answer shorter than the question

Here is the operating rule. For any diligence question, the answer should be shorter than the question, or close to it. Not because brevity is a virtue in itself, but because the discipline forces you to do the work the investor is testing: decide what the answer is, state it, and point to the proof.

Every diligence answer has the same three parts, in this order.

The claim comes first. One sentence, the direct answer to the literal question, leading with the number or the fact. "NRR is 118% over the trailing twelve months." Not the methodology, not the caveat, not the context. The fact they asked for, first, where they can find it without reading.

The proof link comes second. A pointer to the document, tab, or data that backs the claim, so the answer is verifiable without being long. "Calculation and cohort detail in the data room, Metrics tab, rows 12 to 40." The long version of your answer still exists. It lives in the document, where a reader who wants the nuance can go get it, and a reader who doesn't can skip it. The answer's job is to deliver the fact and route the reader to the depth, not to contain the depth.

The one line of context comes third, and only if it's load-bearing. A single qualifier that materially changes how to read the claim. "Sample is 40 accounts, so treat the cohort curves as directional." One line, the one that matters, the one you'd want them to know before they over-index on the number. If no caveat is load-bearing, there's no third part. Most answers are two parts.

That's the whole structure: claim, proof link, optional load-bearing caveat. It works because it separates the three jobs that founders mash together. The fact gets stated cleanly. The verification gets routed to where verification belongs. And the one caveat that matters gets the spotlight instead of drowning in five that don't.

The order is doing real work. Claim first means the reader gets the answer before the framing, which is the opposite of how an anxious founder writes. Proof link second means thoroughness is available without being mandatory. Caveat last and optional means you've decided which qualification earns its place, which is the judgment the investor is trying to assess.

Before / after: four rewrites

The shape is easier to see than to describe. Here are four real diligence question types, over-answered and then rewritten to the structure. The fact in each "after" is the same fact that was buried in the "before." Nothing true was dropped. The decision about what matters was made.

Q: "What's your net revenue retention and how do you calculate it?"

BEFORE (six lines, fact buried, reads as hedging)
  NRR is a metric we've thought hard about. There are a few ways to
  define it and for an early company the choice matters a lot. We use
  a logo-weighted trailing-twelve-month basis, though some would argue
  for a dollar-weighted view. By that method we land at around 118%,
  although our cohort is still small so I'd caveat that number. Happy
  to walk through the methodology on a call if useful.

AFTER (claim, proof, one caveat)
  NRR is 118%, logo-weighted, trailing twelve months.
  Full calculation and per-cohort detail: data room, Metrics tab, rows 12–40.
  Caveat: 40-account cohort, so read the curves as directional, not precise.

Q: "Who owns the IP, and are there any assignment gaps?"

BEFORE (defensive, raises the worry it means to settle)
  This is something we take very seriously. All current employees have
  signed IP assignment agreements as part of onboarding, and we've been
  careful about this from day one. There was an early contractor before
  we incorporated, but we believe that's been handled, and our counsel
  has reviewed the cap table and IP situation and didn't flag concerns.
  I can get you more detail if needed.

AFTER (claim, proof, the one real risk named plainly)
  The company owns all IP. Every employee and contractor has a signed
  assignment on file.
  Agreements: data room, Legal folder, "IP Assignments."
  One gap closed: a pre-incorporation contractor signed a confirmatory
  assignment in March 2025, also in the folder.

Q: "What's your monthly burn and current runway?"

BEFORE (numbers scattered across a paragraph)
  Burn has varied as we've scaled the team. We were running leaner last
  year but increased spend after our last raise to support growth, so
  current monthly burn is higher than the historical average, somewhere
  in the $180–220k range depending on the month. With current cash we're
  comfortable for a good while, and the new round would obviously extend
  that meaningfully.

AFTER (claim, proof, the number that frames the raise)
  Net burn is $205k/month. Cash on hand: $2.9M. Runway: 14 months.
  Monthly P&L and the burn build: data room, Financials tab.
  This round is sized to reach $1.5M ARR, which the model puts ~10
  months out, leaving a 4-month buffer.

Q: "How concentrated is your revenue? What's your largest customer?"

BEFORE (softens the number instead of stating it)
  We have a healthy mix of customers across a few segments. Our largest
  account is meaningful but we don't think we're dangerously concentrated,
  and we've been intentionally diversifying. The top customer is a larger
  share than we'd like long-term but the pipeline is reducing that
  dependency quarter over quarter.

AFTER (claim, proof, the trend that matters)
  Largest customer is 22% of ARR. Top 3 are 41%. Top 10 are 68%.
  Account-level breakdown: data room, Revenue tab.
  Concentration was 31% on the top account two quarters ago. The trend
  is down, and the rewrite is in the pipeline detail.

Look at what the rewrites have in common. The number leads. The document carries the depth. One caveat survives, and it's the one a sharp reader would have asked about next, so you've answered the follow-up inside the first answer without padding. The "after" is shorter than the question in three of the four cases, and the one that isn't is barely longer. None of them reads as nervous.

The artifact: a diligence answer review checklist

Before any diligence answer leaves your outbox or goes into the data room Q&A, run it through this. It takes thirty seconds and it catches the over-answering reflex before the investor sees it.

DILIGENCE ANSWER REVIEW CHECKLIST

Length
[ ] Is the answer shorter than, or about as long as, the question?
    If it's 3x longer, you're hedging. Cut it.
[ ] Can the reader find the literal fact in the first sentence
    without searching? If not, move the fact to the front.

Structure
[ ] Claim: one sentence, leads with the number or fact.
[ ] Proof link: points to a specific doc / tab / row, not "the data room."
[ ] Caveat: zero or one, and the one is load-bearing.
    Delete any caveat the reader could live without.

Decision quality
[ ] Have I decided the answer, or am I letting the reader
    decide by giving them every version?
[ ] If there's a real risk in this answer, did I name it in one plain
    line instead of burying it in reassurance?
[ ] Would this answer survive being read out loud in a partner meeting
    without me there to add context? If it needs me, it's not done.

Reusability
[ ] Is this answer saved somewhere I can reuse it for the next investor
    who asks the same question?
[ ] Does it match the number in the deck, the model, and the last
    investor update? (Mismatched numbers across docs is the fastest
    way to turn an easy question into a hard one.)

The last two items are where the payoff compounds. Diligence questions repeat. Every investor asks about retention, concentration, burn, IP, the cap table, churn. If you write each answer fresh under time pressure, you re-do the work every time and you risk giving the third investor a number that doesn't match what you told the first. If you write the answer once, to this structure, and save it, every later instance is a paste plus a sanity check. The discipline that makes a single answer clean is the same discipline that makes your answers consistent across a whole process.

Where this connects to RoundOS

The reason diligence answers drift long and inconsistent is that the proof lives in a dozen places. The number is in the model, the methodology is in a slide, the cohort detail is in a spreadsheet, the IP agreements are in a folder, and the version you sent the last investor is buried in an email thread. Writing a tight answer means assembling all of that from memory, fast, while three other investors wait. That's the condition that produces six-paragraph hedges.

RoundOS sits on top of the sources where the round already lives: the model, the deck, the data room exports, the meeting notes, the prior investor updates. When a diligence question comes in, you're not reconstructing the answer from scratch. You're drafting it from a knowledge base that already knows your stated NRR, where the calculation lives, and what you told the last investor who asked, so the draft comes back as claim plus proof link with the load-bearing caveat surfaced, and it matches the number you've used everywhere else. The structure in this article is the manual version of that. The product is what keeps it consistent across forty questions and four investors when you don't have thirty seconds per answer to spare.

The move this week

Pull the last ten diligence questions you've answered, or the ten you expect next. For each one, write the answer to the structure: one-line claim, one proof link, at most one load-bearing caveat. Then compare each rewrite to what you sent or would have sent. If the rewrite is shorter and the fact is easier to find, that's the version that goes into your diligence Q&A, saved and reusable, so the next investor who asks gets the decided answer instead of watching you decide in real time.

If you want the assembly done for you, RoundOS can draft concise diligence responses from your own sources, claim and proof link already linked to the document that backs them. Upload your data room and model, and generate the first batch of answers to see the structure applied to your real numbers.