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.

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.

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.

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.

Casey Winters takes the product/market fit model further in his post Feature/Product Fit:

Every product team tries to make their core product better over time. But sadly, at most companies, the process for this is launching new features and hoping or assuming they are useful to your existing customers. Companies don’t have a great rubric for understanding if that feature is actually valuable for the existing product. This process should be similar to finding product/market fit, but there are some differences. I call this process feature/product fit, and I’ll explain how to find it.

This is a great way to approach ongoing, consistent improvements to our products. Casey’s practical checklists and advice are worth reading and bookmarking.