Product Development Lifecycle

The product development lifecycle is a holistic way to think about a product's journey. It is similar to Agile in its emphasis on iterative, feedback-driven development, but Agile insists upon itself with tools and terminology useful for the boots-on-the-ground workers that stakeholders couldn't give two cents about. Product development is the name of the game. The product development lifecycle is the macro cycle a product moves through. The macro phrases of the lifecycle - DISCOVER, DESIGN, BUILD, and LAUNCH - are constants, they appear in some form in every loop. How each team implements them can change across products and loops: testing, user interviews, and other activities might demand a significant enough budget, but they all fit within the four overarching phases.

The lifecycle begins with an IDEA - the spark, the vision, the calling to put something out into the world. Everything that follows will rip the idea apart and put it back together again. Write it down, capture it in its most honest form. This doesn't have to be the golden path, but it will be nice to return to during reprioritization (or nostalgia).

With the idea in hand, we set off to DISCOVER. This is foundational research. Put the idea in front of as many people as possible. Talk to people and ask the right questions. Listen to what they say and how they say it. Explore competitors — what they do well, what you can do better, what you can take from them and improve. Think about some of these questions:

What problem does the idea actually solve? Who are you solving this problem for? What do they think about your idea? What do they understand about their industry that you do not? Will they pay for you to solve this problem? How much? Have other people tried to solve this problem? What did they do well? What can you steal from them? Where did they fail? What can you do better? Do you have the resources to compete with them? Can someone steal your idea and do it better once it's out there? Do you not care if they do?

This is where most ideas stop (or should stop). Deal with hard truths now. If you decide it's not worth continuing, that's a win - a good research phase is one where you discover something significant enough to change course. Document your user research and what your competitors do. Spend time with what you write down. Recognize what you still don't know or understand. Write those gaps down too - they will surface as you move through the lifecycle.

Now it's time for DESIGN. The idea was the caterpillar, research was the cocoon, and this is where the idea crystallizes. In this phase you define what you are doing in a way you can communicate to stakeholders, agents, and teammates whether it be technical writing, mockups, or prototypes. You should be able to clearly and concisely describe who you're building for, what you want them to do, and why. You don't need to change the world in this phase, but you do need to describe how what you're doing is valuable. Different teams and different cycles will move through design differently — maybe an early cycle is more about interviewing users, maybe a larger team can run more experiments, maybe later stages focus on refining UX decisions.

With the game plan defined, then starts the BUILD — the standard development work where the wizards enter their chambers to study and cast spells and return with compiled code. They do their due diligence: testing, strong CI/CD. If anyone has questions, they can ask an AI agent with codebase access to explain it in their own terms.

Once it's built, it's time to LAUNCH. This doesn't always mean straight to the app store. It could be to a focused group of testers, easily segueing back to DISCOVERY. Or it could be to the public, ready to be monetized or met with an accompanying service.

How AI Affected The Product Development Lifecycle

Some people think AI has made development 50x faster. Some people think not at all. I think AI helps me write code at a clip about 3x faster than without. The same dollar buys about 3x as much development output from your wizards. When code is cheap, you can spend more time on planning, research, and iteration. From there, we have three new moves: 1) raise the bar for what gets developed in the same amount of time, 2) reallocate the time and money pointed at engineering to other parts of the product development lifecycle, or 3) take your winnings, close the loop, and iterate faster.