Rita Sheth — Founder, Product Architect & Strategist

Product–market fit is one of the most used phrases in startups. Founders are told to "find PMF" as though the journey is binary — either the market wants what you have built, or it does not. In practice, there are several distinct stages between identifying a real problem and building a product the market repeatedly chooses, pays for and keeps using. That distinction matters, because different failures require completely different responses. It also prevents founders from giving up when they have found a problem that is genuinely painful, and a market that appears to feel that pain, but something still will not stick. In that case, one of the bridges between pain and market is broken — and the only useful question is which one.

A better way to think about early product development is as a chain: problem validity, pain and priority fit, product–mechanism fit, proposition and perception fit, adoption and value fit — and only then product–market fit. Each stage answers a different question. If you skip over the distinctions, it becomes very easy to diagnose the wrong problem. You might change your target customer when the mechanism is weak. You might rewrite the landing page when the product cannot yet prove its value. You might build more features when the real issue is adoption friction. Or you might conclude there is no market, when the market simply cannot yet understand why your product is better. Naming the stages turns a symptom into a diagnosis.

The first question is the most basic: is the problem real? Does the customer genuinely experience it — can you observe it in behaviour, cost, inefficiency, risk or missed opportunity? This stage has nothing to do with whether someone likes your proposed solution. A team may make important decisions using fragmented spreadsheets and repeated meetings; that establishes that a problem exists, but it does not establish that they want your software. If the problem is not real, no amount of good product will save you. But if it is real, you have only cleared the first bridge.

The second question is whether the problem matters enough. A problem can be real without being important. This is where many founders get misleading signals, because a potential customer might agree with everything you say and describe the problem in exactly your language — yet if the consequence of doing nothing is small or easily tolerated, the problem never reaches the top of the buying list. The test is not "does this hurt?" but "does it hurt enough, for the right person, at the right moment, to justify action?" That is a different threshold. You can have a real problem and a sympathetic buyer who still will not prioritise it.

Then comes the stage I think deserves far more attention than it gets: does the product actually contain a mechanism that can be easily demonstrated to move the customer from their current state to a meaningfully better one? Not "does it have useful features", not "does the AI produce impressive outputs". The test is whether, in a thirty-second explanation, you can show how you move from A to B in extremely simple terms. Can the product take a real decision from A to B, and make it obvious why B is better? A strong mechanism has a visible causal chain — context in, intervention made, result observable. The user should be able to understand what changed because the product was involved.

This is why feature-rich products can still feel strangely unconvincing. Until the causal mechanism is obvious, adding more surrounding functionality makes the product feel more sophisticated while making the core value harder to see. That was an important principle at MercuriDash. Our internal test was whether the system could move a real product decision from A to a visibly stronger B, without needing founder interpretation to explain why it was better.

Even a strong mechanism will not sell itself. The next stage is proposition and perception fit: does the market understand what the product does, believe it will work for them, and feel motivated to act? A founder may see the causal chain clearly, while the market sees only features, jargon or an abstract promise. Proposition fit is the work of translating the mechanism into a concrete transformation the customer can picture themselves experiencing. It is not enough that the mechanism is logically sound; the right person has to grasp it in the right context without effort. If your messaging describes internals, features or broad benefits rather than the specific before-and-after state the customer will reach, perception breaks down. The aim is to take them from A to B in their imagination with no gaps, no blank filling and no doubt about whether they will end up better off.

A lot of time is spent on finding a painful problem. But much less time is spent interrogating whether the solution actually solves the problem, and whether it can be expressed in a straightforward cause-and-effect way. Having product–mechanism fit and proposition fit together means you can sell more easily, because you can show the mechanism to anyone and it captures the a-ha moment. In part this is the work of ingenious sales teams that go beyond selling to sales engineering — fitting demos to problems, closing the perception gap and making mechanisms crystal clear. However, increasingly this is something the founder and product lead need to think through before sales ever gets involved.

Then comes adoption and value fit. The customer understands the mechanism, believes the promise and is motivated enough to act — but can they actually get to value? This is where onboarding, friction, trust, switching cost, implementation and first-run experience become decisive. A product can have a strong mechanism and a clear proposition and still fail because the path from sign-up to first successful use is too long, too complex or too uncertain. The question here is not whether the product works in theory; it is whether the customer can make it work in practice, and whether the value they receive exceeds the effort they had to expend. Repeat usage, retention and willingness to pay all live at this stage.

