Stop Making the Wrong Thing Better

I've spent a lot of time in startups and big companies chasing product–market fit. Getting it on the first try is rare. Most of the time I'm guessing and wondering whether I'm early or just wrong.

When I'm in that fog, these are the principles I come back to.

Building things "right" before we know if they'll work is a huge waste of time. When we have a thesis to test, I look for the scrappiest way to learn the truth fast.

At one company, we were building a commerce system that required a credit card. We had no idea if people would actually pay. Instead of building payments, we put up a dialog that didn't charge anything. It just counted how many people tried to pay.

It wasn't pretty or functional. But it answered the only question that mattered.

Early progress is often just a more expensive way to avoid the truth.

When I'm building something new, my first design is always wrong. Not because I wasn't thoughtful, but because it hasn't met real usage yet.

So I aim for just enough that someone can complete the core journey. Then I ship and watch.

Where people hesitate or misunderstand things is where the product actually is. Good products aren't designed in one pass. They're debugged into existence.

When teams get stuck, the instinct is to polish. Tweak things. Add features.

Sometimes that helps. Most of the time it doesn't change much.

If we're playing the same game as everyone else, small improvements don't show up. When progress stalls, it's usually because we're playing the wrong game. Getting unstuck means making a real change, not a tweak. A different user, a different problem, or a different product altogether.

If I'm not using the product for real work, that makes me nervous.

At Borland, we used the compiler to build itself and set a hard date to switch to the alpha. It was a mess, but once everyone lived inside the product, things improved quickly.

Bugs became obvious. Priorities got clear. Fixes landed fast.

A lot of teams think they're talking to users when they're really just broadcasting and waiting.

Silence isn't feedback.

When I want signal, I spend time watching how people actually do the work today and listening to what "better" really means to them.

If we don't do that, we still get feedback. It just shows up later as churn.

If I zoom out, it all comes down to this: start with a thesis, find the hack, ship something real, learn fast, and be willing to change.

I'm back doing this again at Guild.ai, and these lessons feel just as sharp now as they ever have.

The job isn't to defend the idea. It's to figure out what's actually true.

The most common failure mode I've seen is brutal in hindsight: months spent making the wrong thing better.

Guild is the enterprise runtime for AI agents — built for teams that need governed, observable, event-driven execution they can actually trust in production.

We're applying these same lessons as we build: shipping fast, staying close to users, and making real changes when the signal tells us to.

Want to see what we're building? Join the waitlist →

We're onboarding design partners now and would love to hear how your team is thinking about AI agent deployment.