How to Spot a Partial Product Manager

Kate Hopkins By: Kate Hopkins

This post originally appeared on the Mind the Product blog.

What’s a partial product manager?  We’ve all met one, and many of us have been one – a partial product manager is someone who holds the product manager title, but isn’t doing the full job.  It can happen really easily, because great product management encompasses a great deal and is constantly evolving.

I’ve categorized some common types of partial product managers to make it easier to identify and fix gaps.  Leaning on Martin Eriksson’s post, ‘What, exactly, is a Product Manager?’, the role sits at the intersection of user experience (UX), tech, and business.  If you subdivide UX into the constituent parts of design and customer understanding, you end up with a modified Venn diagram, and at each of the incomplete intersections, you can find a different type of partial product manager.

Categories of Product Managers

1. Requirements Writer

The first type of partial product manager is a holdover from waterfall days when product design entailed a sequential process of researching, then documenting, then passing along requirements for development.  Sometimes product teams still get sucked into that outdated role, thinking of themselves merely as translators between the business and tech sides of the company.

Without enough customer involvement and design thinking, product management ends up documenting requirements for features that may or may not lead to desirable outcomes.  The first version of a new idea is often finished code, which means that developer resources are wasted when untested assumptions lead to a product flop.

Signs to watch out for:

  • Product managers rarely interact directly with customers
  • The company doesn’t create or test prototypes before building
  • The company often has unexpectedly low usage of newly developed products or features

2. Deal Chaser

A deal chaser is too swayed by loud, internal stakeholders.  Product teams in this category end up adding all kinds of specific feature requests to the backlog.  Longer-term strategy gets distracted by short-term thinking to land a deal this quarter.  This happens most often in companies with strong sales cultures, and is exacerbated when product managers don’t have enough customer touchpoints of their own (and so lean on information relayed by customer-facing teams).

The things sales asks for are probably good for at least some customers, but a deal chaser doesn’t invest enough in understanding the underlying problem that inspired the feature requests, and in assessing what those sales asks would mean technically.  Product runs the risk of signing up for a lot of work that may not be aligned with the company’s strategy or the needs of its target customers.  In the longer term, scattered development can make the product harder to maintain technically and harder to successfully position in the market.

Signs to watch out for:

  • An erratic roadmap that lacks cohesive themes
  • Frequent, bespoke development for specific customers
  • Promised features written into sales contracts

3. Super Support

For a super support product team, planning takes a backseat to ticket-taking.  This can happen when a lot of bugs crop up at once, or if there isn’t adequate customer support in place.  Under either circumstance, a wave of individual issues hits the product team, and with so much to do, it can feel like there’s no time to synthesize or prioritize.

But, a ticket-taking product team can never dig its way out of the hole.  If things are going badly and bugs are a real problem, hopping reactively from issue to issue can mean that product misses the opportunity to address the root cause of the problem and end the cycle.  If things are going well, a support mindset can lead to backlogs full of incremental improvements for existing customers and no room for development that could significantly help the business in the longer term.

Signs to watch for:

  • A very long, detailed backlog
  • Highest priorities always align with the needs of existing, individual customers
  • A team that never says “no” (or “this isn’t aligned with our priorities”)

4. Idealistic Inventor

This product team’s favorite phrase is “wouldn’t it be cool if”, and some of their ideas do sound pretty cool.  Idealistic inventor teams build products that are slick and scalable, and they may even prototype them first, but too frequently, usage and sales are lower than expected.  The more funding, the more likely a team like this can grow and flourish.

Without grounding in customer needs and market realities, product can bring forth theoretically awesome products that aren’t, in reality, worth much.  The team can fall into the trap of assuming that something that appeals to them will also appeal to their target customers.  If product doesn’t fervently insist on understanding and surfacing customer needs, and especially if the technical team members are strong, team thinking can center on what the team will build into the product instead of what problem the product should be solving.  If the finished product doesn’t end up solving a real and burdensome problem, it won’t generate much revenue.

Signs to watch for:

  • Stealth mode (no talking to any customers or potential customers)
  • Discovery activities that “lead the witness” to confirm that a solution would be valuable
  • Starting with features instead of problems

What to do When you Spot a Partial Product Manager

All partial product managers allow themselves to be sucked too far into one sphere of the role.  No matter the type, start by taking a step back, to revisit key goals that inform bigger-picture prioritization.  If you find you are the partial product manager, carve out time to re-center.  If the partial product manager is someone you work with, ask about the objectives that underpin decisions, and why product has confidence that the things being prioritized serve those objectives.


Kate Hopkins
Kate is Vice President at Mainsail Partners, working with portfolio companies to accelerate growth. Her focus is in product and market strategy.
More by Kate Hopkins
This content piece has been prepared solely for informational purposes. The content piece does not constitute an offer to sell or the solicitation of an offer to purchase any security. The information in this content piece is not presented with a view to providing investment advice with respect to any security, or making any claim as to the past, current or future performance thereof, and Mainsail Management Company, LLC (“Mainsail” or “Mainsail Partners”) expressly disclaims the use of this content piece for such purposes.

The information herein is based on the author’s opinions and beliefs on how to build a product management team and related topics and are not necessarily representative of those of Mainsail. There can be no assurance other third-party analyses would reach the same conclusions as those provided herein. The information herein is not and may not be relied on in any manner as, legal, tax, business or investment advice.

Certain information contained in this content piece has been obtained from published and non‐published sources prepared by other parties, which in certain cases have not been updated through the date hereof. While such information is believed to be reliable for the purposes of this content piece, neither Mainsail nor the author assume any responsibility for the accuracy or completeness of such information and such information has not been independently verified by either of them. The content piece will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof, or for any other reason.

Third-party images and logos included herein are provided for illustrative purposes only. Inclusion of such images and logos does not imply affiliation with or endorsement by such firms or businesses.

Certain information contained herein constitutes “forward-looking statements,” which can be identified by the use of terms such as “may,” “will,” “should,” “could,” “would,” “predicts,” “potential,” “continue,” “expects,” “anticipates,” “projects,” “future,” “targets,” “intends,” “plans,” “believes,” “estimates” (or the negatives thereof) or other variations thereon or comparable terminology. Forward looking statements are subject to a number of risks and uncertainties, which are beyond the control of Mainsail. Actual results, performance, prospects or opportunities could differ materially from those expressed in or implied by the forward-looking statements. Additional risks of which Mainsail is not currently aware also could cause actual results to differ. In light of these risks, uncertainties and assumptions, you should not place undue reliance on any forward-looking statements. The forward-looking events discussed in this content piece may not occur. Mainsail undertakes no obligation to update or revise any forward-looking statements, whether as a result of new information, future events or otherwise.

No representation, warranty or undertaking, express or implied, is given as to the accuracy or completeness of the information or opinions contained in the enclosed materials by Mainsail and no liability is accepted by such persons for the accuracy or completeness of any such information or opinions.

For additional important disclosures, please click here.