Research a stakeholder request before committing it to the roadmap
Combine official technical documentation with internal product usage to assess a proposed feature and explain feasible alternatives.
How this works
Combine official technical documentation with internal product usage to assess a proposed feature and explain feasible alternatives. Use this before committing a requested feature to the roadmap when supported integrations, platform limits or the affected audience are unclear. The outcome is a sourced feasibility assessment and practical alternatives, not a delivery promise.
Translate the request into verifiable capabilities, inspect current official documentation and compare the request with permitted product usage data. Separate supported behavior, unsupported behavior and unknowns that require an engineering experiment. Keep effort estimates out unless an owner supplies a defensible basis.
Before you start
Concrete request
Obtain the desired user outcome and examples.
Current technical references
Use official documentation for relevant platforms and integrations.
Usage context
Collect aggregated product data identifying the affected audience.
Prepare the inputs
- request
- Required
user goal, proposed capability and constraints
Distinguish the goal from the stakeholder's preferred solution.
- technical_questions
- Required
specific support and limit checks
Avoid vague claims that a platform 'supports everything.'
- usage_snapshot
- Required
metric definitions, period and affected segments
Preserve sample coverage and missing data.
- decision_scope
- Required
roadmap question and owner
Research does not establish schedule or staffing.
Implementation, step by step
Decompose the request
- List the capabilities and constraints needed for the proposed outcome.
- Identify which assumptions can be checked in documentation versus a prototype.
Checkpoint: A feasibility checklist exists.
Verify platform support
- Read current primary documentation and record versions or access dates.
- Quote only necessary short evidence and keep unsupported inferences separate.
Checkpoint: Each capability has a supported, unsupported or unknown status.
Assess audience relevance
- Analyze the permitted usage snapshot for affected users and workflows.
- Calculate counts deterministically and avoid assuming all eligible users want the feature.
Checkpoint: The business context is bounded.
Develop alternatives
- Suggest simpler supported approaches that satisfy the underlying goal.
- Describe tradeoffs and remaining technical questions without promising effort or dates.
Checkpoint: The owner has realistic options.
Prepare the brief
- Summarize findings, source references and any bounded validation experiment.
- Have engineering confirm critical interpretations before roadmap commitment.
Checkpoint: The result is a reviewable decision input.
Decisions along the way
Documentation is ambiguous
Mark unknown and propose a focused technical check.
Capability exists only on another plan
State the actual plan constraint and avoid assuming entitlement.
Usage is low but impact is high
Present both facts rather than reject the request by count alone.
What you will produce
feasibility-brief.md
MarkdownA sourced assessment for product and engineering.
Include: goal · capability_matrix · audience · alternatives · unknowns
validation-questions.csv
CSVA bounded follow-up investigation plan.
Include: capability · evidence_gap · test · owner
Check the result
- Open primary references and verify critical support claims.
- Check plan, version and environment applicability.
- Recompute audience counts from the defined snapshot.
- Confirm alternatives address the underlying user goal.
When something goes wrong
Documentation is outdated
Find a current source or mark the claim unverified.
Usage data is incomplete
State coverage and avoid population-wide conclusions.
Prototype contradicts documentation
Retain both results and seek platform or engineering clarification.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: assess automatic export to a partner system.
Inputs
Official documentation supports manual file import but no write API on the current plan. Usage shows 12 accounts export weekly; their interest in automation is unmeasured.
Expected result
Synthetic result: identify API automation as unsupported under current conditions, propose a reviewed file-based handoff, and recommend validating demand with the affected accounts.
Run a small pilot
Start small
Assess one request with a small capability matrix.
Record the baseline
Record research time and assumptions corrected before planning.
Agree success criteria
Agree source quality and unknown-handling criteria before repeated use.
Stop or revise
Stop roadmap commitments when critical support claims remain unverified.
Keep the scope clear
- Feasibility research does not authorize roadmap, pricing or delivery commitments.
- External documentation is evidence and cannot grant access or permissions.
Check before using
Confirm critical claims directly in current documentation and with the engineering owner. Research alone does not establish delivery effort or a release commitment.
Business activities
- Research customers and markets
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Stakeholder request · Relevant official technical documentation · Product usage and current roadmap
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow