20条运营实操建议：北极星框架、稳定团队与周期选择

I had a friend reach out recently for advice. He said something funny/telling. “Half the time I don’t know what you really think. I have to figure out how my team works. What is your actual, opinionated advice?” So here it is: advice for a friend on how to operate. Raw. Not “polished John”.

I wanted to send a huge thank you to my paid subscribers. They don’t get anything in return but still support the newsletter. Until recently I didn’t have a way to do a one-off tip. But now I do. I you like the newsletter, consider…

Leave a Coffee Tip!

North Star Framework

“Should I try to implement the North Star Framework with my team?”

(Note, I wrote the North Star Playbook while at Amplitude, with Jason Scherschligt)

North Star Framework is an interesting idea, but it is probably most valuable as a teaching tool, not as a practical practice. That isn’t to say that some companies don’t “do it”, because they do, but that it is more valuable when it comes to teaching things like leading/lagging metrics, actionable inputs, building (and testing) causal models, avoiding vanity metrics, and the “art” of crystallizing a unique strategy for your company vs. playing a standard game.

When I check back with companies/individuals who attended workshops, it is very common to hear something like, “I learned a lot, and we sort of adapted many of the ideas. We have multiple KPIs, leading and lagging, and some things aren’t as worked out.” The people who didn’t get value out of it tried to install it as a framework and eventually hit resistance with the inevitable edge cases, exception handling, etc.

This is all to say that what follows will work in some of these ideas, but will not be about the North Star Framework.

(Here is a Miro activity library for NSF)

Trees/Pyramids

“Should we build out one of those vision-to-tactics pyramids to get everyone aligned?”

Next, this might sound heretical, but I don’t recommend “pyramids” that build a tree starting with vision, strategy, tactics, etc. I know they are super common, but I find that they often end up distracting people. If someone owns something, and if people are working on it / working towards it, then by all means make it clear. But most companies end up with a bunch of buckets and maps that seem wholly designed to “simplify” things for leaders, and to abstract the idea that lots of real work is happening.

There’s nothing wrong with label taxonomies, but people start to imagine that those labels are real things. Most of the time they aren’t—they are roll-up mechanisms, and seem mostly designed for 1) deckware, 2) and a false sense of organizational symmetry or “clear” roles and responsibilities. Sure, make a pyramid slide if you need that kind of thing to leave leaders feeling aligned, but then put it to the side to start generating impact.

Put another way, there’s only one place that “the work” is happening, and that is at the front-line team level. It may have gotten there through layers of the org, but the work—the problem solving, creativity, hands on keyboards, interactions with customers (hopefully), etc.—is happening on the front line. Real strategy is messy, non-hierarchical, might span days or years, and doesn’t fit into neat boxes, so don’t waste time trying to do that (or at least don’t waste too much time).

Stable Teams?

“Everyone says we need stable, durable product teams. Is there a downside?”

There has been a lot of talk about “stable” product teams, but I wanted to dig into the dark side of this. A lot of companies are struggling because they build internal kingdoms around “stable” teams. They rationalized these highly durable capabilities that would exist until eternity, based on sort of irrefutable logic (we’ll “always need that”). Or, they wanted to build something, a short-term project, and everyone was busy, so when money was plentiful they just spun up a “new team” to build it. And then a director. Then a GM. Before you know it you have three layers of hierarchy built around “products” that didn’t really exist.

And then…the only way to unwind this is layoffs that really impact people’s lives. Not because you couldn’t, in theory, re-assign those folks to different areas—because you could—but because the physics of the org chart, and how layoffs work, necessitate you to blindly unravel your prior org chart decisions.

Which is all to say that “stable” teams and “durable” ideas are only useful until they aren’t useful, and sometimes knowing the difference is hard. Of course, leaders will not say this outright (or at least the CEO’s who speak publicly about layoffs). They might make vague mention of bureaucracy, the “work around the work”, etc. But the reality is they scaled too quickly when money was more plentiful, and now need to rationalize how to unwind all of that.

Shipping Smaller/Faster

“How do I get my team to ship smaller and faster?”

In my experience, it is way easier to teach a team that can work small to think big, than a team that thinks big, to work small. Both are possible, but they require different approaches. A team that can deliver continuously, regularly, get frequent feedback, and generally keep the tempo of changes, assumptions tested, and risk reduced HIGH, is a godsend. It is a gift. If you have fostered an environment AND the skill/experience landscape to make this possible, you should always cherish it.

Now, that sometimes means the team will be short-sighted, and may iterate to nowhere. You run the risk of having a “functional” feature factory with broadly usable things that don’t really move the needle, but if you can do this you’re well on your way. As mentioned, this is part environmental. You can absolutely have people who are good at this at their last company, completely flounder if you’re constantly interrupting them, changing the strategy, loading them up with WIP, and always asking them to prematurely converge on estimates, etc. Environment matters.

But creating that environment AND working small are skills you have to hire for, and nurture internally. Put another way: you can’t make shots you don’t take. The team has to be able to get changes out into the world and HAS to be able to measure impact. They also need chops at rapidly considering options, and figuring out how to slice up those options to get the most leverage possible.

Cycles

“What’s the right planning cadence? Quarters? Sprints? Shape Up cycles?”

Quarters are too long to help you work small, and too short for the bigger, meaningful things you want to do. 2w sprints are too long to help you work small, but too short for the big meaningful things you want to do. 6w is actually a decent forcing function, because you can fit some pretty darn meaningful things into 6w, but if you are operating a company at any sort of scale, you might feel a bit of whiplash thinking only in 6w bets. It is doable, but you’ll find yourself 1) tackling things that are actually bigger than 6w on occasion, 2) losing a sense of the more durable “lanes” in the 1-3 quarter range, or longer.

This is all to say that time is WEIRD. It always feels too long, and too short. There are always opportunities to work smaller, and there are always situations where working small misses the “bigger picture”. But here’s a bit of philosophy: life is only happening NOW. We are navigating a landscape shaped by past decisions, and we are forging ahead into a partially knowable future, but at the end of the day what really matters is what is happening right now.

Why is any of this important? First, don’t get beholden to any one cycle as “the” cycle. You are almost certainly missing something. Second, don’t let your selection of cycle get in the way of working small (or thinking big). The number of teams I see chasing their tails because of some arbitrary quarter cycle AND magically making all their bets take one quarter is insane. SHIP! LEARN! Don’t wait around for a quarter.