Saturday, June 27, 2026

I almost didn't write this.

Not because it's uncomfortable — although parts of it are — but because most company "lessons learned" posts are written backward. Someone takes a decision that worked out and reverse-engineers it into wisdom. The failures that nearly ended the company get softened. The pivots get reframed as strategies. The moments of genuine panic get edited into "productive uncertainty."

What I want to write is the other version. The one where the decisions were actually bad, the reasoning behind them was actually flawed, and the thing that saved us wasn't cleverness — it was a combination of stubbornness and luck that I won't pretend was a plan.

Nexus is doing well now. We have customers we're genuinely proud of. The product does things I wasn't sure we'd ever figure out how to build. But the path here included eighteen months where I wasn't sure we'd make it, and I think the specific texture of those eighteen months is more useful to other builders than the version where everything makes sense in hindsight.

So. Here's what actually happened.

We Built for the Customer We Wanted, Not the One We Had

The original vision for Nexus was an AI analytics platform for enterprise marketing teams. That was the pitch. That was who we interviewed during research. That was the persona we designed around and the problem we thought we were solving.

The first twelve customers who actually paid us were none of those things.

They were small growth teams — two to five people — at Series A and Series B startups. Scrappy, understaffed, operating with budgets that our original enterprise target would consider rounding errors. They found us through Twitter and ProductHunt. They signed up for trials on Friday nights. They emailed us directly when something didn't work.

And here's what I told myself about this for far too long: these are early adopters, not our real market. The enterprise customers are coming. We just need to get the product to a level where they'll take us seriously.

That story was comfortable because it meant we didn't have to change anything. The customers we had were a phase. The customers we wanted were the destination.

It took us nearly eight months to face what was actually true: the customers who were paying us, using us daily, and telling their friends about us were not a temporary anomaly. They were telling us something. The fact that we'd built something genuinely useful for a specific type of team — and specifically not useful for the enterprise customer we'd been designing for — was information we refused to accept.

The moment that broke through was a call with a VP of Marketing at a large media company. We'd spent two months chasing this meeting. The call lasted twenty-two minutes. She said the product was interesting but that her team needed integrations with five enterprise systems we didn't have, procurement processes that would take eight months, and a security review that we weren't resourced to pass. Then she wished us luck and got off the call.

I sat in my apartment afterward and thought about the twelve people who had paid us that month without being asked, without a sales call, without a procurement process. And I thought about how little we had learned from them because we were too busy chasing someone else.

We changed our roadmap the next week.

We Confused "Impressive" With "Useful"

In the early versions of Nexus, we had a feature we were genuinely proud of. We called it the Intelligence Graph — a visual map of every data connection in your analytics stack, with AI-generated annotations showing how each node influenced your key metrics. It looked extraordinary in demos. Investors who saw it consistently said some version of "whoa."

Our actual users never opened it.

Not rarely — never. We had a cohort of forty paid users at the time we discovered this. The Intelligence Graph had been live for three months. Forty users, ninety days, zero voluntary opens. The only session data we had came from our own team testing it.

We did what any reasonable team would do: we assumed the problem was discovery. We added an onboarding tooltip. We put it in the navigation. We sent an email campaign specifically about it with a GIF of it working. Usage went from zero to nearly zero, then back to zero.

Marcus and I spent a long time not wanting to say what was becoming obvious. We had built something that was technically impressive and completely irrelevant to the problems our users were actually trying to solve. Every hour we'd spent on the Intelligence Graph was an hour we hadn't spent on the reporting automation that three different customers had asked for by name in the same week.

"Impressive in demos" is a real thing to optimize for, but only if your demos lead to customers who stay. Ours didn't. The customers who converted from Intelligence Graph demos left within sixty days because the feature they'd been wowed by didn't connect to anything they needed to do every day. The customers who converted based on our more boring features — the ones where we'd say "it automatically pulls your weekly numbers and drafts the summary" — those customers stayed. They weren't wowed. They just kept coming back.

We killed the Intelligence Graph seven months after we launched it. It remains the right decision.

We Hired for the Team We Wanted to Be, Not the Team We Were

