You were the first product hire at your startup, and now you’ve been given the green light to start building a team. Exciting!
Once the excitement subsides, you start to think and plan what your role should be, how you should spend your time, and what you should handover to your new team members. On top of that, you’re working closely with the engineering team to ship the new features and products you’re working on – so what’s the best way to work together?
To answer all these questions, we turned to Tom Verrilli, Chief Product Officer at Twitch. Tom gave us a rundown of how to think about the role and growth of a Product Manager and what Product should own, so that the wheels don’t fall off as you start to hit hypergrowth.
PM 101
All Product Managers (PM) are leaders – but what does that look like in the role? At Twitch, Tom breaks this down into 3 areas that govern a PM’s behaviour:
Operational leadership
PMs are responsible for the effectiveness of product delivery. The nuts and bolts are identifying customer needs and goals, defining the solution, prioritisation, an orderly go-to-market and the ownership and achievement of goals.
People leadership
PMs have to be able to inspire, motivate and direct a team. There’s no formal qualification to become a PM, so your capacity to corral a team to follow you, when in theory, they could do the job you’re doing, is critical to your success. As your company gets bigger, your ability to cooperate with other teams to ensure that your product fits with theirs and your cycles aren’t disruptive becomes essential.
Thought leadership
PMs have to become experts in their product domain and customer. They must articulate a vision that enables others to engage and align with their strategy without needing to be in the room.
“The litmus test for our Senior PMs on thought leadership is: You’ll know you’re a thought leader in the company when you constantly hear your words coming out of other people’s mouths as if it was their own,” says Tom.
What does the PM role look like as you scale?
If you’re in a scaling startup, what you’re doing over time will change. Your job is to move to the right as you hire:
As you start building out a team who owns features, products and portfolios, you’ll see outcomes if they’re getting the execution, people and thought ratios right. For Tom, this breakdown also becomes a helpful tool for evaluating a PM’s performance and behaviours.
“If I’m doing a review with someone who has been working on an onboarding flow, I ask, ‘Who do you think has the best signup flow?’. If they can’t answer that question, then I know they’re not spending the right amount of time on thought leadership as they should have a strong opinion on that question,” says Tom.
If you were one of the first PMs at your startup, by virtue of having spoken to more customers, seeing how features fit into the grand plan and honing your instincts over the years, you’re a better PM than the people you hire. As you start rapidly scaling, the trap you want to avoid is giving your team the answers rather than asking them the right questions.
“If you start telling people the answer, they’ll never get good, and you’ll be stuck doing this at scale and burnout,” says Tom. “The number one way product leaders fall over is when they think everyone else is useless and they have to be across everything. That’s their fault because they’re not giving them the time or autonomy to get the reps in.”
As you go from an operational PM to a product leader, your company changes a lot too. Half the things you knew stopped being true, and the likelihood your assumptions are wrong increases as time goes on. You’re at risk of keeping your understanding of the customer and the product management function in a time capsule.
Tom shares three ways of combatting this:
- Reserve strategic autonomy for yourself and disseminate tactical autonomy
Here’s a common scenario: you want your team to be autonomous, so you say, “Tell me what you want to work on.” They go away and come back to you with a bottom-up strategy. But, that doesn’t align with your strategy. So you start questioning their tactics and giving them nitpicky feedback because you inherently disagree with the strategy, and therefore the tactics don’t satisfy your needs.
You want to do the inverse of this – let them know the strategy and the problem you’re looking to solve.
“Give them the happy path, and say, ‘If you bring me something that solves this, I’m going to say yes,’” says Tom. “Now they have the right level of tactical autonomy, and you’re not sending them down the wrong track.”
- Absorb ambiguity
PMs often have to make decisions based on imperfect data and limited context. If you have a junior team who don’t know what to do in these scenarios, the best thing you can do as a leader is absorb ambiguity and disseminate clarity. Sometimes you’ll make a decision, and in hindsight, it’s the wrong one. But at that point in time, you’ve given your team clarity on what they should be doing and where they should allocate resources.
- Your job is to define the quality bar, rather than define experiences
When you give your team feedback such as, “I understand what we’re trying to build, but I don’t understand how this matches back to the strategy,”, you’re defining what they need to bring you to get a yes, rather than telling them how to do it.
What does Product own?
Product management does different things in different companies. But if you’re looking for a rule of thumb of what product should own in your startup, Tom offers up a simple rubric.
When you combine these do’s and don’ts, the happy path should look like:
- A crisp articulation of the customer problem that you’re trying to solve. If everyone on the team understands from the PM what the explicit problem is, they’re empowered and enabled to make micro-optimisations as they work on solving the problem without needing the PM in the room.
- A clear set of solution requirements. By combining the technical scope and acceptance testing criteria, individual contributors can do their jobs independently as they know what the problem is and the things that will be true once it is solved.
- A documented priority list. As a PM, it’s easy to get tunnel vision, but technical teams don’t have that luxury. You need to document and prioritise the problems you’re solving, not just today, but the top 3-6 things you’re trying to achieve in the next 6-12 months.
Once you’re on the happy path, half the battle is staying on it. “The most powerful thing I do to stay on the happy path is asking questions when I’m talking to my team, rather than imparting wisdom. If I’m always speaking and telling them things then I’m dangerously close to the sad path,” says Tom.
It’s not uncommon for product management to end up on the sad path. This looks like:
- Prescriptive instructions, such as “make x” without explaining why or what you’re hoping x will do.
- Scope creep, when you find yourself saying, “also, can you make it do X and then we’re good.”
- Thrash, the ultimate derailing of “actually, team, I need everyone to stop working on A and focus on B.”
I work at an early-stage startup – do I need to do all of this?
If you’re reading this thinking, “This is an absurd level of construction to do in order to build things,” Tom stresses how important it is for you at this stage to answer the ‘W’s” before the “H’s” or you’ll be giving your team the wrong set of instructions.
And you may not want to hear this, but you probably need to: “You’re the most dangerous person when it comes to scope creep,” says Tom. “No-one is going to question you, and if you haven’t had the discipline to ask yourself who exactly the customer is and what your priorities are before you dive in, you’re the hand grenade that goes off in the middle of a dev-cycle. You’re the person you used to hate when you were a junior.”
