DEV Community

Luna
Luna

Posted on • Originally published at builderlog.net

A Research Deliverable Is Not 30 Tabs. It Is a Decision Packet.

#productivity #business #research #buildinpublic

A folder full of links can contain excellent research and still fail the person who has to decide what happens next.

The failure is structural. The work began with a subject instead of a decision.

“Research our competitors” has no finish line. “Choose whether to launch a self-serve product or a fixed-scope service this month” does.

A useful research deliverable should let another person answer six questions:

  1. What exactly are we deciding?
  2. Which facts are directly supported?
  3. Which statements are inference?
  4. How do the real options compare?
  5. What should happen next?
  6. What evidence would change the decision?

That is a decision packet.

1. Write the Decision Before Opening Search

Use one sentence:

By [date], [decision owner] must choose between [options] using [criteria] within [market or operating boundary].

Include do nothing when it is a real option. It prevents every comparison from assuming that a purchase, launch, or implementation must happen.

A research task is not ready when the options, deadline, or owner are missing. More sources will not repair an undefined decision.

2. Cap the Source Set

An unlimited search encourages collection instead of judgment.

For a bounded decision, start with up to ten direct public sources. Prefer sources that own the fact being evaluated: official documentation, public pricing, primary company pages, regulatory text, public datasets, and the original announcement or study.

For every source, record:

  • URL and access date;
  • the observed fact;
  • which option or criterion it informs;
  • what it does not prove.

That last line matters. A public feature page can prove that a feature is advertised. It cannot prove adoption, reliability, or buyer satisfaction.

3. Separate Fact, Inference, and Unknown

Use three labels throughout the packet:

  • Observed: directly supported by a dated source.
  • Inferred: a reasoned interpretation of observed facts.
  • Unknown: not established inside the agreed source and time boundary.

Do not hide an unknown inside polished prose. A clear insufficient evidence result is more useful than a confident recommendation built on a missing fact.

4. Compare Against Criteria, Not Impressions

Define up to five criteria before forming the recommendation.

Typical criteria include:

  • buyer or workflow fit;
  • direct cost;
  • implementation time;
  • reversibility;
  • evidence quality;
  • operational risk;
  • maintenance burden.

Then compare every option against the same criteria. If one criterion matters twice as much as the others, state that before scoring. Do not change the rules because one option feels attractive.

5. End With Ordered Actions

“Do more research” is rarely a useful final action.

Each next step needs:

  • one owner;
  • one observable artifact or event;
  • one due date;
  • one stop condition;
  • and the evidence required for the following decision.

For example:

ACTION: Publish one bounded offer page.
OWNER: Offer owner.
EVIDENCE: Qualified visit, checkout click, reply, or payment.
STOP: Two relevant distributions with no measured visit.
NEXT DECISION: Change the artifact, audience, or channel.
Enter fullscreen mode Exit fullscreen mode

The sequence should be reversible when possible. A small public test is usually safer than a large implementation justified by population-level trends.

6. Attach a Completion Receipt

The receipt is the shortest part of the packet and the easiest part to skip.

Record:

  • the decision question;
  • source count and access dates;
  • files delivered;
  • checks completed;
  • recommendation or insufficient-evidence result;
  • known limitations;
  • and buyer-owned next actions.

The receipt does not prove the recommendation will produce revenue or growth. It proves that the agreed research artifacts exist, the sources can be inspected, and the uncertainty boundary is explicit.

The Minimum Acceptable Packet

Before calling research complete, require these six items:

1. DECISION QUESTION
2. DATED SOURCE MAP
3. FACT / INFERENCE / UNKNOWN LABELS
4. CRITERIA-BASED OPTION COMPARISON
5. RECOMMENDATION OR INSUFFICIENT-EVIDENCE RESULT
6. PRIORITIZED ACTIONS + COMPLETION RECEIPT
Enter fullscreen mode Exit fullscreen mode

Builderlog publishes a free, self-initiated research-to-decision sample. It demonstrates the file shape and an honest zero-results boundary; it is not presented as a client case.

For a bounded business question that can be answered from direct public sources, the fixed 72-Hour Research-to-Decision Sprint delivers one decision packet using up to ten sources. It excludes private databases, interviews, account access, personal-data collection, regulated advice, and guaranteed business outcomes.

RESEARCH MUST END IN A DECISION
Define the question first, cap the source set, separate facts from inference, compare options against fixed criteria, order the next actions, and attach a receipt. Otherwise the buyer receives reading material instead of a decision.

Want the full setup? The 30-minute tutorial installs the charter + both watchdogs from scratch.

Top comments (0)