Skip to content
Hooney Notes

How Far Should I Take a Product Before Releasing It?

The tension between refining a product and finding out what it is worth, and the risks on both sides for a developer in the age of AI.

  • AI
  • Development
  • Product
An orange path crosses points for work and review on an off-white page before reaching its goal.

When I build a product, I start to notice things I could not see at first: a transition between screens, whether I can pick up where I left off, and whether there is a way to choose again when the result surprises me. Each one may seem small, but together they shape the experience of using a product.

I think a developer’s craft is the care not to overlook those details. It means going beyond making a feature work and asking whether it feels natural to use and whether people can trust it when it matters.

But wanting to build something well does not answer one question: Can I solve someone’s problem, create value, and receive something in return? A business eventually has to answer that. I have not answered it well enough yet.

Should I stop building and find out what the product is worth now? Am I building to test its value, or am I putting that test off so I can keep working on the parts I want to build?

That does not mean I think what I am building has no value. Understanding the technology and refining a product take time. So does learning to trust an unfamiliar product and making room for it in daily life. But believing something has value and seeing that value confirmed are different things. That is where I am now.

Careful craft or an endless round of preparation?

Developers sometimes use the phrase “yak shaving.” It describes starting one task for the work you meant to do, then finding another task to prepare for that one, and gradually taking a longer route. Every step may connect to the original goal, yet the goal itself keeps getting farther away. (MIT CSAIL)

I do not want to call every careful product detail yak shaving. Helping someone keep their work when they leave and return, correct an unexpected result, or understand an important choice is more than polish. In some cases, those things are what make a product usable in the first place.

The hard part is not only spotting pointless work. Even when something helps, I still have to decide whether it needs to happen now.

For example, letting someone undo an AI-generated result may be necessary for them to trust it. Organizing the internal structure to support that feature may also be necessary. But if the next round of structural work leads to another round of cleanup, I need to look again at how far it is from the experience I am trying to protect.

One more change might make things better. A little preparation might make the next task easier. Each step has a reason. But if I accept every reason, the list of things to do before release never seems to get shorter.

Craft and endless preparation can feel alike while I am working. Both take time, solve problems, and improve something. Effort alone does not tell me which one I am doing. I also need to ask whether the work helps someone discover the product’s value, or mainly helps me feel ready.

An orange path links work notes, modules, and evaluation charts in a loop of preparation before reaching a product outcome.

Even when every task has a reason, I need to check how far it takes me from the question I meant to answer.

When preparation for validation delays validation

I find this boundary harder to see as I use AI tools. I can make more things, and revise more of them. Improvements I might once have left for later now seem within reach.

I think that makes it more important to evaluate the user experience and quality. It is not enough to implement a feature; I need to pay closer attention to the experience those features create together.

But that same belief can make it harder to release. I see how the result could be better and think I should do a little more. I think I need to meet a higher bar before I can show people the value. Gradually, the level of completeness I consider necessary for validation rises.

That is the pressure I feel. I can build faster, but the quality bar I think I need to meet before release rises too. I want to make something better so I can keep up, yet the moment I show it to people moves farther away.

Would releasing faster solve the problem?

If I keep refining the product on my own until it feels complete enough, I delay the chance to learn what people who use it actually care about. They may value something much simpler than the part I spent the most time on, or they may not use it for a reason I never considered. I cannot know until I meet them.

On the other hand, if people cannot finish what they came to do because I released too early, their response may be hard to understand. I may not know whether they did not need the product or needed it but could not use it properly. Missing quality can keep real value from showing through.

So neither more polish nor a faster release is an answer by itself. If I keep refining for too long, I miss a chance to learn. If I release too early, I may not know what I learned. Choosing either side does not make the tension go away.

An orange path passes a review point and reaches markers for people's responses, while a shortcut below ends abruptly.

A late release and a release that comes too soon can each make it harder to learn, in different ways.

How much refinement does a product need before I can show it?

I still want to turn the experiences I care about into a product. In an era when AI makes it possible to try more, I think it will be hard to survive if I give up on the product. I want to build on that belief, show it to people, and find out what it means to them. I do not want to dismiss all the time and possibility behind it just because I have not proved it yet.

But I cannot keep putting off the work of finding out.

The release bar cannot be “nothing left to improve.” How complete does a product need to be before people can use it to do what they came to do and judge its value? That is the question I want to answer first.

Can someone complete the task they came to do? Are their important choices and results preserved along the way? Can they try again if something goes differently than expected? Refinement that helps answer those questions may be necessary. But if every next task begins with “before that, we need to…,” I should ask how it relates to the value I am trying to test.

I do not have a clear line yet. Some work needs to happen before release; other needs may only become clear after someone tries the product. The hard part is deciding which is which in advance.

Time spent understanding and refining the technology, time spent helping people trust and use the product, and time spent turning that experience into business value are different. I do not want to call all that time wasted just because I do not have enough evidence yet. But needing time cannot become an excuse to keep delaying the release.

What I need to work out is how to make that judgment: when more refinement could help, and when I need to show people the product to learn what comes next.

I want to be someone who builds good products. I hope that desire does not become the reason I never put one into the world.

Discussion

Anyone can read the comments. Sign in with your GitHub account to join the conversation.

Can't see the comments?Find the conversation on GitHub ↗

Comments and reactions