A product hypothesis is cheap to state and expensive to leave untested. "We believe real-time recommendation scoring will increase conversion" sounds reasonable in a planning meeting. Whether it is actually true, under real data volume and latency constraints, is an engineering question, not a product one. That is exactly what a proof of concept is for.
Getting from hypothesis to a useful POC requires more discipline than most teams apply. A rushed technical feasibility study tends to prove the wrong thing, leaving the real risk unaddressed even after weeks of work.
Step 1: Isolate the actual unknown
Every product hypothesis contains multiple assumptions, but usually only one or two carry real technical risk. Before writing any code, separate what is genuinely uncertain from what is simply unbuilt. If the team already knows how to do something, testing it in a POC wastes time. A proper technical feasibility assessment starts by naming, explicitly, the single riskiest unknown the POC needs to resolve.
It helps to write this down as a single sentence: "We do not know whether X is possible under condition Y." If the team cannot state the unknown this precisely, the POC has not been scoped yet, no matter how much enthusiasm exists for starting to build.
Step 2: Define a falsifiable success condition
"See if it works" is not a success condition. A usable POC needs a number: sub-200ms response time at expected load, 90 percent classification accuracy on a representative dataset, successful integration with a legacy system's actual API, not a mocked version of it. Without a defined threshold, POC development process discussions tend to drift into subjective judgment calls about whether results "feel good enough."
Setting the threshold before running the test also protects against the temptation to move the goalposts after seeing a disappointing result. Once a number exists on paper, it is much harder to quietly redefine success after the fact.
Step 3: Strip everything that is not the unknown
This is where POC software development differs most from production work. No authentication, no error handling beyond what is needed to get a reading, no UI beyond the minimum needed to observe output. Every hour spent polishing something outside the core unknown is an hour not spent answering the actual question.
A useful discipline: before building anything, list what the POC explicitly will not include. If that list is short, the scope is probably still too broad. Reviewing this list with a second engineer, someone not emotionally invested in the idea, often catches scope creep before it starts.
Step 4: Design the POC architecture for disposal
POC architecture should assume the code will be deleted, not extended. This changes real decisions: use the fastest tool to stand something up, even if it is not what production would use. Hardcode configuration instead of building it out. Skip tests beyond what confirms the core result. Teams that build POCs "cleanly, just in case" usually end up spending POC-level time on production-level rigor, defeating the purpose.
Step 5: Run it against realistic, not convenient, conditions
A POC tested against a small, clean sample of data will often produce a misleadingly positive result. Wherever feasible, test against data volumes, edge cases, and system conditions that resemble production, even if the POC itself is disposable. An algorithm that performs well on a curated dataset and poorly on messy real-world data has not actually answered the question the business needed answered.
Step 6: Document the result, not the code
The valuable output of a POC is a written answer to the original question, with supporting data, not the codebase itself. A short writeup covering what was tested, under what conditions, with what result, and what it implies for the real build is far more useful six months later than the throwaway repository.
Step 7: Make the go or no-go call explicit
A POC that quietly gets absorbed into "well, it kind of worked" without a clear decision has failed at its actual job. The team should explicitly answer: does this result support building the real feature, does it require rethinking the approach, or does it kill the idea. Any of these three is a successful POC outcome. The only unsuccessful outcome is ambiguity.
A tightly scoped POC, run this way, usually takes days, not weeks, and gives a much clearer answer than a broader effort that tried to prove too much at once. The discipline of scoping tightly is, in most cases, more valuable to a team's long-term velocity than the answer to any single hypothesis.
Top comments (0)