Tag Archives: Product Management

Google’s Project Aristotle and psychological safety

stressed_2580348b-large_trans_NvBQzQNjv4BqpJliwavx4coWFCaEkEsb3kvxIt-lGGWCWqwLa_RXJU8

After 18 months, the team was still struggling with the project. Lots of work had been done, but most of it was unfocused, and even at this late date, no one could articulate a clear set of requirements. Hitting the deadline, an aggressive goal from the start, was starting to feel like an impossible task. The team knew they were in trouble.

As the team started to miss internal deadlines, the rest of the company began to get concerned too. Meetings were called, presentations were given, and more deadlines were set. Unsurprisingly, these new deadlines – piled on top of old deadlines that were already being missed – were missed too.

People from across the company offered to help the team in any way they could – time, expertise, snacks – but the team politely declined. They knew that failure was not an option, but they didn’t know how to accept the help that was being offered. Worse, they were scared. In order to avoid painful conversations, they pretended they had a plan. What the team really needed was to talk with the customer, to establish a definitive set of requirements to deliver. But how could they tell the customer 18 months into a 2 year project that they still didn’t know what they were supposed to be building? They decided they couldn’t. Better to keep their jobs for the next six months than to risk being fired immediately.

The Emperor has no clothes

Everything changed when a new Product Manager came into the mix. On day one, he said the emperor had no clothes. On day two, he said we were back at square one. Then he started working with the team to gather a definitive set of requirements.

“How is it possible you’re just doing that now?” stakeholders asked, “this should have happened months ago.”

“You’re right, the new Product Manager said, “it should have. But since it didn’t, we’re going to do it now.” On day five, we had a meeting scheduled with our customer to make sure we had the requirements right.

One week after our new Product Manager was hired, we had a plan. Somehow, throughout the interview process and his first week, nobody told our new Product Manager he was supposed to be too scared to do his job. As a result, he wasn’t.

Google’s Project Aristotle

I recently re-read Charles Duhigg’s terrific 2016 New York Times article, What Google Learned From Its Quest to Build The Perfect Team. Here’s the setup:

Five years ago, Google — one of the most public proselytizers of how studying workers can transform productivity — became focused on building the perfect team. In the last decade, the tech giant has spent untold millions of dollars measuring nearly every aspect of its employees’ lives. Google’s People Operations department has scrutinized everything from how frequently particular people eat together to which traits the best managers share.

The company’s top executives long believed that building the best teams meant combining the best people. They embraced other bits of conventional wisdom as well, like ‘‘It’s better to put introverts together,’’ or ‘‘Teams are more effective when everyone is friends away from work.’’ But, ‘‘it turned out no one had really studied which of those were true.’’

In 2012, the company embarked on an initiative — code-named Project Aristotle — to study hundreds of Google’s teams and figure out why some stumbled while others soared.

28mag-teams1-facebookJumbo-v2

The article goes on to describe how the test was constructed and how challenging it was for researchers to identify which group norms consistently characterized successful teams. After studying hundreds of groups over several years, however, researchers made a breakthrough:

They noticed two behaviors that all the good teams generally shared. First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’

Second, the good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues. 

Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety, or ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up. It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

This finding is both intuitive and incredible. The highest performing teams, it tells us, may not have the smartest people, or the clearest goals, or the most inspiring leaders, or the clearest focus. The highest performing teams are those in which people feel “comfortable being themselves.”

Learning from failure

Psychological safety is not the only thing that makes a team great – according to the Times article, “there were other behaviors that seemed important as well – like making sure teams had clear goals and creating a culture of dependability.” But can a team be great if they don’t have each other’s backs? Can a team be great if they’re afraid to take chances? Can a team be great if they blame each other when things go wrong?

Google’s research is aligned with lots of great writing about learning from failure. Great teams take big swings, and when they miss (which all teams do), they learn from their mistakes and move on together. The conclusion is clear: as leaders, our job is to make sure our people feel safe enough to take chances, to challenge each other in productive ways, and to bring their very best ideas to work without the fear of being wrong. That’s the way we’ll build high performing teams, and the way our high performing teams will do amazing things.

