I really like Jeff Gothelf’s approach to the question “Does every project need to be Agile?” in his newsletter issue Digital transformation is not innovation:

No. Every project does not have to be Agile. However, each project you work on should encourage and support agility. This means that every initiative creates the ability, desire and safety to change course in the face of evidence that contradicts our original plan.

He goes deeper on what it means for teams to have the ability, desire, and safety to change when needed.

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.

Thales S. Teixeira distills years of research on how companies are disrupted in his HBR article Disruption Starts with Unhappy Customers, Not Technology:

For eight years I’ve visited leading companies in more than 20 industries around the world that claimed to be in the process of being disrupted. Each time, I’d ask the executives of these incumbent companies the same question: “What is disrupting your business?” No matter who I talked to, I would always get one of two answers: “Technology X is disrupting our business” or “Startup Y is disrupting our business.” But my latest research and analysis reveals flaws in that thinking. It is customers who are driving the disruption.

He goes on to explain why disruption is a customer-driven phenomenon, and how incumbents should respond.

Jase Clamp asks, What’s in the DNA of Product People? I especially like his depiction of the complementary forces of empathy and optimism.

This process of synthesis we call empathy. We all know that is what is needed to begin the job of product. But if it stopped there, we’d just be counselors, sitting with people, understanding their pain, and journeying with them.

We harness an opposing force that provides balance — it’s our ability, while reaching into the present to understand problems, to also reach into the future and feel what could be. As product people we often don’t know the exact shape a solution will take, but we have to believe that there is one and we’ll keep striving until we find it — which is an essential sense of optimism.

And on the topic of empathy… I shared this in the weekly newsletter, but I feel like I’m seeing a lot more articles on the importance of empathy in product management and design. One way I know this is that the blowback articles have started popping up as well (“6 Reasons Why Empathy Is A Bunch Of Crap!”). I recently came across this video from Brené Brown on the differences between sympathy and empathy. Even though on the surface it has nothing to do with technology work, it gave me a lot to think about in terms of how we interact with colleagues and customers. Check it out, it’s only 3 minutes long.

Tremis Skeete has a good write-up of a recent Marty Cagan talk in his post Product vs. Project Managers: Marty Cagan’s Twelve Best Lessons for Product Team Work. His four traits of a competent product manager is something most of us have probably read about before, but it’s a nice refresher. Especially the first two:

The first is a deep knowledge of the users and customers. This seems like a daunting task, but if a product manager just gets out of the office and talks to users and customers, they can easily acquire this deep knowledge.

The next thing a competent product manager needs to have is a deep knowledge of the data that customers generate. To achieve this, a product manager needs to utilize things like web analytics tools, sales analytics tools, and some form of data warehouse tool that shows how the data changes over time. “Most successful product managers begin their day with dedicated time with those tools so that they know how to answer questions that may come up throughout the day,” Marty says.

The article also provides a good overview of the differences between product discovery and product delivery, and why it’s so important to separate the two activities:

Product and project teams need to understand the difference between discovering a solution and delivering a solution; because by doing so they can work together to formulate strategies that complement each other.

In The Importance Of A Clear Career Path For Product Managers the Intercom team links to their Product Manager expectations by level (PDF). It’s a really good resource and fascinating look at their approach to product management. Here’s how they define the role at Intercom:

There are many elements and facets to being a PM at Intercom, but ultimately it comes down to: “Identify the most valuable problems to solve, enable your team to ship and iterate high-quality solutions quickly, and validate market impact.” Underpinning this, there are 5 Skill Areas that we explicitly set expectations for and judge performance against. These are

1. Insight Driven
2. Strategy
3. Execution
4. Driving Outcomes
5. Leadership Behaviors

The document goes into the expectations for each of those skill areas, at each level.

Will Larson shares some interesting perspectives on teams in the interview How to Size and Assess Teams From an Engineering Lead at Stripe, Uber, and Digg:

Larson believes that the fundamental challenge — and cornerstone — of organizational design is sizing teams. “The most powerful unit of work is a gelled team. People who know how to work together and are practiced at working together can accomplish truly remarkable things,” says Larson. “When managers design too literally around the current product or architecture, they churn people and lose what I think is the only truly renewable source of energy in the world: people who really love — and know how — to work together.”

He goes on to describe four states a team can be in — falling behind, treading water, repaying debt, and innovating — and the best way to improve teams that are in each of those stages.