The Focus Advice Is Right. It’s Just Aimed at the Wrong Moment.
AI lets founders build and test more ideas than ever. Focus still matters, but when one capability can become ten different products, founders first need to discover which application actually deserves it.
“Find a problem. Pick a customer. Focus. Productize. Make it obvious.” Every founder has heard this. Most have said it to someone else. It is good advice, but it describes where you want to end up more clearly than how you get there.
AI has made that distinction more important. Sam Altman, CEO of OpenAI, told the room at Y Combinator’s Startup School in 2026 that work his first startup took three months to build by hand in 2005 could now be produced by a coding agent in about seven minutes.1 Michael Wee, a venture investor and Forbes contributor, describes the same shift from another direction: building the initial product used to be the expensive and scarce part of starting a company, while what becomes scarce instead is “judgment, distribution, and the discipline to build for where the models will be, not just where they are.”2
That sounds like an advantage, and it is. But it also removes a constraint that used to make decisions for founders. When building five applications was expensive, you picked one early because you had to. When the same underlying capability can now become five prototypes surprisingly quickly, nothing forces the choice. The founder has to provide the discipline that scarcity used to provide for free.
This is not an argument against focus. Paul Graham, co-founder of Y Combinator, made a related point in early 2025: as writing code turns into a commodity, understanding the user’s actual problem becomes more important, not less.3 A researcher writing for NYU’s entrepreneurship program pushed the same idea further, arguing that when building got easy, real customer discovery started to matter more because a working demo is no longer strong evidence that real demand exists.4 The question is increasingly not whether something can be built, but which of all the things that can be built deserves to become the product.
When the capability comes before the product
This question becomes especially difficult when a company has developed an underlying capability that can be applied to several different problems. The capability might come from technology, data, accumulated knowledge, workflows, networks, trust, expertise, or some combination of them. One application could solve a content problem, another identify sales opportunities, a third provide market intelligence, and a fourth help match founders and investors.
Such a fundamental, reusable capability is sometimes described as a primitive. AWS is an obvious infrastructure example. Palantir represents a somewhat different model: an underlying capability is applied deeply to specific customer problems, and what gets learned through those implementations can feed back into the platform itself. The important point is not the terminology. It is that a strong capability does not always reveal its best product immediately.
This is where conventional focus advice becomes difficult to apply. If one capability could credibly become five different products, telling the founder to “focus” is not yet an answer. Focus on what? The founder still has to discover which problem, customer and application deserve that focus. AI makes it cheaper to explore those possibilities, but it does not make the judgment for you.
Running broad for a period is therefore not necessarily the same as being unfocused. There is a difference between randomly chasing opportunities and deliberately testing several applications of the same underlying capability. The first produces motion. The second can produce evidence. The purpose of the exploration is still convergence: finding the applications where the same problems, buyers and value patterns start appearing repeatedly.
Two conversations, two kinds of evidence
Real customers are where that evidence comes from, but not every useful customer conversation looks the same. Early in discovery, there are at least two different conversations worth having, because they reveal different things about the same capability.
One buyer is concrete. They want to know what they can buy, what it costs and what they get. They force the capability into something specific, priced and bounded. A recurring signal report on a narrow slice of competitor activity, for example, can become a clear subscription with a fixed scope and price. This buyer helps reveal what a sellable slice of the capability could look like today.
Another buyer approaches the same capability conceptually. They want to understand what it really does, where it could go and whether it intersects with something they are already trying to accomplish. Someone who understands a signal-detection capability might ask whether the same system could identify investor fit during a fundraising process. That is not primarily a question about price or packaging. It is evidence about the possible boundaries of the capability itself.
These conversations can happen in the same week, with completely different people, and neither is necessarily more valuable than the other. The concrete buyer helps show where a product can begin. The conceptual buyer helps show where the capability might eventually go. Treating the second simply as an earlier stage of the first misses what is being learned. They are two instruments reading the same underlying signal from different distances.
This also suggests that not every potential customer should be approached in the same way. A buyer looking for a straightforward solution should not need to understand the architecture, philosophy or full potential of the underlying capability before they can see value. Give them the clear application first. With the right strategic buyer, however, a more open conversation can be worth having because the unexplored applications themselves may contain valuable information. The broader the conversation, the more important it becomes that the potential value and learning justify the time spent exploring it.
Confusion is product data
There is another form of evidence that founders can easily interpret as failure: the customer who does not understand.
“What problem does this actually solve?” is uncomfortable to hear when you have spent months thinking about the answer. But during discovery, the question contains information. Perhaps the problem is unclear. Perhaps the wrong application is being presented to the wrong buyer. Perhaps the founder is explaining the capability instead of the outcome. Perhaps the customer understands the value but cannot imagine how it fits into their existing work.
The goal is not to become comfortable with confusion. It is to use it. If ten people fail to understand the same thing, there is probably something to simplify. If several unrelated customers independently ask whether the capability could solve the same adjacent problem, that is another signal. If several are willing to pay for the same narrowly defined application, the signal becomes stronger still.
This is an important distinction for founders working with broad capabilities. A messy early explanation does not prove that there is no product. It proves that the product has not yet become clear enough. Failure is not hearing “I don’t get it.” Failure is hearing it repeatedly and learning nothing from it.
The buying process is part of the product
Customer discovery also needs to reveal more than what people want. It needs to reveal how their organizations are capable of buying it, because understanding a product and being able to adopt it are separate problems.
A customer can fully understand the value and still fail to buy because of procurement, security review, integration costs, legal requirements or internal politics. Call the first kind of problem understanding friction and the second buying friction. Both produce information about what the product eventually needs to become.
Consider an application that requires listening to every salesperson’s calls, processing sensitive internal data, connecting to a CRM and passing a security review. Selling that as a cheap self-service product may make little sense even if the technology itself is inexpensive to operate. The buying process requires significant organizational commitment. Enterprise-level pricing may be necessary not only to cover acquisition and delivery costs, but because senior stakeholders need to consider the problem important enough to spend their own time approving the project. A large price does not guarantee importance, but a very small price attached to something structurally difficult to adopt can signal that it is not important enough to justify the effort.
The inverse also holds. Another application of the same underlying capability might require no integration, touch no sensitive data and be usable immediately by one person. That could become a low-friction product bought directly by a business owner or functional leader. Same underlying primitive, but a very different product because the buying process, not only the feature set, helps define what the product actually is.
This is also why discovery cannot stop at asking whether customers like an idea. You need to understand who can approve it, what has to happen before they can use it, what organizational risk it creates and whether the value is large enough to justify that process. Those constraints are not administrative details to solve after product-market fit. They are part of the evidence that tells you what kind of product you are actually building.
Clarity is downstream
The standard advice, find a problem, pick a customer, focus and productize, is still right. The mistake is treating a description of the destination as a complete set of directions for getting there.
Steve Blank, the Silicon Valley entrepreneur turned Stanford and Berkeley professor whose Customer Development methodology reshaped how a generation of founders approach early growth, made the underlying distinction plainly: a startup is not a smaller version of a company. It is a temporary organization searching for a business model rather than executing one it already knows. His prescription was blunt: get out of the building. There are no facts inside it, only opinions.5
The same logic applies when the uncertainty is one level deeper. You may already know that an underlying capability works, but not yet know which application of that capability should become the product. The search then consists of putting concrete applications in front of buyers, having broader conversations with people capable of seeing other possibilities, watching what people understand immediately, paying attention to what repeatedly confuses them, and learning how their organizations actually buy. Over time, some patterns disappear and others keep returning.
Blank made a second point worth carrying over directly: hiring a VP of Sales before the business model has been found is one of the common ways startups fail, because that person is trained to execute a known playbook and, during the search phase, there is no stable playbook yet to execute.5 The same mistake can happen with productization. Forcing a still-being-discovered capability into one segment, one application, one price and one message before enough evidence exists can simply make a company extremely focused on the wrong thing.
The founder’s job during this period is not to defend the original guess. It is to notice which guesses keep surviving contact with reality: which problems repeat, which buyers care enough to act, which applications are easy enough to adopt, which questions keep returning, and which parts of the underlying capability become more valuable each time they are used.
The goal is still the obvious product. The customer should eventually be able to understand what problem it solves, for whom and why it matters almost immediately. But that obviousness does not have to exist on day one. It can be the result of dozens of messy applications, conversations, misunderstandings and corrections.
Clarity is an outcome of discovery, not a prerequisite for it.
Sources
Sam Altman, in conversation with Garry Tan at Y Combinator’s Startup School, July 2026. Reported by multiple outlets, including The AI Corner and BigGo Finance. ↩
Michael Wee, “The New Logistics Of Startup Ideas In The AI Age,” Forbes, August 2, 2026. Link ↩ ↩2
Paul Graham, post on X, February 10, 2025. ↩
“Speed Is Not Strategy: Why AI Can’t Replace Customer Discovery,” NYU Entrepreneurship blog, December 8, 2025. ↩
Steve Blank, “How to Build a Great Company, Step by Step,” Commonwealth Club, August 14, 2012; framework also set out in The Startup Owner’s Manual (Blank and Dorf, 2012). ↩ ↩2
