Empathy and Optimism as complementary forces in product management

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.

The traits of a competent product manager

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.

Resource: Product Management career ladder

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.

How to improve teams no matter what stage they’re in

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.

How we use productboard for planning at Postmark

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.

For healthy product retention, build fewer but more memorable experiences

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.

Key principles for servant leadership in product management

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.

How to talk to customers: lessons from a journalist

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.

“Agile” is not just for software development, it’s for the whole business

Steve Denning’s Forbes essay Understanding Fake Agile is the most useful thing I’ve read about the state of Agile in a long time. It starts off extremely strong, with his “three laws of Agile”:

  • The Law of the Customer — an obsession with delivering value to customers as the be-all and end-all of the organization.
  • The Law of the Small Team — a presumption that all work be carried out by small self-organizing teams, working in short cycles and focused on delivering value to customers—and
  • The Law of the Network — a continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.

Note that there’s no mention of software in those laws. This goes way beyond the original Agile Manifesto, and the idea that Agile is for software only:

But restricting agile to software development becomes a problem. When agile thinking takes over software development in a traditionally managed organization, it inevitably begins to run into conflict with other parts of the organization that are moving less rapidly and less flexibly.

This is how you get organizations that follow an agile process for their development process, while the rest of the organization still operates in silos. Steve discusses many of the other misconceptions and problems with Agile in his post.

The product management role is too broad, and should differentiate between goals

One of the issues that’s often lamented about the product management profession is that it is not well understood. I think one of the big reasons for that is that we try to put too many different jobs in the same category. I have come around to the viewpoint that product manager roles should be classified in terms of the type of goals they are trying to accomplish. I like Saeed Khan’s breakdown in 5 Steps to Building a Great Product Management Organization:

Roles in Product Management should differentiate between technical and business focus; between short term tactical and longer term strategic activities; between internal (inbound) and external (outbound) responsibilities. These roles should be organized as small teams focused on specific products or product lines, with defined metrics to measure progress and success.

This is what is done with virtually every other department in a company. Why should it be different for Product Management?

Another way to look at it comes from Jonathan Golden. He talks about Pioneers (focused on taking risks and building new things), Settlers (focused on growth and scaling), and Town Planners (focused on infrastructure and platform management), and then makes this point:

Even in an established company, all three types of product managers are critical. “The product team needs each of these PMs to be nimble and responsive. Otherwise the business won’t endure for the long term,” says Golden. “We allocate product resources across three main categories: core initiatives that focus on the existing product, new initiatives that explore possible areas of growth for the business, and platform initiatives that focus on building fundamental technological infrastructure.” Pioneers and settlers don’t become obsolete just because you’re at scale.

I think this type of thinking wil help a lot with the misunderstandings and misconceptions that exist in the product management landscape.


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. ...
  9. 134