Only when those pieces hold together does the broader PMF question become meaningful. Product–market fit emerges when the problem is real, the problem matters, the mechanism works, the market understands the mechanism, customers can actually adopt it, and the resulting value is strong enough to drive repeat usage and willingness to pay. Which is why "we don't have PMF" is often too vague to be useful. It tells you the destination has not been reached. It does not tell you which bridge is missing.

Of all the stages, I suspect product–mechanism fit and proposition fit are the ones that matter most for AI startups right now. The cost of building features has collapsed. The cost of generating impressive demos has collapsed. So the harder questions have become: what is the proprietary cause-and-effect loop inside your product? And can you express it so clearly that the right customer believes it before they have even used it? A useful mechanism should survive being stripped of its interface. Remove the dashboard, the branding, the animations, and what remains should still be a clear transformation from A to B. But a clear mechanism still needs a clear proposition, because customers do not buy engines — they buy the better state the engine creates.

So when a startup feels stuck, instead of asking "do we have product–market fit yet", I think the better questions are these. Is the problem demonstrably real? Is it important enough for someone to act? Does the mechanism by which we solve the problem actually work? Does it have a logic that is obvious? Can the customer understand and believe that mechanism? Can they reach the value easily enough? And only then — does the market repeatedly choose and retain it? The sequence is not perfectly linear; you will move backwards and forwards between the stages as you learn. But naming the stages turns a symptom into a diagnosis. "We haven't found PMF" is not a diagnosis. The useful question is which part of the chain is failing — and for many early AI products, the answer is rarely that the market has rejected the problem. More often, the product has not yet made its mechanism undeniable, or the proposition has not made that mechanism visible.

We taught AI how to build. Now we are beginning to teach it what is worth building.

For much of the current AI wave, the focus has been on execution. Can AI write the code? Create the image? Analyse the spreadsheet? Draft the copy? Research the market? Connect the systems? Complete the workflow? Increasingly, the answer is yes. The technical problems are by no means finished, but the direction is clear. AI is making execution dramatically cheaper and faster across software, design, research, content and operations. A capable person with the right tools can already produce things that would once have required a much larger team.

That creates an interesting consequence. As the cost of making things falls, the value shifts upstream towards deciding what should be made in the first place. The harder questions become: which problem is actually worth solving? Which opportunity should we pursue? What should the product do? Which version should we back? What should we change? What should remain untouched? What trade-offs are acceptable? And perhaps most importantly, what should we not do? These are not primarily execution questions. They are product strategy questions.

There is a tendency to describe product management as coordination: gathering requirements, maintaining roadmaps, writing tickets and moving work through a development process. But that misses the most valuable part of the job. A strong product strategist connects a vision to something that can actually be built. They translate an ambition into objectives, product architecture and priorities. They consider alternative routes. They balance evidence against instinct, short-term opportunity against long-term position, customer requests against product coherence, speed against quality, commercial potential against technical cost. And then they make choices.

Good product strategy is therefore not simply a plan. It is a continuous decision system: vision leads to objectives, objectives to architecture, architecture to options, options to trade-offs, trade-offs to decisions, decisions to execution, execution to outcomes, and outcomes back to learning. The loop matters as much as the initial decision. A good product leader does not simply decide once and assume they were right. They watch what happened, understand why, update their model of the problem and make a better decision the next time. Looked at this way, product strategy already resembles the architecture of an agentic AI system. And that may be where the next important frontier lies.

Most current AI interaction still begins with an instruction. Write this. Build this. Summarise this. Analyse this. Fix this. The human has already made the fundamental decision about what needs to happen. AI performs the work. A product-strategy agent requires a very different level of reasoning. Instead of being told to build Feature X, it might be given an objective: increase activation without materially increasing onboarding complexity. Now it has to understand the current product, available evidence, user behaviour, technical constraints and company strategy. It may generate several possible interventions. Then it has to compare them.

Perhaps one creates more upside but introduces substantial engineering work. Another is easy to ship but treats a symptom rather than the cause. A third improves activation but damages retention elsewhere. A fourth requires no new feature at all — only removing friction from something that already exists. The difficult part is not generating those four ideas. The difficult part is deciding which one deserves to happen. That requires judgement.

