There are many technology jobs where you can throw on your headphones and block out the rest of the world for large chunks of your day, but product management isn’t one of them. Interacting with others is a huge part of the job and being a hermit simply isn’t an option.
Working alongside a wide range of people is one of the benefits of product management, as you are the facilitator of collaboration, the hub at the center of various organizational spokes, and the engine that turns a market requirement or customer request into a useful piece of functionality. But the job can become unpleasant quickly when you don’t enjoy dealing with the people you must collaborate with on a regular basis.
Symptoms of an unsatisfactory team environment include complaining about individuals, avoiding meetings, antisocial or aggressive behavior, and obvious exasperation. But even when a product manager isn’t broadcasting their unhappiness with their coworkers, they can still be silently seething as they dread another day dealing with someone who makes them miserable.
And since talent-craving companies are always advertising what great places they are to work, the grass can definitely seem greener elsewhere.
There are three common ways a manager can be perceived as a “bad boss” that a product manager might want to flee from:
- Lack of leadership—Product managers don’t just want someone to tell them what to do, they want someone who will help them improve and grow. If a manager isn’t providing mentorship, constructive feedback, recommendations, and inspiration, they won’t fully engage the product managers under them or inspire much loyalty.
- Lack of clarity—When there’s only one product manager, the role is very clear (do everything). But as teams grow, responsibilities must be divvied up and areas of accountability must be clearly defined. Not only should a product manager know what they’re responsible for and the accompanying expectations, they should also have ownership of distinct parts of the product or process. Having to constantly check in with your boss is both inefficient and demotivating.
- Lack of opportunity—There aren’t too many product managers content to do their existing job forever; they’re looking for chances to advance, take on more responsibility, and expand their skill set. Their manager plays a key role in making this happen by creating an environment where individuals are encouraged to grow and take risks, as well as by offering specific opportunities for product managers to extend themselves and develop their careers.
Everyone dreams of having a job they love, where they jump out of bed excited to go into the office and see what the day holds. While many people eventually shelve those aspirations for a steady paycheck, most product managers don’t have to.
Instead they find products and companies that are exciting and opportunities they are truly passionate about. Why work on something uninspiring using outdated technology and stale business models when there are so many other opportunities to build something truly innovative that changes people’s lives?
Even in a space that may not be as sexy as self-driving cars or virtual reality, there are still many chances to innovate within an industry, leverage emerging technologies, and shake up the status quo. When a product manager doesn’t feel like their current gig is giving them that chance, they’re likely to look elsewhere for a job that will let them scratch that itch.
“Due to the varying scope of responsibilities for the product manager from company to company, the skills and experiences at one place may not translate to automatic success at another,” says Vinh Jones of Lithium Technologies. “As the hiring manager, you have best grasp on what skills are needed to be successful within your current environment.”
Although you can’t always control all the variables enough to create a totally harmonious experience, you can at least mitigate the drama with some good planning. Of course symbiotic personalities within the product team itself are also key; there should be good dialogue and trust between team members and not too much competitiveness and jockeying for position.
Beyond personalities, roles should also be assigned to create an opportunity for product managers to be successful while developing additional skills and experiences. Giving them responsibility for discrete areas of the product that are within their capabilities but still provide stretch goals and challenges is a tricky, but essential, balancing act for leaders.
Not everyone dreams of being a manager, sometimes you just get elevated to the role because of your excellent work as an individual contributor. But once you get the title and a team, the hard part begins.
There’s no shame in admitting that you’re not a great manager right out of the box. You just need to identify and acknowledge your own growth areas and work to address them. As a leader, your focus is now on your team versus yourself, and you might need to add some skills to your repertoire to become the manager you want to be (and your team wants as well).
Are you setting clear and achievable goals? Are you having quality one-on-one’s with each product manager on a regular basis? Are you providing constructive feedback and praise? This isn’t rocket science, but for someone not used to managing others it’s easy to fall into bad habits and not cover Management 101 items while still focusing on product strategy.
The other tricky part of management is knowing when to step back and let your team members succeed or struggle on their own.
“Don’t solve their people problems. Don’t make decisions for them. Overall, don’t disempower them by doing their job,” says Brandon Chu of Shopify. “Doing so sets them up to fail, because people around them will no longer perceive them as having the agency to make decisions, and their job-ending frustration is self fulfilling from there.”
While the have-to-dos have to get done, product managers should be encouraged to pursue their own ideas as well, as long as they don’t become too much of a distraction. There are plenty of examples of unexpected positive outcomes coming from letting individual employees experiment (think Google’s 20% rule) and it will let product manager’s scratch that itch without actually leaving the company.
“Talented employees are passionate. Providing opportunities for them to pursue their passions improves their productivity and job satisfaction,” says Travis Bradberry of TalentSmart. “Studies show that people who are able to pursue their passions at work experience flow, a euphoric state of mind that is five times more productive than the norm.”
3 Things Product Managers Owe to Internal Constituents
One of the most important things you can do as a product manager is regularly communicate the product vision to your team.
Frequent discussions about the product vision help your product team understand the big picture problems your product is trying to solve and how their work fits in with the broader strategy. Increased clarity into long term goals and strategy empowers the team to make more informed decisions. In addition, it also helps them validate assumptions as to which product constraints they need to concern themselves with today and which can safely be de-prioritized.
.. Sure, you’re already giving your team direction at your iteration planning meetings as well as giving them a great set of user stories to work from. But, no matter how well-written those stories might be, questions will inevitably arise.
As product managers, we often fall in love with not only the problem but the solution, as well. This often leads to us driving the solution to completeness before involving our team in the definition of that solution. However, your team likely has a more in-depth knowledge of their chosen technology stack than you ever will. For this reason, it can be helpful to lean on your team’s expertise when defining your solution.
.. Great designers and developers don’t want to be mere order takers. They want to use their brains, and it’s up to you to give them the space to do so. However, this doesn’t mean that you have to give them complete creative license. Work with your team to collaboratively set boundaries that everyone can agree on. This will ensure that everyone has a shared understanding of how much freedom your team has to make decisions independently and at what point they must involve you.
.. One of the most obvious ways to do this is to be sure that you invite all relevant stakeholders to your product reviews. Doing so can help you be sure that you’re getting the feedback you need from inside of your organization before launch, and prevent any unexpected surprises after launch. However, between these reviews, you’ll also want to actively solicit feedback from others in your organization about your current strategy and vision for your product’s future.
5 Mistakes You’re Making When Sharing Your Product Roadmap
Not all roadmap presentations are created equal, even when you’re presenting the same roadmap. Although your audience shouldn’t change the fundamental elements of your roadmap, the things you focus on and emphasize should be tailored to the particular people you’re presenting to.
Executives want to stay at a high level, with a focus on big features and themes that support the overall corporate strategy. Meanwhile, sales wants to know what new goodies they’ll be able to talk about to prospects.
Engineering will focus on technical implications, while marketing will want to know how the product stacks up against the competition and what kinds of content and outbound activities they can plan around coming releases.
Customer support wants to know if common pain points are going to be addressed and finance wants to see what the revenue and expense implications may be.
And, last but not least, your customers want to feel confident they’ve bet on the right horse with your products and see if their wish list items are included. And, since not all customers care about the same things, you’ll want to highlight the upcoming items most relevant to them specifically. You might even want to edit the version you show them to remove items they don’t care about so they don’t try to “jump the line” with their particular favorites.
2. Diving too far into the details
A product roadmap is a high-level vision for where your product is headed and the main steps you’re taking to get there. But painting this vast picture of strategy and direction means you can’t spend too much time on the details.
First of all, excursions into the weeds will harm your narrative flow; you’re telling a story and the main plot points are key. The point of a roadmap isn’t to discuss implementation, UX or dependencies; it’s about concepts and themes.
Additionally, any time you spend on the small stuff opens yourself up to being challenged and derailed by skeptical audience members that want to nitpick over nuances. There will be plenty of time to debate the merits of a given feature, but the purpose of a roadmap presentation is getting buy-in for the high-level aspects of your plans for the product.
Depending on your audience, you might even be able to get away with a roadmap that doesn’t call out specific features or releases at all, sticking instead to overall themes and vague delivery windows (i.e. near term/medium term/long term). But the most important thing is delivering a roadmap presentation that includes the minimum amount of detail required to secure overall approval and convey the general direction and priorities of the product.
3. Not doing your homework
Anything in your roadmap is open to questioning and challenges, so you must be confident that everything on there exists for a reason. Having the rationale for every item at the ready will enable you to quickly quash any probing attacks into your diligence and keep people focused on the high-level vision.As a product manager presenting this plan, you will inevitably be forced to justify all the decisions made to get to this point, so you’d better be prepared.
“Technical teams need context for why you are building something on a roadmap,” says Martin Suntinger of Atlassian. “Engineers need to see evidence for why you see demand for a feature. Let data speak, but also tell a powerful story from the perspective of your users. Use personas, and talk about some alternatives that you’ve excluded, and why.”
4. Ignoring what’s NOT on the roadmap
No realistic roadmap will include every single possible thing your product could potentially include, and it’s highly probable there are items missing that received a good deal of attention, consideration, and discussion. Thinking you don’t need to discuss any of these will put you on the defensive when a missing feature is inevitably raised by someone in the audience.So instead of waiting for someone to ask you why something didn’t make the cut, be sure to proactively cover the top items you didn’t include as part of the presentation. You can briefly explain why they’re not part of the immediate future plans and hopefully snuff out any dissent quickly.
Although this won’t make everyone happy, it’s better to illustrate that these items were given fair consideration and excluded or delayed for a particular reason.
5. Dating yourself
What’s worse than presenting a roadmap to customers that doesn’t leave them excited for the future and confident they’re working with the right company? Promising to deliver key features and functionality by a specific date when you didn’t intend to.All product roadmaps should come with giant asterisks and banner headlines proclaiming “Subject to change” and “All dates are estimates,” but that might take away from the visual aesthetic you were going for. However, one of the key messages everyone (particularly customers) should walk away with is some version of, “This is our current long-range plan, however we don’t know exactly when things will be delivered and new information or events may cause a shift in priorities.”
But beyond those qualifying statements, you can avoid some drama by simply taking the dates off your roadmap completely, instead using your roadmap to paint a linear narrative without a particular timeline. For example, instead of showing Single Sign-On support in Q1 and Automatic Backup in Q2, you can remove the Qs altogether—this still shows the audience that SSO comes before Automatic Backup without locking you into a specific, self-imposed deadline.
Showing roadmap dates and commitments can be extra dangerous with customers. They may simply assume this is when things are definitely going to happen and start getting very cranky when July rolls around and they don’t have the widget you’d projected would arrive during a roadmap presentation six months ago.
But a roadmap with dates presented to your sales organization can be just as troublesome. They might run with your planned roadmap and start making promises to prospects, who then sign on with the explicit understanding that some feature will be available by a particular date.
Even if it’s boldly labeled “for internal use only” there’s nothing stopping an eager sales rep from boasting about what’s in the development pipeline to help them close a deal. And while some sales opportunities are worth making those kinds of commitments, that should happen intentionally and with lots of internal discussion, not just because a particular salesperson was oversharing.
This roadmap will self-destruct in five seconds…
Remember, a product roadmap is a vision of the future presented at a specific moment and will probably be outdated soon. It is not set in stone nor intended to be viewed as a contract between you and your audience. Applying caveats judiciously and making presentations interactive can limit the tendency to view them as absolute plans, as can soliciting feedback during the presentation to reinforce the idea that things could change.
And while there were earlier warnings about using dates on roadmaps, there’s one date you should always include—the date of the roadmap itself. This will keep any old versions that might be floating around from being mistaken for the latest one you’re currently presenting.
What is the Ideal Product Team Size?
Another method for deciding how many product managers a company needs is to base it on the number of engineers working on the company’s products. In 2007, Marty Cagan of the Silicon Valley Product Group said you need one product manager for every 6-10 developers, and today the “seven, plus or minus two” mentality is fairly pervasive (which makes sense given the Agile model).
This is really a Goldilocks-style conundrum: if the ratio is too small, the developers won’t be able to code fast enough to keep the product manager busy, and they’ll just be adding items to an ever-increasing backlog; and if the ratio is too large the product manager may not be providing enough details and interaction with the engineering team to properly guide its work.