Product Leadership Principles

Recently, I had a chat with a PM who had just moved into management, and they were asking me how I made certain decisions when it came to hiring, staffing, coaching, etc. The conversation prompted me to think through my latent product leadership principles (and biases) that I’d accumulated and refined over the years, which I’ll be sharing here today.

I’ve found these principles have both fascinated and frustrated the folks in my orgs over the years…

---

1/ iteration » ideation

I prefer bias for action over talking. Of all of Amazon’s (my first real product role) leadership principles, this one spoke to me the clearest and loudest. PM-ing, to me, is fundamentally about making good decisions over and over, which means you actually have to attempt things vs just brainstorm forever. Don’t get me wrong, I don’t measure this by how much product you ship or how many features you launch, but rather that the team you’re leading is accumulating learnings through your direction (and learnings can come from launches, research, write-ups, prototypes, etc).

2/ system » sections

I enjoy understanding the end-to-end experience vs going deep on any 1 component. This mindset is what originally prompted me to switch from being an engineer (accountable for one portion of the system) to an architect (accountable for the entire system), and that techincal architecture mindset carried over into my initial forays into platform product management. Another way to say this, for perhaps a PM with a UX Design / Research background, is that products are workflows, and a lot of product innovation comes down to deconstructing and reconstructing workflows in novel ways.

3/ foundation » features

Thinking through "building block" investments (that will pay off multiple times in multiple ways) is way more interesting to me than short-term shiny objects. The systems thinking I highlighted above carries over into careful product planning and bet compounding - I appreciate PMs who know how to make 1+1 = 3. You can layer product choices over time to compound value for your users / customers, just like you can exacerbate product debt over time by carrying it - foundational work is critical to both compound value and debt payoff.

4/ synthesis » status

I prefer insights over updates - don't recite a slide / table / chart that I can read for myself, enlighten me on what I missed because I didn't read between the lines. One of the most frustrating things for product leaders that IC PMs don’t understand is the flood of information - constant updates from innumerable channels on every topic make it so you can’t separate signal from noise. Most leaders either have to be either hyper operationally savvy to control the flow of information or hire someone to be a human filter. If there’s a real use case for AI in product development, I would bet it’s a synthetic agent that serves as a 2nd brain for CPOs. And this is why the most common advice I give PMs who are meeting with a product leader for the 1st time is “make 1 point and spend 30 minutes driving it home vs a hodgepodge of status updates”.

5/ outcomes » output

This is a pretty standard one and the industry has really come around - move *the* needle vs *a* needle (metrics-wise). This one can is less a principle that people need to be convinced on, and more a philosopohy that’s hard to put into practice - most organizations are geared towards proxies for customer value because it’s too hard to show a direct link to customer value over the short term. I think PMs are in an especially tricky position because most functions can point to an output metric - every incremental marketing dollar has to generate more pipeline, every additional sales person is supposed to close more deals, and even more developers are supposed to ship more features - but every new PM should result in better quality outcomes, not in any added output.

6/ sustainable » sporadic

It’s unpopular, but I don’t think you should “do things that don’t scale” - you should do the bare minimum now to scale properly later. As hard as 0 to 1 innovation is, most companies plateau / atrophy not because of failiure to innovate, but rather failure to scale. Moreover, I think the PM function at a lot of companies discourages an ownership mindset by focusing on short-term feature shipping, which leads to accumulating product cruft and technical debt and ultimately constrains what might be built and how long it takes. I’m not sure why everyone is always interested in punting on scale - to survive long-term you have to scale.

7/ fluidity » firmness

I prefer strong opinions weakly held - but not the lip service kind - actual dispassionate evaluation of ideas / tactics with a willingness to pivot hard the minute you know you need to. This goes back to my view that PM-ing is fundamentally about making good decisions over and over, which is tough since many PMs have been incentivized to lock in on an early solution and ship at all costs.

8/ planning » plans

It’s the habit vs the actual plans that matter long term. If you’ve been in a product organization long enough, you inevitably have a debate about why planning has to be quarterly or if annual planning is necessary - to me these are all snapshotting exercises that can be made simple with always having a now / next / later plan. When I look at roadmaps, I’m less interested in dates and more keen on what made the list and what didn’t, and why - one of my annoying line of questions is about the rationale used to prioritize a backlog vs the actual prioritized list.

9/ quality » quickness

Just like planning for scale, quality (usability, performance, cost) can’t be a bolt on after shipping - this is a not a data-based opinion, this is my own bias as a user (rough edges in a product grate on your over time and cause emotional churn in my opinion). I will acknowledge that many poor quality products have won the day with speed to market or feature velocity, but ultimately I would rather work on iconic products (many of which don’t “win”), and those always have quality that shines through.

10/ proxies » process

One of the functions of a PM is to form a perspective on the market any way they can - sticking to structured feedback rituals that don’t provide value is silly when there might be other / faster ways to learn about your target user / buyer. I’m not saying don't directly talk to your customer if you can as often as you can, I'm saying getting an ad-hoc pulse from sales / partners / analysts every so often is also a reasonable path. Customer experience learning loops come in many forms, and my view from a product leadership vantage point is breadth matters more than depth (the latter comes into play when you want to make sure you’re building the right solution after zero-ing in on a customer problem).

11/ direction » data

I love data, but it’s purpose is to provide direction, so worry about the higher order bit. Too many people get caught up in correctness over clarity - you just need enough signal to decide on a path - precision can come later when you're optimizing. Again, this is my mindset as a product leader - making sure we’re heading in the right direction generally vs trying to take the shortest next step every single time. I’ve written extensively before on how I evaluate this competency when I interview PMs (see the link below on Data vs Intuition).

12/ loops » leaps

One-offs are exactly that - moonshots don’t happen by accident, luck is manufactured by being 1% better every day. My personal biases strongly creep in here, but I prefer to see a string of good decisions vs a wild swing that happens to land - the former is skill, the latter is luck.

13/ writing » winging

If you can’t articulate it via an n-page doc, you haven’t thought it through deeply and are just winging it. You can hide in every medium (Powerpoint, Slack, Miro, Twitter) except a long-form document. This lesson was really driven home for me after having been the 1st PM to work with an engineering team multiple times in my career - for a PM to onboard successfully, they have to provide differentiated value, which only comes from clarity of thinking, which can only be confirmed through writing.

---

I’m teaching a course on Scaling B2B Products on Maven - you can sign up for an upcoming cohort (Dec or Jan) via the link below - if you enjoy my writing it’s a great opportunity to apply these frameworks in practice to your product!

---

As always, I’d also love to hear from readers about their product leadership principles - please chime in via comments👇 or join the chat via the Substack app.

And if you enjoyed this post, please consider subscribing.

---

further reading / references

• Amazon’s leadership principles (they’ve added a couple since I worked there)

• Span (vs Split) Personas elaborates on “products are workflows”

• I’ve written before about The Power of Layering Product Choices (which is a decision making principle I learned at Amazon, albeit not one of their publsihed ones)

• Where’s the “So What?” is a great post by a McKinsey alum that is the essence of synthesis » status

• Metrics Malfunction is a common anti-paattern across product development orgs

• As I wrote recently, the reason many organizations shy away from Bet Boldness is they start using the “process as a proxy for the result they want”

• Customer Experience (CX) loops come in many forms - here are some that I learned from my time at Amazon, Twitter, Box, and Amplitude

• Data vs Intuition is a post where I talked about how I evaluate trade-off decision-making as a skill in PMs

• The Anti-Moonshot Factory talks about how a product team can operationalize innovation by getting 1% better every day

• I think writing is such an important skill for a PM that I have a whole series of posts around it

---

childish drawing / interpretation