The most valuable Product Manager skill (collaborating, influencing, and working with others)

  • by

What is the Single Most Important Product Manager “Skill”? (Answer: Influencing, Collaborating, and Working with Others)

In light of an Amazon company-wide Product Management panel that I sat on last week, I wanted to share how collaborating, influencing, and working with others is essential to succeeding as a Product Manager.

Why is influence and collaboration important for Product Managers?

A Product Manager is a fascinating position. While a product’s vision owner, Product Managers have surprisingly little bestowed and mandated authority. She or he must rely on “influence without authority” to lead designers, developers, and business to build the product. (Refer to Appendix 1 for a more detailed description of Product Management responsibilities). Almost all of these other executors lie outside PM’s authority and in almost every case, expertise. For example, within my team, I define the roadmap for a software team that reports to a different senior manager.


If you are non-technical and lack direct authority, how can you establish a strong working relationship and set direction for hyper-technical software developer engineers?

Early in my Product Management role, I wanted to launch a number of new data-source experiments to expand our product usage. I worked for several days straight to document my lofty plans and scheduled a document review. I was really excited to share my vision … and in the meeting, my ideas were promptly rejected. I still remember talking and feeling the palpable lack of focus from developers. My visions of grandeur were immediately dismissed as not plausible.

How does someone who is not formally-technically trained and does not have direct authority tell software developers what to do? I needed to adjust. By providing real value and working with developers, I created strong working relationships to together chip against my originally lofty vision, launch over 10 data-source experiments, and increase our product usage by 14% Below are some major lessons for how I did this.

First: Contribute by providing valuable knowledge and perspective that developers may not have.

A great way for Product Manager to contribute is by providing context and the bigger picture. Software devs are impressively smart, but many hyper-focus on details and fixate on “how” (instead of the “what, why, who”. Appendix 1). Many will not ask “should we build this? Is this actually good for the customer? Will this help our business win?” I found that acting as the expert on customer demands, the business goals, and competitor activity allowed me to guide and influence the product roadmap. Providing perspective and strategic thought to answer the “what, why, and who” questions earns a lot of trust with software developers. Consequently, it becomes far easier to build things with others!

Second: Learn from everyone you work with!

While a Product Manager may set direction, it is very important to learn about software development to know what is actually possible! For example, what is possible with native code vs HTML code? Can we port our video-player through a web-view and still meet latency requirements? How does deployment work? Why is Q/A necessary? Since you’re making decisions, it is really important to be informed execution capacity. Imagine trying to build a house without understanding what a brick is. This is also why many companies prefer PMs with a CS or technical background. To learn, I personally sat with our developers’ daily and weekly sprint. This helped me understand what is/is-not possible. Being curious and understanding a basic comprehension of the target technical craft goes very far in your personal ability to make decisions. Also, this will earn a lot of trust from your developers. (Refer to Appendix 3 for more tips on learning how to earn-trust from technical developers).

Third: Patiently teach.

While I may have originated the data-source project idea, I needed everyone else to believe and co-own this goal/project. Instead of asking the people to do work simply because I said so, I found it far more effective to explain WHY this project was good for our team and HOW it would compliment our team goals. In addition to emails and documents, a lot of this communication happened via meetings or face to face conversations. Personally, many great discussions occurred in our developers daily scrum stand-up. It is important to make the goal a team goal and a team quest, not a personal quest. Developers don’t want to do something for me (and I don’t expect them to); they want to build something that will move the team and the business forward! Frame it like thus, and (patiently) teach everyone why this is good for the team.

If done successfully, a Product Manager unites others behind the vision to create the product. The combination of these three lessons helped me develop relationships with my software developers; together, we’ve done been able to tackle really hairy problems that I could never do myself, such as launch over 10 fairly sophisticated algorithm, launch on mobile devices, expand to over 50 business groups, and many other projects thats increased our product usage five-fold over the last year. Ultimately, a Product Manager is successful if able to unify the rest of the team.

OTHER TIPS: If you want to be a Product Manager, learn how to influence and collaborate!

