Rita Sheth — Founder, Product Architect & Strategist

The founder's journey is a unique and awkward path. Most people don't understand it because, quite sanely, they value peace, fun, leisure and relationships. Founders are not a monolith, and of course they are not robots, so they also value these things. However, they are both driven by a broader vision and also a frighteningly narrow focus at the same time. This strange combination, a focus on a future no one sees and a tunnel-visioned, short-sighted approach to the present, means they approach life, decisions, relationships, pleasure, enjoyment and satisfaction from a fundamentally different frame of reference and seem to prioritise very different things.

Even if they started off sharing many of the values and goals of the people around them, the very nature of the journey draws them further and further away from the people, environment and values they started with. The things they go through, the resilience they build and the sheer requirement to absorb so much pain and constant learning all contribute to that change. Often this isn't a conscious choice. It's a by-product of the journey and of having to prioritise different types of things. Staying in to work, rather than going out on a weekend, becomes a choice that moves them in one direction, for example. These kinds of choices compound, weekend after weekend, day after day, and so it becomes inevitable that they end up in a totally different place from where they started.

At a very deep level, founders need to shift their identity, core beliefs and fundamental values, not even just to succeed, but simply to survive. People are drawn to and resonate with others who share similar values. So it is no surprise that entrepreneurship redefines and restructures   relationships - to people and an environment. 

For founders who haven't already experienced this, there may be people who become angry, remain in denial about shifting priorities, call them snobbish or selfish, or are simply baffled by how much they have changed. And the truth is that they have changed, even without realising it. It happens slowly yet surely, and is often more immediately apparent to others than to the founder themselves.

Alongside grieving an old self, an old life and relationships that didn't make it, there is also a period of walking alone that no one warns them about. It falls between where they were and where they are going. But on the other side is a different view. They look back at what they left behind and can't even recognise that version of themselves. And although their life isn't always necessarily better, it is usually different in a way that feels like, ultimately, it was always meant to be this way.

For a long time, how many people you employed said something about your startup's success. Headcount meant status. Investors used it as a proxy for traction, journalists used it as a proxy for importance, and founders used it as a proxy for progress. Even inside companies, the size of your team signalled how seriously people should take you and your contribution.

AI is doing away with the need for many different functions, and it is changing the types of people you need and when you need them. You could even argue that too many people are now a sign of inefficiency. Rather than being applauded, a big team should be questioned by investors and clients, because the extra costs and overheads reduce returns on one side and push up pricing on the other. When the two biggest reasons companies hired in volume, shipping the product and selling the product, are both being rationalised, team size is no longer a useful way to judge progress or potential. Arguably it never should have been.

When AI fully streamlines these functions, what is left that genuinely needs headcount? Probably a much smaller list than most org charts suggest: perhaps domain-level judgement, perhaps relationships, perhaps creativity, strategy, and organising resources and roadmaps. Much of the rest may just be a hiring habit, and a way of spending investors' cash because that's the way it has always been done.

I suspect the result is not just leaner startups, but a different idea of what a company is. When scaling revenue no longer requires scaling people, successful companies may stay surprisingly small for much longer.

Dario Amodei, the CEO of Anthropic, has predicted that we will soon see the first one-person billion-dollar company. A few years ago that would have sounded absurd. Now it sounds inevitable. AI scales in a way that teams cannot. It offers a one-to-many return on investment: build a process or system once and it delivers over and over again. Training people does not work that way. People leave, and their expertise leaves with them. Even with the most codified processes, someone new still has to learn them.

Scalability isn't the only reason a lean structure beats a larger team. Lean is simply better when technology moves this fast. The landscape changes every few months, and the companies that win are the ones that can respond quickly. The more people you have, the more alignment, process and politics you need before anything changes direction. Too many people can mean an inability to adapt, and right now that is a liability rather than a strength.

Being lean doesn't mean being alone, though. Even if you are building on your own, you can still benefit from working with people. They just don't need to be traditional hires in a traditional startup set-up. I think we will see more loose coalitions, networks, contractors, agencies, board members and advisors. They will fill crucial gaps, but also provide the camaraderie, support and resilience that are still needed, both for the business and for the people in it. We still need to work with others, and ideas and connections are still traded. What changes is how influence grows. It used to spread downwards and inwards, through employee numbers and culture inside the organisation. The future may be culture and influence spreading sideways and outwards.

