Conversation

Of course, experienced product people like John and Edo have been saying this for years. Sample thread:

Quote Tweet

Edo van Royen

@edo

Maybe instead, we should go slower. Maybe we should spend more time on strategy, discovery and creating context for our teams. Maybe better decisions on what to build, will achieve 10X of the impact without burning anyone out. Just maybe.

Show this thread

This was a surprisingly hard idea for me to learn because of my past experiences. In my last company, we had very straight forward development because we were building point of sales systems, and we were behind our competitors. In that scenario, shipping cadence was everything.

What this looked like: for the first three years, we just built whatever our customers asked us to build. We got to ~$4.5m annual revenue this way. Sure, we exercised *some* product judgment, but it was usually clear what to build next.

A lot of the uncertainty in those early years was mostly the go-to-market motion, and learning to deal with fierce competition. But once we got to feature parity, and tried building genuinely new features, suddenly shipping cadence wasn’t that important.

TBM 36/52: Looking at Example Boards

I didn’t realise this at the time, of course. I was aware of the general idea, but it took this

@johncutlefish

post to hammer the point home.

cutlefish.substack.com

In this post I am going to try something a bit different. I am going to: Share boards inspired by real world teams (I see lots of boards) Share what I see in the boards Share links to what people on...

What’s notable about this post? Well, John outlines a number of product team setups and mistakes that he’s seen from real world setups. But the one thing that leapt out at me was the team setup that took *learning* into account. That hit me like a ton of bricks.

7:38 AM · Aug 27, 2022Twitter Web App

Think about it: let’s say that you shipped five features in two months. Well done. Clap yourself on the back, post about it on social media. But were those features the RIGHT features? Did you have enough time to learn from changed user behaviour? Did they inform future cycles?

Replying to

This is, by the way, the workflow implied by Team A in the diagram below. It’s clear that they have a ship and learning cycle lined up. If you ship too much, at some point you’re going to overwhelm your product org’s learning capability. A lot of energy, much of it wasted.

Counter-intuitively, even though Team A is working on less things, the fact that they have both shipping and learning loops lined up means there’s probably greater *effective* velocity.

What’s interesting is that it’s context dependent. Sometimes shipping cadence matters most. e.g. you need some set of boring enterprise features like SSO, compliance, data residency, so you just lean on the shipping accelerator. But other times, slow the fuck down

I’m starting to realise this is an expert-novice differentiator for product. Novices crow about their shipping velocity. Experts aim for ‘flow’. Flow is a Cutler term for product teams who are deliberate, smooth, and focused in their iterations.

Getting both shipping and learning loops to line up is one way of getting to flow. But experts are also more ok with downtime, to not ‘build anything’, in order to figure out direction/product strategy, instrument for better learning, or get team+org alignment.

Related thread:

Quote Tweet

Aug 25

There needs to be a name for the phenomenon where people start executing without instrumenting or thinking, and then turn out to do worse in the long run compared to teams who take the time, up front, to instrument properly.

Show this thread

What is the Product Mindset?

Another way to think about this expert-novice divide is

@chrizbot

’s “the product mindset is a healthy respect for and comfort with uncertainty.”

medium.com

Learning to navigate an uncertain world