Chapter 3. Showing Up Curious

When I started working as a product manager, I was incredibly intimidated by data scientists. I was never a “math person,” and these folks were writing up complex equations on whiteboards and making nerdy in-jokes that I desperately wanted to understand. I spent the first year or so of my career as a product manager tiptoeing deferentially around the data scientists in my orbit, never really understanding what they did and assuming that they had no interest in explaining it to me. After all, these were, like, actual geniuses. Why would they want to waste their time taking me to data science preschool?

After a year or so, it became clear to me that this approach was making it much more difficult for me to do my job. Even though they weren’t on my immediate team, our data scientists had a lot to offer, and I didn’t even know what to ask for. So, in a moment of caffeine-fueled anxious desperation, I emailed somebody on the data science team to see if he would be willing to chat. It was a short email, that went something like this:

Subj: Coffee?

Hey! Hope your week is off to a great start. I’m really curious to learn a little bit more about what you’re working on—are you free to grab a quick coffee this week? Maybe Thursday morning?

Thanks!

I hit “send” and logged out of my inbox in an attempt to distract myself from creeping anxiety and embarrassment. Had I just done something totally weird?

Within a few hours, I got a straightforward response that included none of the overcompensatory enthusiasm of my original message. And that Thursday, we had our coffee—I’m hesitant to even call it a “meeting.” It was a great conversation that revealed both some mutual interests (turns out we’re both musicians!) and some important insights about our work together. It turned out that this data scientist felt just as alienated from the product team as I did from the data science team. It was difficult to admit, but this disconnect was entirely of my own making. In assuming that other people had no interest in what I was doing, I had created the impression that I had no interest in what they were doing. Oops.

In this chapter, we discuss the single most important dimension of a successful product manager’s attitude and approach: curiosity.

Taking a Genuine Interest

When people ask me how product managers can earn the trust of developers, or data scientists, or compliance officers, or any other person with a specialized and distant-seeming expertise, my answer is: take a genuine interest in the work that they do. “I’m curious to learn more about the work that you do” is the most powerful sentence at your disposal as a product manager, whether it’s your first day or you’ve been working in the field for decades.

A simple gesture of curiosity can have an enormous and immediate positive impact on your work as a product manager. Here are three critical things you can accomplish by reaching out to your colleagues from a place of openness and genuine curiosity:

Learn “hard skills” contextually

No matter how much time you spend trying to learn “hard skills” such as data science or programming, you will never keep pace with the people whose actual job is to use those skills. You will learn more by asking those people about their work than you will by reading a book about data science or Python and then showing up to work trying to “talk the talk.” Learning about hard skills from the people tasked with applying those skills ensures that you will learn about the specific hard skills that are most important to your organization right now—and that you’re doing so in a way that directly strengthens your bond with technical folks.

Note that this approach applies equally to nontechnical specialized skills. For example, I’ve seen this strategy work very well for product managers who need to work with compliance experts at financial services companies. As a product manager, it is exceptionally unlikely that you will become an expert in compliance, but getting to know and understand the folks who are experts in compliance will help you make better-informed decisions and work more closely with their teams.

Build bridges before you need something

If you only talk to people when you need something from them, nobody will be particularly happy to hear from you. The relationships you build with people when you don’t need something from them will be there when you do need something from them, and the things you’ve learned about each other will help you collaborate more effectively.

Expand your network of influence

The people you reach out to each have their own networks of influence—people they talk with “off the record” and from whom they are willing to call in favors when needed. By reaching out to folks in your organization beyond the people you are working with every day, you’re building a far-reaching network that might lead you to places you never expected.

In my experience, it has been exceptionally rare that “I’m curious to learn more about the work that you do” has been met with anything other than gratitude and some sense of relief. And in the rare instances where these inquiries have been met with mistrust or skepticism, it has provided a jumping-off point for a difficult but critical conversation about mistrust and skepticism in the organization at large.

So, take a moment and reach out to somebody who is not an immediate member of your team. Maybe it’s somebody whose team you have worked with in the past, but you are not working with at the moment. Maybe it’s somebody whose role you don’t fully understand, but you think could have an impact on your work sometime in the future. Maybe it’s somebody from a far-off corner of the organization whom you met during an offsite or other company event. There is no wrong person to reach out to—any step toward expanding your network of knowledge and influence is a step in the right direction.

