A Development Strategy describes how a product, system, or feature will move from an approved design into working software. It establishes how the work will be divided, estimated, built, tested, reviewed, and eventually released to users.

The goal isn’t to predict every detail before development begins. Software has a habit of teaching us things once we start building it. Requirements become clearer, technical constraints appear, users respond differently than expected, and sometimes an idea that looked great on paper simply doesn’t work as well once it’s real.

A good Development Strategy accounts for that uncertainty. We plan enough to know where we’re going, work in small enough pieces to learn along the way, and use what we learn to improve the plan.

Terminology

In this article, I’m deliberately using a few broad terms because different teams use different names for similar concepts.

Iteration refers to a short, focused period of development. You might know it as a sprint.

Development Cycle refers to a larger collection of iterations working toward a meaningful objective. Depending on the project or methodology, you might instead call this a release, milestone, phase, or something similar.

The terminology matters less to me than the structure: small pieces of work should contribute toward something larger, and each should give us an opportunity to learn before committing too heavily to what comes next.

Plan the cycle. Refine the iterations.

Before development begins, I group related features into Development Cycles. Each cycle should have a meaningful objective: a feature set, capability, milestone, or other collection of work that moves the product forward.

We can estimate that cycle at a high level, but I don’t expect every iteration inside it to be perfectly defined from the beginning.

Instead, the upcoming iteration gets the most attention. Its requirements are refined, its work is broken down, and its estimate is based on the best information we currently have. Later iterations remain more flexible because we know something important:

By the time we reach them, we’ll know more than we do today.

Estimate the iteration, not the future.

An iteration is a short period—typically around a week—during which I focus on a specific, achievable set of functionality.

At the beginning of the iteration, we should have a clear idea of what we’re trying to accomplish and enough information to reasonably estimate the work. While I’m building the current iteration, stakeholders can review what came before it, answer questions, and help refine what comes next.

That overlap is important. Development doesn’t need to stop every time someone needs to review something, and stakeholders don’t need to wait until the entire project is finished before they see working software.

It also makes estimates more useful. Estimating six months of detailed development before we’ve written the first line of code creates a level of precision that simply doesn’t exist. Estimating the work immediately in front of us lets us use what we’ve already learned.

The closer we are to the work, the more precise the estimate can become.

Three environments. Three different jobs.

Development, staging, and production aren’t simply three copies of the same application. Each environment has a different purpose in the process.

Development is for planning.

Development is where new work first becomes real.

This environment is allowed to change frequently. Features may be incomplete, data may be mocked, experiments may fail, and things may occasionally break. That’s expected. Its purpose is to give me a place to build and test ideas without affecting the stable version of the product.

It’s also where the next iteration begins to take shape. Questions that couldn’t be answered during design often become obvious once implementation starts.

Development is where we find out whether the plan actually works.

Staging is for proving.

Once a feature is stable enough to evaluate, it moves to staging.

Staging should resemble production closely enough that stakeholders can experience the feature in something approaching its real environment. This is where we confirm that the implementation matches expectations, test complete workflows, identify usability problems, and make sure the feature is actually ready for users.

The important distinction is that staging isn’t where we’re inventing the feature anymore.

Development asks, “Can we build this?” Staging asks, “Did we build the right thing?”

Production is for users.

Production is the live application.

By the time something reaches production, it should have already survived development, stakeholder review, testing, and approval. Production isn’t the place to discover whether a feature fundamentally works.

That doesn’t mean production teaches us nothing. Quite the opposite. Real users will interact with software in ways that designers, developers, and stakeholders didn’t anticipate.

But those lessons should inform future iterations—not turn the live environment into our testing ground.

Production is where our assumptions finally meet reality.

Give users a chance to prove us wrong.

Stakeholder approval tells us that we’ve built what we intended to build. It doesn’t necessarily tell us that real users will experience it the way we expected.

For features where that uncertainty matters, a user trial gives a small or selected group of users an opportunity to work with the feature before it becomes broadly available. Their feedback can reveal confusing workflows, missing information, unexpected behaviors, and needs that weren’t obvious during design.

Not every project needs a formal user trial. The amount of validation should fit the risk and complexity of the feature.

The point is simply to create an opportunity to learn before a mistake becomes expensive to undo.

Final Approval

At the end of the cycle, the work we’ve built and tested needs a clear decision: is this ready?

Stakeholders review the completed functionality, outstanding issues, user-trial feedback where applicable, and any changes that occurred during development. Once the agreed requirements have been satisfied, the work can receive final approval and move into production.

If development uncovered something that materially changes the scope, timeline, or budget, that change shouldn’t quietly become part of the project. It should be documented, discussed, and approved. Significant changes can be incorporated into the Project Plan or handled through an addendum to the original proposal.

Once approved, completed features become part of the project’s finalized work.

Approval creates a line between what we’ve agreed is finished and what we’ve learned we should do next.

Every iteration teaches us something.

The first iteration is usually the one we know the least about.

We may have good requirements, thoughtful designs, and reasonable estimates, but we haven’t yet learned how those assumptions behave inside the actual system. Once development begins, we start collecting real information.

How long did the work actually take? Which requirements were incomplete? Where did the architecture help us? What created friction? How quickly could stakeholders provide feedback? What did users misunderstand?

Those aren’t just observations about the iteration we finished. They’re information we can use to make the next iteration better.

Estimates can become more accurate. Requirements can become clearer. Work can be divided differently. The Development Cycle itself can change if what we’ve learned suggests that our original plan no longer makes sense.

That’s why I don’t see a changing plan as evidence that planning failed.

A good plan is supposed to get smarter.

How long should an iteration be?

For many of my projects, I prefer iterations of about one week. That’s usually long enough to accomplish something meaningful without creating too much distance between building something and getting feedback on it.

But iteration length should fit the project and the people involved.

If stakeholder feedback takes several days, a one-week iteration may create unnecessary bottlenecks. If the work is highly exploratory, shorter iterations may make sense. Larger teams may also benefit from a different cadence than a project being handled primarily by one developer.

Consistency is generally more useful than chasing the theoretically perfect length.

An iteration should be long enough to build something meaningful and short enough that changing direction doesn’t become expensive.

How many iterations should there be.

There isn’t a magic number.

Instead of deciding that a project needs twelve iterations simply because twelve fits nicely on a schedule, I prefer to start with what the Development Cycle needs to accomplish.

The features required to reach that objective can then be divided into logical iterations. Early iterations might establish foundational functionality, later ones may build on it, and the final iterations can focus more heavily on refinement, integration, and validation.

A small cycle might need only a few iterations. A larger one may need considerably more.

The important part is that the number isn’t arbitrary. Iterations exist to serve the objective of the Development Cycle—not the other way around.

And then we do it again.

We start with a meaningful objective and divide it into manageable iterations. Work moves through development, staging, review, and—where appropriate—user trials. Stakeholders provide feedback throughout the process, estimates become more informed, and the Project Plan evolves as we learn.

Once the cycle’s objective has been satisfied and the work receives final approval, it can move into production.

Then we do it again.

Later cycles benefit from everything we’ve learned during the earlier ones. Estimates become more grounded in actual project history. The team understands the product better. Stakeholders become more familiar with the review process. And users begin providing real-world information that no amount of planning could have given us beforehand.

That’s the strategy behind the title of this article.

We can’t plan everything. But we can plan what we know, build enough to learn something new, and use what we learn to make a better plan.