Research can inform decisions or advocate for them. Knowing which you’re doing matters.
Exploratory vs. Advocacy
Exploratory research says: here are the options, here are the trade-offs, here’s what becomes possible. It expands the solution space without committing to any particular path. The value is in making possibilities visible and documenting what exists.
Advocacy says: we should do this. That requires problem validation. Have we hit the friction? Is the complexity justified? Did anyone actually ask for this?
The gap between them is the difference between here’s what’s possible and we should build this now.
Why the Distinction Matters
For researchers
When you default to proposing solutions, you risk:
- Over-engineering answers to problems that don’t exist yet.
- Inventing work instead of solving requested problems.
- Spending time on architecturally sound but premature proposals.
Framing speculative research as this would be useful if… rather than we need this because… keeps options open without creating implementation pressure.
For decision-makers
When evaluating research outputs, knowing the frame helps:
- Exploratory research → valuable for future reference, no action required now.
- Advocacy → requires problem validation before implementation.
- Unclear framing → ask: is this a recommendation, or just documentation?
For the commons
Clear framing prevents:
- The library filling with speculative architectures that were never requested.
- Confusion between what’s technically possible and what we should build.
- Implementation pressure from intellectually interesting but unjustified complexity.
Calibration Checklist
Before finalizing research, ask:
-
Am I proposing a solution before confirming the problem exists?
- Did anyone experience the friction this solves?
- Is this answering a question that was asked, or one I invented?
-
Is complexity justified by actual friction, or just intellectually interesting?
- Would this solve a real pain point, or is it just architecturally elegant?
- What’s the simplest thing that could work?
-
Did anyone ask for this, or am I inventing work?
- Can I point to a specific request or observed problem?
- Or did I just think wouldn’t it be cool if…?
If you can’t answer yes to question 3, frame as exploratory, not advocacy.
Examples
Exploratory: platform comparison
Request: How do I publish D&D content?
Research output:
- Comparison of platforms (itch.io, DriveThruRPG, Patreon, self-hosted).
- Licensing options (OGL, CC, proprietary).
- Trade-offs clearly stated.
- No recommendation of which to use.
Framing: Here are your options. Each has different trade-offs depending on your goals.
Outcome: Clean scope, useful output, no over-engineering. The requester chooses based on their needs.
Advocacy (premature): infrastructure proposal
Request: (none — self-initiated)
Research output:
- 27 KB architectural proposal for some integration.
- Use cases, technical patterns, governance safeguards.
- Technically sound and comprehensive.
Problem: No confirmation that the friction exists. Nobody asked for this. Intellectually interesting, potentially speculative.
Better framing: Here’s how this integration would work, if we experience friction the current setup can’t solve. No action needed now — this is for future reference.
Outcome: The proposal remains exploratory documentation rather than creating implementation pressure.
Ship-Then-Polish, but Honestly
A wiki benefits from publishing useful research before it’s polished. That principle applies here too:
- Ship exploratory research when it documents options clearly.
- Ship advocacy when the problem is validated and the solution is sound.
- Don’t ship speculation framed as necessity.
Research that explores possibilities is valuable. Research that advocates for implementation without problem validation creates technical debt before the problem exists.
See Also
- Self-Describing Systems — making implicit knowledge explicit
- Asynchronous Meeting Facilitation — separating information-sharing from decision-making