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.

This is a good write-up of Alice Newton-Rex’s talk on Setting Goals for Product Success. She explains some of the key principles for effective goal-setting from a product perspective. One section I found particularly useful is her point that metrics and goals are very different depending on the phase a company is in. For example, for a brand new product, she advises not to create traditional “growth” metrics:

But, in my experience, these goals aren’t so useful for new products. It’s a lot harder to put numbers against your goals when you don’t have anything to dial up or down, and achieving some business outcome at all costs is less important than learning. I suggest adopting more hypothesis-style goals, in which success looks like proving or disproving that hypothesis. Don’t default to aiming to gain sign-ups, users or revenue for your new product. Aim instead at proving your riskiest hypothesis.

My kids are obsessed with the podcast Wow in the World (and, to be fair, it’s really good). Guy Raz is such a goofball on that show that it was a little weird to see the headline Guy Raz: Five Lessons PMs Can Take From Famous Entrepreneurs. But I thoroughly enjoyed Laura Baverman’s write-up of one his recent talks at the first ProductCraft conference. He gives several recommendations for PMs on how to run successful products, including “Focus on What’s Different, Special, or Better Than Anything out There”:

Advisors to Allbirds were concerned that launching just a single shoe design in only four colors was a recipe for failure. To succeed in the direct-to-consumer retail market, they’d need to provide options for shoppers, those experts said.

But founders and co-CEOs Tim Brown and Joey Zwillinger were most concerned with creating a superior product—an environmentally-friendly shoe made of superfine Merino wool. They were convinced that getting these values right would help them sell the shoes, and expansion into other types of shoes or products would happen from there.

They were right. Within 30 days of launch, they sold out of a year’s worth of inventory. Three years later, the company is valued at $1.4B, and according to Raz, still offers something better than anything else comparable. Allbirds ignored what the competition was doing and create a truly differentiated product.

There are some great lessons in these stories.

I really enjoyed Heart-Centered Innovation — a short, from-the-heart essay by Sari Harrison. She talks about how hard it is to see problems from a neutral point of view:

Most people have a center from which they see the problems around them. A sun that everything revolves around. This leaves it up to the person who has the problem to do a lot of filtering among solutions, often with no way of knowing which option is best.

What if we didn’t do that? Instead, looking at all possibilities for generating the outcome we are hoping for?

It’s a good reminder about the value of getting out of our own heads, and into those of our customers to make sure we understand problems and use cases from their point of view.

Lenny Rachitsky wrote a helpful and comprehensive guide on How To Get Into Product Management (And Thrive). This is a really good resource for any new product manager. I especially liked his section on seven core skills, and how to get better at each of them. One could certainly argue the validity and importance of each skill, but there are lots of good insights here. For example, on “Leadership through influence”:

In order to succeed you need to be able to build trust with your teammates, make decisions but also give everyone a voice, and keep morale up no matter what’s going on. The best PMs quickly become the de-facto leaders of the team, not because of any actual authority, but because they help everyone on the team do the best work of their lives.

This is a helpful article from Jeff Vincent about the “nth user problem”. This is a not-so-great term for a very real problem: how to make sure you’re able to effectively onboard additional team members on a customer’s primary account. From SaaS has an nth user problem:

A huge driver of churn in the most successful SaaS businesses is loss of champion churn — or when your product’s greatest advocate within a customer company moves on to another job or department and the replacement admin abandons your product in favor of a new platform. This is the end result of the nth user problem at work.

Jeff shares lots of good advice on how to take care of additional account users and make sure they become engaged users and advocates.