Generative AI has conditioned us to associate intelligence with producing more. More concepts. More alternatives. More code. More content. More possibilities. Product strategy often requires the opposite. Sometimes the intelligent decision is to preserve almost everything and change one thing. Sometimes it is to reject a superficially attractive opportunity because it pulls the product away from its strategy. Sometimes a customer request should not become a feature. Sometimes an underperforming experience requires a major rethink. Sometimes it requires nothing more than allowing the current idea enough time to produce evidence. And sometimes the correct answer is simply: do not build this.

That is a much harder form of AI than generation. A useful product strategist has to reason about what is fixed, what is flexible and what is actually causing the problem. It needs to understand that improving one objective can damage another, and that the highest numerical optimisation is not always the strongest strategic choice. In other words, it has to understand trade-offs.

This is where things become particularly interesting. Once an AI system is making decisions rather than merely executing instructions, there may no longer be one objectively best version of it. Imagine two highly capable AI product strategists looking at exactly the same opportunity. One has a strong bias towards rapid experimentation. It recommends shipping the smallest reversible test and learning from real behaviour. Another prioritises product coherence and believes the proposed feature creates architectural debt. It recommends waiting and solving the underlying problem properly. Neither is necessarily wrong. They have different philosophies.

One AI might systematically favour differentiation over market conformity. Another might favour margin over growth. One might tolerate significant technical debt in pursuit of speed. Another might be unusually conservative about platform architecture. One could be excellent at zero-to-one product creation because it places more weight on novelty and learning. Another might be exceptional at mature-product optimisation because it prioritises statistical confidence and incremental efficiency. Another might be particularly suitable for regulated environments because its threshold for uncertainty and risk is much higher. At that point, what we currently think of as model behaviour begins to resemble product leadership style. We may end up talking about AI product strategists in remarkably similar ways to human ones: that one is excellent at 0→1; that one is commercially aggressive; that one sees second-order effects incredibly well; that one over-optimises; that one protects the long-term product better; that one is brilliant at identifying when we should stop building.

There may never be one best AI. It would have been reasonable to expect AI to become winner-takes-all. Intelligence benefits enormously from scale, so perhaps eventually one model would simply become better than everything else and everyone would use it. Yet that is not how the market currently feels. People already move between different general-purpose models. Developers use different coding agents for different kinds of work. Creative professionals switch between image, video and design systems. And sophisticated users sometimes use several competing systems in parallel even when their headline capabilities overlap considerably. That is interesting because AI was supposed, in one sense, to commoditise capability. Instead, it may be creating another kind of differentiation.

Two systems can both be extremely capable yet feel meaningfully different in how they reason, communicate, prioritise and respond to ambiguity. That difference may become even more important as AI moves into strategy. Execution often has a relatively observable answer: the code works or it does not. Strategy rarely does. It involves values, time horizons, uncertainty, opportunity cost, organisational appetite and competing definitions of success. Different systems can therefore reach different conclusions without one of them necessarily being defective.

This is perhaps the deeper point. Once an AI is balancing several legitimate objectives, its judgement necessarily reflects priorities. Suppose a company is considering a new product. The evidence suggests strong demand, but the idea weakens brand differentiation. It could generate substantial revenue, but it creates operational complexity. It serves current customers, but it moves the company away from the market it wants to own in five years. What is the "correct" answer? There isn't one until someone determines how those objectives should be valued. That is strategy. An AI can help make those priorities explicit. Eventually it may learn them from an organisation's history: what leaders approved, what they rejected, which departures succeeded, where they repeatedly regretted compromising, and which decisions ultimately created value. But even then, the machine is not discovering some universal objective truth. It is developing a model of what good judgement means in this particular context. That is why I suspect the future of product-strategy AI will be more pluralistic than people expect. Different companies may need different strategic intelligences. And the same company may want different ones for different decisions.

None of this means that the CPO or product strategist disappears. If anything, it clarifies what their highest-value work actually is. Humans increasingly move from producing every artefact themselves towards defining the system within which decisions should be made. What are we trying to become? What are we unwilling to compromise? What constitutes success? Which risks are acceptable? Where should AI have autonomy? Where should it abstain? Which decisions require human judgement regardless of confidence? And when the evidence contradicts the organisation's existing assumptions, who has authority to change them? Those are governance questions, but they are also product questions. The senior product leader becomes partly the architect of the organisation's decision intelligence.

