guest blogger product management

How to Lead without Authority (a Product Manager POV)

Guest Post by: Cornell Pineda (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Vikas Batra]

When I started my current product role last September, I had a textbook definition of what makes a great product manager. In my view, he or she should have these main skills: manage the release process and roadmap prioritization, be able to suggest technical solutions during discussions with developers, and be knowledgeable in all the tools and terminology of the Agile process. I interviewed for the Product Mentor program to participate as a mentee and receive guidance on how to gain these skills. But on day one of the program kickoff, I already began to re-assess my initial definition!  From my participation in the program and the lessons I’ve learned from my mentor, I now have a wider perspective on the challenges that come to every product manager. While each challenge is unique, I believe the main challenge that’s common to anyone in this role is how to lead a team without authority.


As Product Owner, I face these two monumental tasks: manage stakeholder expectations that constantly shift and lead a scrum team to deliver a sprint on time and with quality. Initially, leading these two groups without authority was challenging because I applied tactical approaches to solving our issues. Through my mentorship, I learned that a good product manager should have a balanced set of tactical and strategic skills. But what makes a great product manager is the ability to communicate effectively, which is a soft-skill often overlooked as a must-have for any product role. Yet communication is the bridge that connects the tactical and strategic approaches to solve a problem. This has been the most crucial skill I’ve had to hone to lead stakeholders and team members without authority.

First, I adjusted my communication style with the stakeholders. They are very busy executives who demand more features be built and delivered faster. On several occasions, stakeholders changed priorities in the middle of the sprint while the Scrum communicateteam already started development. Without questioning their request, I would accept the change in priorities without considering the impact to the current sprint’s delivery or the team’s feedback. The results were not always positive. The quality of the code suffered while features were delayed. And I had to explain why the team did not meet the sprint’s goals.

To level set stakeholders’ expectations, I started becoming more firm and transparent in my communication style. First, as Product Owner, I started protecting and respecting the team’s feedback when they were asked to change the scope or priorities during the middle of the sprint. Then, I gathered data that represents the risks incurred and areas impacted, including delaying delivery of certain features. As I presented this to stakeholders, they were able to clearly see the impact of switching priorities. As a result, they made more informed decisions. While stakeholders often have the last word on a decision, a Product Owner should still be empowered to lead them without authority through transparent communication. By presenting the right data and it’s impact to short-term and long-term goals of the product, I’ve learned that decision-makers appreciate when they can concretely see the trickle-down effect of their decisions.

On the other side, my initial challenge in leading a scrum team without authority lies in the team logistics. Our team is spread over three locations – NYC, North Carolina, and Ukraine. I established my relationship with the team mostly through web conferences. In my situation, I was limited to lead effectively due to the physical gap. But one way I established rapport with the team was having one-on-one conversations. It wasn’t until 6 globalmonths into the project when the entire team and I finally met in person and held our first retrospective in the same room in the Ukraine offices.

All the assumptions I developed up to that point were completely scrapped when I had real-time conversations with each team member. My mentor emphasized the value in asking questions, such as what motivates them and what do they enjoy doing or not, during these one-on-one’s. This helped build a stronger foundation in my ability to lead. My mentor said, “As a leader, you don’t choose your followers. Your followers choose you.” It is a statement that will become part of my refined definition of a Product Manager.

An added value of face-to-face interaction is the chance to form a more honest sense of each team member’s personality type. A team member’s personality can be perceived inaccurately over web conferences or telephone calls since we can’t observe a person’s body language. In one of the Product Mentor Live Talks, my mentor described how to communicate with team members according to their personality types (color energies). When you try to understand how a person receives and reacts to information, a product manager can adjust how to communicate in certain situations with certain team members.

For example, a Senior Developer in my Scrum team is very vocal during our refinement sessions. He questions every detail of the acceptance criteria in the story. This takes time away from reviewing more stories during the hour-long session. With my mentor’s suggestion, I adjusted the way I lead the refinement calls by understanding the developer’s personality type, or more specifically, how he likes to receive information. First, he and I were able to clarify his reasons for asking detailed questions, which were motivated by covering edge cases during development. Our conversation gave me insightful feedback because I learned that he needed more details of edge cases in the acceptance criteria. Understanding a team member’s personality type helped me lead our refinement sessions more efficiently.


In closing, the most important lesson I’ve learned over the past year as a Product Owner is to adjust how and what I communicate, in order to lead a team without authority. By appreciating every team member’s contribution and truly understanding what motivates them, I established a solid relationship that helped me lead a dynamic team who supports my decisions. And through communicating with transparency supported by the right data, I was able to influence stakeholders as they made informed decisions that impacted the Scrum Team’s success. With the help of my mentor, I’m able to re-write my definition of this important role — a product manager is more than a tactical or strategic thinker, a great product manager is a great communicator.

About Cornell Pineda

5p15 - Cornell - IMG_9321Cornell Pineda is a Product Owner based in New York City. He honed his leadership skills during his participation in the program. He will continue to seek and share new lessons learned in order to expand his product management experience.



More About The Product Mentor

TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

%d bloggers like this: