Spike for PMs
A spike is a time-boxed investigation I use when uncertainty could materially affect a product decision. The question may involve an unfamiliar integration, a performance constraint, data quality, security, or an edge case that a normal story does not explain. A spike can help me learn enough to choose a path, but it is not automatically a feature and it is not a promise that the final implementation will be easy.
I keep the distinction clear because a spike can look productive while avoiding the real decision. I define what I need to learn, who will use the answer, and what will happen when the time box ends. The goal is reduced uncertainty, not a task that remains open forever.
Name the uncertainty first
I start with the product or customer decision behind the investigation. “Explore the API” is not specific enough. “Can we support a customer’s required permission model without exposing data across workspaces?” gives the team a risk and a question. “Can the service respond reliably enough for this workflow?” identifies a different question and may require a different test.
I describe what is known, what is assumed, and what would change the product direction. I also state the consequence of being wrong. A small unknown may need a lightweight answer. A risk involving privacy, safety, money, reliability, or a core customer promise deserves more deliberate investigation.
I connect the question to a problem statement for PMs or an opportunity brief when that context exists. The spike should serve a product decision rather than become an engineering activity detached from customer value.
Choose the smallest useful investigation
I agree with engineering on the smallest activity that can produce meaningful evidence. That might be reading official documentation, building a thin proof of concept, tracing data through a workflow, testing a representative load, checking an SDK, or mapping failure and recovery paths. I do not ask for a production-ready implementation when a narrower test can answer the question.
I am careful about representative conditions. A toy example can show that something is possible while hiding the data volume, permissions, latency, operational burden, or customer behavior that matters in practice. I ask which conditions the investigation covers and which it leaves unresolved.
When the unknown is primarily about user comprehension or desirability, I do not use a technical spike as a substitute for customer learning. A prototype or research session may be the better next step. The label “spike” should not turn every form of uncertainty into engineering work.
Set a time box and an exit condition
I write the time box, owner, scope, and expected output before work begins. The time box creates a reason to make a decision instead of exploring every interesting branch. It should be long enough to learn something useful and short enough that the team can reassess.
The exit condition is more important than the number of hours. I might expect a recommendation between two approaches, a list of constraints, a working proof of concept, an identified blocker, an estimate with assumptions, or a decision to run a larger investigation. I do not call the spike complete merely because time ran out.
I also define what the result cannot establish. A proof of concept may demonstrate a path without proving maintainability. A benchmark may reveal a bottleneck without proving the complete system is ready. A vendor conversation may clarify an integration without proving the contract, support model, or customer fit.
Make tradeoffs visible
I ask the team to compare options in the language of the product decision. One approach may reduce implementation effort but create a dependency. Another may give us control but add operational work. A third may protect the current workflow while limiting future flexibility. I want those tradeoffs documented, not left in a conversation that only a few people remember.
I include non-functional concerns when they are relevant: security, privacy, accessibility, reliability, observability, migrations, support, and the ability to recover from failure. These are not polish for later if the product promise depends on them.
I use build vs. buy for PMs when the spike compares an internal approach with a service or component we could acquire. The investigation should make the decision criteria explicit rather than treating “build” or “buy” as a default ideology.
Read the result without overclaiming
At the end, I ask what the evidence actually says. I distinguish “possible,” “works under these conditions,” “recommended for this scope,” and “ready for production.” Those statements are not interchangeable. I record assumptions about scale, data, permissions, dependencies, costs, and ownership so a future reader does not mistake a narrow finding for a broad guarantee.
I also ask what surprised us. A spike can uncover a technical constraint, but it can also expose a product or operational issue. The integration may require customers to change a process. The data may not carry the meaning the feature needs. The failure mode may create support work that changes the value of the idea.
If the investigation is inconclusive, I say so. “We need better evidence about recovery behavior” is a useful result when it changes the next test. I do not stretch a partial answer into a confident recommendation simply to close the ticket.
Connect the result to planning
I turn the findings into a product decision, a follow-up, or an explicit unresolved risk. If we proceed, I update the scope, acceptance criteria, architecture notes, dependencies, and rollout plan. If we do not proceed, I record why so the question is not reopened without new information.
I avoid counting spike output as shipped customer value. The work may be essential, but it is learning or risk reduction. I look for a separate measure of the customer or business outcome the eventual product work is intended to influence.
I also revisit the decision if the context changes. A vendor API can change, an architecture can evolve, or a customer promise can narrow. A spike is a dated piece of evidence, not a permanent certificate of feasibility.
My bottom line is that I use a spike to buy clarity, not to hide uncertainty behind an engineering label. A good spike has a product question, a bounded investigation, an honest result, and a clear consequence for what the team does next.
Next step
I build stronger technical judgment through the Technical Product Manager Certification, a commercial Product HQ resource. The Product HQ newsletter shares practical guidance for product and engineering decisions.
