Move over product manager, introducing the Behavioral Product Manager

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 BPM knows that their users do not have fixed preferences. They know their users make different decisions depending on the design and context of an experience.
• A BPM is not afraid to be paternalistic. They understand that giving users all the choices and information can be burdensome rather than welcome. They believe it’s their job to make decisions easier and this sometimes means making decisions in the best interests of the user. (See last point on good vs evil: a good BPM has reason to believe the behavior they are encouraging improves the welfare of their customers)
• A BPM knows users make different decisions if they are deciding for today’s self (now) or tomorrow’s self (future me).
• A BPM understands that habit formation is extremely tough. They know that it’s much easier to have the user make a one-time decision that automates their usage and value extraction than to insert their product into the user’s life on a daily basis and ask them to log in/perform a new action every day.
• A BPM is able effectively to communicate, educate, and translate behavioral science insights for the engineering and design team. They ensure every person on the team is tuned into the small details of an experience and asks each other for the behavioral insights to justify small and large product and design decisions. There is a shared language, focused on details.

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 BPM ensures that all team members have input and agree with this specific key behavior. They work to ensure all team members are actively using it to drive their priorities. A BPM formulates a research plan around this key behavior, has appropriate data tracking metrics for this key behavior and is open to change the key behavior when it stops driving business growth as expected.

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 BPM will question their own intuition on the problem and solution — and their team’s intuition. When someone says “we tried that before and it didn’t work” they will ask to see the data as proof. They will not reference their personal experiences as justification for a feature request.
• A BPM will listen to customer interviews and focus groups but remain skeptical that people’s attitudes, beliefs and perceptions will translate into actual behavior. The good product manager is constantly thinking about the “say/do” dilemma.

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 BPM promotes a team culture that is unforgivingly meticulous about data integrity, test methodology and tracking actions the user takes in the product.
• A BPM will have a data / logging QA process they follow rigorously. They never launch a feature without first testing that the data collection works as specced.

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 BPM uses experimentation to understand why something works or doesn’t work, which gives them confidence to build a long-term roadmap and strategy from the results.
• A BPM is ruthless about the experimental control condition. Once they decide to invest valuable resources to conduct an experiment, they do not compromise on the experimental design. They insist that the control must isolate the key variable, even if it degrades the customer experience. They understand they are trading off a small number of current customers for an improved experience for future customers.
• A BPM ensures random assignment and avoids self selection. Everyone in the experiment should be equally likely to end up in the control. When relevant, they ask their data team to double and triple check the randomization to ensure it’s truly random.
• A BPM documents the experimental conditions such that design and engineering understands the key question and hypothesis.
• A BPM publishes the team’s hypothesis on which version will win, their assumptions on sample size, conversion, effect size and how long the experiment will run. They ask the data team to publish their data analysis plan prior to launching.
• A BPM packages and promotes both successful and failed experiments so the rest of the company (or public) can learn from the investment. They believe in systematic results reporting and are unafraid to loudly communicate lessons learned from “failures”.

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 BPM meticulously documents the barriers that a user currently experiences. They do this with a combination of observation, the behavioral map and data. They constantly ask the team what barriers can they remove and what benefits can they amplify. They are deeply worried about small frictions within the process and ruthlessly remove them.
• A BPM instills in their designers an unwavering aesthetic for simplicity and ease. They ask designers to justify every additional step, choice and decision a user must make.
• A BPM builds and articulates powerful benefits that increase a user’s motivation to overcome hurdles. They prioritize features that add immediate, concrete and hedonic benefits to using their product, so long as these also align with positive long-term value for the customer.
• A BPM does not leave copy to the end. They understand the role of copy in driving mindset and framing. The product must work hand-in-hand with the copy.

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 BPM works to change the behavior of their users in order to deliver on the company’s mission for customer wellbeing (assuming the mission is positive … tobacco companies need not apply)
• A BPM resists manipulating the irrationality of the human psyche to extract more money from customers for less value.
• A BPM differentiate between short-term and long-term value. For example, if Zynga succeeded in getting me to play games for five hours a day, they may have provided me short-term value (otherwise I wouldn’t keep playing). But they may not be delivering long-term value. Humans act differently when making decisions for short term/today’s self and long term/tomorrow’s self. Because of this, a good BPM would measure the long-term impact of heavy game play and whether it corresponds to positive wellbeing for their users.

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.