The Basics
This post originally appeared on my weekly newsletter The Beautiful Mess. Please consider subscribing to get the latest posts.
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:
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).
Strategy
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.
Roadmap
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.
Bets
The roadmap is filled with Bets (use whatever word works for you).
Bet Artifacts
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.
Here’s?a post about one-pagers.?And?a video?about one-pagers.
Bet Metrics
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.
Target Input(s)
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.
Goals
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.
This post appeared original on my weekly newsletter The Beautiful Mess. Please consider subscribing to get the latest posts.
John Cutler This is really a very insightful framework for avoiding the pitfalls of agile aka mini waterfalls aka sprints. Thanks for posting
Sunand Menon - this is a great small snippet of why focus on the user (person) is necessary.
From Vision to Execution—Faster Products, Better Results, Bigger Impact | SaaS Companies | Product Development Consultants
2 年It is almost never their fault. The hard truth about top-tier development practices is teams can’t really create the environments themselves. They need leadership that will create the systems and culture for them.
Freelance Hands-on Architect with a passion for DDD and Collaborative Design
2 年Robert, misschien vind je zijn posts/nieuwsbrief ook interessant