Roadmaps! Tell stories about challenges, not features

We pursue moving with our company from output/feature-driven to outcome driven product strategy and tactics.

Many product people have good frameworks on how to do that. The two strongest and basically similar ones are OKRs (good article on Product OKRs by Tim Herbig) and the idea of connecting Impacts-to-Outcomes-to-Outputs (Jeff Gotthelf and Josh Seiden here and here. John Cutler here). In this framework, Outcomes are defined as “Changes in user behavior that drive business impacts”.

The bottom line is: Stop talking about outputs and to reverse engineer user outcomes and business impact afterwards. Instead start having the right discussion with teams, stakeholders and execs from the beginning: First define company impact metrics you want to change (e.g. revenue, NPS, active users, conversion — measures no single team can change). Then ask teams to break them down into measurable user behavior that they bet will make a meaningful change for both users and business. Then think about outputs to achieve these behavior changes (features).

Often we focus our discussion around output only. As it’s hard to reverse engineer outcomes and impact, we often remain in output-land. (it’s also much more fun there!). But what if instead we started with the business impact we’re seeking and then slowly work our way down towards the user behavior we believe we need to change in order reach our business impact? Output then is only a means to an end to achieve this user behavior change.

OKRs are basically nothing but the idea of Impact-Outcomes-Output as a cascade.

However, being in a company where OKRs were rolled out 3 years ago I still feel that we are not clear in how to communicate about them. Often colleagues talk about the “Objective” part only — despite the fact that the Key Result part might be much more relevant and precise. And almost no one talks about the full cascade of OKRs when referring to what they are working on — a lost opportunity given that company impacts are the actual goal and restating them often would help aligning teams and organizations.

What could be worse for change management than encrypted inconsistent language?

Additionally, in the past months, I’ve looked a lot into different ideas/movements to deploy an outcomes-over-output mindset in the company. I realized that the language used for impact, outcomes and output and the artifacts used to realize them differ widely. And I believe every time people jump on a new “framework train” all that new language makes colleagues crazy.

What is a “mission”? What is an “epic”? Where does a “bet “take effect? Does only product work with “bets” or business, too? When you call this “Experiment”, does it mean you don’t ship anything real? Why the hell did we change “OKR” to “Bet” isn’t it all the same? Ok, you called “Features” “Experiments” but now it should be “Interventions” because you heard this in a talk by John Cutler, why? So far we wrote “Project briefs”, now you call them “Initiative Briefs”?! What is a “Feature Brief then”?

So why the heck don’t we get rid of all these terms and talk real!?

What if an outcome based team roadmap or company goal overview would have a simple narration like this?

This view includes a clear narrative of the quarterly challenge a team is facing without any encrypted terminology. Is simply states what the team is doing and why and with whose help.

Would this not be scalable? Would this not be clear? Would it take too much space on our slides, sheets, trellos, jiras or whatever? Would reading it take too much time from stakeholders or execs? Would it not be cool enough? I doubt that.

All it is is a clearly stated summary of the OKR or impact-outcome-cascade.

This is how OKRs/Impact-Outcome would map to the parts of the narrative.

To get a sense of what the team does, a simple experimentation Kanban board can be added below the challenge narrative. The wording acknowledges uncertainty by phrasing features as “ideas” and what we do with them as “trials” (the idea is taken from John Cutlers article on hybrid boards). In case the team needs to work on things that are not related to the challenge, this can be added in a non-timebound now-next-later roadmap below.

To summarize, I believe that instead of using encrypted framework terminology, companies and teams should:

• start having the right discussion — define your challenge beginning from top of the impact-outcome-output tree
• speak in sentences, not phrases
• eliminate encrypted terminology coming from frameworks
• simply tell what their challenges are

What do you think about this? I’m happy about comments below.