Temporary Markets and “Easy” Problems
The Suddenly Popular Idea of LLMOps
Sometimes, all of sudden, micro-markets emerge. They can be triggered by all sorts of things, for example an external change (COVID) or a new technical capability (LLMs). The current LLMOps/PromptOps space is an instructive example. Over the last year, the number of developers experimenting with AI model APIs has 1000X'd.
The cycle to date has been something like this:
- Models at scale have emergent behaviors that are magical and shocking.
- Consumers experienced DALLE2, ChatGPT, and a small number of LLM products gained real traction rapidly (Copilot, Jasper, Midjourney, Character).
- Startups have flocked to leverage these capabilities, VCs are funding them like it's 2021
- Many incumbent technology leadership teams are excitedly, anxiously resourcing AI projects.
These developers all start by tinkering: they try different prompts, chain together model API calls, connect to other non-AI services, and integrate with input data sources. OSS frameworks such as LangChain and LlamaIndex, and a significant cohort of YC companies have already emerged to solve some piece of this problem. A million developers are trying to do the same thing, experiment and ship a prototype. Entrepreneurial developers see an opportunity. The billion dollar question is whether all this interest leads to any durable market.
The history of software features many legendary companies that started with an elephant of a vision almost too big to take the first bite of (Figma, who collapsed several categories of software and put them into the collaborative web to solve end-to-end for product designers). But it is also populated by companies that iterated to platforms, starting with a timely wedge (Hubspot, which expanded from SMB content marketing to the only real contender to Salesforce).
We believe great companies can emerge from the morass of spaces like "LLMOps." But those that do will be teams that see the wedge for what it is, rather than misreading immediate momentum and interest for durable value. The distance between Github stars and Twitter likes and at-scale deployments and six figure enterprise contracts is very far. Solving an easy but acute problem in a temporary market, faster than others do, can be a smart entry point to get momentum. All things are possible for a startup with momentum, money, and the right management team.
When everyone sees the same needs, the bar for understanding those needs and executing on them goes up. The question is not, "Do developers want LLMOps?" but instead, "Which segment of those users do I focus on? What do they really need, and in what order? What will make the product easy to adopt, and what objections will I face? What architecture will support those users, and what compounding advantages can I build?"
AI is a landscape of shifting sands. What developers want today is not what they'll want in six months, and what they need to build demos is not what they need in production, is not what they'll need for integration into existing products. But demos could be the path to distribution. Marching in lockstep with customers along the path to market maturity requires being even more "niche" in an already small market because there are segments even now. The closer you are aligned with where some set of customers are today, the more customer trust you can build, the more likely you are to find demand others don't understand, the better chance you have of building a very important company.
At the beginning of a market, no one really knows what user needs are. Founders who have solved a problem themselves, ahead of the crowd (or a previous iteration of it) have some advantage. But because the market is evolving, founders who are learning from customers, who launch and then have the resolution of conversation necessary to really develop a product, have even more advantage. I’ve often been surprised how common it is for startups to have an insufficient depth of understanding of customer problems, or to misread the signals from customers. Especially when working with friends and early adopters, people are inclined to be nice. If a smart and charismatic team describes a high-level problem they face reasonably accurately, they’ll nod assent, nicely. “Would you like to lose weight?” is a very different question than, “will you lose weight by eating ⅓ fewer calories, not drinking socially, and prioritizing workouts four days a week?” Customers want to solve problems. They may not picture the roadblocks to adoption and tradeoffs. They may not be willing to be directly skeptical. Here is where increasing resolution of conversations, forced prioritization and asking for the sale all provide better signal.
Sometimes, emboldened by the strength of immediate need, and feeling the pressure to raise money and execute quickly in a noisy market, founders will be quickly drawn to “defensible technical depth” as their narrative to investors. The risk is that they're not yet sure it's true, but they say it enough to convince themselves of a world model that's wrong. Counterintuitively, recognizing that no part of solving the immediate problem is hard forces a more useful ongoing search and paranoia. Defensibility is overstated for most early-stage startups. It is wrongfully sought by investors, too.
The problem with the "sell picks and shovels during a gold rush" analogy is that picks and shovels are fungible, and software products are not. Eventually, defaults emerge. The risk of solving easy problems is that they're easy for other people to solve too. They can be solved by incumbents with a distribution advantage, or by other startups.
Leadership even in "temporary markets" is a valuable position, and "easy problems" can still be good entry points for startups to leverage. Almost any growing problem ends up deeper than it first appears.