inhale exhale

The Four Tendencies

The Four Tendencies

Why every Product Manager Should Read Gretchen rubin’s book

Screen Shot 2019-08-14 at 3.09.57 PM.png

I recently adopted a new framework from The Four Tendencies, by Gretchen Rubin, to influence my interactions with my team members. The book theorizes that based on how a person meets internal and external expectations decides their tendency: Upholder, Questioner, Obliger or Rebel. Refuse to believe people can so easily be categorized? You’re likely a Rebel but stay with me for now.

Using this framework, product managers can distinguish between personality types on their team and tweak their communication styles and actions to motivate their team to meet project expectations. Encourage your team to take the survey and circulate the results.

Because product managers lead without authority (unless you count the power of sugar-laden donuts on release days), designers and engineers must align with our product roadmap to deliver on it.

Communicating effectively with our team is critical since a portion of our success is dependent on the work they complete. If team members miss their deadlines, the domino effect ensues as we fail to meet the outer expectations of our clients, users, and stakeholders. We all lose. Identifying upfront how much work from our team is realistic to complete in a finite amount of time and understanding what compels our them to deliver on these expectations is a valuable insight for product managers. Let’s dig into the tendencies.

It was fascinating to read this account of how product managers can use the Four Tendencies to work more effectively with teams
— Gretchen Rubin

Questioner

I’ll comply — if you convince me why.

Questioners resist outer expectations and meet inner expectations. However, this doesn’t mean they only selfishly act on behalf of their inner needs; Questioners turn outer expectations into inner expectations. But first, they must research and craft their own rationale to shift from an outer to an inner expectation. They’re prone to gathering info and using their research to inform this self-directed decision. They decide for themselves what course of action they will take. And once they make up their mind, they follow through without much difficulty or resistance. Many people are Questioners, second only to Obligers.

Questioners are the team members who, well, ask a lot of questions and might challenge the product strategy you’ve laid out. If you’re kicking off new feature development with Questioners, start by revealing the data and research to back up your idea as they’ll need that info readily accessible to comply with the ask. Resist defensiveness when overloaded with questions from a Questioner — it’s their character to dig into the why. But provide limitations to avoid analysis paralysis, a typical reaction amongst Questioners, like time-blocking off the first 10 minutes of the meeting to address the Questioner’s questions.

Democratize data by sharing dashboards or sending pre-reading before the meeting, so they’re empowered to gather and digest data on their own. Because they challenge assumptions, they’re an excellent asset to help you resist the status quo and biases in your product by playing devil’s advocate. Use this to your advantage when you’re stuck with how to move forward with a user challenge and seek out a Questioner to bounce your ideas off of; they’ll force you to refine even your brightest ideas.

Upholder

Discipline is my freedom.

Upholders willingly meet inner and outer expectations due to their high discipline. They’re reliable, thorough and meet deadlines. Upholders stick to the rules but potentially come across as defensive and rigid. Given their self-starter nature, Upholders make great CEOs.

Upholders may express frustration over the failure of others to meet their expectations. Imagine a large-scale bug arises in the code blocking the release of your product. It’s critical to communicate early and often with Upholders if a deadline is at risk of being met. Include options and workarounds with a clear plan of follow-through since an Upholder will expect that level of detail.

If an Upholder engineer coded the bug, how you deliver feedback is crucial— focus on the problem, not the person. “I understand working in this complex codebase is challenging. Can you help me understand the bug so that I can effectively communicate the issue with management?” The high-performing, consistent nature of an Upholder to deliver on expectations could result in defensive behavior when facing their mistake.

Watch out for the Upholder on your team who takes on multiple priority-competing projects. Relentlessly set clear priorities so an Upholder can delegate to others if necessary.

Be sure to provide as much notice as possible if the roadmap is changing since Upholders might feel uneasy with a sudden course of change midway through a project. Rely on your Upholders to tackle high-priority projects and rest assured they’ll deliver.

Obliger

You can count on me — and I’m counting on you to count on me.

Obligers easily meet the outer expectations imposed by others but struggle to fulfill the inner expectations they introduce to themselves. They respond well to external accountability as they prioritize follow-through for others. The Obliger is the most popular tendency. They’re the ones whom people count on the most and get along best with the other three tendencies. Often they’re the responsible, team player.

Obligers need accountability to stay motivated so be sure to define clear deadlines. Obligers are prone to taking on too much work. If your lead UI Designer shares her time across two teams and happily takes on incoming projects, and app onboarding redesign is due next week, remind her that users will finally be less confused with account creation when they install the app. Reinforcing the deadline by including accountability of end users will go over smoother than a controlling tone if you said, “You’re taking on too much, and this app onboarding project is most important.” Monitoring progress and checking in provides sufficient accountability that helps the Obliger meet their deadlines.

Protect against overloading an Obliger who consistently meets expectations until the breaking point when they refuse to continue forward. This could be your overworked engineer who stayed late for two weeks to hit a release and silently watches others fail to do their part. They’re on the verge of burnout. Keep an eye out before they’re too fed up and ready to quit. Depend on your Obligers to step up the plate when others don’t by reinforcing accountability and recognize their hard work.

Rebel

You can’t make me — and neither can I.

Rebels oppose all expectations, outer and inner alike. They do what they want, in their own way and on their own time, and resist when others ask them to do something. They crave freedom and self-expression. They might change jobs frequently. Rebels are a smaller group than Obligers or Questioners.

If there’s a Rebel on your team, do not supervise or micro-manage them. Tweak your message from a required ask to a challenge — “The app onboarding redesign is a tough problem to solve for users, and I think you’re exactly the person to tackle it.” With a hands-off approach, they work drastically different than an Obliger.

If they’re skipping deadlines, present them with an information-consequences-choice framework: “This is the last release before our holiday traffic spike when we have the highest potential to retain new users. If you don’t deliver the new app onboarding designs by Friday, you might get stuck on a smaller, basic task.” Present them with a choice and give them the freedom to decide.

I‘ve worked with notably talented designers who fit this tendency. And for a good reason: their creativity is boundless. They reject strict guidelines and defy boxed-in conventional thinking. They might come across as arrogant, but if they firmly believe in a cause, they’ll fight with all their power for it. Lean on your Rebels for innovative and creative product ideas, and they’ll bring it.

Before We Go

The graphic below often circulates in the product management community. At the heart of the Venn diagram is people: the user experience that compels people to try our product; the people who innovate and iterate on the technology that powers the product; the people who fund and invest in the product and the people who create it. The better we work others, the more stellar product managers we will become.

Find out your tendency by taking this survey.

blog post content

Brainstorming Doesn't Have to Suck - Here's How To Make it Work

Brainstorming Doesn't Have to Suck - Here's How To Make it Work

Using Mental Models

Using Mental Models