Cultivating a Growth Mindset

In her pioneering work on learning and success, Stanford psychology professor and author Carol Dweck posits that people operate in either a “growth” or a “fixed” mindset. When operating in a growth mindset, people see failures and setbacks as learning opportunities. When operating in a fixed mindset, people see failures and setbacks as negative reflections of their intrinsic worth. People operating in a growth mindset are able to approach skills and subject matter that are new to them as an opportunity to, well, grow. People operating in a fixed mindset feel threatened by skills and subject matter that are new to them.

If you have spent most of your life being an overachiever, as many product managers have, it is excruciatingly likely that you are operating in a fixed mindset. Why? Because many overachievers find success not by growing their skills in areas where they struggle, but rather by avoiding these areas altogether. Fixed mindset overachievers dismiss as useless, irrelevant, or counterproductive the things at which they do not immediately excel. By way of self-incriminating example, I avoided taking any music theory courses in college because “formal training takes the soul out of music.” But in reality, I avoided these courses because reading music was something that I found to be really challenging. It was easier to create a self-serving lie around a kernel of defensible half-truth than it was to simply admit that there were areas where I could stand to grow my knowledge and skills.

As a product manager, you likely cannot succeed if you are operating in a fixed mindset. There are simply too many new things that you will need to learn, and you will not even know what these things are until it is too late for you to give yourself an overachiever-y head start. Like it or not, you will need to acknowledge and address the limits of your own personal knowledge and skills if you want to do right by your team and your organization.

For example, imagine two product managers are facing the same challenge. They have spent the last couple months working on new mobile products for a large financial institution. The week before launch, both product managers receive a letter from their compliance department that their projects are not approved to move forward.

The first product manager is operating in a fixed mindset. He receives the letter and goes red-faced with embarrassment and anger. He whispers furiously under his breath, “my team is going to f****** hate me for this.” But he also knows that his team has been through this before, and will probably be more than willing to lay the blame squarely on those jerks in compliance. The next day, he gathers his team together. “Well, guess what? Those jerks in compliance have done it again. Say goodbye to the last six months of work.” The team is crushed. The product never launches.

The second product manager is operating in a growth mindset. She receives the same letter and immediately sends an email to the compliance department. In a nicely worded message, this product manager explains that she wants to make sure that she understands why exactly the compliance department could not approve this product. The next day, she has a meeting with the compliance officer who wrote the letter. The product manager—who has no legal background—asks the compliance officer to walk her through the exact process by which compliance evaluated the product. In the course of this walkthrough, the compliance officer reveals that there was one specific user interaction that compelled them to reject the entire product. The product manager proposes an alternate approach, and both parties agree. The team learns an important new consideration for developing future products. And the product launches the following week.

If you are going to succeed as a product manager, you must be willing to engage deeply with people whose knowledge and expertise in a specific area greatly exceed your own. If you want to be the smartest person in the room, you probably will not succeed as a product manager. In fact, if your first impulse upon walking into a room is to defensively compare your own perceived intelligence to that of the people around you, you are probably not going to succeed as a product manager.

The Gift of Being Wrong

Truly cultivating a growth mindset means being open not just to the unknown, but to being flat-out wrong. The most rewarding compliment I ever received as a product manager immediately followed one of the most difficult and contentious meetings I’ve ever attended. “You know,” said a senior leader as we walked out of the conference room, “you walked into that meeting advocating for one path forward, and by the end of it you were advocating for something totally different. I’m really impressed by how you let yourself be convinced by the other people in the room.”

Just a few years prior, this comment would have infuriated me. I had gone into a meeting with senior leaders to present my vision for the product, and by the end of the meeting I was effectively advocating for someone else’s vision. In a very real sense, I abdicated any claim I might have had to being the company’s “product visionary.” But I also demonstrated to senior leadership that I was willing to go with the idea that seemed best for the company, even if it wasn’t my own. For one of the very first times in my career, I had accepted the gift of being wrong.