We are already moving from copilots that help people perform tasks towards agents that take responsibility for outcomes. The next step is not difficult to imagine. AI systems will increasingly help organisations decide what initiatives to pursue, which products to build, where products are weak, what interventions have the highest leverage, which bets deserve investment and which should be stopped. And crucially, they will be able to observe what happened afterwards. That closes the loop. A system that remembers the context, recommendation, human decision, intervention and eventual outcome can learn something much more valuable than a static best practice. It can begin to learn which kinds of decisions work here.

That is where AI stops being merely an execution engine and begins to resemble a product strategist. And it may also be where some of the most defensible AI products are built. Because when execution becomes abundant, judgement becomes scarce. The first era of generative AI was dominated by the question: how much of the work can machines do? The next may revolve around a harder question: how much of the judgement can they help us improve? We have spent the first era of AI teaching machines how to execute our decisions. The next era may be about teaching them how to help us decide what is worth doing in the first place.

And if that happens, the defining question may not be which AI is smartest. It may be: which AI has the right product judgement for the problem we are trying to solve?

Artificial intelligence is entering a phase that most venture funding models were never designed to support. Early AI companies were funded to prove technical feasibility; later-stage companies are funded to scale. A growing number of startups are now stalling in between. As AI products move from impressive early products into scalable organisations, the source of value creation shifts. Model capability matters less; integration, behaviour change and trust matter more so that you can unlock enterprise value. Customers are not simply buying software. They are being asked to change how decisions are made, how work is organised and how accountability is distributed. That takes time, training and experimentation, and it creates a phase of company-building that is capital-intensive, slow to signal success and still poorly understood by investors.

The traditional venture playbook works well for software that slots neatly into an existing workflow: build the product, sell it, scale it. AI is transformative and therefore behaves differently when scaling it to enterprise. Pre-seed and seed capital prioritise shipping and early traction, while growth investors expect predictable expansion. The difficult work required to move from one state to the other — educating users, redesigning workflows, building confidence in AI-supported decisions and adapting the product around real-world behaviour — is often treated as overhead, or assumed to resolve itself.

This creates a missing middle in AI investing: a post-build, pre-scale phase where otherwise strong companies can look weaker than they really are. Slow usage may be read as weak demand, friction as poor product-market fit, and early churn as a market signal rather than the cost of introducing a new way of working. Yet many AI companies are not failing because their products lack value; they are stalling because their customers do not yet have the capacity to adopt them quickly.

The uncomfortable part is that no single source of capital is especially well designed for this phase. Angels can be essential early believers but rarely have the mandate for slower, non-linear progress once a product is built. Traditional venture is good at scaling proven patterns but often uncomfortable with ambiguous traction or no traction while navigating the enterprise adoption gap. Corporate investors can bring domain knowledge and integration experience, but may move slowly or introduce different strategic incentives. Founders are left caught between investors expecting speed and customers needing time.

The more interesting question may be whether this integration phase creates space for new funding and operating models altogether. Some of the value may come from deeper customer partnerships, co-build arrangements or customers effectively funding part of the adoption journey through paid pilots, implementation work or strategic collaboration. There may also be a larger role for venture operators, specialist funds or private-equity-style models that are more comfortable with operational complexity, longer integration periods and hands-on value creation than traditional venture capital. None of these is necessarily the answer on its own, but the gap suggests an opportunity for capital structures that are better matched to how AI businesses actually move from technical capability to embedded use.

This is not an argument for lowering standards or subsidising weak companies. It is an argument for recognising that AI often creates new costs before it creates new returns, and that capital structures may need to reflect that reality. During this integration phase, the most useful signals may not be headline growth metrics, but learning velocity, depth of engagement, quality of implementation and whether the company is building the conditions for lasting adoption. This is in line with the change in thinking between the lean startup thinking of the 2000s and the build well thinking we are now moving into, when trust, security and stability are seen as a differentiator in a landscape full of sloppy products.

Investors who understand that may have an edge. Supporting companies through the messy integration period rather than pulling back at the first sign of friction creates the possibility of participating in the compounding that follows. More importantly, it reduces the risk of writing off strong businesses simply because they are solving real problems on timelines the market has not yet adjusted to.

