Up until now, when thinking about risks, I defaulted to the risks in the project pyramid. That's because each project offers different value over the product's lifetime. (See Product Roles, Part 4: Product Orientation and the Role of Projects for images of why we want ever-increasing product value, but why we might space the projects out.)
If we understand our boundaries and constraints, we can trade off the various risks in the project. (See Manage It! and the Project Boundaries: Drivers, Constraints & Floats series.) And we can choose a lifecycle that works for this project's risks.
BTW, I like product development teams that stay together, preferably on one product at a time. That helps to manage the risks of the people and their capabilities part of the pyramid. However, that does not always work. In that case, I optimize for the team that (mostly) stays together, where they learn how to learn together.
I use projects as containers. That way, people can choose their teams, and the team stays together. Then it matters less when the team works on its next incarnation of this product.
However, today, I realized there are also product risks. In my previous books, I assumed the two were linked by where the product was in its journey across the chasm. (See Product Planning, Information Persistence, & Product Lifetime to see what I mean about the product lifecycle.)
My risk thinking was incomplete.
Project Risks Differ From Product Risks
Now, I see that the determinism of the problem itself—the innovative nature of the product—also brings risks to the project.
The more innovative the product is (or we believe it to be), the less we can plan at any one time. That's because we need to iterate more frequently, both over features and when we deliver increments of value. That's all in service of obtaining customer feedback.
The less innovative the product, the more we can plan at one time. We don't have to worry (much) about the changing nature of the product or what the customers expect.
These product risks are a little more subtle than the tradeoffs between features, defects, and time to release. And these risks affect our lifecycle choices.
Which Lifecycle to Choose?
We can use a serial approach on all problems that are totally deterministic, those on the left of the continuum. Those problems tend to be defect fixes or very short projects. Those projects cannot even be six weeks long, because things will change the longer the project continues. Some will want something else.
And we must use an agile approach for all the problems on the right of the continuum, where we need recursive discovery and delivery.
But all those problems in the middle? That's where teams need to clarify the risks of which pieces of which feature sets the customers need to see now. Which pieces can the customers see later? That's where the innovation risks require more subtle lifecycle choices—and probably, more combinations of lifecycles.
When we choose which pieces when, we can also change how to organize the next piece of the project. That's how we can use product risks to help the team manage its project risks.