Shaun Juncal has a good overview of the importance of watching your churn numbers carefully in his post Churn: The Most Important Product Metric for SaaS. It’s especially important to figure out why people leave when they do:

But you can also learn something from that lost customer, namely why they left. Were they drawn to a competitor? Did the value your solution offered fade over time? Was a missing key feature causing them to bail out? Answering these questions can inform what should be done to retain your current stable of paying customers and attract new ones.

A simple churn number can’t tell you why someone leaves, so this is data that has to be collected qualitatively. But how? You don’t want to provide a negative user experience to customers on the way out, so putting a giant hurdle in front of them is not a good look. We solve this problem at Postmark by providing an optional text field on the page where you select your downgrade option:

I’m sure we would get more responses if we made this a required field, or turned it into a pop-up. But at what cost to negative perception would we do that? Following someone as they exit a store is creepy. Don’t be creepy.

Seth Fiegerman’s history of Pinterest and their approach to business and product is a breath of fresh air. In The anti-Facebook: Inside Pinterest’s slow and quiet rise, Fiegerman describes a company whose motto might as well be “move slow and debate things”:

Pinterest resisted throwing money at its problems, debated product tweaks extensively and did not rush to copy features that helped larger competitors achieve viral growth, employees said. Fond of touting itself as an anti-social media platform, Pinterest never introduced live-streaming or standalone messaging apps, nor did it become a primary hub for news. These features attracted press and users for other companies, but were also later abused by bad actors.

That is such a good example of a company that knows how important focus is. Their approach reminds me of Richard Rumelt’s succinct summary in Good Strategy, Bad Strategy:

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.

Lenny Rachitsky starts off his article on A three-step framework for solving problems with a really good insight:

Though many factors contribute to a project’s failure, nothing is more certain to cause a project to fail than a misunderstanding of the problem you are solving.

He spends the rest of the article focusing on how to develop and rally around a good problem statement, which is an essential skill to have for any product manager. I really like this framework and am keen to try it on my next project, alongside a version of Marty Cagan’s Product Opportunity Assessment that we’ve adapted for our specific needs.

Hiten Shah’s deep-dive into the history of Evernote is a very interesting read from a product management perspective. Of particular interest is the immense damage they inflicted on themselves due to a lack of focus on their core mission:

It’s hard to understate the damage that the branded products sold through the Evernote Market inflicted on the Evernote brand. It made absolutely no sense. Users didn’t want Evernote-branded tablet styluses or Evernote Moleskine notebooks or Evernote backpacks. They wanted an organizational and productivity product that worked.

The fact that the 2013 version of Evernote was widely considered the buggiest, most unstable version the company had released at that point added insult to injury. Rather than fixing the software problems that users actually cared about, Evernote started selling branded backpacks instead.

This is such a good example of the importance of knowing the core value of your product, and deepening that reach instead of trying to broaden into unrelated areas where you don’t have a core competency.

Sometimes we can get overly reliant on our frameworks and methodologies to help us make sense of our products and our worlds. Melissa Perri shares some excellent advice about the dangers of this in The Science of Product Management:

These motions, these frameworks, they were made to teach you to think. They were a means to an end, not the end goal itself. They are training wheels. How can they help you understand your work better, so you can DO your work better?

The point of Product Management is not to put things in JIRA in a specific format, use a specific framework for writing out goals, or make sure your developers have full backlogs. The point of Product Management is to create valuable products that customers love.

That’s where the real science of Product Management comes in. The science is about understanding the patterns to building products that people love from a strategy perspective.

I shared some similar thoughts on Twitter in the context of this new-ish push for “product thinking”:

I’m in a spot where I feel we’re trying too hard to make “product thinking” a thing with fancy words and lofty concepts. Like we have some kind of inferiority complex with other disciplines we’re trying to make up for. Talk to customers, understand the market and the business, and experiment until you get it right. That’s pretty much it, right? How you do that looks different in every org, but that’s where the art comes in. You can’t codify product management.

