AI Skill Report Card
Conducting Strategic Research
Quick Start13 / 15
When asked to research a topic (e.g., "Should we adopt Kubernetes vs. serverless for our platform?"), produce four deliverables in this order:
- Research Summary - concise synthesis of findings
- Comparison Matrix - side-by-side evaluation of options
- Risk Map - categorized risks with likelihood/impact
- Recommendation - clear, justified decision or next step
Never skip straight to a recommendation without the supporting analysis.
Recommendation▾
Add a fully filled-out example output (with actual matrix values and risk entries) rather than describing what the output would contain
Workflow14 / 15
Progress:
- Clarify the decision or question being researched
- Identify options/candidates to compare (2-5 typical)
- Gather evidence for each: technical fit, cost, maturity, ecosystem, risk
- Write Research Summary
- Build Comparison Matrix
- Build Risk Map
- Write Recommendation
- Sanity-check recommendation against stated constraints (budget, timeline, team skill)
1. Clarify Scope
Identify: the core question, the decision-maker's constraints (budget, timeline, team capability), and success criteria. If not given, state reasonable assumptions explicitly rather than asking the user.
2. Research Summary
2-4 paragraphs covering:
- Context/problem statement
- What was evaluated
- Key findings (3-5 bullet takeaways)
- High-level direction the evidence points to
3. Comparison Matrix
Table format, options as columns, criteria as rows. Standard criteria unless topic demands otherwise:
| Criteria | Option A | Option B | Option C |
|---|---|---|---|
| Feasibility | |||
| Cost (setup/ongoing) | |||
| Time to implement | |||
| Maturity/ecosystem | |||
| Team skill fit | |||
| Scalability | |||
| Score (1-5) |
4. Risk Map
Group risks by category, rate each:
| Risk | Category | Likelihood | Impact | Mitigation |
|---|---|---|---|---|
| ... | Technical/Financial/Operational/Market | Low/Med/High | Low/Med/High | ... |
5. Recommendation
- State the recommended option/path in one sentence
- Justify with 2-3 reasons tied directly back to the matrix and risk map
- Note conditions under which the recommendation would change (decision triggers)
- Suggest concrete next step (pilot, PoC, further research, go/no-go)
Recommendation▾
Include an edge case for when research turns up insufficient/conflicting evidence
Examples14 / 20
Example 1: Input: "Evaluate feasibility of migrating our monolith to microservices." Output:
- Research Summary: notes current pain points (deploy speed, scaling), evaluates microservices vs. modular monolith vs. status quo
- Comparison Matrix: 3 options scored on feasibility, cost, time, team skill, scalability
- Risk Map: includes "team lacks distributed systems experience" (Operational, High likelihood, High impact, mitigation: phased rollout + training)
- Recommendation: "Adopt modular monolith first, revisit microservices in 12 months" with trigger conditions (e.g., team grows past 20 engineers)
Example 2: Input: "Is entering the Southeast Asia SaaS market a good opportunity?" Output:
- Research Summary: market size, competitor landscape, regulatory notes
- Comparison Matrix: compares target countries (e.g., Indonesia, Vietnam, Philippines) on market size, competition, regulatory ease, localization cost
- Risk Map: currency risk (Financial), regulatory shifts (Market), local competitor response (Market)
- Recommendation: prioritized country entry order with rationale
Recommendation▾
Show a 'bad output' example (e.g., vague recommendation) alongside a good one to reinforce the pitfalls section
Best Practices
- Always quantify when possible (scores, ranges, percentages) rather than vague qualifiers
- Keep the matrix criteria consistent across options — don't cherry-pick per-option
- Separate "what the evidence shows" (Summary/Matrix) from "what to do" (Recommendation)
- State assumptions explicitly when information is missing instead of stalling
- Make recommendations actionable and reversible where possible (pilot before full commitment)
- Tie every risk to a mitigation, even if the mitigation is "monitor and revisit"
Common Pitfalls
- Don't present a recommendation without a matrix/risk map backing it
- Don't use identical scores across all options — differentiate genuinely
- Don't ignore non-technical risks (regulatory, financial, organizational) when focus is technology
- Don't produce vague recommendations like "it depends" — always give a primary direction plus conditions for change
- Don't bury the recommendation at the end without a one-line summary up front