Skip to main content
Value testing tells you whether customers want your solution. Feasibility testing tells you whether your engineers can build it. Both questions need answers before you commit to a direction - and teams that skip the second one often find out the hard way 😬 Feasibility testing is the practice of validating technical assumptions early in discovery, before significant design or engineering work begins.

​
Why it belongs in discovery

The classic mistake is treating feasibility as an engineering concern that gets figured out during development. By then, you’ve already committed to a solution, stakeholders have expectations, and “actually we can’t build this” becomes a crisis instead of a learning. When engineers are part of the product trio and attend discovery sessions (see Product Trio), feasibility questions surface naturally and early. An engineer in a customer interview will hear something and immediately think “that would require real-time data processing we don’t have” - that’s a feasibility signal, and it’s infinitely more useful on day one than on day thirty.

​
What you’re testing

Feasibility assumptions typically fall into a few categories: Technical complexity - Can we build this with our current stack? Does it require capabilities we don’t have? How long would it realistically take? Data availability - Do we have the data this solution needs? Is it clean enough? Can we access it at the speed the solution requires? Third-party dependencies - Does this rely on an API, integration, or external service that may not exist, may be unreliable, or may be prohibitively expensive? Performance and scale - Does the solution work at the scale we need? A prototype might work for 10 users; will it work for 100,000?

​
How to run a feasibility test

Feasibility testing doesn’t need to be formal. It’s usually a spike - a short, time-boxed technical investigation to answer a specific question. “Can we process payments via X provider?” - one engineer, two days, yes or no. “Can we surface real-time inventory data in the UI?” - small proof of concept, three days, confidence level returned. The output isn’t working code. It’s a confidence level on a technical assumption. High confidence - move forward. Low confidence - revisit the solution or adjust scope.

​
The right time to test

Feasibility questions should be asked in parallel with value and usability testing, not after them. By the time you’ve validated that users want something and can use it, you want to already know whether it’s buildable. Lesson learned: the most painful product situations I’ve been in were ones where we’d sold a vision to customers - sometimes literally - before engineering had a chance to poke at the hard parts 🤦 Test feasibility early, test it cheaply, and make it a team habit rather than a last-minute check.