AmirHossein BozorgKian
I help businesses accelerate growth with Agile mindset and scalable software solutions
In Uncertain Conditions, the Emphasis Is on Learning, Not Production
A short while ago, in one of my conversations, a topic came up that has always been a challenge for me:
Should we take action quickly, or should we first dedicate enough time to learning and discovery before making any move? In that discussion, many defended the concept of “Fail Fast” — failing quickly to learn quickly.
This question led me to reach out to Kent Beck for his perspective. The term “Fail Fast” originally comes from the world of TDD (Test-Driven Development), and since TDD became mainstream through the XP method, this term gradually turned into a common idea in Agile conversations. I asked him this question directly in a LinkedIn message, and fortunately, he kindly responded.
His answer was enlightening. He wrote:
“In uncertain conditions, the emphasis is on learning, not production. Production comes as a side effect of learning.”
That sentence was a turning point in my thinking. My personal interpretation is that in today’s world — full of uncertainty and rapid change — if we don’t prioritize learning before execution, we quickly fall into the trap of building without purpose, creating low-value outputs.
This article is a continuation of that mindset and my personal reflections: why learning should precede execution, what dangers lie ahead, and how we can build truly valuable products for users using the right tools and approaches.
Learning Before Doing: Why?
After receiving that short but powerful sentence, it became clear to me that in the world of product and software — especially in uncertain environments — Learning must always come before Doing. This isn’t just a motivational quote; it’s a real necessity for survival and growth.
In many teams, when people jump into execution without a deep understanding of the user’s real problem or need, they quickly encounter cycles of expensive rework, bloated products, declining performance, increased technical debt, and user dissatisfaction.
At first glance, “starting fast” may seem appealing. However, when you look at the results, it often becomes clear that a lot of time, energy, and resources were spent without delivering real value.
Learning before execution means understanding exactly what problem we’re solving (Why), what needs to be built (What), and who the real customer or user is (Persona). This clarity enables the team to move forward with confidence and avoid building wasteful or misaligned features.
The Deming Cycle (PDCA) and Incremental Learning
One model that helped me better understand the importance of learning before execution is the Deming Cycle, or PDCA. Originally designed for continuous improvement, it plays a key role in the product and software world — especially under conditions of uncertainty.
The cycle consists of four main stages:
- Plan: Define the problem, identify assumptions, and design an initial learning step.
- Do: Execute the plan and collect data.
- Check: Analyze results, compare with assumptions, gather feedback.
- Act: Improve or change direction based on what was learned.
In this model, “Plan” doesn’t mean a full design upfront. It means understanding the issue and preparing just enough. Unlike traditional project management, where planning is a fixed early phase, PDCA treats planning as a living, adaptive effort with the goal of reducing risk and accelerating learning.
This approach helps teams avoid the trap of over-planning and instead improve iteratively and incrementally. Just like the product itself, learning must also be incremental and iterative — step by step, with feedback and adjustment.
Understanding Discovery in Product Strategy
One resource that deepened my view on Discovery and product development was Roman Pichler’s book “Strategize.” In it, he introduces a four-stage path from idea to product:
- Idea
- Discovery & Strategy
- Development
- Product
Many teams skip the second stage — Discovery — and jump directly from idea to development. The result is often a product that doesn’t work, doesn’t solve a real problem, or doesn’t deliver value to the user.
In the Discovery phase, we answer fundamental questions:
- What is the real problem?
- Who is the customer or user?
- What value are we trying to create?
- Does the idea align with market needs and business strategy?
In Strategize, Pichler emphasizes that Discovery — like product development — should be iterative and involve a mindset of Continuous Discovery. With every cycle, through user feedback, strategy review, and, if needed, updates to the product, roadmap, or backlog, we get a clearer picture of the real needs and solutions.
This reminds me that Discovery isn’t a one-time phase. It’s an ongoing process.
Traps and Syndromes: When Learning Is Ignored
In a Feature Factory, the focus is on output — more features, more releases, more motion. But no one stops to ask: Did this change behavior? Did anyone use it? Did it solve a problem?
In the Build Trap, building becomes the goal itself. The team or organization continues developing features based on internal assumptions or time pressure, without clearly understanding why. Delivery replaces discovery.
Warning signs include:
- No time allocated for Discovery
- Top-down feature delivery without validation
- No real feedback from actual users
- Success measured only by delivery speed
By practicing Continuous Discovery, collecting user feedback, and regularly reviewing strategy, teams can return to a healthy cycle of Continuous Improvement and shift their focus from just building to building what truly matters.
Scrum’s Refinement Session(event): Preparation, Not Prediction
In Scrum, there is no official “Refinement” event, but nearly all experienced teams treat it as essential. Refinement is where the team, before entering Sprint Planning, discusses and clarifies Backlog items just enough to make decisions.
The focus is on clarifying “What” and “Why” — not detailed implementation. When teams skip Refinement, they often face issues like:
- Long, unfocused, exhausting Sprint Planning sessions
- Vague or unrealistic Sprint Goals
- Large amounts of incomplete work by the end of the Sprint
The goal of Refinement is not full planning. It’s achieving enough clarity to start — not more. It’s a learning activity, not a forecasting exercise.
In mature teams, these discussions often extend to N+1 or even N+2 items — those that might enter the Sprint in the near future. This creates progressive discovery, where teams are prepared, but not over-planned or locked into rigid assumptions.
Refinement helps teams move forward with learning, not just tasks — making it a direct link to the idea of learning before execution.
Learning: The Prerequisite for Meaningful Movement
It all started with a simple question:
Should we act first and then learn, or should we learn before we move?
The answer I received from Kent Beck — “In uncertain conditions, the emphasis is on learning, not production” — wasn’t just a quote for me. It became a guiding principle in product work, team coaching, and strategic thinking.
Throughout this article, I’ve tried to show that learning before doing is not just a theory — it’s a practical necessity. From the Deming Cycle to Roman Pichler’s strategy models, and even through everyday Agile practices, they all emphasize this shared principle: learning must be continuous, iterative, and tightly connected to action. Without learning, teams fall into traps like the Feature Factory or Build Trap, where making becomes the goal, not value.
In contrast, with Continuous Discovery, real feedback, and strategy alignment, teams enter a cycle where building is the natural result of learning — not its substitute.
If there’s one sentence I want to always remember, it’s the same one this article started with:
“In uncertain conditions, the emphasis is on learning, not production. Production comes as a side effect of learning.”