I think most of us know Ben Horowitz’s classic Good/Bad Product Manager post. At Wildbit we have a whole section of similar Good/Bad posts to help define our take on various roles — but until recently, the Product Manager slot was empty. I started working on our take on the Good/Bad Product Manager debate a while ago, and we finally published it last week.

I realized that the most important lesson I learned about product so far at Wildbit is the importance of a happy and effective team, and how much of a Product Manager’s time should be spent on that:

No amount of workshops, sticky notes, or JTBD theory will help you create consistently awesome products that customers love if you don’t work with a team that is fulfilled and motivated.

That might be a slightly controversial idea, and it might not work for every organization. But it certainly works for us. So here it is, our perspective on what it takes to be a good product manager.

Des Traynor shines a light on the unglamorous side of the PM role in Q&A: What does a product manager do?

If you look at how actual product managers work in any company there’s a lot more nitty gritty work. There’s a lot of spreadsheets, wireframes. Google Docs, emails, and oh-so-many Slack channels. And they all exist to research, collaborate, dictate, and document consensus on a direction the product is going. But I think if the role was titled “Direction and Consensus Manager” you might not get as many applicants.

Giff Constable writes about The difference between design and product management and makes this good point about the nature of the PM role:

A big difference is where they spend their time. You’ll hear me call design and engineering “deep dive” roles, while PM is a multi-tasking role, which is why it is relatively easier for PMs to assume more of a leadership role. Even though we work in very collaborative ways (“rough draft culture”) at Axial, both design and engineering require getting into a “flow state” on a problem. Design takes a lot of iteration and trial and error to get something right. PMs, on the other hand, are bouncing around a million tasks, from clarifying a user story, to managing communication inside and outside the organization, to doing whatever it takes to un-bottleneck the team, to all the things listed above.

This is one of the things that makes Product Management such a challenging role. It’s not just about switching tasks, it’s about developing the ability to switch focus really quickly as well. There is no time to meander from one task to the next. Once you switch to the next thing you have to be in it right away.

I enjoyed answering some questions about prototyping and Product Management in startups from the nice folks at Justinmind recently. Among other things I got an opportunity to share my thoughts about a particular phrase we hear a lot about Product Managers, one that I think is quite dangerous for our profession…

What kind of challenges and opportunities face Product Managers in a software development context?

I think the Product Management role is still incredibly misunderstood (and misused). I’ve never liked the “We’re like mini-CEOs of the Product” thing you often hear. Any metaphor you come up with that implies a hierarchy (such as air traffic controller, shepherd) gives Product Managers an incorrect view of themselves as The Boss™, and serves only to alienate teams.

We might be the final decider on some issues, but it’s not because we’re “above” the team. It’s because our jobs are to know about user needs, business goals, technical needs, and how all of it comes together in a successful product. Our jobs are to listen to our teams in their various roles and make sure that everyone knows what they need to know. And then our jobs are to walk with the team in a direction that everyone understands and agrees on. It’s not “here are your requirements, see you on the other side of design!” We still see way too much of that in the industry.

Until we change that perception, which will require a change in attitude from us as product managers, we’ll continue to be viewed as obstructionists in many companies. Maybe the best metaphor to use is that we’re servants. Servants to our customers, our teams, and the product. That’s the opportunity we have to bring value.

You can read the full interview here.

Charles Duhigg has a long feature in the New York Times called What Google Learned From Its Quest to Build the Perfect Team. It includes a summary of really fascinating research on the core elements of a healthy, productive team:

As the researchers studied the groups, however, 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.” On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. “As long as everyone got a chance to talk, the team did well,” Woolley said. “But if only one person or a small group spoke all the time, the collective intelligence declined.”

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. One of the easiest ways to gauge social sensitivity is to show someone photos of people’s eyes and ask him or her to describe what the people are thinking or feeling—an exam known as the Reading the Mind in the Eyes test. People on the more successful teams in Woolley’s experiment scored above average on the Reading the Mind in the Eyes test. They seemed to know when someone was feeling upset or left out. People on the ineffective teams, in contrast, scored below average. They seemed, as a group, to have less sensitivity toward their colleagues.

So, effective teams are built on equality and empathy. Seems terribly obvious, of course, but I feel like very few teams actually live these values. We can do better.

Maria Konnikova digs into the research on How People Learn to Become Resilient:

[Developmental psychologist Emmy Werner] found that several elements predicted resilience. Some elements had to do with luck: a resilient child might have a strong bond with a supportive caregiver, parent, teacher, or other mentor-like figure. But another, quite large set of elements was psychological, and had to do with how the children responded to the environment. From a young age, resilient children tended to “meet the world on their own terms.” They were autonomous and independent, would seek out new experiences, and had a “positive social orientation.” “Though not especially gifted, these children used whatever skills they had effectively,” Werner wrote. Perhaps most importantly, the resilient children had what psychologists call an “internal locus of control”: they believed that they, and not their circumstances, affected their achievements. The resilient children saw themselves as the orchestrators of their own fates. In fact, on a scale that measured locus of control, they scored more than two standard deviations away from the standardization group.

Daniel Zacarias has some tips for How to Deal with “Sinatra” Stakeholders—those people (usually HiPPOs1) who only want to design and build things their way. At the end he makes an important point:

These stakeholder attitudes don’t come out of the blue or from malfeasance. They result from misalignment and even when you can’t change your entire organization, you can definitely affect change around your product.

This is something I constantly have to remind myself about. If someone isn’t buying into our vision or “getting” the design, it’s not their fault. It’s ours. It is our responsibility to bring people along on the journey. We can’t blame them if they come into a project context-less and then ask difficult questions.

---

1. Highest Paid Person’s Opinion ↩

Courtney Martin’s essay on The Reductive Seduction of Other People’s Problems really got to me. She makes the case that instead of traveling all over the world to solve social problems in other countries, we should focus on the problems at home:

The reductive seduction of other people’s problems is dangerous for the people whose problems you’ve avoided. While thousands of the country’s best and brightest flock to far-flung places to ease unfamiliar suffering and tackle foreign dysfunction, we’ve got plenty of domestic need. […]

I think there is tremendous need and opportunity in the U.S. that goes unaddressed. There’s a social dimension to this: the “likes” one gets for being an international do-gooder might be greater than for, say, working on homelessness in Indianapolis. One seems glamorous, while the other reminds people of what they neglect while walking to work.

Her proposal is worth considering:

There’s a better way. For all of us. Resist the reductive seduction of other people’s problems and, instead, fall in love with the longer-term prospect of staying home and facing systemic complexity head on. Or go if you must, but stay long enough, listen hard enough so that “other people” become real people. But, be warned, they may not seem so easy to “save.”

In my latest column for A List Apart, called The Distance to Here1, I discuss a theory I’ve had for a while now:

The larger the distance between people who build a product and people who make decisions about the product, the harder it is to make a good product.

The post goes into detail on how I think companies can continue to make good products as they grow.

---

1. Anyone else old enough to get the reference? ↩