Kulicki.tech / Blog
Just a few years ago, someone might’ve perceived execution as the biggest challenge for startups. Even the best idea required usually months of work before founders could validate whether there was real market demand. AI has changed that dynamic. Today, a prototype, a landing page, or an early product version can be created in days, sometimes even hours. That is a huge advantage, but it also comes with a significant risk. Never before has it been so easy to create something that looks like progress but is actually moving in the wrong direction. As a result, we can now build things faster than ever, including… things nobody needs.
Don’t believe? Try for yourself 👉🏻 https://www.reddit.com/search/?q=ai+saas
That’s why, in the age of AI, the advantage won’t go to those who simply build the fastest. Advantage will go to those who figure out fastest what is actually worth building.
Why AI makes experiment-first thinking more important, not less important
One of the most common misconceptions in the AI era is the belief that if we can build faster, we automatically learn faster as well. In practice, these two things do not always go hand in hand.
For years, the product development process followed a fairly similar pattern. First, an idea would emerge. Then the team would invest time in building a solution. The product would be released to users (or at least Friends and Family), and only then would feedback come in. The problem was that much of the work had already been done by the time such feedback arrived. If the initial assumption was wrong, we often discovered it only when a significant amount of time and resources had already been spent.
It was precisely this pain point that gave rise to approaches like Lean Startup, Agile, and the concept of the MVP. Their core idea was the same: shorten the distance between an assumption and its verification. Instead of building a complete product and waiting for feedback at the very end, teams started working in short cycles — releasing small increments, measuring real user reactions, and adjusting direction along the way. Learning stopped being the last step of the process and became part of it.
Then AI entered the picture — and dramatically changed the speed of building. What used to take weeks can now take days or even hours. But speed hasn’t changed the fundamental challenge. We still need to answer the same question: “Are we building the right thing?” If anything, it’s now easier than ever to confuse activity with progress. A product doesn’t become valuable just because it’s been created.
This is where the biggest challenge lies. The speed of creation can give the illusion of progress, but execution alone doesn’t answer the most important question: “Are we solving a real problem?” Every idea is built on a set of assumptions. We assume that users actually have a specific need, that it’s important enough, and that the proposed solution will be valuable to them. The problem is that without verification, these assumptions remain nothing more than beliefs.
Experiment-first thinking takes Build–Measure–Learn idea one step further. Test before you even build. Instead of validating an assumption through a working product, even a minimal one, first look for the cheapest possible way to check whether a given direction makes sense at all. Only then do we invest time in implementation. First, we seek an answer to the question of whether a given direction makes sense, and only then do we invest time in implementing it.
What an experiment-first framework actually means
An experiment-first framework is an approach to decision-making where, instead of immediately investing time and resources into building a solution, we first verify whether the assumptions behind that solution are actually valid.
The difference may seem small, but it changes the entire way we work. In the build-first approach, the starting point is an idea. A new feature, a product change, or a new direction is proposed, and the next steps focus on implementing it. Only later do we find out whether it was the right decision.
Agile and Lean improved this significantly. Build something small, measure how users respond, and learn from it. But notice that even here, learning still starts with building.
The experiment-first approach begins even earlier - with uncertainty. Instead of asking, “What should we build?”, we first ask, “What do we need to learn?” Then, we turn our assumption into a hypothesis, design an experiment, collect data, and finally make the next decision based on that data.
The most important change is that we stop treating building as a way to find answers. Building becomes the next step - one we take only after we have more information and a better understanding of the problem we’re trying to solve.
Importantly, prototypes are still a great tool for experiments — but there’s a key distinction: a prototype is not an MVP. Its purpose is not to be a smaller version of the product, but to answer a specific question as cheaply as possible. It doesn’t need to look sellable. It needs to produce a clear learning. The bar for quality rises later, when you move from testing assumptions to testing whether people will actually buy.
Experiment-first doesn’t replace Agile or Lean — it precedes them. Once you’ve tested your riskiest assumptions, you can move into build cycles with far more confidence. You’re not guessing anymore. You’re building on evidence.
How to break down your problem into experiments
An experiment begins when we stop treating the action as an end in itself and use it to gather meaningful information. Instead of asking, “What should we do?”, we ask, “What assumption do we need to test before deciding to act?”
That’s why before launching any experiment, it’s worth answering five questions:
- What assumption do we want to test?
- Who do we want to learn from?
- What result will confirm or refute our hypothesis?
- How will we measure the outcome?
- What decision will we make based on what we learn?
Notice that the template ends with results, but the process shouldn’t. A well-designed experiment doesn’t end with the result alone. Its value lies in helping us make better decisions with greater confidence. “We got 251 signups” is not a conclusion; “we’re moving to a closed beta with these five groups” is. For that reason, experiment-first should not be a one-time exercise but a repeatable decision-making system. Every experiment should leave us with a clearer understanding of our users, market, or product — and that knowledge should shape next decision.
No single framework, no hack, nothing is ever going to guarantee success in GTM. But what it can guarantee is raising the odds of success. Ask yourself every Monday: “Are we smarter this week than last week?” It doesn’t have to be big, and it doesn’t have to be small. If we cannot objectively say that we are smarter this week, we are learning too slowly.