How a Product Manager Can Empower Various Team Members

The exact definition of a "Product Manager" is notoriously elusive; it vastly varies from one company to another. Some companies will assign a "full-stack role" to the Product Manager where they are identified as the linchpin between product, development, sales and marketing. In this case, they are ultimately running the show like a mini-CEO.

Some other companies, on the other hand, will establish a smaller playing field for the PM by limiting their circle of influence to engineering and design teams, holding them accountable for just engagement and churn. But regardless of what flavor of Product Management you belong to and what you're held accountable for, one thing will stay the same for certain - your success at the job depends how well you execute your responsibility to empower team members around you to succeed at their job.  

In the span of 10 years in the field, I've seen a spectrum of product managers and invariably, their success or failure could be tied to how well they ensured that other team members were setup for success. Sure, their personal experience, expertise, intellect and aptitude to learn directly affected the strength of their product strategy but it only correlated well with their performance as an individual. Leading a product to achieve its business objectives was always about how well they "served" their key team members.

Sure, the "influence without authority" mantra is often brought up as a shield, citing it as a limitation of how much a Product Manager can dictate terms. But it's not about how you much "command" a product team to perform a certain way. It's how well you align your expectations with them and equip them with the necessary information, knowledge and process to set them up for success and ultimately, make a positive impact on the product.

How about a quick analogy?

 Imagine a football field consisting of 100 yards. Let's say the goal of the Product Manager is to ensure each member of the team runs the length of the field to the opposite end zone in a straight line.

