Was sind die wichtigsten Metriken und Indikatoren zur Messung des Erfolgs und der Auswirkungen einer agilen Roadmap?

If you write your OKRs and then file them away for 90 days, they've done very little good. Part of the value of clear OKRs is in creating alignment with cross-functional teams. First, identify your dependencies -- what other teams need to help you to achieve your goals? Does your product have platform requirements, etc? Second, identify which teams are dependent on you. For some product teams, this may be your sales or marketing functions. They may need to align their strategy with what is being built. Ultimately, the point is to create alignment, or agreement on what is important. A healthy debate over OKRs is a lot more efficient than learning in 90 days that you were pursuing a different vision than your partner teams.

If you want to get started with outcome based roadmaps without getting into the political discussions about OKRs, do this: 1. Set the time horizon's (let's work with quarters for this example) main goal. E.g. increase activation. 2. Formulate a directional goal that stands for activation, e.g. make our users experience the core value fast. 3. Identify specific metrics and goal-values that reflect this goal, e.g. time to value from x to y, CSAT of x for that feature, etc. 4. Communicate to your manager that you want to focus on achieving the main goal, and you've identified these metrics that will help you understand if you've achieved them. That's it. You've created the foundation for your team's outcome based roadmap.

You can use RICE, pasta or pizza as a prioritization framework, but it won't do you any good unless you are able to enroll the powers that be to greenlight your priorities. And that means using the same criteria that your stakeholders care about. Make sure you're prioritizing based on currency that matters to your boss and your skip. So, if you have a way to measure "retention" or "engagement" for features, you better translate what that means in "greenbacks", "dollars", "contract renewals", "moolah" or whatever the CEO cares about. Show the currency conversion, or better yet, prioritize based on the stuff that they'll easily understand. Or, your beautifully RICE-ified roadmap will end up in Moscow, or in the trash can.

Well, before you want to prioritize ANYTHING, you have to have stuff to prioritize. And that means you need to do your homework and actually find solutions, experiments and research questions that you want to prioritize. A roadmap is as agile as the understanding in the company is allowing the roadmap to adapt to learning. So, plan your themes for the metrics that I mentioned in the comment above, identify the solutions that might move the needle, and also prioritize the next research / discovery topics into your roadmap for future time horizons. And for that, forget about MoSCoW and (R)ICE. Basically what Lisa Kostova said in her comment.

Or in plain English: Test your ideas before you build them. Provided that you've got so far to ideate solutions to the outcomes that you want to achieve. My advice: After you've identified product outcomes to work on, build your Opportunity Solution Tree and discover opportunities and solutions, OR do a strategic prioritization of the million ideas against the outcome. And then for those solutions that your confidence is still low but are highly risky, create experiments to check their impact on achieving the product outcome.

Well, actually this step needs to be your first not forth step. You want to create goals and outcome around business KPI so that you can show how your team's efforts will contribute to achieving business goals. Therefore, you start with KPIs and break them down into leading indicators that can serve as outcomes for your roadmap. Or you run an Impact Mapping session and for the KPI you want to focus on you first find actors and then outcomes. More info on Impact Mapping by Gojko Adzic is here: impactmapping.org

One key aspect of reviewing and updating your roadmap is keeping your team and stakeholders informed of changes. One best practice I've applied is having an easy-to-remember link with a standard format (usually in google sheets) that the team can refer to on an ongoing basis. Keeping the same format also sets a standard for each planning cycle, driving co-ownership and alignment.

Yes please. Don't turn it into a graveyard or a stone that you have engraved the feature or whatever list on. Update it based on your learnings along the road. BUUUT before you do that make sure that your stakeholders understand that it's a living document. This is the hardest part of having an agile roadmap.

This is often misunderstood. We often retrospect our failures, but not our successes. Smart product companies do the reverse. Failures are inevitable. They're like the 80% of the output that is needed to identify the 20% that succeeds. It's useless to understand failures unless they follow a structural pattern that can be corrected. Most failures are simply the results of constant experimentation. Successes on the other hand need not only be celebrated but understood. My days as an early PM at Zynga taught me that. I still remember sweating at the whiteboard in front of Pincus trying to explain why my feature did 5x my projections. Zynga was great at breaking down the mechanism behind any success and putting it into a playbook.