There is a version of this section where I name everyone we hired prematurely and explain in detail why it didn't work out. I'm not going to do that because those people don't deserve to be examples in a blog post. What I will say is that between months six and twelve, we hired five people and let three of them go within four months, which meant we spent significant money on severance, significant time on hiring, and an enormous amount of emotional energy on transitions that left everyone feeling worse than before we started.

The pattern in every case was the same. We'd hit a problem that felt big — a technical limitation, a sales gap, a customer success deficit — and our instinct was to hire someone who could solve it. The hire would come in, encounter a product that was still finding its shape, a company culture that hadn't yet hardened into something consistent, and a leadership team that was operating on four hours of sleep and changing priorities weekly. They'd spend their first month trying to understand what we actually needed. By month two, it was clear the role as defined didn't exist yet. By month three, everyone had silently acknowledged that this wasn't working.

What we needed in that period wasn't more people. We needed more clarity. We needed to know what we were actually building well enough that a new hire could contribute to it rather than join in the confusion.

The hires that worked in that period were the ones who brought tolerance for ambiguity and a genuine desire to build something from scratch — not people who were great at executing a defined role. We learned to ask different questions in interviews. Not "what have you built?" but "tell me about a time when the thing you were supposed to build turned out to be the wrong thing, and what you did next."

We Ignored the Feedback That Made Us Uncomfortable

We had a customer in month four — a growth team at a direct-to-consumer brand — who gave us the same piece of feedback three separate times in three separate sessions. She said the product was powerful but that she never knew where to start when she opened it. She said it felt like opening a toolbox when what she wanted was someone to hand her the right tool.

We logged the feedback. We thanked her. We told her we were working on onboarding improvements. Then we worked on other things.

She churned in month five. In her exit survey, she wrote four sentences. Three of them were variations of the same thing she'd said three times before.

This is embarrassingly common. The feedback that is hardest to hear is usually hardest to hear because it requires changing something fundamental — not a button placement or a tooltip, but a core assumption about how the product works. Fixing that kind of feedback is slow and expensive and requires admitting that something you built confidently was wrong.

So teams log it, acknowledge it, and quietly hope that enough other users don't feel the same way. They usually do.

The onboarding she was describing is now one of Nexus's most praised features. It took us four months to build after she left. Every time I see a positive review that mentions it, I think about how we had the information in month four and chose to act on it in month nine.

We Tried to Grow Before We Had Anything Worth Growing

Month ten was when we ran our first paid acquisition campaign. We'd raised enough money to try it, we had a product that worked, and everyone we talked to said that at some point you have to find out if you can grow beyond word of mouth.

We spent sixty thousand dollars over six weeks. We got a lot of signups. Nearly all of them churned within thirty days.

The problem wasn't the campaign. The targeting was reasonable, the creative was decent, the landing pages were clear. The problem was that we were pouring water into a leaky bucket — driving new users into a product experience that hadn't yet solved the retention problem at its core. People would arrive, get confused at the same point our organic users got confused, and leave. The difference was that organic users who stayed were either highly motivated or had a connection to us personally that kept them patient through the rough edges. Paid users had neither.

We stopped the campaign and didn't run another one for five months. In those five months, we fixed the things that were causing people to leave. We weren't ready to grow before we'd earned the right to — meaning a product that keeps people once they arrive.

What Eight Months of Wrong Decisions Actually Teaches You

I don't think of that period as lost time, even though parts of it were genuinely painful. What it gave us was specificity — a clarity about what we were building, who it was for, and what it needed to do that we could not have arrived at any other way.

You cannot think your way to product-market fit. You can only act your way toward it — which means being wrong, noticing you're wrong, and changing direction faster than you lose the will to continue. The teams that don't make it through this phase aren't usually the ones who make the worst initial decisions. They're the ones who hold onto those decisions longest.

The question I now ask about every significant product choice is simple: if this turns out to be wrong, how quickly will we know, and what will we do next? It sounds obvious. It took us eighteen months to make it a real habit.

Nexus is better for every decision we got wrong. Not because failure is valuable in itself — it isn't — but because the specific texture of each failure told us something true about the product and the people who needed it. That information was not available any other way.

If you're in the middle of a period that feels like this, the only advice I have is to keep the feedback loops short, stay honest about what the data is telling you, and don't let the story you want to be true crowd out the story that's actually happening.

The story that's actually happening is always more useful.