This is not to say that product managers should be spineless and just defer to what other people want. For being wrong to be a gift, you need to know exactly why you’re wrong—and choose to prioritize the overall goals you are working toward above your specific plan for achieving those goals. If somebody else suggests an approach that better reflects what you are collectively working toward, aligning with that plan gives you a chance to reinforce the entire group’s commitment to your goals. And, as we discuss throughout this book, clarity around goals is perhaps the single most important organizational prerequisite to a product manager’s success.

Spreading Curiosity

Good product managers bring curiosity and openness to their everyday work. Great product managers turn curiosity into a core value for their team and their organization. Genuine curiosity can be contagious, and naturally encourages people to collaborate more closely and better understand each other’s perspectives. In a curious organization, negotiations between stakeholders feel expansive rather than combative, and deep conversations about goals and outcomes feel like an important part of your work, rather than an impediment to doing the “real” work. Curiosity makes everything seem more interesting and less transactional.

The first key to spreading curiosity is to model it yourself, relentlessly. “I’m too busy right now” is a very dangerous sentence for product managers. If your colleagues are taking the time to come to you with questions and thoughts, however trivial-seeming those questions and thoughts might seem, encourage that behavior. Similarly, if you’re interested in something that a colleague is doing, don’t feel bad about asking for some of that person’s time—be confident in the knowledge that time spent learning from your colleagues is time well spent. And when you do need some time to go heads-down on a project and work in relative isolation, avoid saying things like “I just need a tiny bit of time to myself so that I can actually get something done.” Remember, the time you spend communicating with your colleagues is time spent getting things done.

Another great way to spread curiosity is to cross-pollinate knowledge and skills among your colleagues. If you’re working with a team of designers and developers, ask them what other skills they’d like to learn. Maybe you have a designer who wants to learn more about frontend development. Or a web developer who wants to better understand the UX patterns of mobile apps. Make it as easy as possible for people to learn from one another as part of their day-to-day job. I’ve seen some product managers go so far as to declare one day a week “cross-functional pairing day,” in which designers and developers (or developers working in different technical systems) pair with each other for the explicit purpose of expanding their knowledge and skills. Formal practices like this make it clear that you are explicitly valuing curiosity and knowledge sharing among your team.

Finally, organizing “demo days” and other opportunities for product teams to present their work to the organization at large is an incredibly valuable way to spread curiosity far and wide. I’ve been truly amazed to see how a team’s work transforms when they are tasked with presenting to their colleagues once a week—people work harder, collaborate more closely, and begin asking questions about their own work in anticipation of those they will receive from their colleagues. The assumption that, for example, people in marketing couldn’t possibly care about a highly technical product is replaced by the question, “How can we present this highly technical product to all of our colleagues in a way that seems interesting?”

Summary: Curiosity Is Key

Every organization is different, every team is different, and every individual is different. As a product manager, it is your responsibility to communicate, align, and translate between people who might have wildly diverging skill sets, goals, and agendas. The only way to do this is by taking an open, genuine, and curious interest in the work that they do. Learning about specialized skills directly from the people who use those skills within your organization is always more valuable than learning about them from a book or a Wikipedia. Indeed, every single channel of open and curious communication that you can establish is an important step toward the success of your team. We’ll discuss this more in Chapter 5, “The Art of Egregious Overcommunication.”

Your Checklist:

  • Reach out to folks in your organization, ask to meet up for coffee (or over Slack, Skype, or whatever other remote collaboration tools you might use if you are not colocated), and say, “I’m curious to learn more about the work that you do.”

  • Be just as vigilant about getting to know people outside of your immediate team, and take the time to understand their goals and motivations before you need something from them.

  • Cultivate a “growth mindset” and open yourself up to learning from people whose skills and knowledge exceed your own.

  • Resist the urge to avoid situations that test the limits of your abilities or knowledge.

  • Embrace “the gift of being wrong” by choosing the plan that best meets your organization’s goals, even if it is not your plan.

  • Shake up the work that people are doing and cross-pollinate knowledge and skills to keep your team curious and actively learning.

  • Model the value of curiosity for your team and organization.

  • Avoid saying “I’m too busy to deal with that right now” and other things that might implicitly discourage your team from asking open and curious questions that don’t have an immediate transactional value.

  • Encourage your colleagues to learn from one another, and pair up folks who want to learn about one another’s skills.

  • Organize “demo days” and other opportunities for product teams to share and discuss their work with the organization at large.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset