Software is getting cheaper to produce. A capable team can turn an idea into a working prototype in days, and AI-assisted tools have shortened the distance between a conversation and something people can use. That gives founders and product teams more room to explore. It also removes friction that once forced difficult decisions before work began.
That friction had value. When engineering capacity and budget were visibly scarce, teams had to decide what mattered, what could wait, and what they were prepared to own. Now a dashboard, assistant, workflow, or internal tool can feel close enough to build that the conversation shifts straight to delivery. A convincing demo can look like progress even when nobody has established whether it deserves a permanent place in the business.
The scarce skill is no longer simply producing software. It is product judgment: seeing the full business and product equation before a quick build becomes a lasting obligation. An MVP is not a business model, and shipping is not proof of viability.
The new bottleneck is choosing
This is the Build-It-Because-We-Can syndrome. It appears when technical possibility becomes the reason to act. The team asks how quickly it can show something instead of whether the work solves a meaningful problem, fits the company’s direction, and can earn ongoing investment. Speed then amplifies weak choices just as efficiently as strong ones.
The better question is not only, “Can we build this?” It is, “Would this become a viable, sustainable business or product if we did?” It includes the problem, buyer, experience, economics, operating model, and burden after launch.
Start with the problem and the people around it
A viable product begins with a problem described without the proposed solution. What friction, delay, risk, cost, or missed outcome exists today? How often does it happen, who feels it directly, and why does it matter now? A problem that is occasional or mildly inconvenient may still be worth solving, but it needs a proportionate response rather than a product built around a weak signal.
The people involved are rarely one group. The person experiencing the problem may not be the daily user. The user may not control the budget, while the buyer may not own the outcome that determines whether the work succeeds. A team needs to identify each role, including the person accountable when the promised result does not happen.
That distinction changes the decision. A user may welcome a smoother workflow while a buyer sees no reason to fund it. A sponsor may want a capability while the operating team inherits the extra work. If nobody owns the outcome after launch, the initiative risks becoming an under-owned product with a growing list of requests and no clear decision-maker.
People have usually found a way to cope, whether through spreadsheets, manual handoffs, a competitor, a general-purpose tool, or acceptance of the inconvenience. Those alternatives reveal the real bar. They show what people tolerate and what must be meaningfully better for a new product to change behaviour. They also prevent a team from mistaking a familiar workaround for proof that a new solution is wanted.
Demand must support a business, not a demo
Positive feedback is not enough. People can like an idea, admire a prototype, and still keep doing what they do today. More useful evidence is behaviour that shows severity and urgency: repeated effort, an attempt to solve the problem already, a willingness to change a process, or a willingness to pay for a better outcome. The point is not to force a purchase before any product exists. It is to distinguish interest from the commitment that could support one.
Willingness to pay needs the same honesty. It is not answered by asking whether someone likes a feature. It is answered by understanding whose budget is involved, what value they expect in return, what approval is required, and what they would compare the spend against. If the buyer cannot see a credible reason to move money, time, or attention from an existing priority, adoption alone will not create a business.
Commercial viability follows from that logic. A team should explain how the product could generate enough recurring or repeatable value to justify its costs, without inventing a market size or price to make the story work. The revenue path may be direct payment, retained customers, reduced operating effort, or a strategic capability that supports a larger offer. What matters is whether that path is specific, believable, and connected to a buyer who benefits.
Feasibility includes the cost of staying alive
A product is not feasible because a prototype runs. The team must understand what technology, data, permissions, integrations, and reliability the real experience depends on. An AI-enabled workflow may look simple until it requires access to sensitive information, accurate outputs in edge cases, human review, or a dependable connection to systems the company does not control. Those limits are product constraints, not details to postpone until after launch.
Accuracy deserves particular care. If an incorrect answer wastes time, creates risk, or leads someone to make a poor decision, the product needs a clear way to prevent, detect, or explain that failure. Reliability has the same practical meaning. Users do not experience a system as technically impressive if it is unavailable when they need it, produces inconsistent results, or cannot explain what happened.
The operating cost is broader than hosting or development. Someone must support users, handle incidents, maintain integrations, improve the product, keep documentation current, secure data, answer questions, and make decisions when requests conflict. These costs may be manageable, but they should be visible before a team commits. A cheap build can create expensive organisational debt when its ongoing work has no budget, owner, or priority.
The experience has to repeat
A compelling demo is designed for a controlled moment. A viable experience must work in the ordinary moments that follow. Can a user understand what to do without a presenter beside them? Does the product fit their actual workflow, including handoffs and exceptions that a prototype often avoids? Does it produce a result valuable enough to bring them back?
Teams should also resist the idea that every request belongs on the roadmap. A growing feature set can hide a weak core problem, confuse users, raise maintenance costs, and make ownership harder. Some requests should be declined, merged into an existing workflow, paused until the evidence improves, or stopped entirely. The discipline is not in building the longest list. It is in protecting the value that makes the product worth returning to.
A product and business viability test
Before building, expanding, or keeping an initiative alive, founders and product leaders can use a broader test. Start by writing the problem in plain language and naming the affected person, user, buyer, and outcome owner. Then assess its severity, frequency, cost, urgency, and current alternatives. If the answer relies on assumptions, make those assumptions visible rather than allowing a prototype to conceal them.
Next, test whether demand and economics connect. Ask what evidence suggests people will change behaviour or pay, who controls that decision, and how the product creates revenue, strategic value, or enough operational benefit to justify itself. Then examine the practical delivery model: the data required, accuracy and reliability expectations, permissions, integrations, support needs, security responsibilities, and ongoing maintenance. A plan that works only while its original builder is available is not yet sustainable.
Finally, decide the smallest experience that can create repeatable value, and define what should not be built. Set conditions for expansion as well as conditions for pause, redesign, merger, or retirement. This gives a team permission to stop a weak initiative before it becomes permanent by default. Stopping is not always the opposite of growth. Sometimes it keeps attention available for the work that still deserves it.
The current conversation around AI often focuses on what technology will make possible next. For founders and product leaders, the more urgent question is what deserves to become real inside their company. The strongest teams will not be the ones that build the most. They will be the ones that can see whether the problem, buyer, economics, experience, operating model, feasibility, and maintenance burden form a business worth sustaining.
That is product judgment. And it is becoming the scarce skill.
Sources
- Dario Amodei, “We Must Pace the Frontier”: https://darioamodei.com/essay/the-adolescence-of-technology
- Hacker News discussion: https://news.ycombinator.com/item?id=49672510