The case for shipping a product before you have a product strategy

The conventional advice for any new product is well-established: define the strategy first, identify the target customer, validate the problem, then build. Most founders nod along to this sequence, then sit in a strategy room for three months trying to write a deck they cannot honestly believe in because they have no real data to anchor it.

There is another way. Three of our recent product engagements have followed it, and the results have been instructive enough that we wanted to write down what we have learned.

Strategy decks are cheap. Code in users' hands is not.

The hidden cost of the strategy-first approach is not the time spent on the deck. It is the false confidence the deck creates. A well-written strategy document feels conclusive. It has charts. It cites numbers. It identifies a segment. By the time the team starts building, the strategy has calcified into something nobody wants to question, because questioning it would mean admitting the last three months were spent on assumptions.

The alternative — shipping a thin, deliberately incomplete version of the product into the hands of a small number of real users — is uncomfortable for exactly the same reason strategy decks are comforting. It exposes what you do not know. It produces conflicting signals. It generates feedback that contradicts your assumptions. But this discomfort is the point. Discomfort is what learning feels like.

Three engagements, three different patterns

Avluz — testing whether the data was the product

Avluz, our price intelligence platform, started with a hypothesis we were not sure we believed: that everyday shoppers would pay for, or at least heavily engage with, structured price history data the way that Amazon sellers already do. The strategy-first version of this project would have spent months mapping consumer segments, modelling willingness to pay, and building a comprehensive feature set across multiple retailers.

Instead, the first version of Avluz did one thing — show the seven-day price history of a product when you pasted in its URL — for a small set of categories. We shipped it, watched what happened, and learned more in two weeks than we would have in two quarters of strategy work. The shape of the product today, with its catalogue of millions of products and its emphasis on category-level trend data, was decided by what users did, not by what we predicted they would do.

SellerBlaze — letting the workflow define itself

SellerBlaze, our Amazon seller analytics product, took a slightly different shape. We knew the audience well — Amazon sellers have a known set of problems, well-documented in forums and reviews. The risk was not "is there a problem?" but "which of the many problems is the wedge we should lead with?"

Rather than picking the wedge by analysis, we shipped four distinct features in the first release and watched usage. Two of the four were essentially ignored. One was used in unexpected ways that suggested we had misunderstood the workflow. The fourth became the spine of the product and continues to drive the majority of engagement today. Three months of strategy work could not have surfaced that ordering. Three weeks of real usage did.

ViralForge — discovering the customer was upstream

The third engagement, ViralForge (sucut.xyz), was originally pitched as a tool for individual content creators. We built a clean, focused version of the product for that audience, launched it, and watched the analytics carefully for two weeks.

The pattern that emerged was not what we expected. The most engaged users were not individual creators. They were small media operations and content agencies — people who needed to process volume rather than craft individual pieces. We had built for the wrong customer. But because we had built quickly and cheaply, the pivot was a matter of repositioning, not rebuilding. Had we spent three months on strategy first, we would have spent that time refining our understanding of the wrong audience.

What this approach actually requires

Shipping-as-research only works if a few preconditions are met. It is not the right approach for every team or every product. The preconditions are:

• You can build cheaply. If the minimum credible version of the product takes six months and a million dollars, this approach is wrong for you. You need to be able to ship a thin slice in weeks, not quarters.
• You can measure honestly. Shipping without instrumentation is just throwing things into the void. The product needs to be wired with analytics from day one, and the team needs to be willing to look at numbers that contradict their assumptions.
• You can change direction without ego damage. If the team cannot tolerate the early results being wrong, the early results will be ignored. This is more cultural than technical.
• You have a small, real audience to ship to. Public launches are too noisy for early learning. The first ship needs to land in front of twenty, fifty, perhaps two hundred real users — enough to generate signal, few enough that you can actually talk to them.

What the shipped product should not be

This approach is sometimes confused with "ship anything, see what sticks." It is not. The first ship has to be coherent enough that the user can succeed at one specific thing. The discipline is not in shipping less; it is in shipping a narrower scope of working product rather than a broader scope of half-finished product.

A good first ship is a knife. It does one thing well. A bad first ship is a Swiss Army knife with two tools missing and one tool that bends if you push too hard. The first communicates seriousness; the second communicates that the team is not yet ready to take this product seriously.

Where strategy actually belongs

None of this is an argument against strategy. It is an argument against strategy-before-evidence. Once you have shipped, gathered real usage data, and learned what your users actually do, strategy becomes a much more grounded exercise. It stops being a series of bets dressed up as conclusions and starts being a series of conclusions that the data supports.

For each of the three products we mentioned, the strategy document we wrote at month three was completely different from the one we would have written at month zero — and infinitely more useful. The early ship was not a substitute for thinking. It was the data source that made thinking possible.

If you are sitting in a strategy room right now trying to write a deck you do not quite believe, the most useful thing you can do is close the laptop, find the smallest possible version of your product that could plausibly help five people, and start building. The deck you write afterwards will be the one that was worth writing.