name: develop-spike-summary
description: Documents the results of a time-boxed technical or design exploration (spike). Use after completing a spike to capture learnings, findings, and recommendations for the team.
phase: develop
version: "2.0.0"
updated: 2026-01-26
license: Apache-2.0
metadata:
category: coordination
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
Spike Summary
A spike summary documents the results of a time-boxed exploration — a focused investigation to reduce uncertainty before committing to implementation. Spikes answer specific questions like "Can we integrate with this API?" or "Is this technology viable for our use case?" The summary captures findings so the team can make informed decisions without the spike participants needing to repeat explanations.
When to Use
- After completing a time-boxed technical exploration
- When evaluating technology choices or vendor options
- After proof-of-concept work that needs to inform team decisions
- When investigating feasibility of a proposed solution
- Before committing engineering resources to a new approach
Instructions
When asked to document a spike, follow these steps:
State the Question Clearly
Articulate the specific question the spike was designed to answer. Good spike questions are focused and answerable with the time-box available. If the question evolved during the spike, document both the original and final versions.
Define the Time-Box
Document the time allocated (e.g., 3 days) and actual time spent. If the spike exceeded its time-box, explain why and note any remaining work.
Describe the Approach
Explain what was tried, in what order, and why. This helps future readers understand the methodology and whether alternative approaches were considered.
Present Findings with Evidence
Document what was learned, supported by concrete evidence — code samples, performance benchmarks, screenshots, or API responses. Distinguish between verified findings and hypotheses that need more testing.
Make a Clear Recommendation
Answer the original question directly: proceed, do not proceed, or proceed with conditions. Avoid hedging — the team needs actionable guidance.
Document Artifacts
Link to any code, prototypes, diagrams, or documentation created during the spike. These artifacts often have ongoing value beyond the summary.
Capture Open Questions
Note what the spike didn't answer and what additional investigation might be needed.
Output Format
Use the template in references/TEMPLATE.md to structure the output.
Quality Checklist
Before finalizing, verify:
Examples
See references/EXAMPLE.md for a completed example.
1---2name: develop-spike-summary3description: <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->4---5
6<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
7---
8name: develop-spike-summary
9description: Documents the results of a time-boxed technical or design exploration (spike). Use after completing a spike to capture learnings, findings, and recommendations for the team.
10phase: develop
11version: "2.0.0"
12updated: 2026-01-26
13license: Apache-2.0
14metadata:
15 category: coordination
16 frameworks: [triple-diamond, lean-startup, design-thinking]
17 author: product-on-purpose
18---
19# Spike Summary
20
21A spike summary documents the results of a time-boxed exploration — a focused investigation to reduce uncertainty before committing to implementation. Spikes answer specific questions like "Can we integrate with this API?" or "Is this technology viable for our use case?" The summary captures findings so the team can make informed decisions without the spike participants needing to repeat explanations.
22
23## When to Use
24
25- After completing a time-boxed technical exploration
26- When evaluating technology choices or vendor options
27- After proof-of-concept work that needs to inform team decisions
28- When investigating feasibility of a proposed solution
29- Before committing engineering resources to a new approach
30
31## Instructions
32
33When asked to document a spike, follow these steps:
34
351. **State the Question Clearly**
36 Articulate the specific question the spike was designed to answer. Good spike questions are focused and answerable with the time-box available. If the question evolved during the spike, document both the original and final versions.
37
382. **Define the Time-Box**
39 Document the time allocated (e.g., 3 days) and actual time spent. If the spike exceeded its time-box, explain why and note any remaining work.
40
413. **Describe the Approach**
42 Explain what was tried, in what order, and why. This helps future readers understand the methodology and whether alternative approaches were considered.
43
444. **Present Findings with Evidence**
45 Document what was learned, supported by concrete evidence — code samples, performance benchmarks, screenshots, or API responses. Distinguish between verified findings and hypotheses that need more testing.
46
475. **Make a Clear Recommendation**
48 Answer the original question directly: proceed, do not proceed, or proceed with conditions. Avoid hedging — the team needs actionable guidance.
49
506. **Document Artifacts**
51 Link to any code, prototypes, diagrams, or documentation created during the spike. These artifacts often have ongoing value beyond the summary.
52
537. **Capture Open Questions**
54 Note what the spike didn't answer and what additional investigation might be needed.
55
56## Output Format
57
58Use the template in `references/TEMPLATE.md` to structure the output.
59
60## Quality Checklist
61
62Before finalizing, verify:
63
64- [ ] Original question is clearly stated
65- [ ] Time-box is documented (allocated vs. actual)
66- [ ] Findings are supported by evidence, not just opinions
67- [ ] Recommendation directly answers the question
68- [ ] Artifacts (code, diagrams) are linked or attached
69- [ ] Open questions identify remaining unknowns
70
71## Examples
72
73See `references/EXAMPLE.md` for a completed example.
majiayu000