How to Spot a Partial Product Manager "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs August 08 2019 True partial product manager, product management, Product Management Skills, Stakeholder Management, Mind the Product Mind the Product Ltd 1017 Product Management 4.068

How to Spot a Partial Product Manager

BY ON

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.

This blog post has been prepared solely for informational purposes. The blog post does not constitute an offer to sell or the solicitation of an offer to purchase any security. The information herein is based on the author’s opinion on product management and therefore, generally reflect the opinions and beliefs and related topics and are not necessarily representative of those of Mainsail Management Company, LLC.