Move over product manager, introducing the Behavioral Product Manager

Kristen Berman
Jan 19, 2018 · 11 min read

A traditional product manager generally has a keen instinct for human behavior. However, a behavioral product manager has learned how to incorporate the science of human behavior in a more rigorous way than just relying on instinct.

This post (with a nod from Ben Horowitz’s seminal post) introduces the idea of a behavioral product manager (BPM) — a product manager who integrates the science and methods of behavioral science into product design — and discusses the traits of BPMs and traditional PMs.

Update: Check on Kristen’s Tedx on why you *shouldn’t* listen to your customers. Give it a like or comment to support this movement.

A Behavioral Product Manager

  • A BPM understands that humans have systematic irrationalities. They seek to understand these irrationalities and build for them.

A traditional PM builds for a persona or the ideal customer behavior rather than the actual user behavior.

A traditional PM inundates the user with information or features, without any assistance or help, because they believe the user has enough time and expertise and also wants to make most decisions by themselves. They assume the user prioritizes their product as much as they do.

A traditional PM does not appreciate the power of framing and context to drive behavior change. They do not acknowledge that people have difficulty making choices that benefit their long-term self-interest.

A traditional PM does not fully internalize the power they have over the user and sees them as an engine to drive product metrics.

  • A BPM is ruthless about identifying and prioritizing a key behavior — what uncomfortably specific action they want the user to do (rather than a generic action like ‘log in’*). For example, if they are building an online education platform, they may define the ideal key behavior in concrete terms like, “Add online course schedule to their calendar, right after signing up for the course” or “Get to min 30 or 40 in their first online course.”

A traditional PM focuses on generic and short-term product measures over behaviors. They value the act of logging in or time spent and not what someone does when they log in. For example, it is common to hear a traditional PM say they want users to view their dashboard. This traditional PM values exposing their user to information vs. having the user act on that information.

A traditional PM articulates a key behavior that is broad and general vs. uncomfortably specific. They may say something like, “Help the user finish the online course” or “We want them to try out different courses”. You can quickly figure out if the behavior is too broad by asking everyone on the team what they think the key behavior is. If everyone says different things, the behavioral product manager has failed.

*I’ve shot down “logging in” multiple times and will continue to in this post. Why? “Logging in” to your product does not inherently mean anything. It does not mean the user has succeeded in obtaining value. It does not mean they will pay you. In fact, it may be a signal that your product is NOT providing positive customer value. If a user has to come back daily, have you helped them to save time? Have you helped them worry less? Imagine you are Quickbooks Online or Mint. You are not helping people if someone has to log in every day to check their business accounting system or their personal finances. But if Quickbooks Online measures active use (which it did) it will be incentivized to build features that get you to log in vs do actions to improve your business finances. This is why it’s critical to measure and thus incentivize an actual behavior that represents positive value for the user. For more on this refer to the time-well spent movement.

  • A BPM will assume they are not the first person to identify a customer insight or product opportunity.When investigating a new problem, they will not start with original research or new features. They will seek out existing academic literature/case studies to not reinvent the wheel.

A traditional PM does not use data-driven insights to drive their research agenda or product prioritization.

A traditional PM does not conduct a literature review prior to writing product requirements. They consistently let original qualitative research drive prioritization on the roadmap.

  • A BPM will prioritize logging and testing infrastructure — the tools for understanding — over new product features. In fact, they will likely choose to delay a launch in order to put in a testing system.

A traditional PM puts off building testing frameworks and capabilities into the core functionality. They reference their own or their network’s experience as proof that a feature or idea is worth prioritizing. They get surprised when the logging didn’t work or the key outcome can’t be measured without more engineering work.

  • A BPM understands that behavior is hard to change. Because of this, they seek proof that a feature/change will produce the intended results. A BPM is religious about experimentation.

A traditional PM does not think about the difference between correlation and causation. They frequently and confidently misattribute feature changes to causation (the new feature worked because of our design) when there was no controlled experiment to show this.

A traditional PM compromises on the experimental control in favor of short term business results. They keep a test running until it gets to statistical significance vs. declaring a target sample size.

A traditional PM does not articulate the experimental conditions and detailed hypothesis to the design and engineering team. This results in multiple revisions and meetings (and possibly future resentment of experimentation given how much time it takes).

A traditional PM doesn’t celebrate a null result and the fact that they saved the company money by not over-investing in an ineffective feature.

  • A BPM creates a behavioral map of all the decisions that a potential and current user must do to reach the key behavior. The map zooms into each step and every detail of the whole process. They use their detailed map to gain a shared vision of the problem and prioritize product and feature opportunities.

A traditional PM creates arbitrary personas like “soccer mom” and
segments by demographic rather than mindset. A bad product manager does not facilitate a behavioral mapping process with the team. They think about
changing attitudes and beliefs over changing the details of an environment in which someone makes a decision.

A traditional PM does not print out designs when they are reviewing them. They scan them for the aesthetic but don’t ask the designer to defend the copy, visual elements or benefit framing of their designs. A bad BPM does not care if their team is worried about the details.

  • This is simple but will be controversial when practiced. A BPM uses their powers to bring positive value to their customers lives.

A traditional PM consistently prioritizes short-term growth metrics. A bad BPM uses powers to take money and time from their users, without concern or prioritization of positive user value. A bad BPM uses their powers for evil.

— —

Want to learn more about behavioral economics and how you can apply it? Kristen runs a bootcamp for product managers. Check out the Behavioral Economics Bootcamp.

Kristen was a PM for 6 years at Intuit and startup called Lytro. She is a co-founder of Irrational Labs, a behavioral science product design shop and Common Cents, a Duke University research lab. She helps startups and tech companies apply behavioral science to help people become happier, healthier and wealthier.

Want a discount for our 8-week online bootcamp? Apply and during check out use the code MEDIUMFRIEND to get $50 off.

Hacking Behavior