Rethinking Product Strategy in the Age of AI
How founders and executives should think about product form, workflow design, and the defensibility of AI products
One of the most important forces shaping AI applications has been product form. In 2023, when I was investing as a venture capitalist, one of my biggest reasons for passing on many AI application startups was that they felt like ‘wrappers’ around ChatGPT. I had picked up that term on Twitter, though in this piece I want to define it in a more thoughtful way.
That hesitation was not theoretical. It came from experience. I had already burned my fingers investing in startups building domain-specific AI image products for businesses on top of foundational image models like Stable Diffusion and DALL·E. Startups like these usually run into two core problems.
The first is that customers care deeply about output quality. In the example I saw, the requirement was hyper-realistic furniture images. In practice, customers wanted near-perfect realism, often closer to 99 to 100 percent quality than something merely good enough. That was the real problem. The product could only be as strong as the underlying image generation models powering it, and at that stage those models were simply not reliable enough. A founder building on top of any underlying foundational model has only limited control over improving the result. In many cases, the company’s success ends up being tied to capabilities it does not actually own.
The second problem is the exact opposite. Sometimes the underlying model improves so fast, and adds so many new features and product experiences, that the startup built on top of it starts to look unnecessary. That is what is happening across a large part of the AI startup landscape today. Quite a few VC-backed companies are potentially headed toward irrelevance. That, in my view, is where the real bubble sits.
But the smartest AI entrepreneurs saw this risk early. They realized that succeeding in AI would require going beyond traditional product management playbooks and rethinking how humans and AI interact. If applications built on top of foundation models could not fully control accuracy and efficiency, and those had already become table stakes anyway, then they needed to build defensibility somewhere else. That somewhere else was experience.
Reimagining experience in the age of AI came down to three critical choices.
- The first was about initiation. Who actually kicks off the AI? Is it the human? Is it a software system that triggers AI when context changes? Or is it the AI itself, acting on its own?
- The second was about scope. What is the AI allowed to touch? Is it limited to text? Does it only have read-only access to outside sources? Or can it take editable action across the many tools an enterprise already uses?
- The third was about how errors compound. In a one-step workflow, a mistake is usually visible, diagnosable, and fixable. But in a twelve-step process, an error at step two can quietly carry forward all the way to step twelve, creating fresh problems along the way.
This third parameter is especially important. Solving for data, context, and execution is what creates a near-zero-error experience, and that is what actually delights customers. And those near-zero-error experiences do not happen by accident. They depend on how well the AI system is architected underneath, which is where real product defensibility begins to emerge.
Out of these choices came five core product archetypes in AI apps:
The progression shown in the image above has shaped product strategy across the entire AI ecosystem, not just for startups, but also for incumbents and frontier labs like OpenAI and Anthropic. The first wave was simple and powerful. Companies won users through chat-based products built on top of their models. Once ChatGPT and Claude saw broad adoption as consumer-facing assistants, both companies opened up APIs. That unlocked a flood of startups building narrow applications on top of these foundation models. These were the products many people casually started calling ‘wrappers’.
But the bigger shift came when the model stopped being just something you talk to and started becoming something that could plug into the rest of the software world. Anthropic’s introduction of the Model Context Protocol mattered because it made it much easier for models to securely connect with external tools, applications, and data sources. That changed the role of the model itself. OpenAI and Anthropic were no longer just offering chat interfaces and APIs for text generation. They were moving toward assistants that could understand context and begin interacting with the tools people already use every day.
As model quality improved, this shift accelerated. Models became better at handling larger context windows, better at working across tools, and better at carrying memory across sessions and even outside the session itself. That mattered because it helped break one of the biggest limits of the copilot era. Copilots were useful, but they were usually trapped inside a specific product, workflow, or ecosystem. Agents changed that. With agents, the human sets the goal, but the system can decide how to get there, break the task into steps, move across tools, and execute with far more independence. That is where the current product innovation wave is really happening in 2025 and 2026.
What makes this evolution so important is that every shift in product form expands both capability and risk. Moving from API to chatbot, from assistant to copilot, and from copilot to agent increases what the product can do, but it also increases how many things can go wrong. The surface area for error gets wider at every step. And that is exactly why the winners in AI will not just be the ones that make these systems more powerful. They will be the ones that design them to be reliable from day one.
The final phenomenon that meaningfully changed how organizations think about AI product strategy was Cursor.
Before Cursor, incumbents had already started responding to the rise of ChatGPT and Claude by layering AI into products they already owned. GitHub Copilot was one of the strongest early examples. Inside the VS Code ecosystem, it showed just how valuable AI could be for developers. But it also revealed something deeper. Adding AI into an existing product is not the same as rebuilding the product around AI. That gap created the opening Cursor went after.
There were three reasons this opening mattered.
- GitHub Copilot lived inside VS Code as an extension, which meant it had to operate within the boundaries of what the extension layer allowed. It could read files, suggest completions, and open a chat sidebar. That was powerful as a starting point, but it still left AI sitting at the edge of the developer experience rather than at the center of it. It did not fundamentally redesign how the editor behaved. It could not natively hold the entire repo in context, rethink core interactions like the tab key or command palette, or move fluidly across terminal, file tree, and multi-file rewriting as a deeply integrated system. That was the ceiling of building on top of someone else’s product surface.
- Microsoft’s scale was an advantage in distribution, but a constraint in product speed. GitHub Copilot’s roadmap was only one input among many shaping the broader direction of Microsoft and the VS Code ecosystem. In a large company, product decisions move through more layers, more tradeoffs, and more internal alignment. And when the company is public, those decisions are judged even more carefully because they tie back to revenue, customer expectations, and platform stability.
- Third, and perhaps most importantly, product choices at Microsoft had to remain aligned with Microsoft’s broader business model. GitHub Copilot could not evolve in ways that too quickly disrupted Azure, GitHub’s enterprise packaging, or other parts of the stack. Large companies almost always innovate with one eye on what must be protected. That creates space for startups. Startups do not have to defend the old system. They just have to build a better one.
Cursor saw that opening clearly. It recognized that developers already loved VS Code because it was familiar, flexible, and deeply embedded in daily workflows. It also recognized something equally important. Coding is unusually well-suited to AI. It is structured, testable, and full of feedback loops. Outputs can be checked. Errors can be caught. Improvements can compound quickly.
What Cursor did was not just add AI to the editor. It rebuilt the editor around AI. By forking VS Code at the application level, Cursor gave itself the freedom to redesign the product much more deeply. It could rethink how key interactions worked across the editor, the command palette, the file tree, and the terminal. That architectural decision is what allowed Cursor to solve the earlier constraints in a way extensions could not.
- It gave AI awareness of the broader codebase without having to wait on Microsoft. That created room for richer agentic workflows that would have been much harder to deliver if the product had remained just another layer on top of the existing ecosystem.
- It also benefited from organizational focus. Cursor was not one priority among a hundred. The company was the product. A lean, aligned team could move fast and ship features like multi-file editing, codebase indexing, and agent mode with far greater urgency.
- And its incentives were simple. Cursor did not need to protect a larger platform strategy. It just needed to build something developers loved enough to pay for. That is a very different motivation from the one driving Microsoft and GitHub.
Cursor’s success was not just limited to building a great product for developers. It showed that in the agent era, the winning move is often rebuilding the entire workflow around the agent. In that sense, Cursor introduced a new product form for agentic software. The agent was no longer just a helper sitting beside the product. The agent became deeply embedded in the product surface, the interface, and the way work actually got done. It gave the market a blueprint for a whole new category of products, which is why so many founders and investors started describing new companies as ‘Cursor for X.’
With this evolution, both incumbents and startups have become much more deliberate about product form in the age of AI. The real strategic question is no longer just whether AI should be added to a product. It is how that AI should show up. In practice, the choice between building a ‘Copilot for X’ and a ‘Cursor for X‘ usually comes down to two things: verifiability and switching costs.
That distinction matters. A ‘Cursor for X’ approach means rethinking the primary workspace of a professional from the ground up. A ‘Copilot for X’ approach means leaving the existing tool in place and layering AI into the workflow people already live inside.
A ‘Cursor for X’ model works best when output can be checked quickly and confidently. Code can be tested. Video renders can be reviewed. SQL queries either return the right result or they do not. In these environments, users can tolerate a new interface because the value shows up immediately and the feedback loop is tight. This becomes even more attractive when the incumbent product is familiar but not deeply locked in, and when its architecture or incentives make it poorly suited for AI-native work. In those cases, the old interaction model and the new one often cannot coexist for long. The better experience usually comes from rebuilding the product around AI rather than attaching AI to the side of it.
The ‘Copilot for X’ model becomes the default when one of those conditions breaks. Maybe the output is harder to verify because it is subjective. Maybe the tool is deeply embedded not because users love it, but because regulation, compliance, procurement, or company policy makes it very hard to replace. In those markets, people are not going to switch their core environment easily, no matter how elegant the new product is. So AI has to enter as a layer, not as a replacement. That can still create real value, but it is a different kind of business. It carries permanent platform risk, depends on someone else’s distribution, and usually does not produce the kind of explosive product-led adoption that Cursor-style products can.
For founders, the cleanest way to make this decision is to ask five simple questions.
- Is the output highly verifiable? If yes, that is the strongest argument for a Cursor-style approach.
- Is the incumbent tool just a habit, or is it part of a deep workflow? If it is a weak habit, users can be moved. If it is a deep workflow, a copilot is often the more realistic path.
- Will the platform owner eventually ship its own AI layer? If the answer is yes, that should immediately raise caution for anyone trying to build a lightweight extension business. In that case, a deeper product rethink is often the better bet. If the answer is no, then building a copilot can remain viable.
- Does the user spend most of the day inside one tool? If yes, rebuilding that environment can create enormous leverage. If not, then a copilot layer that travels across workflows may be the better fit.
- Can the model’s context hold most of the relevant project data? If yes, Cursor-style interaction becomes much more powerful. If not, the wiser move is to start with narrower, high-value use cases before attempting a full workflow replacement.
Using that lens, some categories look especially well-suited for the ‘Cursor for X’ model. Legal work, music production, game development, video editing, software development, frontend development, education, and enterprise search all have strong reasons to move in that direction.
Other categories are more naturally suited for the copilot model. Content workflows, email, marketing operations, recruiting and HR, CRM and Salesforce optimization, spreadsheets, healthcare systems and EHRs, finance and trading, and CAD often sit inside environments where distribution is entrenched, and switching is harder.
And then there is a middle ground. Areas like DevOps and infrastructure, Figma-based design, scientific research, and customer support can move either way depending on the exact workflow, the strength of the incumbent, and how quickly users can trust and verify the output.
That, ultimately, is the deeper point. In AI, product strategy is no longer just about what the model can do. It is about where trust can be built, where behavior can change, and where a new interaction model is strong enough to replace the old one.
If you are an entrepreneur or investor building agents or copilots for enterprise or consumer use and want to brainstorm, reach out to me at pdchhaparwal@gmail.com.
