There are three types of PMs in the world…

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?

The value (and pitfalls) of process

Phil Johnson has some good advice for product managers in The Goldilocks of Process:

Blindly following process is a project-killer—not just in terms of efficiency. The real poison is the mentality: in these cases process became a crutch to lean on, with these individuals no longer thinking critically about their tasks. In many ways, the process became the job, where process really should be what enables the job. This rings doubly true in the software development world.

On any team, you want your process like you want your porridge: just right. If you have too little, the team may not know what the priorities are, or who is responsible for the next step. Too much, and your team will end up doing more process than actual work. The right strategy should be flexible enough to fill in the cracks of the team’s blind spots while enhancing their strengths. It’s up to the PM to find that sweet spot.

This also reminds me of Michael Lopp’s essay The Process Myth, and these words that will forever be etched in my brain:

Engineers don’t hate process. They hate process that can’t defend itself.

More on the need to slow experiences down for users

I talked about adding friction to products last week, and Kurt Yalcin’s article Against Engagement makes for a great companion piece. He touches on many topics, but I especially appreciate his views on that topic:

Slowing experiences down with intention and adding deliberate requests for user action at critical moments in a user flow makes for better experiences in the long run. Bring a level of consciousness to your designs and address the pressures you may have to reduce friction at all costs. If adding an additional click means giving users more freedom, go with the extra clicks. This level of awareness in your design enables users to make conscious choices about when, where and how to engage with your products, rather than acting on autopilot.

“Growth hacking” is user-hostile and needs to stop

This morning I clicked on a link to read a blog post, and within 3 seconds of arriving the popup above stopped me in my tracks. I am asked to provide my email address before I’ve had any opportunity to determine if the site might have value to me1. I came to the site to read an article, which means I intended to spend time there. By serving a pop-up just as I enter the site, it is preventing me from seeing any value until I make a decision about whether or not to give them access to my email.

In a discussion about this topic on Twitter the most common defense I heard is that the sign-ups are worth it even if the method is sketchy. I disagree with that, and firmly believe that product growth should never happen at the expense of users. It might take longer to get right, but I would rather work to find ways to create more value for users and attain product growth that way, than resort to tactics that are hostile.

Which brings me to the topic of growth hacking. I think it needs to be said that all growth hacking methods, at their core, use human psychology to get people to do what you want them to do without taking their needs or intentions into consideration. The founder of the term defines a growth hacker as “a person whose true north is growth.” Growth at any and all cost. When we talk about this type of growth it’s usually in the context of persuasive design and habit-forming products, which have implicit goals to “nudge” people into directions they didn’t intend to go.

I don’t think this an ethical practice, and I think as product managers it is our responsibility to put an end to it. Instead of evaluating features and ideas based on the concept of “growth at any cost”, let’s ask the question “growth at what cost?” to guide our decisions more. Let’s find ways to grow that respect users and their intentions, not subvert them.


  1. I don’t mean to single out this site — this happens everywhere on the web these days. It was just the proverbial final straw today. 

Don’t have a separate “queue” for bug prioritization

Emily Tate’s article on the best ways to prioritize bugs comes at the problem with a Scrum lens, but many of the points are more broadly applicable to product management. I particularly like her assertion that there’s nothing “special” about bugs, and as such they should be prioritized just like any other idea/feature:

As product managers, we should always manage our backlog so that the next most important thing is at the top of the list. Many times, the bug you would work on is less important than other things on your backlog. By working on the lower priority bug, you are deferring the more important work that can help you reach your strategic goals.

The flip side of this is also true: sometimes the next most important thing may be five or six bugs that really need to be fixed before adding yet another feature on top of a fragile platform. If you live in a world of separate queues or say you’ll always devote 20% of the team’s time to bugs, you actually lose the opportunity to say “this week, we are squashing these bugs that have been plaguing us before we do another thing.” In reality, you will likely have a mix of bugs and features in your backlog, but the most important thing is that you prioritize strategically and intentionally, not letting a false constraint determine what the ratio of your backlog looks like.

Good products from small companies are starting to break through in the enterprise

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…

How to make “product principles” more useful

There’s an interesting discussion going on in the Elezea Community about “Product Principles”. What they are for, when you need them, how they can be made more useful, etc. A couple examples given are Intercom’s set of guidelines for making decisions, Dan Ritz’s interface design values and my own company’s values.

The biggest challenge I see with principles like these is figuring out how to make them specific enough to help us make decisions. The further I get into reading Good Strategy, Bad Strategy the more I realize how much we tend to hide behind nice words, when in most cases those nice words don’t actually change our behavior in any meaningful way. For example:

