The dominant assumption in AI product development right now is that intelligence lives inside the model, and that if you pick the right model and prompt it well, you have a product. That assumption is wrong, and it is why so many AI products fail quietly in production while looking competitive in demo.

An LLM only knows what you give it at the moment of inference. It has no memory of previous interactions, no understanding of the user's context beyond what is in the prompt, no awareness of what was true yesterday versus what is true today. Without explicit architectural decisions about memory, retrieval, and reasoning constraints, and about human validation, the model is effectively amnesic, and any product built on it will eventually surface that amnesia as hallucinated continuity, forgotten preferences, or fabricated history. The model is not failing in those moments. The system around the model is. And almost every "AI product is bad" complaint I see, when you trace it back to first principles, is actually a product architecture failure expressed through model behavior.

This matters because the architectural decisions get made early, often before the team has any user data to inform them, and they are almost impossible to retrofit at scale. The teams that win at AI product development are not the ones with the best models. They are the ones who treat memory, retrieval, reasoning, and control as four distinct architectural layers, each calling for deliberate product decisions, none of which the LLM will make for you.

Because memory is where AI products fail in the ways that most permanently erode user trust, and almost nobody is designing it deliberately.

Most teams solve AI memory the same way: dump everything into a vector database and retrieve by similarity. It works fine in demos, but demos don't run for months. The problem shows up the moment a product needs to feel consistent over time. It breaks in a way that's hard to explain because the system isn't obviously wrong. It's just quietly inconsistent in a way users can feel but can't name.

What I've come to believe, and what I've argued in my writing, is that memory in any production AI system has to be split into two distinct shapes from the very first design decision. Semantic memory holds the atomic, structured facts about a user: their job, their preferences, the constraints they've told you about. Episodic memory holds the narrative record of what actually happened, timestamped, append-only, and never overwritten.

When you collapse these two into a single store, which is what naive vector retrieval does by default, the system starts treating fleeting moments as if they were stable facts about the user, and stable facts as if they were fleeting moments. The result is hallucinated continuity. The system feels uncanny to users, and it is almost impossible to debug.

A small example. If a user says "I am stressed out about this launch," a naive memory system might store that as a semantic fact about the user, and surface it three weeks later as if "being stressed about launches" were a defining trait. But that's not a fact, it’s a moment. By the time the system surfaces it, the launch is probably long over, and the user feels misread. Multiply that across hundreds of edge cases and you get a product that confidently knows things about its users that are not true. In this way, trust will quietly collapse, and you cannot recover it with better prompting.

The mistake I see most often, including in earlier versions of work I have been part of, is treating human-in-the-loop as something that happens after the system fails. A reviewer catches an edge case, fixes it, moves on. That framing treats validation as a process problem, when it is actually a system design problem.

Treating validation as infrastructure means making explicit architectural decisions about where humans sit in the system, what they see when they review, how their judgment goes back into the model's future behavior, and how fast the feedback loop is. These are not edge-case questions; these are literally central product decisions that determine whether the AI product gets measurably better release over release, or whether the same kinds of mistakes recur for months because the validation signal never makes it back to the model. In the AI products I have worked on, the validation work I personally did, sitting with the system's outputs and classifying them as correct or incorrect, was the most architecturally important thing happening. It was the layer that produced the training signal that made the rest of the system reliable. If we had treated it as ad-hoc QA, the product would have shipped overconfident and untrusted.

The architectural question I would push every PM working on an AI product to answer is this: what confidence threshold triggers a human review, what does the reviewer see when they review, and how long does it take for their judgment to change the system's behavior? If those questions do not have crisp answers in your product, you do not have a control layer. You have a hope.

The Cognitive Entry Tax is about the moment users decide whether your product is worth their time, which almost always happens before they have understood what the product actually does.

The standard frame for onboarding is that it teaches users your product. The framework I argue for instead is that onboarding is the moment users generate a verdict on the mental effort you are asking them to invest. They aren’t learning your product in those first five minutes; they’re calculating whether learning your product is worth the effort. If your onboarding asks them to absorb seven concepts, configure four settings, and complete three setup steps before they see any value, they are not learning anything; they are only paying a tax and deciding whether the eventual value justifies the cost.

The reason this matters from an architectural perspective is that most teams optimize onboarding by adding more guidance, more tooltips, more clarification, when the actual fix is almost always a reduction in the number of “help” features. The teams that win at product-led growth are the ones who minimize the cognitive entry tax, deliver real value within the first session, and treat every step of setup as a cost the user is paying for the right to continue. It reframes the entire onboarding conversation from "Did the user understand?" to "Did the user decide?"

