The Basics

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:

  1. A charter and mission
  2. A strategy
  3. One or more models
  4. A roadmap filled with bets
  5. Artifacts for those bets
  6. Bet-related metrics, Input metrics, goals
  7. Great kickoffs and great learning reviews
  8. 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).

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.

No alt text provided for this image

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.

Here’s a free webinar on OKRs.

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.

回复
Cameo Doran

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.

Paul van der Slot

Freelance Hands-on Architect with a passion for DDD and Collaborative Design

2 年

Robert, misschien vind je zijn posts/nieuwsbrief ook interessant

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了