Chapter 12: The Product Gap

We built an AI agent platform. Apex let founders and SMBs build agents that could automate work, act as assistants, create dashboards — the full vision. We'd sold people on the future of AI-powered operations.

Our own team couldn't figure out how to use it.

The company selling picks and shovels for the AI gold rush, and the people inside our own walls were staring at the tool wondering what it did. Not because they were slow — because the product had been conceived, designed, and built so fast that the understanding of what it was never left my head and Dan‘s head. We’d built it in the fever of zero-to-one, and the thing in the app bore only a passing resemblance to the thing in our pitch deck. Both were real. Neither was complete.

Nobody on the team had the map.

Not the technical gap — we‘ve covered that. Not the market gap — Daniel and Sergey showed us those. This is the organizational gap: the product arrived faster than the team’s ability to understand it, use it, sell it, or support it.

The build outran the humans.

When I started rolling Apex out to the internal team, something happened that I should have predicted but didn‘t. Every person I brought on amplified one or two issues. Not because they were creating problems — because their fresh eyes found problems that my builder’s blindness had normalized. And the issues compounded. Person one surfaced two things. Person two surfaced two more, plus their questions about person one‘s issues created a third. By person four, I wasn’t onboarding a team. I was running a support desk for my own company.

The system wasn‘t built for n > 1. It was built for me — one builder, one brain, one set of assumptions about how everything fit together. The moment a second person tried to use it, the invisible scaffolding I’d been standing on became visible.

It was made of string.

I got ground to a halt. Couldn‘t build features — I was supporting the internal team. The team couldn’t learn the product — the issues they hit blocked their progress. They couldn't build playbooks — the product was still shifting under their feet.

And real customers were starting to show up. Walking into a house where the family hadn't finished moving in.

Dan knew the team needed to use the app. This wasn‘t a visionary-ignoring-reality situation — to his credit, he was clear about it. Dan was user number one. He had a precise vision of what Apex needed to do and how it could work for people. But his understanding was conceptual. He had the architecture of the idea. The product was a different animal — messy, specific, full of decisions the AI had made and I’d accepted and nobody had documented. The gap between Dan's vision and the actual artifact was the same gap the team was falling into. Everyone was working from a slightly different version of what Apex was.

The mad dash wasn't a project plan. Not a war room with a whiteboard. A few exceptional people willing to run hard in the face of not knowing. No SOPs. No playbooks. Willingness to create them in real time, under fire, while customers were watching.

Communication went through the roof. Not structured — frequent. Messages flying. Questions answered in minutes because they had to be. And a culture emerged that I didn‘t plan but I’m grateful for: if something didn't exist, nobody asked why. They moved on and built it, or worked around it, or flagged it and kept going. The alternative — stopping to blame the builder for not having documentation, not having training materials, not having a support process — would have been reasonable.

It would have killed us.

Some of those people chose to stand in front of the firing squad. That‘s the only honest way to describe it. They took customer calls knowing they didn’t fully understand the product. They answered questions with their best understanding and then came back to me to verify. They got things wrong and corrected themselves. They were the human buffer between a product that wasn't ready and customers who had been promised something.

Because of Dan‘s reputation, our first round of customers were forgiving. They knew it was new. We’d set that expectation clearly. And that forgiveness turned out to be one of the most valuable things we had — not because it let us off the hook, but because it gave us room to learn. Every customer interaction was a data point. Every confused question revealed an assumption we‘d made that didn’t hold. Every “I thought it was supposed to do X” showed us the gap between what we'd built and what people expected.

Letting people in — that‘s the lesson underneath the chaos. Not keeping them at arm’s length until the product was perfect. Letting them see the mess. Letting them be confused. Letting them tell you what matters by watching what they actually try to do. The customers who stuck with us through those early weeks taught us more about what Apex was than any amount of internal testing would have.

And here‘s what I learned about myself: I had attached value to things that didn’t matter. Features I was proud of that nobody used. Architectural decisions I thought were clever that customers walked right past on their way to the three things they actually cared about.

The overselling wasn't malicious. It was a team figuring out what the product was while simultaneously telling customers what it could do. The pitch evolved weekly. Sometimes daily. Not because we were dishonest — because we were learning in real time what honest even meant for this product.

Nobody quit. Customers stayed. But there were varying levels of joy — I'll put it that way.

The world model lens from Chapter 1 keeps applying in places I didn‘t expect. The journey from one to two is about externalizing the understanding — getting it out of the builder’s head and into systems. But at Apex, the understanding hadn‘t even made it to the team, let alone into systems. The world model was trapped in two heads — mine and Dan’s — and even our two versions didn‘t match. The code had its own version. The pitch deck had another. The customer’s mental model was yet another. Five versions of what Apex was, none complete, all partially true.

You can have working code, paying customers, and a team of good people, and still not have a product — if the understanding of what the product is hasn't survived contact with real humans. The code is the skeleton. The understanding is the body.

Whether you‘re solo or have a team, the test is the same: put the product in front of someone who wasn’t there when you built it. Watch what happens. The questions they ask — the confusion, the workarounds, the “wait, how does this part work?” — that's your real feature list. The one your product is writing in the gaps between what you built and what humans need.

Daniel Noel learned this the expensive way. Two hundred thousand dollars building past “feature complete” without validating that anyone knew how to use it. His advice — “underinvest in features and overinvest in one or two people” — is the product gap in a sentence.

Sergey Izvekov hit the same wall from a different angle. Full web app, iOS, Android — and his team couldn‘t sell it. “The whole problem flipped. Building was the easy part. Now it’s: who is this for, how do we position it, how do we even explain it properly?”

Three versions of the same gap. Daniel‘s team built features nobody adopted. Sergey’s team built a product nobody could explain. Our team at Apex built a platform our own people couldn‘t use. In every case, the code worked. In every case, the product wasn’t real.

AI made this gap wider. When building takes months, the team learns the product as it‘s being built. They’re there for every decision, every pivot. The understanding accumulates naturally, at human speed, alongside the code. When building takes days, the team shows up to a finished artifact with no history, no context, and no map.

You can't deploy shared understanding with a git push.

The fix is not documentation. Documentation helps, but it‘s a trailing indicator. The fix is proximity. Put people close to the product early — not when it’s ready, while it's still wrong. Their confusion is your most valuable feedback loop. Their ability to explain it to someone else is the test of whether the understanding has left your head.

At Apex, the team that ran through the chaos built something no codebase could contain: a shared understanding of what the product was, what it wasn‘t, and what it needed to become. That understanding didn’t come from a document. It came from the friction of real humans colliding with a real product and refusing to let the confusion win.