How to run a product spike in an afternoon

You can run a product spike in an afternoon if you test one assumption, build only the screen where it lives and put it in front of five people the same day. The trick is not speed, it is being strict about what you leave out.

What a spike is, and what it is not

A spike is a time-boxed experiment that answers one question so the team can stop guessing. That is all. It produces knowledge, not a feature. The code is allowed to be ugly and is usually thrown away.

People get this wrong in two directions. Some treat a spike as a small version of the real project, with login, settings and a nice empty state. That is a first sprint wearing a costume. Others treat it as a meeting with slides. Slides tell you what people say they would do. A spike shows you what they actually do with a thing in their hands.

Choose one assumption

Pick the belief that, if wrong, makes the rest of the plan pointless. Then write it as a sentence that can turn out false. Good ones name a person, an action and a condition.

• Good: office managers will upload their own supplier spreadsheet without us cleaning it first.
• Good: a customer who sees a price estimate before booking will still book.
• Bad: improve onboarding. There is nothing in it that can fail.
• Bad: users will love the dashboard. Love is not an observable event.
• Bad: the system can handle ten thousand rows. That is a technical question, and a different kind of spike.

If you have three assumptions, you have three spikes. Do the scariest one first. The other two may stop mattering once it fails.

Write the kill criterion before you build

Decide now what result ends the idea. Put a number on it, and write it down where you cannot quietly edit it later. For the spreadsheet example: fewer than three of five people reach the confirmation screen without help, so the idea is dead in its current form.

Why bother? Because once you have built something, you are attached to it. Without a line drawn in advance, two people finishing becomes 'promising' and one person finishing becomes 'a good sign'. Every outcome gets read as a win. A kill criterion is how you stay honest with a version of yourself who has spent three hours on this.

A spike with no way to fail is just a demo.

Build the smallest thing

Describe only the screen where the assumption lives. With an AI app builder such as StarBuild, you do this in a chat, and the first message might read like this: build one page where a visitor uploads a CSV of suppliers; after upload, show a table of the rows we understood and a red list of the rows we did not; save each attempt in a database table with the time, the file name and whether the person pressed Confirm.

Notice what is in that request. The upload, the result the user has to react to, and a record of what they did. The record is the point of the whole thing, because it is your evidence.

Now what is left out, on purpose. No sign-in, because five people will use a link once. No settings page. No email. No mobile layout work. No real matching logic if a rough one is enough to make the screen believable. If a participant asks about something you skipped, that is a finding, not a bug. Write it down and move on.

Recruit five people fast

Five is enough to see the big problems, and it is about all you can recruit in an afternoon anyway. They should resemble the customer, not your team. A colleague from sales who has never seen the product is better than the engineer who sat in the planning.

Start with a message to people you already know: 'I am testing an idea, it takes ten minutes, no preparation, I need your honest confusion more than your opinion.' Ask existing customers, friends of the team in the right role, or whoever answers a short post in a community where your users hang out. Offer a coffee or a small favour in return. Book the slots before you finish building so you cannot slip the deadline.

Run the sessions and watch the right things

Publish the link, share your screen if it is remote, and give one task: 'you have this spreadsheet from a supplier, get it into the tool.' Then stop talking. This is the hard part for a product owner. Do not explain, do not rescue, do not say 'oh, you click there'.

• Where the cursor wanders before the first click. That is where the screen is unclear.
• Long pauses. Silence while someone hesitates is the best data in the session.
• What they say out loud when they are confused, in their words, not yours.
• Whether they finish the task at all, and how many hints they needed.
• Anything they try to do that you did not build. They are telling you the real flow.

Take notes as plain facts: 'paused eight seconds on the file field', 'tried to drag the file onto the table'. Save interpretation for later. At the end, ask one open question, like what they expected to happen next, and write down the answer verbatim.

Decide, then document

Put the results next to the line you drew earlier. Passed, failed, or neither. Do this the same evening while you still remember the pauses. Then write a short note in the backlog item: the assumption, what you built, what happened with each of the five, and the decision. Three sentences are enough if they are specific.

If it passed, you now have a reason to refine the story properly, and the prototype tells the team what the key screen should feel like. If it failed, you saved the team a sprint or two, which is the whole value of the exercise. Archive the prototype. If the builder lets you export the code to Git, keep it somewhere the team can find it, but do not let anyone ship it just because it exists.

When the result is ambiguous

It happens a lot. Two of five finish, which sits right between your kill line and your hope. Do not average it into a yes. First check whether your prototype was the problem: did the failures come from the assumption, or from a confusing label you could fix in ten minutes? If it was the label, fix it and run three more people on the same evening or the next morning.

If the failures were real but varied, split the assumption. Maybe it holds for customers with tidy data and fails for those without, and that is a segment decision, not a spike result. And if you still cannot tell, the honest outcome is 'not proven, here is what we would need to see'. Writing that down is a perfectly good spike. Pretending you learned more than you did is the only bad one.