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.

On the Postmark blog I talk about how we use productboard to improve our product planning process. I’ve written before about about what I look for in product management software, and we’ve now been using productboard for a full 3 months at Postmark, so I wanted to write an update on how it’s going, and how we’re using it.

So far, productboard has improved my life significantly. I feel much more comfortable that I have a handle on everything we are working on, what we have to plan for, and what our customers need, than I did when we used non-specific tools for this kind of work. I know we all have a bit of “tool fatigue” going on, but this is something that truly adds value to our product and the way we work.

You can read the post here.

Emile Ledure tries to answer the question, “how do you build products that stick and last in a healthy way?” I really like his approach in Healthy Retention: What Makes People Keep Coming Back? I especially appreciate the principle “Have fewer but better interactions”:

You don’t necessarily build retention by pushing people to use your product every day, you do it by bringing high value every time they need it — even if it means being absent most of the time. So don’t be greedy. […]

Fewer but more memorable experiences help you build stronger and deeper relationships with your users, which creates loyalty in the long run.

Christine Itwaru writes about Servant Leadership for Product Managers:

Reflecting back, there’s one critical thing I didn’t recognize until I was in the thick of it. I realized those in product management — from product owner to chief product officer — are never individual contributors. Instead, they’re in a position to become true servant leaders.

I would only clarify one thing, and that is that PMs are, for the most part, never individual contributors only. We still do a lot of hands-on work, but I do agree with the larger point that we need to teach more general leadership skills in the role. Christine continues:

Several key principles belong to servant leadership and are critical to being good students and teachers, including empathy, persuasiveness, and generosity. We’re going to talk about how to be a servant leader in product. Let’s go into more detail on how these traits apply to your team, your people, your organization, and finally, your customers.

She shares some very good advice in the rest of the post.

I usually stay away from article titles like these, but I thoroughly enjoyed Chris Cannon’s What a Journalist Can Teach Lean Startups about Customer Interviews. If you talk to customers at all as part of your work, in any context, this is a goldmine of good advice:

Problems are stories — it’s a dull tale that has no conflict to resolve. The customer on the other side of that table is the protagonist in their own adventure. We’ve selected them as a persona that might be interested in casting us as their hero (or even in a supporting role that lets them be the hero of their own story).

So be accommodating: Engage the customer on their terms. Be perceptive: Listen for gaps in the customer’s story that might be worth investigating further. Be a listener: Only talk to make the customer comfortable or to dig for details. And then shut up.

Amen to that.