All of this matters when having discussions with investors and with enterprise clients. One of the things investors used to judge a company on, team strength and a balance of specialisms, arguably matters much less now. Instead, you need to show them that one person driving is actually better than decision by committee, because speed and adaptability beat diversity of experience when AI has covered so many of the gaps a broader team used to fill. On the sales side, it can look intimidating when a small team seems to be batting above its weight with enterprise clients. But it makes sense, and clients can be reassured when you explain that automation handles much of the operations, which leaves more time for high-level work and for them.

My prediction is that in a few years, we will be in a new era where team size is just not discussed anymore. Non-technical founders used to be told they needed a technical co-founder. That is now rarely an issue, and it has largely been forgotten as a criterion for judging a startup's success. In the same way, team size and dynamics will no longer be pertinent. What investors and clients will be asking (and what they should be asking) is: how much technology are you using to drive returns, results and innovation, and where headcount is used in place of technology, why that is better? In effect, you will have to justify why each person matters, what their role adds, and why investor money or client trust should move in that direction.

Agents rationalising software development is now yesterday's news, however the new wave of automation is the rise of agents helping with sales and marketing. Traditionally we needed to scale sales teams to scale growth - the two were more or less directly correlated in a very 1-1 way. A lot of GTM needed a sales team to just physically ramp up the amount of outreach you could do, which was supposed to directly feed the bottom line and revenue generation. However, if GTM can instead scale with agents then this opens up, even further, the number of companies that can stay leaner longer and the amount of value that can be generated within smaller teams.

We can already reduce tech team sizes by using AI for much of the work that needed a separate front end developer, backend engineer, designer, dev ops and more. Now AI can do much of that work with some human checks and balances. Sales was always thought of as a fundamentally human skill. But what if you could train your AI to send personalised contextual outreach, follow up properly and do everything up to and including booking a call (and perhaps even taking the initial one?). What possibilities does that open up when one of the core constraints and bottlenecks to scaling-up was the size of your sales force and the speed at which you could ramp them up, train them and get a return on that hire and training period?

The possibility is exciting when most people just take it as a given that at least 30-40% of a batch of reps will churn or underperform, and accept that hiring sales teams is notoriously inefficient, costly and frustrating. If AI enables scaling sales, with all of its constraints and inefficiencies, not just for the initial funnel stages, outreach and lead generation, but the actual sales process, with much less friction, less training and time-lag to results, and perhaps most importably a repeatable, easily systemisable process, scaling becomes predictable rather than the wobbly and unstable ladder it has hereto been.

Sales is thought of sometimes as the last area where only humans can be effective, but consider this: it may actually be that in some cases people may actually prefer to buy from an AI, because they can ask questions frankly, don't feel manipulated or pressured and feel more comfortable saying yes or no. This may actually make for an even better and higher converting sales process, because sales isn't usually about convincing someone to buy, or deploying your skills of persuasion, a lot of times it's about answering questions and providing information.

This is all hypothetical and no one knows whether AI sales reps would perform better or worse than human sales reps. If anyone has done a study, it would make for interesting reading to see whether my instinct about humans maybe preferring to deal with an AI sales rep is true or not. However with AI being used now in first round interviews,  the logical leap to using them in first round sales calls doesn't seem that far and the next breakout company may be a company that nails AI driven sales.

There is an active debate happening right now in a lot of companies: should we build this ourselves, or buy it?

With vibe coding and cheap AI execution, a small team can build and ship fast. So they are looking at products they currently pay for and asking whether they could just build their own. And to be honest, it has scared a lot of AI startups. The worry is: if we show people what our product does, will they just reverse engineer it?

At first, I thought this was an existential threat to start-ups but now I am pretty sure it is not because I have come to the conclusion that in most cases buying still makes more sense for most types of software and for most types of companies and is often the better strategic and financial choice.

Firstly, building it yourself is not as cheap or as easy as it looks because it's not just about the working first version, it's about iterating that to fit your needs and get something that really will get adopted and used and make a valuable difference. That part hasn't been solved or made easier with the availability of rapid prototyping tools.

The hard part is not a quick build, it is getting a decent piece of software over the line — reliable, secure, maintainable and integrated enough to run a real part of the business. That takes longer than people think. It doesn't just need engineers, it needs a product lead, and a business owner — which also means hiring a team, not just one person. Decent AI engineers and product people are not free, and the market for them is competitive. An internal build that looked like a saving can cost much more than a yearly subscription and is less flexible. You are kind of stuck with it, whereas with a vendor you can move on if it's not a good fit.

But the larger argument is not really about building the first version. It is about maintaining it for years after. And really there is no point having something in-house if it is badly maintained; if you are not going to invest long term, it's a wasted investment in time and money.