Encouraging people to stop the line with both carrots and sticks

2012-02-10-Carrot-and-stickIn my last post, I described a work challenge around delivering high quality products, noting that despite repeated encouragement, members of my team were reluctant to stop the line, even if that meant sacrificing quality for speed. I offered a few thoughts on why this was the case, including mixed messages from leadership, aggressive deadlines, our tendency to fall in love with technology, and peer pressure.

In this post, I’ll describe a few things we’re doing to try and correct the situation. Some of these things are what I’d call “carrots,” or rewards that come with stopping the line to focus on quality. Others are “sticks,” or penalties.

Carrots

Celebrating line stoppers
If someone stops the line, we celebrate it publicly. At our all eCommerce team standup this week, we discussed a project that didn’t go as planned, thanking the person on our team who stopped the line and slowed it down, helping us avoid a big mistake.

Using numbers
Products that are well-designed and well-executed tend to outperform those that aren’t. Regular KPI reviews encourage our product teams to do their best work. Sometimes this requires stopping the line.

Holding design review meetings
Last month, we instituted design review meetings with our team’s leaders (it’s a riff on Ed Catmull’s “Braintrust” idea). At first, our teams were afraid they’d be micromanaged.  But a month into the new process, they see the value and appreciate the attention. And they’re quickly becoming more detail oriented.

Showcasing great design
When something is designed well, we share it, far and wide. Being a team that focuses on quality products is becoming a point of pride for all of us. Building “good” things is boring – our products should be great. We want our people to be able to tell the difference between good design and great design, and to aspire to create the latter.

Finding evangelists within the team
I’m actively recruiting people on the team to promote the value of stopping the line. I started with our UX people, who seized the opportunity to get the rest of the team focused on the user experience. (As you’d expect, it was easy to get them on my side.) By now, the entire team has heard the message, and we’ve got lots of evangelists – and converts.

Sticks

Requiring rework
One great way to ensure someone on the team stops the line is to make it clear that the whole team will be starting over from square one if they don’t. When faced with the prospect of removing functionality from our sites and rebuilding it from scratch, stopping the line starts to feel like the much faster option.

Public shaming
This is a route we haven’t really gone down, since one of our core principles is to celebrate failure. Still, when we see poor customer experience, sloppy design, or performance issues, we let the team know. We favor blameless postmortems, but we also favor paying attention to details.

Instituting sign-offs
Our team knows that when they release code into the wild, they’re implicitly saying it’s ready to go. If we need to, we can make this explicit. This would be a last resort – sign-offs aren’t part of the culture we’re nurturing – but it’s an option if we need it.

These are just ideas, of course. If stopping the line and focusing on quality are important to you, you’ll need to work with your team to figure out how to make it happen, and you’ll likely need to revisit the conversation over time.

As leaders, we also need to model this behavior. This means there are times we need to stop the line ourselves, even when it’s our own work we’re doing and our own deadlines we’re missing. We need to make the same trade-offs we ask our teams to make, and have the same tough conversations we ask them to have with stakeholders.

What do you think? Have you had similar experiences as it relates to stopping the line to focus on quality? How have you addressed them? I’d love to hear from you.

 

Why is it so hard to stop the line?

taiichi-ohno-lean-manufacturing-1

Those of us who’ve adopted (and adapted) Lean software techniques owe a debt to Eiji Toyoda, and especially to Taiichi Ohno, who developed the Toyota Production System (TPS) and forever changed the way manufacturing – and eventually much of software development – works. According to Wikipedia:

TPS is grounded on two main conceptual pillars:

  1. Just-in-time – meaning “Making only what is needed, only when it is needed, and only in the amount that is needed”
  2. Jidoka – meaning “Automation with a human touch”

Core to jidoka is the concept of “stopping the line,” which means that when someone at Toyota identifies a problem, they’re required to stop production and resolve the issue. This ensures problems are addressed immediately, when they’re easier, less expensive, and less frustrating to fix.

Our eCommerce team has embraced this way of thinking. Our agile product teams are familiar with the Toyota story, and they understand the importance of identifying problems early. They sit together at tables, which makes collaboration easy, and they have daily stand-up meetings to make sure everyone’s on the same page. Best of all, they’re aligned around common goals, so they have the same motivation to improve the customer experience and their KPIs.

