Iteration Zero: A Great Starting Point for New Products

We practice adaptive planning where we approach making plans differently based on the time horizon we’re looking at:

• Iteration = 4 days
• Release = 4-6 iterations
• Project = one or more releases

By iteration we mean a fixed timebox where we take a desired product slice and create a shippable product slice. Our iterations are four days long, because we work on client projects Monday through Thursday, reserving Fridays for internal meetings and personal development.

Note not all software projects create a new product. Many software projects are enhancements to existing products or systems. This article will focus on software projects where we are creating a new product from scratch, from an initial concept all the way through releasing a final product to customers. 

Does agile mean no planning?

When we start developing a new software product, it can be tempting to immediately start writing code so we can get to market quickly. Why waste time planning – isn’t that old fashioned? Isn’t it faster and more agile to start building now and figure out the rest later?

“Plans are worthless; planning is everything.” – Dwight D. Eisenhower

Just Enough Up Front

When we create a new product, how do we get going in a lean, agile way while making sure we solve the right problem? How do we balance making decisions at the last responsible moment, without going in the wrong direction resulting in massive waste of time and money?

The hardest single part of building a software system is deciding precisely what to build.”

Frederick Brooks, Jr.

During the first week of creating a new product, we lay the foundation for a successful outcome. We call this first week “iteration zero” because it is a special iteration where we answer the most important questions:

• What is the immediate business need?
• What does success look like, and how do we measure it?
• Who are we building this product for and what do they care about?
• What does done look like?
• How will we will build this product?
• What constraints will affect this project?

When we finish iteration zero, we have a gameplan to create a minimum marketable product, user experience, and software system through a set of releases within a target time range with a list of unknowns, risks, assumptions, and constraints.

Here are some examples of activities we perform during iteration zero.

Business and Customer

We start by getting to know a client, their business, and their customers. What is the problem they are trying to solve? How does software fit in? Why aren’t existing solutions getting the job done? What are customers’ expectations? Why build something now?

Domain Discovery

Part of getting to know a client, their business, and their customers is learning about their domain. What does your current business process look like? What are the pain points in your current process? What do you like about your current process? What external entities influence your process? Who carries out the process? Who are the output stakeholders?

All of this information, and more, not only helps us better empathize with your needs, but also suggest changes to scope that will increase ROI.

Problem/Solution Fit

We next ask a client what they want from their product. What are its capabilities, its jobs, its functions? What job is the user hiring the product do to? How does the proposed solution solve the user’s problems and meet business needs? If necessary we may run a design sprint.

We then prioritize requested features into Needs, Wants, Desires. This informs our next few steps of UX Design, Engineering Spike, and Defining Scope.

UX Spike

A UX designer is involved early to get a deep understanding of the businesses needs and objectives. After assessing the client’s goals, the designer will facilitate exercises including customer interviews, see | do mapping, and other activities that help tackle the biggest issues at hand. 

Many teams have found it valuable to run experiments prior to engineering a new product — most notably design sprints popularized by Google Ventures.

Engineering Spike

The purpose of an engineering spike is to determine how to design a software system to support a client’s stated needs and priorities. It takes as input business goals, product concept, platform, non-functional needs such as security, scalability, and monitoring. We evaluate specific designs, technologies, data models, etc in order to frame out how we would build a software system and mitigate risk. If necessary we will consider additional factors such as the client’s existing tech stack, 3rd party APIs, and tooling.

Define Scope

With inspiration from The Four Big Risks, when defining project scope we consider:

• What is viable for the business, expressed by the client
• What is usable by users of the product, expressed by the designer
• What is feasible to build, expressed by engineering
• What is sensible to ship, recommended by product manager and team given the project’s assumptions, constraints, risks, dependencies, and team capabilities

Plan Releases

We plan releases as a large chunk of the desired product that has immediate user value. This helps us understand how to break up the project into parts so we can prioritize, estimate, and start building.

We scope and sequence releases based on:

• Release goal
• Relative value and complexity of each release
• Reducing unknowns as fast as possible
• Obtaining user feedback as early as possible
• Minimizing waste

 After release planning, the outputs are:

• Project scoped with high level estimates for all releases
• First release planned and estimated with granular user stories
• Areas of highest uncertainty/risk marked for follow up

Plan Product Launch

The purpose of planning product launch is thinking through all activities involved with operationalizing the product in order to set up the client for success after our engagement ends. This includes transferring ownership of the product, systems, codebase, licenses, etc to the client as well as training client teams on specific technologies. This step helps clients transition from new product development to go-to-market and operating a production system.

Working Agreements

In order to work together effectively we need to agree on some simple agreements between the client, Very, and any additional collaborators. With respect to planning, some examples: Who will play what role, how do we handle feedback, definition of ready vs. definition of done. We also agree on practical things like quiet hours, preferred meetings times, and so on.

In Closing

Following iteration zero we start our first iteration of incrementally building a new shippable product. We have found this helps us all row in the same direction and manage risk effectively.