While a Product Manager owns (and many time crafts) the team’s vision and strategy, the most important input to making this vision a reality depends on a Product Manager’s ability to earn the trust and align everyone else against this idea. Here are some other quick and tangible pieces of advice:

  • Thrive on ambiguity! Here is a secret: even at a huge company like Amazon, it’s all going to be super ambiguous, ill-defined, and messy! The Product Manager must thrive in a ridiculously ambiguous structure. Your goals are to align people in different roles with widely variate incentives to unify and create something that is wins! Be prepared for a mess. People may not want to listen to you. Think about how people work. Something as simple as a weekly touch-base over a month and a half can help three separate teams deliver against their specific inputs. In other cases, generating the support of another team’s Vice President can provide the necessary incentive to align a very far away team. As another example, co-authoring goals with the software team leaders can ensure developers focus on the right projects. Also, be eager and ready to take on the nitty-little-gritty stuff, like sending notes or scheduling meetings.
  • Improve your communication. Get especially good at communicating in your company’s preferred medium. For example, Amazon love documents. Other companies, like Google, may prefer decks. Be able to communicate answers to the “what, why, who” questions. Excellent PMs can sell and convince everyone (especially people who are in different organizations), that their case is the valuable and is worth staffing attention, money, and effort!
  • Develop relationships with people when you may not necessary have an specific/immediate ask. For example, completely outside of work, I built a strong relationship with our lead software developer. We like to discuss product ideology and strategies that we think will win. When it comes to creating a team goal and executing against it, we are very aligned and it is very easy to work together. You’ll need to earn trust — check out Appendix 3 for more details on this.


Appendix 1: What exactly do Product Managers do? / Common Product Manager questions include (What, Why, Who):

Product Managers are responsible for asking and defining the “why,” the “what,” and the “who”, crafting the vision, and delivering against this vision (i.e.: launching the product!). As an example, Product Managers owns a product or feature such as the entire Fire TV experience, or the Dash Button. Personally, I own the customer experience, the strategy, and the vision for Amazon’s short video product under our Video Advertising team. I ask “what, why, who” questions and come up with a very strong vision strategy, and plan to win in this space. For example, below are common Product Manager questions:

  • What are we going to build? (Amazon wants to become a major content and entertainment player. Coupled with our Amazon Video team’s huge licensed and exclusively produced content, what can we build to compliment our goal and penetrate living rooms?)
  • Why do we want to build this? (Would this device further Amazon’s goal to be a major content/entertainment provide? Do the economics make sense? Is this a good investment? Will a living-room presence substantially further our goals?)
  • Who are our customers? (Who will actually want to buy an Amazon specific entertainment/living room device? And given who, what price point can we target? What features do we need for our minimum viable product?)

While some people claim being a Product Manager is like being “the CEO of the product,” others explain “Product Manager …are… essentially a janitor.”

Appendix 2: Who do Product Managers generally work with?

To make this vision a reality, Product Managers sit between design, technical, and business. Given the wide executors, a major Product Management theme is “influencing without authority.”

I personally have 3 general buckets for parties that I work with:
(1) My immediate team of developers, designers, marketing, and operations. These are the folks necessary to actually execute something.
(2) Leadership, involving my direct senior manager, my director, and VP. These folks control head-count and provide air-support against other teams.
(3) Stakeholders and partner teams, such as a partner business team that I would want to launch my video-product on. These folks control other pages that would be very valuable to integrate with.

Appendix 3: Earning trust with technical folks:

One of the biggest obstacles and questions that non-technical aspiring Product Managers face “How do I earn trust from my developers?”. My friend Lulu Cheng wrote a great blog post here about the initial ramp up. One of her key themes is to learn and be very curious about technology Personally, I obtained my own developer box and I personally prototyped a few data sources to power our product. I don’t build any production code, but my understanding goes a long way with earning-trust and communicating with developers! Also, understand that other Product Managers operate differently. A previous product manager in my team used to write a document and then simply throw it over to the software developer manager. There is room for variation as long as you earn the trust of your team-mates and land on a methodology to together iterate and launch.

Appendix 4: Disclaimers about PM roles across different companies

Disclaimer that this will be very variate depending on the organization. For example, I understand that Apple has a very top-down organization where individual teams are very silo-ed. At a startup, I imagine far less stake-holder communication and far more rapid prototyping. Here at Amazon (with its de-centralized “matrix” [technically not matrix b/c single manager] organization structure), I focus a lot of energy on stakeholder team management, roadmap communication to align leadership, ensuring we build something that preserves our current business. Side note: A Product Manager (PM) is also not to be confused with a Program Manager or a Project Manager.