Feasibility is free: why viable and lovable are the bar

If a competitor can clone your feature in a weekend with AI, the feature is not the moat. That is the whole shift. When feasibility approaches free, the scarce, defensible work is upstream (finding a problem worth solving) and downstream (making something people genuinely love). Interviewers at AI-native companies know this, and they are testing whether you know it too. The candidates scoring Strong Hire open with the judgment before touching the build. The ones scoring No Hire say “we could use AI to personalize it” and move on to a feature list.

What actually changed in 2026

The old PM triangle was viable, feasible, usable. All three constrained what shipped. In 2026, feasibility still has residual costs: latency floors, accuracy ceilings, cost-per-query that compounds at scale. Naming those is worth doing in an interview because it signals technical depth without overcomplicating the thesis. But the build itself is no longer where most products fail or succeed. A solo founder can ship a working AI feature in a day. This collapses one leg of the triangle and reweights the other two harder than most PM frameworks have caught up to.

That reweighting matters for interviews because CIRCLES and most product sense curricula were built for deterministic software. They treat feasibility as a meaningful constraint worth walking through. Interviewers at AI labs penalize candidates who use CIRCLES unreflectively because it signals the candidate has not internalized the shift. You do not have to name CIRCLES to get penalized: any answer that spends time on “how would we build this” before establishing “should we build this and will anyone stay” reads as pre-2024 thinking.

According to coaching data across 80 cohort candidates preparing for AI PM roles, product sense on the AI-specific shift correlates more strongly with level placement than behavioral outcomes. It is the differentiating signal at AI-native companies. Getting this right is not a nice-to-have; it is the test.

Viable: someone will pay, and the market is big enough

Viability is not “could this exist.” It is: is there a real problem people or companies will pay to have solved, in a market large enough to cover the cost of the work and still profit, so you can keep building? In interviews, “it’s a huge market” is a non-answer. The questions that produce a hire signal are sharper: who has the pain acutely and right now, what do they pay today to solve it (even imperfectly), why does this company win this market over a clone, and what is the moat.

On that last question: if feasibility is free, the moat cannot be “we built it first.” Speed-to-ship is not defensible. What is defensible in 2026:

• Data flywheel. The product improves with use in a way a clone cannot fast-forward. The training data, the feedback signal, the labeled corpus accrues to the product that ships first and stays used.
• Embedded workflow. The product is where the user already does the work, not a new tab they open. Switching cost is not a lock-in strategy; it is a consequence of being genuinely integrated into how work gets done.
• Network effects. Value compounds with each participant in a way that an empty clone cannot replicate.
• Trust from repeated high-stakes use. A clinical decision tool, a legal drafting product, a financial modeling assistant: these earn trust through consistent performance over time in situations that matter. A new entrant starts at zero trust regardless of feature parity.

Name the moat explicitly. Weak candidates omit it. Strong candidates name it and explain why a well-resourced competitor could not replicate it in six months. That specificity is what separates a hire from a strong hire on viability.

Anthropic’s on-record question, “increase Claude Code WAU 10x,” is a viability question wearing a growth hat. The right answer is not a feature list. It is a specific diagnosis of who is not using Claude Code today and why, which of those gaps is a real willingness-to-pay problem, and what would move those users from aware to retained. Strong candidates name the tradeoff explicitly: “the answer depends on current margin, competitive pressure from Gemini and Copilot, and where the next model release lands.” That level of specificity scores Strong Hire. See proving viability.

Lovable: beyond usable

Usability has a floor now. Any competent team using current tooling ships something that works. Lovable is the next bar: meeting people where they already work rather than asking them to change contexts, anticipating needs and addressing them proactively, and knowing when NOT to act because over-proactivity is its own failure mode. Getting the interaction sequence right so the job actually gets done is the harder design problem than making the UI clean.

What this looks like in practice:

• A coding assistant that surfaces a test failure in the editor where the developer is already reading the error, rather than requiring a context switch to a dashboard, is meeting people where they work.
• An AI that drafts a reply to a customer message and asks for confirmation before sending is proactive without being obnoxious. One that sends automatically is obnoxious. One that drafts and buries the draft in a sidebar the user never opens has failed the interaction sequence.
• An expense tool that prefills merchant, amount, and category from a receipt photo and requires one tap to submit gets the interaction right. One that opens a twelve-field form does not.

The test is not whether the product is usable. It is whether someone prefers it over doing nothing or using what they already have. “Delightful UX” is not the bar. “People come back on day thirty” is the bar.

The metric for lovability is not activation. Activation is a feasibility metric: it proves you can ship something people try. Lovability is proved by retention and depth of use. Do people return? Do they use more of the product over time, or do they narrow down to the one thing that justifies the switch? An answer that cites activation as the success metric in a lovability context signals the candidate has not thought past launch.

See lovable, not just usable for the full treatment, and obnoxious AI antipatterns for the failure modes that disqualify answers in interview.

How to use this in an interview

Open with the judgment, not the build. The sentence that scores the Strong Hire signal at AI-native companies:

“The constraint here isn’t building it. Anyone can ship this in a week with current tooling. The question is whether there’s a real willingness-to-pay problem and whether we can make something people genuinely prefer over doing nothing or using what they already have.”

That sentence does three things. It signals you understand the environment. It reframes the interview toward viability and lovability before the interviewer has to push you there. It sets up a structured answer where everything that follows proves those two claims with specifics.

What interviewers actually score

The difference between a hire and a strong hire on this dimension is specificity. A hire can articulate the framework: feasibility is cheap, viable and lovable are the bar. A strong hire applies it to the specific question with named segments, named moats, named failure modes, and named metrics. They also name what AI specifically changes about the problem, not just that “AI can help.” Interviewers at AI-native companies report that candidates who say “we could use AI to personalize it” score No Hire. Candidates who say “the model gives us [specific capability] which changes the cost structure of [specific step] and creates a data advantage because [specific flywheel]” score Strong Hire.

The other signal interviewers watch for: do you know when the AI answer is wrong? An AI feature that is technically feasible can still fail viability (nobody will pay enough to cover inference cost at scale) or lovability (the model is right 80% of the time and wrong 20% in ways that break trust). Naming those residual failure modes, and explaining how you’d measure and address them, is the mark of someone who has actually shipped AI products, not just theorized about them.

How this applies across company types

The frame is the same across contexts, but where you spend time differs.

At an AI lab like Anthropic or OpenAI, viability means understanding the company’s current margin position, competitive pressure from other frontier models, and how a product decision maps to model usage that funds the research mission. Strong candidates name the tradeoff explicitly: “the answer depends on current margin, Claude versus Gemini competitive pressure, and where the next model release lands.” Generic growth answers do not clear the bar.

At a consumer company like Meta, the lovability question dominates. Meta’s product sense round is thirty minutes traditional followed by thirty minutes prototyping using their Llama-based vibe coding tool. The point of the prototyping round is not to test whether you can build. It is to test whether what you choose to build reflects real judgment about what users will return to. The build is table stakes. Companies running vibe coding rounds including Google, Meta, Microsoft, Adobe, Figma, and Shopify have all reached the same conclusion: building is no longer the signal, choosing well is.

At an enterprise SaaS company, viability and embedded workflow are the whole game. The product has to live inside tools the buyer’s team already uses, prove ROI in the buyer’s language, and survive procurement. Lovability here is measured by whether the champion can get renewals past the CFO, not by NPS.

See kill the AI idea for the test you should run before any AI feature proposal.