Three questions behind a promising idea
A product concept can sound compelling in a presentation yet struggle in everyday use. Evaluating it means looking beyond its most exciting feature. Desirability asks whether people have a problem worth solving and would choose this solution. Feasibility asks whether a team can make and deliver it reliably. Viability asks whether the product can keep operating without consuming more resources than its backers can provide.
These questions overlap, but they are not interchangeable. A beautifully designed device may be possible to build yet too costly to maintain. An affordable service may address a real need but depend on technology that works only under controlled conditions. The goal is not to award three perfect scores on day one. It is to identify the most important uncertainties and learn enough to make a sensible next decision.
Desirability: start with the situation, not the feature
Consider a concept for a countertop device that helps households sort food scraps for collection. Before designing sensors and an app, ask what people currently do with scraps. Is sorting confusing, unpleasant or time-consuming? Who experiences the problem most often, and what do they do when a device is not available? A concept is more likely to be useful if it fits an existing routine or makes a difficult routine noticeably easier.
Conversations and observation can reveal needs, but compliments are weak evidence on their own. Someone may say they like the idea without wanting another object on the counter. A stronger test asks people to try a simple mock-up during a realistic task, then watches where they hesitate or abandon it. Look for differences between what people predict they will do and what they actually do. If the concept serves several groups, such as households and collection operators, test the needs of each.
Feasibility: test the whole experience
Feasibility includes more than whether a component functions in a demonstration. For the sorting device, a prototype might recognize common scraps on a clean workbench. Daily use raises harder questions: What happens when items are wet or mixed together? Can people clean the device easily? Will it fit in typical kitchens, and can replacement parts be obtained? A successful technical test answers only the question it was designed to test.
Separate what is established from what remains hypothetical. A basic container and lid may use familiar manufacturing methods, while automatic identification might still be an experimental feature. Build the simplest prototype that can challenge the riskiest assumption: a physical mock-up for size and handling, or a limited sensor test for recognition. Also consider installation, accessibility, repair and disposal. If a feature cannot yet perform reliably, the team might offer a simpler version rather than treating a future capability as an existing one.
Viability: account for the cost of keeping a promise
A product can meet a genuine need and be technically possible without being viable. Making the device is only one expense. Packaging, delivery, customer support, replacement parts and software upkeep may matter over its lifetime. If a collection service is part of the concept, its operating costs also belong in the evaluation. Estimate these elements as ranges rather than presenting an early guess as a precise forecast.
Viability also depends on who gets value and who pays. A household might welcome easier sorting but resist a subscription; a building manager might pay if the system is manageable across many homes. Those are possibilities to test, not assumptions. Try a simple cost model and compare a few versions of the concept. Removing a costly sensor, for example, could lower the price and simplify repairs, but it might also reduce the convenience that made the idea desirable.
Use the three lenses to decide what to test next
Put the concept on one page. For each lens, write down the main assumption, the evidence already available and a small test that could prove the assumption wrong. Avoid averaging the results into a single impressive-looking score. One unresolved issue, such as a device that users cannot clean or a service with no plausible payer, may matter more than several encouraging observations.
After each test, choose whether to continue, change the concept or set it aside. For the sorting device, that could mean keeping the useful countertop design while dropping automatic recognition, or exploring a shared solution instead of one device per home. Desirability, feasibility and viability are not gates a concept passes once. Revisit them as the design changes: improving one part can create a new constraint elsewhere. That habit helps turn an appealing idea into a product people can use and a team can realistically deliver.
