Digging into the roles, relationships, and handoffs in product management
It turns out we might all have different ideas of what product managers do. There are at least a hundred different Venn diagrams explaining product management: some are deceptively simple, where others confuse PMs as owning nearly everything.
Engineering and Marketing might translate between companies, but the role of product management means different things to different organizations. That’s why Janna Bastow, co-founder and CEO of ProdPad, doesn’t get caught in the weeds with defining what a “product manager” is.
“I know a number of product managers who aren’t called a product manager,” she says. “And I know plenty of others who are called product manager and aren’t doing product management as the world would typically agree with it.”
Bastow has an extensive history in product management. She herself was plucked out of customer service into product management because of her ability to bridge the gap between customers and developers. Now, besides running ProdPad — a tool that helps product managers plan and deliver better products — she also organizes ProductTank events around the world, including Mind the Product (a global product community with over 100,000 members).
Here, Bastow offers us her expert insights into product management—roadmapping, communicating, hiring—as well as what exactly a product manager does in the first place.
What does a product manager do, anyway?
The problem behind that question is that few can fully agree about what’s necessarily included in a product management role. Classically, the product manager is the person who sits at the intersection of technology, the user, the market, and the business. For Bastow, it’s more about looking at how an effective manager can facilitate the flow of ideas through that intersection.
“It’s not the product manager’s job to have all the answers,” she explains. “Instead, it’s their job to ask the best questions, and to get different representatives to work together and come up with solutions. Then, at the end of the day, the product managers’ job is to make the final decision as to what goes forward to development and what doesn’t.”
“It’s not the product manager’s job to have all the answers. Instead, it’s their job to ask the best questions.”
Bastow recognizes that product manager will get input for roadmapping decisions from both the top down and from the bottom up. It’s their responsibility to integrate both perspectives into a successful product:
- Top-down information comes from the company vision and the product vision. “We want to be the X and Y, and these are the big problems we need to solve to get there,” Bastow explains. “But you can’t just work top-down because it means you’re building toward some vision that you had three years ago as opposed to what’s on the ground right now.”
- The bottom-up approach looks at what your customers are asking for, what your team is asking for, and what trends you’re seeing in the market. “You can’t work just bottom-up either, because that means you’re potentially building a whole bunch of features but not necessarily tying it together into any cohesive vision or future product,” Bastow says.
A successful product manager will find a balance between one-off cases or problems that need to be fixed, and the company’s long-term vision for the product.
Building a roadmap—and what belongs on it
“Roadmapping is a really contentious subject,” Bastow says. The temptation with roadmapping is to create a timeline of everything that’s going to happen. While that may work for bite-size projects, that level of granularity will likely set your team up failure at scale.
Bastow refuses to think about roadmaps as law. Rather, she considers them as prototypes that are useful for thinking about your product beyond the next couple of sprints. They force you to plan, communicate, and gain buy-in, but require flexibility and space for innovation.
“When you’re building a new feature, you might explore a number of different solutions,” she says. “You wouldn’t be ashamed if you ended up throwing out your first version and starting again. The same goes for roadmapping: you’re using that prototype, or plan, as a starting point for discussion. You’re saying, ‘Here’s where we think we’re going, these are the big problems we need to solve, and these are the obstacles on the horizon that we foresee. Are these the right sorts of things to work on?’”
“A roadmap is essentially your thoughts on paper to see whether you’re solving the right problems.”
In this approach, the roadmap is driven by the overall company vision—it’s a top-down document more than a bottom-up document, because it’s focusing on your organization’s objectives more than your customer’s requests. It’s broad-scale thinking instead of feature-scale planning. And the roadmap is a communication document more so than it is a plan.
“Roadmapping is essentially putting your thoughts on paper to see whether you’re solving the right problems, and to gauge whether you fully understand the problems,” Bastow explains. “You should be able to communicate the product vision to your board, your customers, your team, to anybody and say, ‘Is there anything you think is an obstacle or problem that we need to solve that I haven’t thought of? Or is there anything on here that you don’t think is a problem relevant to us?’ From there, you can remove something or add something to the roadmap long before you even begin thinking about working on the product design.”
And, yes, Bastow is a firm believer in showing this roadmap to your customers — so long as it doesn’t promise individual release dates. “Get it out there,” she says. “The worst that can happen is you need to change your roadmap — it’s much better to have this validation before the plan is handed off to engineering. Even more, it can help you learn more about what those initiatives should look like, which makes that hand-off even more effective.”
Reducing friction between product and engineering
Since a product manager’s role is to facilitate that crossroads between all the stakeholders in a product, you can see already that translating that communication from customers to company. Handling that handoff between customer input and engineering, then, becomes critical.
“I see a lot of disconnect between the customer-facing folks and what’s actually being built in development,” Bastow says. “You’ll see teams running off to build something, thinking they’re solving the customers’ problem, when they haven’t actually fully understood it.”
One task Bastow recommends for solving this disconnect is—surprise!—connection: connecting the different sources of customer feedback with the things happening in your backlog. If your customers are talking on Twitter, on Zendesk, or directly in the app, consolidate that and make it useful to the engineers.
But however that’s done, the product manager still needs to straddle the fuzzy line between product and engineering and ensure smooth communication from one side to the other. How this works depends on the makeup of your specific teams.
“Sometimes you need more communication because the developer team is newer or doesn’t quite understand the problem as well,” Bastow says. “Other times the developers understand the problem just as well as you do because they sit next to you and hear Sales and Customer Success’s conversations. Or, if development is outsourced, you’re going to have to invest much more time upfront speccing out the requirements, laying down a foundation for seamless communication, and making sure that the other end fully understands the problem that you’re solving.”
“I see a lot of disconnect between the customer-facing folks and what’s actually being built in development.”
As a product manager, you have a say in the general prioritization of what goes into development. But at the end of the day, Bastow acknowledges, it’s up to the development team to deliver. So they get to fine-tune those priorities—with plenty of help from the product managers’ effective communication.
“The product person can say what problems need to be solved,” she says. “That gives the development teams insight into where the company is going as part of the roadmap. Then it’s the product manager’s job to break that down into specs that are detailed enough that the developer can pick it up and start working with it.”
In other words, the product manager makes sure that the developers have enough context to solve problems the first time through without having to go back and rebuild because of misunderstood specs. But that doesn’t mean that product managers have to be as technical as the engineers.
“In reality, as a product person, you should understand how developers work,” Bastow says. “When one of them says, ‘Ooh that’s tricky,’ you should be able to have a conversation about why that’s tricky. You should also be able to have a general understanding of how hard different problems are to solve.”
A lot of this stuff, she says, can be communicated using Post-its and sketches and quick conversations. You don’t have to understand the nuts and bolts of the actual technology. You just have to communicate the customers’ and product’s needs as part of a conversation with Engineering to make sure everyone’s on the same page.
Hiring a product manager
There are two kinds of companies in the world: those with formal product managers, and those who need one. If you’re in the latter category, how do you go about finding a good one?
First, the bad news: “Product managers are notoriously hard to hire,” Bastow says. “They’re actually really loyal to their current companies. They don’t just move on just because another company offers free beers and a foosball table: they tend to stick it out with their companies. And a good product manager can be quite difficult to come across.”
Now, the good news: If you widen your view, you can absolutely find a quality product manager. You may already have one in-house and not even know it.
“You’re looking for a jack-of-all-trades rather than a master of any particular one,” Bastow says. “You’re looking for different skills. Have a look within your company to find out if there’s anybody who’s been wearing a product manager hat, but hasn’t been given that title.”
Oftentimes, internal people are perfectly capable of taking on the role, even if they haven’t stood out before. They don’t need to be the best at copywriting. They don’t need to be the best at coding. They don’t need to be the best at sales. They may even be struggling in one of those roles. But if they’re asking serious questions and seem passionate about the company’s direction, Bastow says, they may be worth a second look.
“You’re looking for a jack-of-all-trades rather than a master of any particular one. You need someone who helps push things in the right direction and gets people working together.”
Product management is not a typical role, she stresses, so don’t look for your typical qualifications either. “Don’t use anything like past experience, number of years, whether they’ve been to school or not,” she says. “Those are terrible metrics for whether a person’s going to be a good product manager.”
Instead, she says, look for people who ask questions, who call out BS when they see it, who aren’t afraid of speaking up and getting involved. You need someone willing to take on a stakeholder management role.
“You need someone who helps push things in the right direction and gets people working together,” Bastow says. “That’s what you need to look for in a product manager.”
In the end, you need someone who can say no to everyone and still get them on their side. You need an individual who’s different than everyone else on your team—because you need someone able to navigate each group of stakeholders with clarity and ease.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.