Expanding Ripples: Agile Product Development Over Waterfall

Harshal

Dec 8, 20244 min read

Your Ideas Expand In Clarity Like Ripples In A Pond

If you’ve worked in product teams, you might have heard:

Can we finalize all PRDs this week so that engineers can start all design docs next week?

Can stakeholders sign off on the requirements before the team designs the technical solution?

Before starting coding, can you develop a detailed project timeline to know when we can deliver this feature?

Agile product development is incremental, both in problem discovery and product delivery. Let’s walk through the concentric circles illustration and Agile development (vs Waterfall) here. I focus on problem discovery and solution ideation here, but not on project delivery. I also compare this mindset to the Waterfall mindset.

I spent 1 hour 24 minutes writing and drawing this blog. You need 4 minutes to read this.

Agile mindset: Increase your clarity incrementally, like ripples in a pond

The Agile Mindset - Expanding Clarity Like A Ripple In Water

Problem and solution discovery in Agile is like a pebble dropped in still water. An idea generates ripples that expand outward, representing increasing clarity and understanding. Each ripple is a step forward. It brings the product, design, and engineering teams closer to a well-defined solution that addresses customer needs.

As the ripple's radius expands, so does the team's knowledge and the solution's fidelity. This iterative process emphasizes starting with low fidelity and refining clarity over time—similar to evolving from a rough sketch to a polished prototype. Illustration from Alphalogic.

Iteratively going from low-fidelity sketch to high-fidelity prototype

1. Idea Generation

Every product journey begins with a spark—an idea.

Ideas can come from:

Analyzing data
Conversations with customers or sales
Feedback from the support team

At this stage, the idea is the pebble striking the water. It represents a starting point, with little certainty. We don’t know:

Is this truly a problem?
Will customers pay for a solution?
Is it technically feasible to solve?

Concept Backlog

When a problem proves too challenging or its scope exceeds the team’s capacity, shelf the idea. Move the idea to the concept backlog. This backlog acts as a pipeline of ideas, preserving opportunities while allowing the team to focus on solving feasible and impactful problems now. It ensures good ideas are deferred rather than lost, awaiting a more appropriate time for exploration.

2. Tech Feasibility: Easy Or Hard?

As ripples expand, so does the team’s understanding.

The next step is evaluating technical feasibility. Ask engineering, "Is this easy or hard?”.

Continue problem discovery if:

The idea is technically hard but has great potential.
The idea is technically easy and offers minor or major potential.

Move the idea to the concept backlog if:

The idea seems technically infeasible.
The idea is technically hard and has low value.

Thanks to Savio for illustration.

2x2 of technical effort and minor to major potential

3. Problem Discovery

As the Product Manager, validate the problem by ensuring it meets these criteria:

Is the problem real?
Is it significant and worth solving?
Does it align with broader user needs?

Gather feedback from users, stakeholders, and internal teams. The goal is to clearly define the problem, often uncovering new insights in the process.

You’ve succeeded when you can describe the problem to a (a, not every) customer, and they respond, "Yes, I have that problem!"

4. Tech Exploration: T-Shirt Sizing

Describe the customer journey and problem to Engineering, and brainstorm potential solutions. Assess the size of these solutions using a T-shirt sizing scale: S, M, L, XL.

5. Deep Dive Into JTBDs And PRD

At this stage, focus on understanding customer needs to identify the jobs to be done (JTBDs). Synthesize your understanding of your company's customers, industry, and adjacent product teams into a Product Requirements Document (PRD) or, in Amazon's case, a PRFAQ. This process helps crystallize product requirements effectively.

6. Technical Spike Or Design Doc

After defining product requirements, align with the engineering and design teams to ensure everyone is on the same page. At this point, the engineering team begins their design or spike. This spike is a time-boxed exploration of potential architectural solutions.

Finally, Project Plan And Timeline

Once the problem, solution, and feasibility are well-understood, the team creates a detailed project plan and timeline. This step signals readiness for execution, ensuring a shared understanding of:

what to build,
why it matters, and
how to approach it.

An insight is that the project plan emerges gradually through iterative stages, starting from an initial idea and evolving into a technical design document. This is not a linear or waterfall process.

Waterfall Mindset

waterfall approach to going from concept to launch

The waterfall mindset assumes that problem discovery and technical planning follow a strict sequence. For example:

First, identify a customer problem.
Then, write a Product Requirements Document (PRD).
Next, create a design document.

These assumptions are flawed. Further investment in any initiative—whether by product management, design, or technical architects—should align with the cost-benefit analysis of the problem.

Why Expanding Ripples Matter in Agile

The expanding ripple analogy emphasizes gradual learning and adjustment in product development, embodying agile principles:

Start Small: Begin with an idea and refine clarity step by step.
Validate Continuously: Gather feedback at every stage.
Adapt and Iterate: Embrace changes as new insights emerge, even shelving ideas when necessary.

Balancing exploration and execution is important. It’s also key to know when to advance or pause

With this model, you can confidently say, "It’s okay not to have everything figured out upfront." The expanding ripples will guide development layer by layer.