AI is not just another software cycle. It is a general-purpose technology that changes how work gets done. Treating it as though it will follow familiar adoption curves risks systematic mispricing and missing opportunities for massive value creation. The question is whether existing funding models are prepared to support the transition.

A few months ago I wrote a paper about the way in which AI fails the creative industries, as a lot of AI products still do not really consider how different people naturally communicate. Some of us think visually, some verbally, some through sound, movement, examples or comparison. Yet most AI tools still begin with the dreaded prompt box, asking everyone to translate what is in their head into written instructions before the machine can do anything useful. We have used prompt boxes in our product, of course, but they need to be balanced with other types of input and used at times as a last resort, especially when we are trying to bridge the gap between the human and creative and the mechanical and logical.

A designer may know what feels wrong before they can explain why. A musician may communicate through sound. A creative director might work through references, mood, colour, association and comparison rather than a precise written brief. Asking them to convert all of that into text is not necessarily making the technology easier to use. It may simply be forcing people to communicate in the way the machine prefers.

There is a quiet inversion at work here. Prompt-based systems end up rewarding the people who can describe creativity well over those who actually practise it, giving an advantage to the prompt-writer rather than the practitioner.

Generative AI is now very good at producing text, images, video, audio and code, but the way we give it information has not developed at the same pace. A richer interface might let someone combine references, sketches, examples, taxonomy, emotional language, images, previous work and simple choices rather than trying to describe an entire creative vision in a paragraph. The point is not to remove language, but to recognise that natural language is much broader than words.

There is a cultural bias built into this too. Prompt systems privilege certain norms of expression, making some forms of communication easier for the AI to recognise than others, which is its own quiet kind of exclusion.

This becomes even more important when AI sits inside real business workflows. Different stakeholders often hold different parts of the knowledge: a designer understands the visual intention, a technical team understands what can be built, a commercial team understands the customer and someone else may understand compliance or production. If AI is going to sit between those people, it needs to help capture and hand off that knowledge without flattening it, misinterpreting it or quietly throwing away the parts that cannot easily be put into words. Human-in-the-loop oversight has a real role to play, but it should be there for judgment and compliance, not as a fallback for an interface that is hard to use. If people keep stepping out of the system just to make themselves understood, the model has failed, not the user.

For product developers, this means thinking beyond the model itself. Domain knowledge still matters, but so does understanding how the people in that domain actually think, communicate and make decisions. The best AI products may be the ones that learn how to meet users in those existing behaviours rather than training everyone to become better prompt writers.

The next step in AI interaction may therefore be less about teaching humans how to communicate with machines, and more about designing machines that can understand the different ways humans already communicate with each other.

We have talked a lot about AI making products faster to build. Vibe coding, AI-assisted development and increasingly capable design tools have dramatically compressed the distance between an idea and a functioning product. But I think there is another shift happening that may be just as important: AI is also changing how quickly we can learn what is wrong with a product.

Traditionally, zero-to-one development involves a slow loop. You research, run discovery, build an MVP, put it in front of a small group of users, wait for feedback, work out what is signal and what is noise, then rebuild and repeat. Early feedback is often limited, biased or incomplete, and some problems only emerge after enough people have used the product in enough different ways. We all know the first version is rarely the real product; the real product gets built through iteration.

AI gives us a way to collapse part of that journey. We can now generate realistic data, run workflows against different assumptions, simulate edge cases, test decision logic and expose inconsistencies before a real customer ever encounters them. AI sandboxes can help identify broken flows, missing states, strange combinations of actions and gaps in product logic far faster than a small beta group ever could. Combined with rapid AI-assisted build, that means we can test, learn, change and redeploy in a much tighter loop.

This does not remove the need for discovery. It changes what discovery is for. Real users are still essential for questions around trust, behaviour, comprehension, willingness to adopt, whether the interface feels intuitive and whether the product actually fits into a real working environment. But we should not be using scarce customer time to discover problems that could have been surfaced through simulation and structured testing first.

The real advantage, then, is not simply that founders can build faster. It is that we can arrive at the market with a product that has already been through far more cycles of challenge and refinement. We can use synthetic data and AI workflows to front-load iteration, reserve human discovery for genuinely human questions, and shorten the uneven path between first build and something much closer to product-market fit. For founders who learn how to use that well, the gain is not just speed. It is a better learning system around the product itself, which can get you to PM fit that much quicker and save months in your runway.