Proof of Concept Design: From Key Assumptions to Actionable Conclusions

The Bottom Line: A PoC Is Not About “Building It” — It Is About “Knowing If It Works”

PoC is the most misunderstood tool in technical decision-making. The most common failure is turning a PoC into “half a system” — investing significant time without answering the critical question.

---

1. Step 1: Identify Key Assumptions

Before starting a PoC, list all assumptions where being wrong would be most expensive. These are what the PoC should validate.

Typical Key Assumption Types

Type	Example
Performance	”This database can handle 100K writes/second”
Compatibility	”This SDK supports our Linux kernel version”
Reliability	”This protocol survives 1% packet loss without disconnection”
Integration cost	”This API auth flow can integrate with our unified auth”
Learning curve	”The team can be productive with this framework in 2 weeks”

Key vs Non-Key

A key assumption: if this is wrong, the approach must change. If yes, it must be PoC’d. If the answer is “we can work around it,” skip the PoC and handle it during development.

---

2. Step 2: Define Pass/Fail Criteria

Each key assumption maps to one clear criterion:

Under [condition], [metric] reaches [threshold]

Good criteria:

• “On a 10-node 4C8G K8s cluster, single-node write throughput reaches 50K points/second, P99 latency < 50ms”
• “Under 1% random packet loss, 50ms latency, the connection auto-recovers within 30 seconds with zero data loss”

Bad criteria:

• “Performance must be good enough” (not measurable)
• “The system must be stable” (no quantitative standard)
• “Must integrate with our system” (not specific)

---

3. Step 3: Scope Control

Minimum Viable PoC

For each key assumption, ask: What is the least work needed to validate this?

Example — validating “Kafka can handle 100M messages/day”:

• ❌ Wrong scope: Full Kafka cluster + producers + consumers + monitoring + data pipeline
• ✅ Right scope: 3-node Kafka cluster, a simple producer load test script, verify throughput and latency

Warning Signs of Scope Creep

1. Discussing “should we add this feature” — you are building, not validating
2. Writing documentation — only write what the validation needs
3. Discussing UI / interaction — technical PoCs need no interface
4. Handling error cases — PoCs validate the happy path

---

4. Step 4: Execution and Recording

Execution Principles

• One assumption at a time: testing multiple assumptions simultaneously means you cannot isolate the cause of failure
• Record all conditions: hardware config, software versions, parameters — reproducibility depends on this
• Failure is a valid conclusion: document the failure and its conditions — this is more valuable than a “success”

Output Format

PoC Report

Assumption: Single-node write throughput reaches 50K points/second on 10 4C8G nodes
Method: 3-node cluster + load test script (see git tag poc-v1)
Result: 62K points/second, P99 latency 32ms ✅
Conclusion: Assumption validated, approach feasible
Risk: Happy path only, failure scenarios not tested

---

5. Three Common Pitfalls

Pitfall 1: PoC Becomes Development

Halfway through, someone says “we have already built half of it, let us finish it.” This is the most expensive trap. A PoC validates assumptions, not delivers features. A finished PoC is not a product — it is an over-invested validation.

Pitfall 2: Avoiding Bad News

When PoC results are not ideal, the tendency is to “tweak parameters and try again” until the result looks good. This is confirmation bias. Let the data speak. If three attempts all fail, the conclusion is “this approach is not viable under these conditions.”

Pitfall 3: Starting Without Criteria

“Let us just run it and see” is the most common PoC starting point. A PoC without pass/fail criteria has no end — you will never know when validation is complete. Set criteria first, then execute.

---

Summary

Phase	Core Action	Deliverable
Identify assumptions	List “most expensive to be wrong” assumptions	Key assumption list
Set criteria	One measurable pass/fail per assumption	Criteria table
Control scope	Minimum work for single assumption	Scope document
Execute	Record conditions, results, conclusions	PoC report
Decide	Go / switch / abandon based on conclusions	Decision record

A good PoC is not measured by what it built — it is measured by what it saved you from. The greatest value of a well-executed PoC is stopping you from investing significant resources in the wrong direction.

Related reading

• How to Run a Technical Review — where PoC fits in the technical review workflow
• Microservice Decomposition — architectural path after PoC validation
• Monolith to Microservices Migration: 6 Proven Strategies — migration execution plan after PoC validation
• How to Find a Reliable Software Development Partner — team selection & outsourcing guide

Need feasibility verification or solution consulting? Contact us — tell us your evaluation goal and constraints, feasibility within 24 hours.