TBM 12/52: The Basics
I’m not a process freak, but I do believe teams should have their house in order. You can get by with very little process overhead.
Too many teams are spinning in circles (or sprints). It often isn’t their fault, but still…the level of reactivity is so draining.
Focus on The Basics.
In my mind The Basics include:
A charter and mission
One or more models
A roadmap filled with bets
Artifacts for those bets
Bet-related metrics, Input metrics, goals
Great kickoffs and great learning reviews
An approach to continuous improvement
If you figure out a minimally viable version of these eight things, you will be further along than most product teams in the world. Pulling this stuff together may seem boring, but the boring bits can be so important.
Charter and Mission
Have a team charter, and a team mission. Whose life are you planning to make easier? Why? What do you care about? What are your operating principles as a team? What are your current working agreements? I am a firm believer that teams should have stable focus areas that span multiple years (except for in the smallest startups).
Have one. Read Rumelt. If the strategy tries to be all things to all people, keep refining it. Ideally, if you do the things below you’ll have a better sense of what is working, and that will help.
One or More Models
It helps to have a couples that act as the connective tissue between your strategy and your roadmap. See the Appropriate Models section in this post. See this post for prompts that can help you evolve your own models.
Have an always up-to-date one year roadmap filled with suitably detailed bets. Detail things at the last responsible moment, and not before.
This is a year’s worth of work. It really isn’t that much.
A year may seem like a long time (especially for the Agile folks). But when done correctly—without solutions, focused on opportunities—it can work fine. Working with a continuous roadmap is so much better than big-bang planning. And to re-iterate, keep it suitably detailed.
The roadmap is filled with Bets (use whatever word works for you).
Every bet has a one-pager, a research folder, a learning backlog, a “core team”, and "extended team", and an advocate. Over time you will accumulate more “stuff”, so be sure to make it easy to find. Write a one-pager for bets in the 1-3 month range. For longer bets, make sure to break them down (but also have a 3-6 pager for the big "parent" bet) .
Note how we don’t worry about detailed one-pagers for work off in the future.
Every bet should have a set of bet-specific metrics. Bet-specific metrics help us understand usage. In general these metrics are more contained. They are more about the internal workings of the bet. And less about impact on Inputs (see below). How do you know you have bet metrics? Simple. They are unique to the bet.
Example: Error rates, time to complete a workflow, the usage of certain interface elements, usage by certain cohorts, etc.
Every bet should target one (or more) persistent input metrics. In the cast of Inputs that are more lagging, you may need persistent sub-Inputs. Persistent input metrics do not change very often. They stay stable for many quarters/years. How do you know if you have a target Input? Simple. Over time, multiple bets will target the same input(s).
Example: Tweaks to the onboarding flow will increase the % of users who successfully complete one or more high value actions within the first two weeks of usage.
Here’s a free webinar on Inputs. If you use the right models (see One or More Models, above), you’ll figure out these inputs before you figure out your bets.
It is up to the team whether to set bet-specific goals, or to set quarterly goals that may span multiple bets. Either will do. OKRs may be a good option, or—if the team has bet-specific goals—may be overkill. Goals are helpful, until you start making it unsafe to have them. So keep goal-setting safe.
Kickoff and Learning Review
Every bet has two hugely important rituals/events. The first is the kickoff. A well facilitated kickoff plays a huge role in the success of any initiative. The second is a learning review. The learning review shares an analysis of impact, and key lessons. If you get kickoffs and learning reviews dialed in, you’re further ahead than most teams. For longer efforts, consider more frequent learning reviews.
Retrospectives and Continuous Improvement
Some kind of mechanism to reflect on how things are going, review past improvement experiments, and prioritize small improvement experiments. I like POPCORN.