There’s a moment, right after something goes live, where the team exhales. The feature is out. The release notes are written. Someone posts in the channel. It feels like the end.

It’s not.

In my team, we work towards MVP. Get the smallest useful version of the thing in front of real users as quickly as possible. Not because we’re cutting corners, but because I’ve learned that the most valuable feedback comes from people actually using the product, not from people reviewing a specification.

MVP is a starting point, not a finish line. That’s where a lot of teams get it wrong.

The moment something ships, a new phase begins. One that’s less exciting, harder to plan for, and almost never gets the same energy as the build.

As soon as our MVP is released, we shift. I listen to stakeholder feedback. I review our support channels. I look at how people are actually using the thing versus how we expected them to use it.

Sometimes the feedback confirms assumptions. More often, it doesn’t. Features get used in ways we didn’t anticipate. Workflows that made sense in a prototype feel clunky in production. Things we thought were obvious turn out to need explanation.

This is the work. Not the build. The iteration.

Continuous improvement sounds great in a strategy document. In practice, it means going back to something you already shipped and making it better, which is less fun than building something new.

There’s no launch moment for “we improved the error messages on that form.” Nobody posts a celebration emoji when you tweak a date picker based on user feedback. But these are the changes that turn an MVP into an actual product.

Some of the feedback is expected. Some of it is things I never considered. All of it is more valuable than my original assumptions.

The problem is incentives. Building something new is visible. Iterating on something that already exists is invisible. Sprint reviews celebrate launches. Nobody gets a standing ovation for “we made the thing we shipped last quarter slightly less confusing.”

But the products that people actually enjoy using are the ones that kept improving after launch. The ones where someone noticed that a button was in the wrong place, or a flow had one too many steps, or a label was technically correct but practically meaningless.

That’s not MVP. That’s craft. And it happens after shipping, not before.

If I’m honest, there isn’t a finish line. The best products I’ve worked on are the ones that never felt “done.” They just kept getting better, one small improvement at a time, informed by the people using them.

The feature isn’t finished when it’s deployed. It’s finished when it stops needing to change.

In my experience, that almost never happens.