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.

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.

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.