Ronke Majekodunmi – How to build strong coalitions
Tonya Edmonds – How to Successfull
Vince Aidoo – The Value of Learning from Failure
Ayo Omojola – Fighting Covid and Pushin
Rafael Balbi Jr. – Key Learnings in Becoming a Principal PM
Sasha Kai Parker – Incorporating Innovation into Product
Product leadership is difficult.
That difficulty comes because it’s often very different from product management. As a product manager (PdM), your focus is squarely on making sure that your team is consistently making the best decisions they can.
When it comes to product management, you can easily access help to upskill yourself. Plenty of resources describe how you can do this more effectively. I’ve written a few myself. Some great voices in the space, such as Matt LeMay, Teresa Torres, and John Cutler, among others, lay out frameworks that help PdMs figure out how to increase the decision quality of their teams.
But what about product leadership? Well, product leaders’ job is to build product teams, which involves less framework and more coaching. You aren’t the star anymore. Instead, you take teams and make sure that they are ready for primetime.
Accomplishing this requires a completely different skill set from strict product management. You start to assume responsibilities that take you outside of a tracker or prototype and have you spending far more time focusing on the people themselves.
This work includes bringing people onto the team that you’re developing. One skill that product leaders must cultivate is learning to hire effectively. If you aren’t adding the right skills to the team, no amount of work you do individually can fix things when they go askew.
The simple truth is that when you become a leader, you have too much to do, from team to resource management, to continue doing your old job. As an executive told me in a previous product leadership position, “You can’t do both.”
And you can’t. So, you’re now hiring new PdMs to do the work you used to do well. But how do you go about that?
Free Toolkit: Successfully Onboard Remote Employees
Download this remote onboarding toolkit to access actionable resources you can implement and see the impact of immediately.
Have you ever heard the saying, “Just because you can do something doesn’t mean you can teach it”? Well, the same thing applies to hiring.
The skills necessary to hire someone who will be a good fit for the role aren’t as simple as one would think. You risk becoming a victim of expertise bias, where you end up looking for someone exactly like yourself. You also have to consider cultural bias, in which the hiring manager prioritizes candidates who look, talk, and think exactly like the other team members. Both of these biases lead to building a team that thinks and looks alike. In a discipline like product management, this can be a fatal error.
No tension on teams means no growth. Unless you get some measure of luck, your team will remain stagnant because no one challenges each other. After all, we’re here to increase the decision quality of the teams around us, and that can’t happen without the team coming together from different backgrounds and points of view.
The bad news, as a product leader, is that you likely won’t be trained on how to do this. The teams around you probably don’t know much about product manager, let alone hiring for it. Even if they did, they hired or promoted you to be a product leader to handle these things.
The good news is that I’m going to give you a quick tutorial on how to avoid some of these traps and push you in the right direction. First, we’ll talk about the importance of being clear about the problem you’re trying to solve with your hire. Next, we’ll use that information to formulate good interview questions. And finally, we’ll talk about being honest about the time you have. Getting all three of these things right drastically increases your chances of making the right hire.
Every team needs a certain headcount. Likewise, every team has a million problems they have to handle. Product leaders definitely understand this since they engage with other teams at the strategic level. Sales could always use another SDR and engineering another back-end developer, just like you can always use another product person.
The fact is, everyone will say yes to another hire if it’s offered. But do you know what you need them for?
The most important part of the hiring process is getting the right mind in the job. The second most important thing is onboarding that person correctly. Third is making sure that the new person knows what they need to do to be successful.
All three factors rely on your understanding what you’re hiring for. What problem are you trying to solve with this new team member?
Product is a flexible profession. As a product leader, I’m assuming you’ve had a couple of product management jobs in the past. Have they ever been similar enough to have the same job description? My bet is no.
Despite that, every product job shares one element: flexibility. As they say, the only constant is change, and that’s as true of product management as anything else. Yet many product job descriptions look the same. And before you copy that mistake, taking a job ad else someone wrote and making some superficial changes, I would like to point you to Kate Leto’s book, Hiring Product Managers. In it, she says that one of the most impactful tools in the discipline is the product role canvas.
In her words, “Ensuring there’s a clear and shared understanding of the role that you’re hiring for is an essential first step to thinking more collaboratively and comprehensively about what a new role might be before the interviewing even begins.“
How you understand the role in your organization’s context is incredibly important for the people who want to fill it. Product means different things to different people. How can you set someone up for success if you can’t define it for them before they walk in the door?
Use the product role canvas to define the problem you want to address before you move forward. Doing so will give you and the rest of the team (usually your designer and engineering peers, but this also can include folks like customer success and sales) an idea of what you are looking for.
Then, you can think about interview questions.
So, you know the problem you need to solve with your hire. With that in mind, you should write a clear job description that matches your problem. Don’t just copy and paste whatever you find on the internet.
Once you publish the job ad, you’ll start receiving applications, and you’ll invite promising candidates for an interview. What do you ask them?
I’ve seen teams blow this part of the process. Instead of being prepared and curated, the questions are either haphazard or clearly ripped from a how-to article. Product is far more calculus than algebra, and so you should know that anything that’s called “the perfect question for product interviews” is only perfect for the context in which the question was created.
Much like a good product, good questions help you tell a story. Even better, you create an environment for the person across from you, usually stressed and hurried, to show you their unique self. Strive to uncover “unique” traits rather than the “best” ones because that best isn’t who a candidate is day in and day out. “Best” is a character they have prepared to show you; unique is who they really are.
Tap into unique by asking questions like these:
These types of questions can lead to stories that give you the unique flavor of a candidate. Uniqueness wins here since you’re looking for someone interesting and adaptable rather and who meets every item on a checklist.
In product, you’re always looking to solve an ambiguous problem, How you rate the uniqueness of a candidate against the problem set you want to solve is important. Think about the problem and the types of both hard and soft skills necessary to solve it.
Your questions should also get the candidate to talk about their experience so they can form a tapestry of their experience. The follow-ups you ask should aim to give you a better understanding of who the candidate truly is instead of the “best” person they have prepared to show you.
Because we’re looking for a story, ask open-ended questions. For instance, ask “Walk me through a time you’ve done X” instead of direct questions about some specific item. This will allow the candidates to tell you their stories.
It’s important to get to the candidate’s uniqueness quickly because we’re on the clock. You don’t have much time to devote to this process.
As a hiring manager, you’re conducting interviews and hiring on top your actual job. Finding time to look over assets and grade things can be a hassle. So, why do teams act like they have a million years to do so?
Generally, you don’t have time to look at that long presentation, nor do you have time to dig into that case study, or to relisten to that hour long interview that the candidate gives you. Sometimes, you may not even have enough time to do more than Mad Libs on a review.
So, create a key for scoring interview answers. This document gives you the ability to do reviews shorthand. You can answer what others need to know without a ton of investment on your behalf.
As a part of that key, define the time that it is going to take to review the answers. Share those targets with both the interviewee and interviewer. Being honest about the time can help you and the team get clear sightlines on how much work you are asking of them. You can even bundle the time (e.g., a standing 30 minute meeting to review interviewees each week) to get through the review process cleanly.
Free E-Book: Core Values in the Workplace
How to create core values that will inspire your workforce.
And getting it right is the most important thing you are going to do as a manager. When you’re ready to take your team to the next level, you can’t afford to fail. Be clear about the problem, put the right amount of rigor in the questions, and set reasonable time expectations.
This may seem like a lot of work up front. Over time, though, you’ll spend less time thinking about the hiring process and more time thinking about the candidates themselves while being transparent about needs, which can help your team get a lot stronger in the long run.
Being a product leader is a different job and requires a few different skills you won’t learn as a PdM. Take the time to learn these new skills, and you’ll get better outcomes.
So, you’ve made the hire. Congratulations — finding the right product manager who can help your team succeed is a huge burden off your shoulders. As a member of the welcoming committee, you well know that onboarding is extremely important to the success of your new colleague.
Here are the stakes, according to Harvard Business Review (HBR):
A bad onboarding process is essentially running that brand-new hire you just made out the door — and a sizable number will leave before they can do anything they promised during the interview process. Onboarding new employees isn’t something that should be taken lightly.
Except that it is.
In fact, Gallup puts the percentage of companies doing poor onboarding at a whopping 88%. That means that you aren’t seeing things — yes, people are leaving jobs rapidly. And while much of that can be blamed on bad management, the specter of bad onboarding can be just as impactful.
Those are generalizations about the overall workforce, and while I don’t have a ton of peer backed numbers, I can be fairly confident that the trends follow in the discipline of product management. My conversations with product leaders and founders tend to support that notion, as one of their struggles continues to be keeping great talent. They find that new hires don’t quite find their footing and seem to never reach full productivity. Those folks tend to start looking elsewhere.
All of that work to bring in someone for them to leave in a few quarters is devastating.
This article is going to address the difficulties that product managers face during the onboarding process. These challenges are based on the understanding that product managers are there to help facilitate product decision-making within an organization. This means that the first few months of a product manager’s tenure is more akin to being a “detective” than anything else.
How a company prepares a PM during the onboarding process can be the difference between a long-lasting team member and a flash-in-the-pan who sends you right back to the hiring boards.
The challenges are that product managers have to:
Let’s go through each of these in turn. I’ll share a few things you can do to move your new hire along so they can be effective, plus some things to throw into the welcome pack to help them on their way.
Your company doesn’t exist in a vacuum. Even if you are creating something on the edges, there is often an alternative that your customer base is currently using to solve their problem(s).
When a new product manager comes on board, it’s critical that they get this information as early as possible. This allows them to ask questions that can improve the current “map” of the company. After all, you hired them for a reason! When armed with accurate knowledge of the market, a product manager is more confident in the bets they make and less likely to run afoul of silent rules that exist in the marketplace.
Put these in the welcome pack: A list of current competitors, the rules of the market from leadership’s point of view, and your business strategy, along with all the artifacts that accompany it.
The company doesn’t exist in a vacuum, either externally or internally. The team or organization made a number of critical decisions in the past, and the company learned from them.
When your new product manager comes on board, they need to know what those decisions were, who made them, and what the company discovered. As they learn this, they get a picture of where they can add value based on their experience and what they don’t need to re-learn. This means they can use their energy effectively going forward. This also applies to the things people in leadership positions won’t do. There’s no need for the new hire to waste their efforts.
Put these in the welcome pack: The last six months of major decisions, an org chart, product mission/vision/strategy, and a list of anything that the company won’t do.
Building on the idea of “wasting energy,” it’s very easy to do so in a new organization, especially as a product manager. When you don’t know what you can do without getting the “ok,” it can be frustrating. It hints at dysfunction within leadership because when these things aren’t clear, people don’t act.
When your new product manager comes on board, they need to know what they can do. Can they just run a research study without an “OK?” Is it company policy for them to be able to hop on a plane to see customers without your sign-off? How about changing the roadmap? What about bringing in new software? If you are thrown off by these questions, I’ve got more, and they easily compound. Don’t waste your new hire’s time — let them know what they can do without asking permission.
Put these in the welcome pack: Rules on company spending/training spending/research spending, old research wins and losses, and anecdotes on when the company changed course.
You’ve made the hire. The person is coming in the door. They are smart and accomplished and are ready to help make the business better.
You trusted them enough with the offer, so help them out, and get them onboarded so they can get right to work, the right way.
Product operations (product ops), the product management discipline’s latest way to track and understand the inputs that drive product strategy, is important. Far too long companies have had it “easy” in product development accounting, as projects were often “done” when they were shipped, and the numbers were rarely investigated more than superficially after that point.
Work from Melissa Perri (CEO at Produx Labs) and Christine Itwaru (Director of Product Operations at Pendo) in the public sphere, as well as some of the work here at Mind the Product, highlight the importance of product operations. To the uninitiated, product ops represents a systematic way to connect your data and processes to product development outcomes. If you’ve ever wondered what product development “costs”, and tried to model it in a way that helps you forecast, product ops is your skill.
As a coach for product development leaders at Approaching One, I often chat with leaders about product ops, especially at smaller companies. A very common topic is how they can engage with systematic product ops practices, and use them to make better product decisions with less waste. Of course, this is after the company has committed to embracing product operations. If your organisation isn’t there yet, I recommend looking at Melissa and Christine’s work (linked above) and advocating for it, if you’re encountering that kind of systematic “leakage” in your data and processes.
Over the course of my conversations with leaders, I’ve noticed a few common product ops pitfalls:
These pitfalls leave teams not getting the most out of the product ops they’ve set up – which is doubly frustrating for them because the most common goal of starting to deploy product ops is to gain efficiencies! I want to talk about all three, and ways you can immediately use the data you are collecting to get more out of the product operations work that you are already doing.
Many of the tools we use make sure they can import and export data. It’s overwhelming, because suddenly data exists in multiple forms, in multiple tools, for various purposes.
The key issue I hear about from product leaders isn’t a lack of data, it’s a lack of alignment around that data. To gain organisational alignment, the organisation must have a level of data fluency.
Data fluency is the ability to understand the data that you collect, and being able to apply it to something meaningful. It isn’t how much data you have, but how effectively you can use it.
As a product leader, you’ll need to be able to judge your team’s ability to understand the data you’re using to achieve business goals. Ask yourself this question:
If I randomly asked someone in the organisation to tell me what the most important KPI is, where they get the data from and why… could they answer it meaningfully?
For most teams, the answer is a slightly sheepish “No”. This is a sign that, even though you are collecting good data, there is an opportunity to evangelise better practices and alignment. For product ops to be useful across the organisation, you’ll need to make sure that people understand why the data is important, what are the critical sources of data, and of course – what the key metric is.
If there is a lack of understanding, well, that’s a great lead-in to our next section…
Great product teams aren’t judged just by their ability to create things, but also to learn. The more a product team learns in service to a company’s mission, and uses those learnings to create impact while minimising risk, the better the company’s “decision fitness” tends to be.
Learning doesn’t just come with a launch. Every interaction with a customer can lead to learning that improves the decision fitness of the entire company. More importantly, when you have solid product operations going, the data you collect should give you insight on how learning is going across the company, as well as the gaps in the company’s knowledge.
It’s worth asking yourself this question:
If I asked people what was the last major learning we had as a company – would people have similar answers?
If teams are unsure when and where learning opportunities are coming from, then any progress you make on “insights” is random, at best. The point of product ops is to tie numbers to outcomes to improve those numbers, and create a consistent cadence of learning opportunities.
Speaking of improvement…
How is your research and development (R&D) going?
If you are wondering if you have R&D, you do – if you are a young startup, then your entire existence is R&D. If you are a larger company, you still have R&D – and if you aren’t intentionally managing it, then it’s happening in pockets, organically.
In these ad-hoc situations, this turns into “science experiments”, or projects that come from the bottom up. You’ve probably got a rogue executive with interesting, creative ideas, who may or may not be in line with the vision of the product.
This might sound like a great idea initially, however, too many uncoordinated science experiments in a company dooms it to being a hamster wheel. If you ever wondered why your team seems to be in the same place despite constantly trying out ideas and experiments – well, I’d bet that you are in the middle of an uncoordinated treadmill.
Innovation can happen randomly and organically. However, if you want it to happen consistently, you need some process. If you find yourself in a place where you feel things are the same, like an innovation treadmill, it’s worth investigating that process as a whole.
Product ops is designed to give you a place to start your investigation. What’s new? What’s different? Where are we gathering information? Is that information useful? How impactful was our last experiment?
Those questions (among others) will help you understand if you are on that innovation treadmill, or if organisational creativity is a random, chaotic process. If you find yourself there, asking those questions and making changes to either stabilise or energise can bring some consistency into your innovation process.
You’ll find some great opportunities through your product operations data.
Product operations are important. The data we collect there can lead to massive insights that scale and build across the entire organisation. Having it available and consistent is a huge plus when it comes to finding alignment, and making things happen at high velocity
That’s why it’s critical to make sure you are keeping an eye on your company’s data fluency, its learning cadence, and its R&D coordination to ensure you’re using your resources to effectively get product operations up and running, and to massively level up your product organisation.