So why won’t they stop the line when they see an issue?

Stopping the line is really, really hard

Recently, my team released a couple of new features that weren’t up to our usual standard – experiences that were a little bit clunky. In both cases, after the projects were complete and the new functionality was deployed into production, we removed the new functionality from our site, sending the teams back to the drawing board. Weeks later, we’re still in the process of rebuilding these features, and we’re going through the work in great detail as a team to make sure we get it right.

Every single member of the team knew – weeks before launch – that the experience was less-than-perfect. And every single member of the team had been coached multiple times to stop the line. Even further, if you asked any member of my team if they understood the importance of stopping the line – if they agreed with it conceptually – every one of them would have said yes. And yet, nobody did it.

I asked three people why, and they all said some version of this:

Our team is working on becoming a well-oiled machine, and I don’t feel comfortable slowing things down.

The machine

Earlier this week I attended DevJam’s excellent Product Conference, and I was glad to hear its founder David Hussman discuss how product and agile are evolving. “We’ve gotten really good at building the wrong thing faster,” he said, and I couldn’t agree more.

My team was built for speed, and although I kept telling them to stop the line, I also told them a lot of other things:

  • “This new functionality is going to add a lot of revenue for our business.”
  • “You’ve got a long backlog.”
  • “If we get this done pre-holiday, it’ll be great for the bottom line.”
  • “Our Marketing team really, really wants this now.”
  • “It’d be great to get both of these projects done next quarter.”

By now you get the idea, and hopefully you see the problem. And it wasn’t just me. My team supports a lot of brands, and the brand owners, marketers, merchandisers, technology teams, senior executives – everyone, really, was in some way or other telling our product team to do more, faster.

In response, we became a machine built for speed. We got good at getting a lot of projects done, and we found a way to set and meet the goals we had before us. We implemented Test Driven Development (TDD), built automated tests, and found ways to get closer and closer to continuous delivery. And I’m convinced that every one of these things was – and is – the right thing to do.

The problem is that we did them at the expense of building great things.

In my next post, Encouraging people to stop the line with both carrots and sticks, I’ll describe what we’re doing about it.

Moving from projects to products

Brian de Haaff, Founder and CEO at Aha!, writes lots of smart things about product roadmaps, Agile software development, and the role of product managers within an organization. Here’s an excerpt from The Product Manager v. Project Manager, published by Huffington Post last fall, explaining the difference between products and projects:

A product is what you are providing to a group of users. It can be anything: a physical product that you hold in your hands, a software application, or a service that you are delivering.

In contrast, a project is a plan with a series of activities that has a defined outcome and a fixed start and end date. The project is completed when that outcome is accomplished.

So, let’s assume that your product is a new mobile application. It might contain many projects before it is ready to be launched. These projects all have their own unique starting and ending points. The mobile application, however, is a product which will continue to be improved as long as it is being sold to customers.

Simple, right? Products last forever, while projects have a beginning and an end. Then de Haaff goes on to describe the roles of product and project managers:

What is a product manager? Product managers are often described as the CEOs of their products. They set the strategy, prioritize releases, talk to customers, and clearly define features. A product manager’s goal is to deliver a lovable product.

What is a project manager? Project managers oversee a fixed project from beginning to end. A project manager’s goal is to work with a broader team with a diverse set of skills and to complete a project on time and under budget.

I love these definitions because they’re so simple and straightforward, and I agree with them completely. And yet, practically speaking, it can be really, really hard to maintain such a clear separation between these roles and functions. Here’s what I mean:

Let’s say your product is website search, and your product manager is its CEO. She’s on the hook for, among other things, prioritizing releases and delivering a lovable product. How will she do that?

If your team works like mine, your product manager will have created a vision of some sort and a list of things that can be done to realize it. The vision will be long-term enough to be aspirational rather than tactical, and it’ll provide a north star by which your product manager can vet new ideas generated by product team members and others throughout the company.

For the sake of example, let’s keep the vision simple. Since our product is website search, our vision is:

To get customers to the right product faster than Amazon.

Now that we’ve got a vision, we can start putting a high-level roadmap together. Our high level roadmap shows that we’re going to work on search accuracy in Q1. Our more detailed roadmap shows this:

  • Move search to the cloud
  • Build user tools to improve backend efficiency
  • Automate the process of building shops
  • etc.

Hopefully you’re starting to see the issue here. Whether we call these roadmap items projects or simply “work,” once they’re identified, delivering them tends to become our sole focus. Other product management tasks, like setting the strategy and talking to customers, take a backseat.

Shifting focus

Although we’ve got business analysts, delivery managers, and user experience experts on each product team (not the typical Silicon Valley approach, I know – I’ll discuss this more in a future post), our product managers often have the clearest sense of our overall strategy and business context, and they’re the ones who are on the hook for delivering the business value they promised. That means our product managers are personally invested (which we want them to be), and that keeping them closely tied to our projects is critical to our company’s success.

Our challenge is this: how do we keep product managers involved in each effort while still protecting their time for things like strategy, talking to customers, and long-term thinking?

Here are a few ideas:

More context for everbody
Product managers can’t be the only people on the hook for delivering business value. We need to work harder to make sure each member of each product team understands what drives the business and has a clear understanding of what success looks like. We need to work more collaboratively and share common goals. Beyond sharing ownership of the project’s goals, everybody on the team needs to understand their role in the context of the overall business.

Expand job definitions
Once everyone’s got enough context, delivery managers, business analysts, and UX experts can more fully own their roles in each project, moving product managers towards a more strategic, consultative role – and out of the role of “gatekeeper.” This can be as simple as a delivery manager making the call to delay a release without consulting with the product owner. (Informing? Yes. Asking? No.) To make this work, product managers have to give up some control, which is a big challenge.

Reward product managers for being strategic
People tend to focus on the things they’re rewarded for, so if we want our product managers to more effectively empower their teams, we need to reward them for things like providing context, delegating responsibility, and thinking long-term. We need to make it okay for other people on the team to be on point sometimes, and we need to provide the training and structure to ensure our products won’t suffer for it.

Protect your peoples’ time
Providing context, training people, thinking strategically, and talking with customers all take time. We need to acknowledge that time is a limited resource, and we need to actively, continuously, help our teams prioritize their work. We can’t tell our product owners that strategy is important without figuring out how to give them time to do it.

Physically separate the team
Part of the reason our product managers get sucked into every small decision around requirements, timelines, and user experience is that they sit directly across from the people working on those things. What would happen if we physically separated our product managers from the rest of the team? Might 20 feet of distance change the dynamic considerably? Might less collaboration lead to more empowerment?

Get feedback and revisit regularly
Change is hard, even for people and teams that do it well. Protecting people’s time, shifting responsibilities, providing context, and expanding roles make people uncomfortable, and sometimes some of these things just won’t work. If we’ve done it right, we’ve created an environment in which our teams are comfortable telling us what works and what doesn’t.

Even more than that, we need to actively solicit input, we need to be open to it, and we need to be willing to revisit our assumptions. The things that worked for us last year, last month, or last week may not work for us today, tomorrow, or next year. Like building great products, building great product teams requires time and focus.

Building trust

I’m a control freak by nature – I like to see everything my team is building, weigh in on the user experience, gather direct feedback, and provide my own. In my experience, there’s only one thing that cures this tendency: trust. In order to be comfortable that I don’t need to weigh in on every small decision, I need to trust that I’ve got the right people in the right roles, and that they have the skills and context they need to make solid decisions and create great products. They don’t need to make the same decisions I’d make, but they need to make educated decisions that they can defend.

Moving our product managers from project to product requires an enormous amount of trust – trust that teams will make the right decisions, trust that each person can handle their part, and trust that we’ll have each other’s backs when things don’t work out. Building that trust requires that we create an environment in which people can learn, experiment, and change. It requires that we allow our teams to challenge each other and to be challenged. It requires that we give every person on the team what we think we need in order to be successful, and that we understand that sometimes they’ll fail anyway.

How does that sound, control freaks?