To keep pace with the best tools, a company has to dedicate serious resources to a problem that is not its core business. A third-party vendor is incentivised and dedicated to only that thing: make their software as capable and competitive as possible, because that is what keeps it alive. Their entire existence depends on it. Your internal team, however talented, is not subject to the same pure market pressure. They are pulled in many directions. Their incentives are tied to your broader company, not to making this one piece of software the best in its category. Over time that creates a predictable gap. The purchased product keeps improving. The internal product survives and probably languishes somewhere down the team's to-do list.

The other reason teams want to build in-house is because of IP and customisation. Both are really procurement issues, not build-versus-buy issues.

On IP and compliance, that is exactly what policies, compliance and contracts are designed to protect. The risk obviously does not completely disappear, but we have often seen just as large privacy and data protection failures in-house as with a third-party vendor. There is no implicit elimination of risk just because you keep data inside your own walls. A careful procurement process gives you a known, managed risk rather than an argument for building everything yourself. It can also be a way of passing off risk rather than owning it yourself.

On customisation, it is tempting to think that unless we build it ourselves it will not be exactly fit for purpose. That's no longer true. The real point is that we can use AI efficiencies to make off-the-shelf products much more intelligent, brand-aware, agentic and personalised. The same capabilities that allow companies to build also allow vendors to capture those efficiencies and offer customisation, support and configuration at much lower cost. AI has made it possible to make something feel so well-configured that it feels bespoke, even when it is not. Of course, at higher values, real customisation is also available, plus dedicated support and touch points, which makes the argument for building in-house even weaker.

There is a related trade-off that is often framed as a downside but can actually be an advantage. When you buy from a vendor that serves many customers, the system gets better because it sees patterns across many organisations, not just yours. Your data and processes can contribute, with the right controls, to a broader learning loop. Done properly, network effects create a better product for everyone. Done badly, it creates a privacy problem. As we have seen at the big social media companies, it is a double-edged sword, and the distinction between customer-specific data and generalised system learning matters enormously. But the underlying point stands: network effects and compounded learning on what makes a product better make the product sharper than any single internal team could keep it.

All of this does not mean building is always wrong. There are clear cases where in-house makes sense. The question to ask is often "is this central to how we work every day, specific to us, and stable enough that we do not need it to keep up with the market?"

A good example is a productivity tool or CRM tool. They both deal with basic functionality that does not require constant maintenance to deliver value as an in-house product. And the benefits probably outweigh the cost, because then you can really make it work for how you manage customer data and your sales process, for example. In fact, I built my own CRM for this exact reason: every sales team works differently, and we all like to organise our tasks in different ways. So in this case a quick build for that added convenience makes sense. In that middle ground — important enough to affect the core business day-to-day, specific enough to be awkward to configure in someone else's product, simple enough to maintain and worth the cost — building can be the right call.

Another sensible case is a proprietary dashboard or reporting layer that shows exactly what your leadership team looks at each morning. The underlying analytics engine is almost always better bought. But the particular view, thresholds and alerts that map to your operating rhythm are sometimes not worth forcing into a generic tool.

But for most of the things people might replace external software with in-house builds for, it doesn't make sense. Even things that appear simple, like AI content engines, video pipelines or drafting software, can be complex or depend on underlying models and algorithms that need to be constantly improved and iterated to work. They need continuous improvement, and it is often much better to buy carefully, with controls in place, than make your own. The time would almost always be better spent working with a specialised provider and shaping the product so it feels as though it was designed for you, even when, strictly speaking, it is not.

I also suspect the current enthusiasm for building is partly a phase. It is exciting to discover that a small team can ship something impressive in a weekend. It is less exciting to maintain that thing for three years while the external market moves on. Many internal builds start strapped onto the core business, funded by diverting budget or hiring someone to own the product internally. Then the champion leaves, the budget gets reallocated, the business changes direction, and the system becomes technical debt nobody wants to touch. The project gets shelved not because the people were not capable, but because it was always a distraction from the company's actual work.

My prediction is that we are in a cycle. Most organisations will probably return to a clearer distinction between what they must own and what they should just rent. The specialised providers will keep getting better, not just because they have more resources, but because their entire existence depends on it. And the companies that resist the temptation to build everything themselves will generally have sharper, more maintainable stacks and more focus on the work that actually matters. They will discover that it is better to make your main thing your main thing. And even when it is your main thing, think contract drafting for law firms, it's still better to make someone else customise it for you and have a dedicated point person, than tie up your tech team for years.

That does not mean you should not hire an AI developer or innovation consultant. I just suspect the better use of their time is auditing options and working with the vendor to customise the offer, rather than building something from scratch. They will not tell you that, of course, because no engineer wants to be a secret procurement person.

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.