In nearly every interview I’ve ever had, I’ve been asked about leading through influence. As I’ve mulled over this question throughout the years, I’ve realized my strategy for accomplishing goals through influence is nearly identical to my managerial style with direct reports.
Good leadership is good leadership, regardless of if you’re responsible for someone’s quarterly review or not.
As a project/program/product manager, you’re in the interesting (sticky? frustrating?) position of being accountable for results that come from work that you are not responsible for producing. So what do you do to achieve the results you need without direct authority over the team executing your plan?
It Starts with Relationships
When you join a new company, team, squad, pod, whathaveyou, focus first on building relationships. Why? Because you don’t work with robots, you work with intelligent professional people who don’t appreciate someone coming in and telling them what to do.
The single most important way you can spend your first few days is by listening, learning, and building rapport.
Doing this is not difficult, but it is time-consuming. Commit to a 30-minute chat with every member of the team, regardless of role. In these meetings, there is no agenda, except to introduce yourself and get to know the person not as your new colleague, but as a multi-faceted human being.
This is the time to ask about hobbies, past jobs, where they grew up, and their interests. I also ask what their experience has been working with product managers before, because as the tech has evolved in the last decade, so has the role, and people’s perceptions of it. Another insightful question is what about tech do they like the most? For engineers, what languages do they prefer? Does the designer love user testing more than prototyping? Good context to have as you learn how to best motivate each person.
Other great level-setting questions in this type of conversation are things like:
- What do you think is the best/worst thing about our product?
- If you could remove one feature, what would it be?
- What do you think is the biggest problem we need to solve?
- What do you think is the first problem we need to solve?
This is a great way to gather input quickly from every member of the team and uncover where there are commonalities and where the sticking points are going to be.
It’s Not too Late
If you’re not new to the team, but are realizing you need to build a deeper connection with your teammates, never fear. It’s not too late. Go on this same kind of listening tour, but in a more casual way. Ask one person out to coffee each week. Ask what’s on their mind, what they haven’t brought up in team meetings, or what they think the team is overlooking.
Share your own thoughts, perhaps a bit less filtered than you might typically be. Remember, your goal is not to interview people but to build a connection with them, and that requires some vulnerability on your part. Put in the work and it will pay dividends.
Take Them on the Journey
When you’re introducing a new product, feature, strategy, optimization — it really doesn’t matter — take your team on the journey. It’s so easy for product managers to forget all the steps it took to get from noticing an opportunity to the proposed solution. Just think about it — you started by observing metrics perhaps, or user behavior. You went on a hunt to explain what you were seeing. You tested your theories and proposed a solution. You iterated on the scope of the solution, and built buy-in from the impacted business units. You went through multiple revisions of ever-increasing fidelity of designs. You consulted with the engineering leaders to get them thinking about the problem and how you want to address it. You adjusted based on their feedback.
And now it’s time to bring the larger team into the conversation. Whew. You’re ready to talk through minute implementation details, while the majority of the team is just now hearing that there’s a problem or an improvement you can make. If you jump right into implementation, you miss the chance to surface important questions and alternative views from the team. You also miss a crucial opportunity to build a shared sense of purpose and goals with the team.
If you skip this step, you’ll end up with a team that may follow your direction because they trust you, or because you’re the loudest voice, or just out of habit, but you’re not going to get their best work. You’ll get someone who implements what you specified without a lot of extra thought, not because they are lazy but because they don’t have enough context to create the best solution.
You may also get a team that rebels and refuses to work on something they disagree with. And then you’re in a real pickle. You can pull back from the brink there, but it takes a lot of 1:1 conversations with the leaders of the rebellion and a lot of shared context creation that can be avoided by putting in the work ahead of time. This is not a step to skip, even if your timeline is tight.
Defer to Expertise
You’re not the best at everything. You probably already know this, but sometimes it’s nice to have a reminder. Everyone on the team has different strengths and their perspective is crucial to developing the best possible solution.
As a product manager, you’ll be constantly faced with decisions and trade-offs both big and small. While the final decision may lay with you, leading through influence requires you not just to involve the experts but to get out of their way. If someone asks you a question that you’re not qualified to answer, don’t respond by default. Send it to the person who knows best. Don’t take credit for someone else’s work (physical or intellectual).
Trust people to do their best work and most of the time they will. Conversely, take control of decisions in the face of more experienced team members, and not only will they not do their best work, they may refuse to follow you altogether.
Be Willing to Change Your Mind
One of the most important qualities for a leader, especially one without commensurate authority, is humility. Humility to invite others to question you, humility to admit that you don’t know all the answers, and humility to change your mind in the face of new information — or better ideas generated by the team!
It’s especially powerful when you’re in a position of leading a team through influence. It shows that you have the product’s best interests at heart. Changing your mind when compelling ideas/information comes to light is the single most powerful way you can reiterate your priorities to the team, the priorities of your users, your business goals, and your team. It shows that doing right is more important than being right.
Don’t be a Dipper
A friend related a story of her son’s kindergarten class and how they were learning about “dippers.” A dipper is someone who constantly “dips” into someone’s “love bucket” — a taker and not a giver. I’ve also called this withdrawing and depositing to an “emotional bank account,” but it’s not as cute as a love bucket.
As a PM, you can’t afford to be a dipper. Call in favors sparingly, and be aware of the state of your shared bucket with each person. Don’t misunderstand — there will be times when you’re asking the team to go above and beyond, to follow a hunch rather than a clear path, to put aside the work in progress for an emergent need.
The difference between a team that rallies behind you and the team that drags their feet is a team whose buckets are full and who can tolerate a dip.
Leading by influence, without direct authority over people, is all about shared trust. Since you have the “carrot” but not the “stick,” motivating people becomes an exercise in establishing common purpose. That purpose comes from bringing the team along your thought process so they can do their best work — and then getting out of their way. Keep an open mind, let the right people make the decisions, and keep an eye on how much you’re investing in individual relationships, so you’re strong enough to withstand the occasional withdrawal.
- The Power of Good Storytelling: Building Trust as a Product Leader by Alexandra Edelstein
Originally published at Ashley Wali | Product Management Blog.