David Hoang wades into the treacherous waters of the Should managers be technical? debate, and IMO comes out safely on the other side. I really like the 3 points he makes towards the end to articulate his point of view. I won’t spoil it because it’s worth reading the whole post. There’s one other bit I wanted to comment on, though:

The key roles of managers are to set expectations, ensure the team is operating efficiently, and maximize the output of the people on your team. In order to develop people, you must have a certain level of understanding of what skills are needed for people to be successful. However, as you progress in your career, there are going to be different org structures in place where it’s relevant. If you’re a Chief Product Officer, they likely have a more broad level of understanding of other functions outside of their domain and will put leaders in place who have the depth of knowledge in those areas.

I agree with the point that as you move into a leadership role, you can’t be as involved in the technical details of the product as much as you used to. But one mistake I see leaders make is to extract themselves completely from the product. And this becomes a bigger problem, especially in larger organizations. The further away the leadership team are from customers and the product, the more difficult it becomes to create product strategies that provide real customer (and business) value. Without the context of how the product works—and more importantly, how customers use the product—you cannot have a strategy that fully takes customer value into account. You end up with strategies that are too heavily skewed towards business value. A good product strategy balances both those things.1

So, leaders: Spend time with your product at a deep technical level. Download Postman and interact with the API. Ask to be invited to a few customer calls each week, and attend at least one every two weeks. Don’t lose your proximity to the heart that keeps your business alive and well.

1. Side note: last week I started a new series for the Elezea newsletter about how our team collaborated on developing our Product Strategy. I hope it will be helpful to those who need to do similar work in 2023. You can read Part 1 (and subscribe to get the rest) here. ↩

In Official myths Mandy Brown talks about how we are trying to solve the legitimate challenges of remote work by blindly (and incorrectly) assuming that the solution is going back to the office:

In many a remote-critical piece I’ve read, there’s a kind of mythical office that remote culture is being compared to, a place where everyone is welcomed, where collaboration and support is easy-going and automatic, where everyone is always whiteboarding or talking in the hallways. It’s kind of astonishing to see how much this presumed office utopia has become implicit, given we have literal decades of satire about offices as locales of poorly lit, soul-sucking, isolated work, where you are more likely to be abused by your boss than sponsored by them.

She goes on to explain the importance of supporting junior staff, and how office environments are often not ideal environments for that.

Tim Casasola’s post Create awareness of reality through bottom-up strategy points to an issue that we often see in teams—the work that they are doing is disconnected from the company’s core strategy:

There is often a difference between what an organization says its strategy is and what customer/project teams do on a day-to-day. When this dissonance is present, customer/project teams share with the org that their reality isn’t aligned with the organization’s vision. “It’s great that we want to pursue this new customer segment, but most of our engineers are focused on improving the experience of our current customer segment… and we’re far from where we want to be there.”

And yet, the org still says they have a “strategy.” The org turns a blind eye when customer/project teams describe their reality and relies on its existing narrative when feeling challenged.

The organization needs to be aware of when this dissonance takes place. So that they can learn from it, and come up with an actionable strategy.

Tim points to John Cutler’s “Bet Up” activity as a useful exercise to make this disconnect clear:

This seems like a really useful exercise for teams to undertake. It might also be really interesting to ask the executive team to fill out row 4 of the above, and see how their answers differ from what the teams come up with. Exposing a big strategy mismatch in such a clear way could be a really powerful tool to move the organization in a direction where a team’s day-to-day work is reflected in the overall product strategy.

Ben Casnocha has a long, excellent piece entitled 10,000 Hours with Reid Hoffman: What I Learned, in which he shares a bunch of lessons he learned from then LinkedIn founder:

A lot of strategists (and CEOs) think that their job is to conceive a strategy and then hand it off to the underlings to execute. They might concede that delegation matters, but usually as a matter of execution more than strategy.

Reid disagrees. He once told me, “Whoever is actually immersed in the actual execution of a strategy should always think of ways to tweak the strategy for the better.” It’s a litmus test for talent: How do you know if you have A-players on your project team? You know it if they don’t just accept the strategy you hand them. They should suggest modifications to the plan based on their closeness to the details. And as they execute, they should continue to tweak the strategy, and you (the owner) should not feel a need to micromanage or second guess—if you do, you’ve got the wrong person.

The whole piece is full of wonderful gems like that. Highly recommended read.

Matt LeMay’s post on how to build safety into team communication might not immediately seem that relevant to product management, but Why is Psychological Safety at Odds With the way we Work? is an excellent reminder for all of us:

Now let’s talk about the product managers who are willing to take on the individual risk that comes with creating psychological safety for their teams. These product leaders often don’t have the opportunity to step into those big “visionary” roles – not because they lack vision, but because they are so busy doing the emotional labor of cleaning up after the other product leaders who are making those big, lofty promises. These are the product leaders who earn the trust and respect of their teams by helping leadership understand the real-world trade-offs that go into actually delivering products, even when leadership doesn’t want to hear about it. And here’s the thing: over time, they actually train company leadership to be better! They sharpen their organization’s focus by saying, “You can have this OR you can have that. Which is more important given our goals and constraints?” These product leaders deliver so much value to the companies they work for, and the truth is, they don’t always get rewarded for it.

Over the years I have become more and more convinced that team safety is the most important job a product manager has.

Ulaize Hernandez Troyas makes a good argument for involving full teams in the prioritization of what to work on:

This type of ongoing communication throughout the prioritization process has a definite cost, but the number of benefits from this approach is worth it. We have reduced friction between teammates, which has saved us from long-winded conversations that stemmed from misunderstandings. The sense of ownership and purpose has increased the team’s motivation. On a more personal level, having these open product discussions has challenged my own thinking many times over, which has definitely improved our product direction as a result.

In terms of the specifics of how this works in practice, I tend to prefer a combined approach rather than asking the team to come up with an initial list of priorities themselves. We have a leads team that comes up with a proposal for our priorities for the quarter, based on our business goals and customer insights. We then spend about a week with the entire team discussing our proposal, refining the approach, and making sure everyone is aligned and excited about what we’re working on.

I listen to The Product Experience podcast every week, so it was such a treat for me to be on the show this week to talk about Crazy Busy Product People. At first I didn’t know what to do — I’m so used to hearing Lily and Randy’s voices that it didn’t seem right to talk back, because that’s not how it usually works! But I did eventually find my feet (I think), and I’m overall pretty happy with how this turned out.

We spend most of our time discussing my article The dangerous rise of “crazy-busy” product managers, but we also touch on remote work and our 4-day work week experiment. I hope you can find some time to listen to the episode, and that you like it!

Jonas Downey argues that nobody really owns anything in a product made by a team. I agree with both his argument, and with how difficult it can be for product managers to make this shift. He gives some advice on how to get used to the idea:

The trick is to change how you evaluate forward progress: the long-term survival of your own contributions is irrelevant. The important thing is that the product is evolving into the best version your team can create together.

The more you appreciate the power of the group over the individual, the sooner you’ll become a more effective collaborator. You’ll be more willing to hear and absorb others’ viewpoints. You’ll be more eager to seek out everyone’s best ideas, instead of digging in and defending your own. And you’ll be able to celebrate other people’s achievements with authenticity instead of territorial resentment.

This is something I tried to articulate last year in a post called The humble product manager:

But equally important — and this is why humility is so important — they need to be open to the possibility that some of their decisions might be wrong. They should hang on to a measure of self-doubt every time they present a new solution to the team or the world. Admitting that someone else’s ideas are better than your own, and making changes based on good critique do wonders to improve products — and build trust within the team.