Bad strategy is not the same thing as no strategy or strategy that fails rather than succeeds. Rather, it is an identifiable way of thinking and writing about strategy that has, unfortunately, been gaining ground. Bad strategy is long on goals and short on policy or action. It assumes that goals are all you need. It puts forward strategic objectives that are incoherent and, sometimes, totally impracticable. It uses high-sounding words and phrases to hide these failings.

I fear that “product principles” are prone to be made up almost exclusively of “fluff”:

Fluff is superficial restatement of the obvious combined with a generous sprinkling of buzzwords. Fluff masquerades as expertise, thought, and analysis. A hallmark of true expertise and insight is making a complex subject understandable. A hallmark of mediocrity and bad strategy is unnecessary complexity—a flurry of fluff masking an absence of substance.

I think product principles, in particular, need to be detailed and specific enough so that they affect day-to-day decision making. This is similar to how we should use Personas (and why so many people hate Personas). If you just put a Persona’s face on a coffee mug, that’s not going to be very useful. But if you’re able to say, “this feature would be useful for a persona that’s not in our target market so we’re not going to build it”, that’s an entirely different story.

Which leads me to wonder if what we call “product principles” should rather just be the combination of a well-defined design system and content strategy. HelpScout’s Style Guide immediately comes to mind as a good example of this. Because what are “Product Principles” for if they don’t help us make product decisions?

Do you have thoughts to add on this topic? Join the community.

The value of adding a certain amount of friction to our products

In The Value of Inconvenient Design Jesse Weaver discusses the role of user friction in design — the things that slow us down from getting a task done — and how the goal is not to remove all friction from our product flows:

The friction of the checkout process provides a check against impulse purchases and overspending. In a world where many people struggle to manage their money, these small barriers can be critical to maintaining financial balance. While the market would dictate that it’s not Amazon’s job to help its customers control their spending, lowering the barrier to impulse purchases could have a net negative effect on the value people get from Amazon’s service. The Dash button, for example, eliminates so much friction that customers may not even know how much they’re spending until after they’ve completed a purchase. In light of this, Amazon Dash was recently deemed illegal in Germany for violating consumer protection laws.

If you’re interested in the topic of “frictionless design”, here is some related reading. Clive Thompson digs into software that aims to add friction to our lives in his Wired essay We Need Software to Help Us Slow Down, Not Speed Up:

It’s certainly possible to slow our software, and thereby ourselves. But it’ll happen only when we become too unsettled by the speed of our journey.

Here is Chris Palmieri in A Practice of Ethics:

But some friction is borne of respect, when we present information about the choices available to users and help them make better decisions. An emailed invoice could remind a customer they were paying for a service they no longer use. A checkbox could assure a user of their current content privacy settings before posting a sensitive photo. Recognition of a past purchase can save a customer the hassle of having to return a book they already have, or confirm that they are re-buying exactly the same shampoo.

And Andrew Grimes in Meta-Moments: Thoughtfulness by Design:

Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.

In short, not all friction is bad…

Learning depends on our grasp of what we’re doing well, not what we’re doing poorly

Marcus Buckingham and Ashley Goodall discuss some fascinating research about how people learn in their essay The Feedback Fallacy:

What findings such as these show us is, first, that learning happens when we see how we might do something better by adding some new nuance or expansion to our own understanding. Learning rests on our grasp of what we’re doing well, not on what we’re doing poorly, and certainly not on someone else’s sense of what we’re doing poorly. And second, that we learn most when someone else pays attention to what’s working within us and asks us to cultivate it intelligently.

As a parent it’s natural to see the elements of “positive parenting” in this research. We (generally) don’t have to deal with tantrums at work, but it still makes sense people would be more motivated by this approach than by reminders of what they’re doing wrong. Something to keep in mind as we work with our teams.

The ideal balance between product building and marketing, and other advice from a product founder

My friend and colleague Garrett Dimon wrote about his experiences building and selling a product in his post Hindsight. He gives some advice based on what he learned. You might not agree with everything, but I think his perspective is really interesting and worth checking out. For example, on the balance between building product and doing marketing:

I don’t want to build an operational system to grow a business and then spend no time on the product. I want to design a company to build the product and serve customers. That’s not to say that there shouldn’t be some type of marketing that will need to be done, but I’d rather find ways where marketing is a by-product of the software rather than a separate activity. Checking analytics and numbers eventually becomes relevant for a business, but it’s a spectrum. I want to check the numbers to make sure the business is healthy, but I don’t want to be in a situation where I’m spending days analyzing or optimizing.

More

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 125