Activation Debt extends the same intellectual project forward into the post-onboarding window. The Cognitive Entry Tax is about whether the user decides to invest at all. Activation Debt is about what happens after they have decided yes, but have not yet completed the setup that would let them get sustained value.

I deliberately use the metaphor of technical debt because the dynamics are similar; every time a user finishes onboarding without completing the setup that would actually equip them for long-term use, a small unpaid balance is created. These balances do not look like anything at the time. The activation event fires, the milestone gets crossed, the dashboards turn green. But the debt sits there, compounding quietly across the first thirty, sixty, ninety days of product use, until one day the user stops coming back, and no one can tell you exactly why.

The architectural solution here is to treat activation as an ongoing balance rather than a one-time event. You measure the activation completeness score (what percentage of the full activation set has each user actually completed), you measure the activation gap (designed activation behavior versus actual user behavior), and you measure latent activation health (the probability that a user, at their current completeness score, will move toward deepening behavior over the next thirty days). Once you can see the debt, you can design product responses to it: progressive activation, activation debt visibility for users, and activation forensics for churned users. None of this requires new tooling; it only requires treating activation as a system rather than a marketing funnel.

The single most common mistake is treating the AI as the product, rather than treating the system around the AI as the product. PMs are picking models, evaluating frameworks, comparing benchmarks, and skipping the harder architectural decisions about where data lives, how it is retrieved, what shape the model's output takes, where humans validate, and how feedback flows back.

The downstream consequence of this mistake is products that look impressive in beta and become unsustainable in production. Every call to an LLM costs money, takes time, and is not deterministic. At scale, this is one of the largest cost drivers in an AI business, and most teams discover this after they have already designed a product that depends on doing many model calls per user interaction. The architectural posture I would argue, instead, is to treat the LLM as the most expensive worker in the system, and to design the system so that the model does only what the model can do. Anything that can be handled by retrieval, by memory, by structured logic, or by caching should be handled there, not at the model.

This is not a cost optimization argument; it’s a product quality argument. Systems that minimize model calls also minimize hallucinations, latency, and non-determinism. The cheapest AI products are also, almost always, the most reliable ones.

The theme that I keep returning to, and that I will use to evaluate all entries, is this: innovation that matters is not about complexity, but about how useful the products are to their actual users. Many entries will be impressive on the factors that are easiest to measure: novel technology, ambitious scope, polished interface. The harder, and more important, dimension is whether the product was architected for the year after launch, not just the moment of launch.

So, in practice, this means I ask specific questions about any AI product I evaluate. Is the memory architecture designed to scale with trust, or will it accumulate hallucinated continuity? Is retrieval treated as a deliberate architectural layer, or as a byproduct of the LLM call? Are there explicit decisions about where humans validate, and is the feedback loop fast enough for the system to improve measurably? Has the team designed the activation experience as an ongoing balance, or as a one-time event? These are, in my experience, the questions that are really hard to answer crisply, which is precisely why the judging work is so important.

There are two shifts I expect to define the next 18 months, and they are happening at the same time but in different layers of the work.

The first is on the product side. The teams that win will not be the ones with the most ambitious models. They will be the ones who have done the unglamorous architectural work of treating AI as a system rather than as a feature. We are already seeing the first wave of that differentiation in the products that feel trustworthy at the year mark, as opposed to the products that wowed in their first quarter and then quietly bled users. I expect the discipline around memory architecture specifically to mature significantly, with the patterns that distinguish reliable conversational memory from naive vector storage being adopted by serious product teams. I expect a similar maturation around the control layer, with human-in-the-loop infrastructure becoming an explicit architectural concern rather than a process afterthought.

The second shift, and the one that has changed the most in the last six to twelve months, is on the building side. The teams I have been working with are using AI tools, agents in particular, not just as features they ship but as collaborators in the building process itself. I write product specifications differently now because part of my audience is an AI agent that will help implement them. I think about technical trade-offs differently because the cost of exploring an alternative implementation has collapsed. Workflows that used to take a week of back-and-forth between product and engineering can now be prototyped in a day. This is changing what the Product Manager role itself is, and changing it fast, and most PM job descriptions have not yet caught up.

The combined implication of both shifts is that the gap between teams that have adapted their product architecture AND their building process to treat AI as a first-class component will widen quickly and become very visible. By the end of next year, you will be able to tell within a single user session whether a product was architected by a team that took this seriously, and you will be able to tell within a single sprint whether the team itself is using AI to build, or just to ship. What I would urge Product Managers reading this to do, regardless of where their product currently sits, is to treat both layers as central concerns. The model and the framework will change every six months. The architecture around the model, and the way your team builds, are what compound.