The 3 Rhythms of Product Management (2023)

If you were to boil down your business functions to their basic essence, you’d find what’s left is just making good decisions and running an efficient process. Product management is no different. Recently, I wrote a few articles that describe my POV on making good product decisions (here and here). This one describes my high-level thoughts on process.

Before we get into it, I should mention that my intention isn’t to put out yet another article on how to do agile product development. There is already plenty of that on the web. Instead, what this post is going for is a higher-level framework — essentially my recommendation for how to run the operating rhythms for a product team.

Here I use the term rhythm because I think I it captures the nature of product management a little better than the term process. Our work is a set of long running, repeating and concurrent activities — where most of the underlying tasks are unpredictable and non-standardized. Rhythm seems like a good term to describe something like that.

When considering the full scope of a typical product team, I think in terms of three concurrently running rhythms-of-business: planning, development and release. Each moves at their own speed, with different objectives, focused on different time horizons, and involving different people. The majority of the meetings, decisions and outputs of the team are done within the context of these three rhythms.

Arguably the most important is the product planning rhythm. I like to work the planning cadence on a quarterly basis — this is how we define the high conviction roadmap items for the upcoming quarter and set provisional roadmap items for the quarter beyond that. This rhythm creates a rolling 3 and 6 month view of what we intend to do.

It starts with a planning meeting involving the top functional executives in the organization. This planning meeting is where we agree on two important decisions.

(a). Investment allocation profile. This is a rough approximation of the type of work we want to put engineering resources toward: net new features, enhancements/bugs, and debt/architecture. Over the course of the quarter, the intent is to allocate the workload (at a high-level) in percentage terms across these types. We adjust these percentages each quarter, depending on what is needed for the business.

Why do this? So we can be explicit about how we are using our engineering investments. Too often, bugs and architecture work are dealt with in an unplanned, ad-hoc, or open-ended manner. Stating up-front how much you are willing to put into it makes it clear. Note: I don’t recommend you try to track effort spent on each type at a fine-grained level (like fractions of hours, like some people do!). High-level approximations are fine — don’t burden your team with unnecessary (and false precision) continuous data gathering.

(b). The problems to solve. In my opinion, the best articulation of net-new product road-map items takes the following form:

Problem + Hypothesis + Metrics.

The problem statement is something along the lines of: ‘because of A our customers can’t do B’. In this case, A is an issue or opportunity that our customers would recognize, and B is the value prop associated with addressing A.

The hypothesis is: ‘we believe we can solve this by doing C’. I consider C to be an epic-level capability that is our current best guess at how to solve the problem. You should have some rationale (and data) that supports this.

The metrics are articulated like: ‘and we will know if the hypothesis is true if we see D, and if true, then the impact to our business will be E’. D is a way to measure whether we are actually solving the problem, and E is how it would impact our operating economics (e.g., increased sales conversion, lower CAC, improved penetration in a segment, etc).

You’ll note that problem statements are not features. Most company’s product roadmaps are essentially a prioritized list of features. Features are how to accomplish a goal, not the goal itself. Indeed, I define features often in the form of hypotheses — that keeps you fact and goal-focused. If you think of your roadmap in this way you aren’t promising to work on features, but rather solutions, of which you have at least one good quality starting hypothesis. That hypothesis may turn out to be false, in which case you need to formulate new solutions — a way better approach than continuing to riff on a feature that ultimately won’t have much value. Some companies care more about activity (clearing out Jira tickets) than outcomes (solving problems) — and they might have a hard time thinking about their roadmap like this.

Another important aspect of this meeting is that it involves discussing options, not merely informing others of your predefined to-do list. A key role of product management is defining and presenting the set of options, at the right level of detail, with sufficient vetting and rationale for the executive team to discuss and agree upon. In this way each area of the business knows and has bought into what is being worked on now (and following quarter, roughly) and more importantly what isn’t — and why. Cross-org alignment is an absolute must if you are running a product team, and this is where it starts.

A couple weeks after the planning meeting, I have our quarterly business review. The QBR serves both as a near-term checkpoint where product planning course corrections can take place as well as proving input into the next planning rhythm.

The second rhythm is the faster running product development cadence. Making software using an iterative, agile method is almost universal at this point, and I won’t elaborate too much on it here beyond a couple of points.

First, I like to organize each sprint team around one or two of the problem-hypothesis-metric road-map items defined in the planning rhythm. You might be thinking that this lends itself nicely to an OKR approach (and you’d be right!). Each team would ideally be full-stack and empowered to solve their own problems — this keeps the team mission-oriented, accountable and empowered. The delivery against these problems are in turn worked in a discrete and iterative manner.

Accordingly, PMs decompose the Epic-level hypotheses into stories. UX designers create corresponding design packages and user flows. The development team implements these in a testable manner that yields data used to determine if the solutions are indeed solving the problems. Based on this information, new hypotheses may be formed or we may double down on our existing solution in subsequent sprints. Bugs and enhancements are folded-in, to the degree they made sense given the current surface area they are working on within the product. All of this done in a two-week sprint cycle, with normal Scrum roles, meetings and artifacts.

Essentially this combination of OKR and Scrum is my product development approach. OKR provides for agile decision making and Scrum provides agile execution.

The third rhythm is the product release cycle. The right pace for this cycle will be driven by your target customer segment and go-to-market approach. For me, being a B2B product guy, I like to go with a seasonal release cycle (e.g., Spring, Summer, etc). This gives you flexibility on choosing launch dates while also signaling to your customers and partners that they can expect a regular delivery pattern.

First, let me clarify what I mean by product release. I am very much a believer in continually shipping code through a CI/CD pipeline into a production environment — but I don’t believe in continually exposing those bits of code to customers until we are ready to maximize the marketing impact. So, while the deployment cadence is tied to daily engineering work and ultimately our sprint delivery rhythms — customer-facing product releases are intentionally decoupled from that. Generally, I would rather big-bang it than drip-feed it, and a distinct product release cycle allows for this.

Packaging new features together into a bigger release has real benefits. This gives you time to create and land a bigger marketing message to customers. A small stream of features is not something your customers will pay attention to — you get more credit for a few big things than lots of little things. This allows you to create documentation, update sales decks/demos, and train support in a more purposeful and efficient manner. This also gives you time to think about how to adjust pricing and SKUs to best monetize this new value.

However, I don’t mean that all customers get all code simultaneously on one predetermined release date. It is important to deliver early access to some features to a set of friendly customers — to get feedback and generate marketing ammo. You may also have sets of customers you may want to hold back introducing features, if they are brand new or in a fragile state, for example. You may also want to load-balance the roll-out of features if you suspect it might generate lots of inbound customer support calls/questions. Also, it should go without saying that important bug fixes ship when they are ready — but all the new things should be bundled together into a bigger release.

Creating this kind of release rhythm requires that you build capabilities into your product itself. Each material feature should have feature flags so you can toggle their access on or off. And there should be a set of release channels (e.g., Internal, Alpha, Beta, Production) that provide different sets of customers with access to different feature flag settings. I’ve found that building feature-flag release management capability goes hand-in-hand with building feature-level instrumentation for reporting, error handling and SKU/packaging. All of these are necessary if you are going to run a proper product management rhythm.