In Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project, I explained how project risks can affect the team's approach to the work. But project risks are not the same as product risks.
Product risks are about the need for product innovation. The more innovation this product needs, the more discovery the (product/feature/project) team will have to do. That's because discovery requires shorter feedback loops.
The shorter the feedback loop, the less up-front planning anyone can do. Very short feedback loops imply these actions:
- The product value team cannot create a roadmap that extends longer than a discovery or two. (Maybe three.)
- The portfolio team cannot “commit” to a project for longer than the roadmap. Instead, they commit to incremental funding based on value.
Why? The outcomes of each discovery (or two) might require the product value team to rethink the product strategy. Rethinking the product strategy might change the project portfolio. Why? Because the project portfolio instantiates the corporate strategy.
The need for shorter (or longer) feedback loops can help the team choose a lifecycle or agile approach that can help manage product innovation risks.
Assess Your Product to Manage Innovation Risks
What kinds of products require which kinds of innovation?
- “Recursive Discovery” products tend to be early in their product lifetimes. The organization thinks it knows the user personas, but the risks of planning a long project are not worth the time investment. Instead, the organization verifies that these customers want solutions to those problems. If you've ever worked in a startup with just one product, you've experienced this.
- Most of the products I see are in that messy middle. Sometimes, the team needs to experiment faster to get some piece of the product right. Other times, it does not. The feedback loops can be longer, but not too long.
- Then, there are the products way on the left, where Someone In Charge thinks there is little to no discovery needed. I see this a lot in ports, where the team is supposed to port “exactly” the same code/outcomes from one infrastructure stack to another. (Think old hardware to contemporary hardware. Or an “old” language to a “new” language.) That Someone In Charge thinks the team does not need any discovery. That works until the team uncovers a previously undiscovered defect—and now they need more and rapid discovery.
Those are roughly the three innovation buckets. Each bucket has its own need for reduced cycle time.
Lower Cycle Time Means Faster Feedback Loops
I never expect the team to get anything right the first time. Sure, there are things every team can do to increase their chances, but none of us are telepaths. We cannot see into our customers' minds to see what they want.
When teams work on small increments of value, they can keep their cycle time low. That low cycle time creates faster feedback loops because the team can see what they actually finished. In addition, if the team can ask relevant people (product value team, sponsors, real customers) for feedback as the team builds the product.
That's why the previous post, Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project, is so important. If the team does not know what's first, second, and third for the sponsor, the team cannot make the “right” decisions or tradeoffs. For example, I can imagine that only the port would work full feature set by feature set. The other two projects would work story by story. The team needs to know the driver and boundaries to work with the product leader to choose which story first.
We already know that the smaller the story, the shorter the cycle time. That ability to finish and see progress is the faster feedback loop that allows everyone to make good decisions and trade-offs.
When teams add a product risk assessment, they clarify their necessary feedback loop durations. That allows them to support or change their feedback loop choices.
The Project Charter Series
- How to Create a Useful Project Charter in Less Time Than You Think: Overview
- Project Charter Part 1: Write (And Test) a Product Vision for This Project
- Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project
- Project Charter Part 3: How Product Risks Can Support or Change Your Feedback Loop Choices
- Project Charter Part 4: Define Release Criteria so You Know What Done Means & Avoid Scope Creep
- Project Charter Part 5: Workshop the Project Charter with the Right People to Manage Everyone's Time
See my books: Manage It! and Create Your Successful Agile Project for what I already wrote about project charters.
Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility will help you see your feedback loop needs. And help you decide how to instill more agility in any approach if you want to.