An oldie but a goodie from Michael Copeland: Shipping is a Feature—Some Guiding Principles for People That Build Things:

For these five bits of advice, I chose to focus on what I think is the most challenging aspect of being a PM, which is achieving clarity and maintaining a point of view for a product when all forces work against this very thing. What customers value most in a product is that “it just work” or “does what it is supposed to do,” and yet at every step in a product, the dynamics of design work to make this the most difficult to achieve.

The whole list is good, but the one that resonates the most with me is “Can’t agree to disagree.” What to do when you simply have to make a decision that not everyone agrees on:

So if you’re on the “winning” side of such a dialog then you have to bring people along every day for a while. You can’t remind people who was right, or that it is your decision and so on. If you’re on the “losing” side you need to support the team. You can’t remind people when little things go wrong (which they will) that you were right. Once a choice is made, the next step is all about the greater good. Nothing is harder for technologists than this because as technologists we believe there is a “right” answer and folks that don’t agree are simply “wrong”. Context is everything and remember you have to ship–as a team.

I am intrigued by the idea of product-specific wikis, as outlined in North Star Product Management. The idea is to have a living document that explains how each product component works, why it exists, why certain decisions were made, and what the future looks like:

The purpose of North Star Docs is not (at least, not necessarily) to minimize changes — changing the North Star Docs is just fine, and is of course actually encouraged, if we can find a better way to do something.

The purpose is, instead, to help map complexity for systems-level, rather than localized, problem solving. They are comprehensive and detailed specs like a Waterfall, yes, but they serve a very different purpose.

This can then be paired with project-specific specs as and when needed. But separating those from the main “this is the overall vision of the product/component” document provides a clear decision-making framework and builds organizational memory.

This interview with Jonathan Golden, Airbnb’s very first product manager and now Director of Product, is sprawling and worth reading in full. It’s a fascinating look at the company’s philosophy on product and teams.

I was particularly interested in the description of three types of PMs: Pioneers (focused on taking risks and building new things), Settlers (focused on growth and scaling), and Town Planners (focused on infrastructure and platform management). What’s important is the point that companies need all three types, no matter their size:

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.

This is the type of framework that brings up lots of (good!) questions for all of us to answer. Which of the three types of product managers are you? Is it possible to be combination of them? Which might you or your company be lacking in?

We all know the old enterprise software joke that “no one ever got fired for buying a Microsoft product”. But one of the important points in Auren Hoffman’s post on how Zoom is beating much larger competitors like Google Hangouts and Slack is that larger companies are not that unpleasantly predictable any more:

One of the biggest trends that is driving Zoom’s success is that companies are forgoing the full stack and buying the best-of-breed. The number of vendors the average company is buying from has increased almost 10x in the last 12 years. Companies are happy to buy from many different places. They are even happy to buy from new start-ups. […]

In fact, it has never been easier to sell to large companies. Large companies are open for business. They want to be sold to. They are sick of having a third-rate solution. They want to use the best product. If you can show them your product is superior, they are excited to buy.

This is an exciting development for product managers, especially if you’re building something in the B2B space at a smaller company. With a really good product it’s becoming so much easier to sell to larger companies without the need for the bureaucratic checklists that used to be an impossible barrier to break through (“Are you ISO 9001 certified?”).

That said, in most cases it’s important not to start there. As Box CEO Aaron Levie points out in this article about Slack’s move into the enterprise:

[Slack] have had a methodical process of continuing to drive strategy up market. They started with individuals and small teams, and then departments and bigger teams, and now broader enterprises. It’s been a very thoughtful strategy.

There are many reasons to start your product growth with smaller teams. One is that it will help you make incremental improvements very quickly. But it’s also really dangerous to end up in a situation where most of your revenue comes from a few large customers. So start small, get better, move into larger markets, and then just keep going…