Now, Product Managers fall into one of these three categories. (I've been guilty in being in some of the non-desirable ones at some stages of my career too)

The first mode of operation is "Pseudo-Authority". Here's when a Product Manager makes demands of the player, instructs them on their mission and sends them on the field to get the work done in a timely fashion. They then impatiently wait on the other endz one in hope that their player makes the distance in a straight line.

(the yellow stars above indicate the position of the Product Manager, the red line shows the path the player took)

More often than not, the player wavers from the straight line and the outcome is far from desirable....and what follows is a combination of reactionary firefighting, frustration, disappointment and accountability.

The second method often employer is the well-known "Micro-Management" approach. Here, the Product Manager accompanies the player on to the field in an attempt to escort them through the field without any hiccups. The effects of this "handheld" approach are that it suffocates the player and ultimately kills their creativity and determination somewhere at the halfway point; the PM now is essentially dragging a lifeless zombie.

(the yellow star and line show how the Product Manager escorted the player. The red line shows an active player; the gray denotes when he/she switched off from the objective)

The reality is that the Product Manager is carrying most of the weight on his/her shoulders and is simply failing to leverage the player's individual ability to his/her advantage.

And here's the more balanced perspective that's called the "Empowerment Play": in this scenario, the Product Manager gives clear instructions to the player but also goes into detail about the larger picture, why the straight line is important, describes the success check points, shares tips on how to stay in a straight line, provides learning material and points to valuable references. The Product Manager walks alongside the player till the 10-yard point to build some positive momentum and then trusts the player to do the rest of the job. The Product Manager then touches base with the player at the 25-yard, 50-yard and 75-yard checkpoint to apply any course corrections if needed. And when the player is bringing it home, the Product Manager receives them at the 95-yard line and gives them a hand to cross the finishing line.

(the yellow stars depict the PM checkpoints, the red line shows the player's line of play) 

Too abstract? Let's explore this with some concrete examples.

Responsibilities towards the Engineering Team

Here's how someone practicing Pseudo-Authority would operate: 

• Shares the spec of a new feature for allowing users to subscribe for a newsletter.
• Asks project manager by when we can expect to have the feature in production.
• Asks to review the feature a day before the release.
• Discovers 10 problems in the implementation, 3 of which were due to ambiguity in the initial spec. Will claim it as a lapse in engineering.
• Demands the feature still be released on time.

 Here's what a Micro-Manager would do:

• Shares the spec of the new feature
• Asks project manager by when they can expect the release
• Goes to individual developers every single day and asks them to show what work has been achieved
• Inspects code and suggests improvement.
• Questions architectural decisions. Shares future vision to prove that architecture is too limiting.
• Provides detailed feedback on in-progress areas still being worked on.
• Sits next to the release team to see the production happen before his/her eyes

 And this is the Empowerment Play:

• Shares a detailed spec of the feature with clarity on scope and objectives
• Conducts a kick-off meeting with the development team. Describes future vision, goals and objectives of the feature. Suggests what to keep in mind when data modelling for the feature and what to track to assess performance.
• Fields questions from the team. Defines what success looks like.
• Provides supporting material like site copy, email copy, wireframe designs. Provides examples from reference sites to show how others are doing it.
• For a 10-day task, checks in at Day 2, Day 5, Day 7 to see if the team needs any clarifications. Progress update is also taken. Feedback is consistently shared.
• Works alongside QAs to test primary flows of the feature.
• Notes down bugs, changes and tweaks that need to be made. Has a discussion with the project manager to prioritize them. Moves non-essential tasks to the backlog for the next sprint.
• Acknowledges the release and thanks the team.
• Shares with the engineering team 1-2 weeks after the feature is released to describe how well it performed and action plan to improve it as time goes by. Fields suggestions, comments and feedback from the team.

The same applies to every other team role as well.

With Designers:

Empowerment players:

• Give clarity on the end goal
• Highlight the metric that is the most important to take care of
• Prioritize design components
• Gives references of other products and explains what can be done better
• Provides skeletal wireframes with annotations
• Work with designers to create some initial rough mockups to decide on a direction

...as opposed to asking them to make a design that looks nice and functions well and come up with 3 choice variations in a day's time.

With Quality Assurance:

Empowerment players:

• Share documentation to describe what success looks like
• Invites them to the kickoff meeting with the development team
• Entertains their suggestions on improvements in UX and UI and tries to incorporate that feedback back into documentation
• Helps build a few test cases (for some core primary flows)
• Has a separate quick meeting before release to help review test cases and highlight the ones that are super essential
• Works alongside QA for a bit to test some of the flows and share feedback
• Prioritize bugs, identify problems which are non-issues and elects areas that can be moved to the next sprint backlog

 ...as opposed to handing them a spec and testing the release on production and sharing a long, lengthy note on what use cases they missed.

 With Marketing Team Members:

Empowerment players:

• Conduct short meetings before and after the release of the feature
• First, share what pain point they are trying to solve for the user
• Summarize the value proposition in 2-3 sentences
• Walk them through the feature that has been developed and define the scope
• Share roadmap items that connect with the feature and will further enhance it
• Field questions from their side and makes clarifications
• Volunteer to read some of the marketing copy of their campaigns and provides timely feedback
• Celebrate successes

 ...as opposed to sharing a brief on what the feature is about and expects them to update the marketing site, integrate it in their acquisition pitch and drive awareness to existing customers

With Sales Team Members:

Empowerment players:

• Share what pain points a feature helps solve for the user
• Define the audience this particular feature will help the most
• Prepare a list of objections that might be thrown from clients and shares potential answers for them
• Deliver a detailed training session to the sales team, records the session and shares the link
• Field questions, offer solutions
• Create a channel of communication where sales members can keep asking questions, providing suggestions and collaboratively create an objection handling document
• If it's a product or an upsell feature, assist certain sales members to client meetings and help evangelize the offering to the client and answer any technical queries
• Celebrate successes

...as opposed to just sharing a brief on what the feature is about, delivering a training, positioning the feature as "take-it-or-leave-it" and being reluctant to entertain sales suggestions and client opinions.

With HR:

Empowerment players:

• Ensure they define the goals of what the person has to achieve
• Explain what daily activities will look like in a draft job description format
• Mention what essential "soft" traits the person needs to have e.g. leadership, communication skills etc. to succeed
• Share "recommendations" on experience levels, educational qualification etc.
• Provides actionable feedback when shortlisted candidate profiles are shared
• Makes time available for timely interviews
• Shares back detailed interview notes to help HR move forward and also incorporate feedback on future candidates
• Work alongside HR to create employee onboarding plan for each incoming hire
• (Bonus) sift through the network and share a couple of profiles that would serve as a good reference point

 ...as opposed to simply asking the HR to hire a Marketing Manager with experience in PPC and Email Marketing with 5 years of experience and telling them to get the position filled within 30 days.

Is it feasible to expect so much?

It might seem that assigning so many expectations to a Product Manager would be unreasonable and awfully time-consuming. The counter-argument is that if the time is not invested, then it has to paid in manifold later on when rectifications need to be made (usually by this time, each correction is far more expensive to make).

It takes immense practice to learn how to strike the balance between minimal guidance and over-directing a team member. The key is to keep asking whether there is something you, as a product manager, could share with the team member that would help them on their journey to execute the task? How can you add value? Are your instructions clear and defined? Is any of this ambiguous? Do you have clarity on the challenges that they might face in completing a particular task? Have you addressed them effectively?

And remember:

Product Managers, in a lot of ways, have to channel the same empathy they are expected to have towards the consumer to all of their supporting team members as well to ensure the success of the overall product.

So, what kind of player are you? Are you on board the empowerment bandwagon in your role as a Product Manager?