If you look long enough at effective product managers in organisations, you can see a trend among all PMs that are very influential. A lot of people know they have to work through influence, but they are not sure what that is or how to do it. So hopefully this blog post (which is heavily based on Ken Sandyâs book The Influential Product Manager and a recent meetup) could shed some light on some of the techniques PM can do to be more influential in their role as PM. Influencing as PM is about how you make people act, how you make the feel, and outcome they produce.
What do most people think influence is?
- These all might sound familiar to you
- Power without authority
- Ability to affect what others do or think
- Ability to change outcome
- Change other peopleâs decisions (outcome of influence)
- Aligning people toward a certain direction or agenda
- Being brought into conversation early to shape what is being build/changed
- Listening, emotion and empathy
- Understanding and agreement across organisation or the product vision
- Gaining trust and developing relationships before you need them
Let’s look at few definition:
Having clarity across organisation is a very important skills for PMs assuring people are on the same page and moving towards outcomes not only outputs.
Pushing people into doing something Vs. motivating them: PMs should explain why this is important, provide a business context and customer needs first. Inspire rather than order them to work on something.
Now we know about peoples’ definition of influence and few main concepts PMs come across, let’s go into few techniques that could help PMs to influence:
1. Own the Idea
So many PMs allow ideas happen to them. There is no shortage of ideas! They come from different sources, stakeholders, backlog. The less product managers take ownership of ideas the more they become victim. To re-frame this, as PMs we should remember product managers job:
âBuild the right productâ â not âbuild the product rightâ
Most PMs skip through and jump into âhere is an idea, here is what we are trying to build, and I am all about getting that deliveredâ. PMs job is to actively manage that top of funnel of ideas, running brainstorming, going out of your way to seek ideas from customers and stakeholder â not just waiting for sales to tell you what to build. PMs need to own the whole process.
- Encourage and embrace ideas from everywhere
- Relentlessly collect data and challenge assumptions
- Ruthlessly prioritise and evangelise the best ideas (saying no to enough of them with right prioritisation)
2. Build Relationship before You Need Them
Build relationships with trust. Trust is frequently quality of interaction plus follow-through minus self-interest. Trust is not about spending a lot of time with people but frequency of that interaction even small interaction to connect to people is more important than spending a whole day on-site and never see them again
Quality: talking to them about something meaningful to them â not talk at them. Follow through: we all know. When you say you are going to do something, you actually do it Self-interest: how much are you interested in them and their goals, how can you find ways to empathise and compromise?
- Identify stakeholders, get out and talk to them (YOU should be going to them)
- Give them transparency to what you are working on
- Come with recommendations and options; if you are coming with problem, try to have some recommendations on possible solutions.
- Leave some space for other options for others for engagement
3. Focus on the Problem Not the Solution
Generally the longer you stay in the problem domain understanding the core problem you are trying to solve, the less likely you are going to pre-emptively settle on a specific solution that is wrong! You can gather a lot more data with deep understanding of the problem, and approach things as a hypothesis that needs testing
- Donât rush into defining solutions. You need to understand the problem well first
- Define and validate from customersâ viewpoint
- Set hypotheses and seek to test possible solutions (prioritise them) This also changes the mental model you are approaching things. If it fails it doesnât look bad on you, you donât own the idea - it was just a hypothesis. This also means you would scope things smaller and make sure you do things faster so you can test and learn and get into market (value of hypothesis)
- Context is clarity; it motivates and empowers teams. Context is describing the underlying reasons that guide a specific course of action or direction. It is âwhyâ you are doing something, not âwhatâ or âhowâ
If you talk to people about why we are doing this, you are on right track!
If you tell them what you want and how they should do things, you are off-track!
4. Collaborate to Set Priorities
The process is easy, the people are the hard bit. PM sometimes do prioritisation in isolation. Unlike what most people think, prioritisation is not about process and score card! But setting goals with people and getting as much alignment as possible (alignment not consensus, consensus may not be possible).
- Saying ânoâ is unpleasant â but âyesâ can be worse. You have to put something out of scope
- Align on user and business goals first before talking about projects. If you separate business goals, customers outcomes and get aligned on them rather than jumping to talk about what to work on - this will set out a framework for prioritisation discussions. Remember if you donât align around goals, you donât have a hope of aligning around anything else.
- Use available best-data and revisit periodically
5. Understand Customers Firsthand
- Do not outsource the most important part of your role. you ask fundamentally different questions to the user experience group (they ask: does my solution work). But you as the PM asking is this valuable?
- Build empathy and discover new opportunities: what are their real needs? Do you know who the customer is? do you understand them from persona prospective
- Frequent, informal and lightweight engagement
6. Context over PRDs
Much upfront requirement documentation goes unread and holds little resemblance to what is delivered. This is really going back to the agile manifesto! stick to the problem
- Specifications that are hypothesis-led and lightweight goal-driven
- Talk about your hypothesis, the outcome you are trying to achieve, KPI you are going to measure, constraints and
- Kick off and start collaborating on solution - allow them to emerge
7. Partner with Engineering
- engineering doesnât work for you
- Focus on why - encourage their ownership of what and how. making it their idea. Depending on organisational culture, size etc, sometimes they expect more prescriptive approach but generally let them have their own space and own it, whiteboard it together
- Value their time more than having fingers on keyboard writing code. let them join you in discovery from an early stage. they are going to ask WHY (from you) help them to understand why.
8. Proactively, Decisively Manage Trade-Offs
Be ready to make tough calls early and throughout execution to keep the team on track. There are few calls that you make early on that you cannot walk back with new information. Put context and make decisions â you will learn a lot of respect. Rather than changing your mind every other day without context and without reason. e.g.
- No nice-to-haves in the specs: do the hard work to scope tightly up front and show you are decisive
- Show you are sensitive about estimates and date setting and engage them around that by showing you have to make some tradeoff and talk to them about their concerns
- Be respectful of quality: when they tell you something is potentially going to break or there is a bottleneck, it is absolutely your right to understand why and how they are thinking it through. Remember about 30% of your time should be working on documentation, tech debt, reworking code, or working on tools to help them work more effective
9. Own the Outcome â Not the Projects
âA product release is not the finish-line, it is the start of the marathonâ
- Communicate and engage across stakeholders group
- Set KPI, keep track of post-launch issue
- Sell into organisation: iterate and optimise until delivery of outcome
10. Measure What Matters
Remember; you are changing conversation about why we are doing this and why this is important!
- What demonstrates customers value your product? short term and long term
- Viability: âcustomer-lifetime valueâ > revenue
- Despite having analytics teams, it is still your responsibility as PM to define, gather, analyse and report out
