Skip to main content

The #1 Mistake Made by Product People at All Levels

In my 20+ year career in product management for B2B enterprise companies, I have seen product managers at every level make a certain kind of mistake. It is so easy to make that I occasionally make it myself when I'm not careful.

What is this mistake? It is to spend too much time on tasks and deliverables that are not core to the product function, which is to to determine and define products to be built. If you keep falling into this trap then ultimately you can't be effective at your job and your company won't sell compelling products.
Your primary job as a product manager is to figure out what your market and customers need and make sure it gets built. If you aren't careful, you can spend all of your time performing tasks in support of products such as sales enablement, customer success, product marketing, and pre-sales.

How Do You Know This Is Happening?

It is easy to fall into this trap for many reasons. Here are a few scenarios that come to mind:
  • Product Marketing is working on an RFP for one of the biggest deals of the quarter and there's no one else available who can answer detailed questions about your product, especially in answering about features that your product doesn't support yet.
  • Sales needs help putting together a set of bullets describing your product's unique value proposition and how it solves problems better than the competitors.
  • The Docs team needs someone to review the docs of the latest feature or release and they can't seem to get anyone in Engineering to take the time to look them over for correctness.
  • Customer Success needs a "quick" doc to explain a complicated new feature to a handful of premier customers who want to implement it quickly.
  • Customer Success and Engineering want to launch a beta of the upcoming release but they need someone who can lead the beta program, organizing a list of trial customers, coming up with a test plan of new features and coordinating weekly calls with each customer.
All of these scenarios are perfectly valid and move the business forward. I've spent considerable time myself on helping with these types of requests. Especially in a startup, we need to do whatever we can to make the business successful.

Consequences of the Problem

The problem, however, is when you are so busy fulfilling urgent requests like this that you have no time for the strategic job of product management, which is to determine what you should be building. Understanding the market requires time to talk to customers and understand the pain points they're trying to solve, or time to study competitors and their documentation to determine how you can uniquely differentiate yourself in the market.
It is easy to feel like you are adding value to the organization by performing lots of tasks that seem high priority and are valued by other teams. But if you can't spend time on strategy or customer and market research then ultimately you aren't being effective at your job. Your company will execute well on the products it has but in the long run it won't be competitive and uniquely differentiated.

How Do You Respond?

So how do you avoid this problem? As with many things, the first step is to realize when this is happening. If your to-do list is filled with accomplishing tasks or deliverables for other teams and you aren't dedicating blocks of time to talking to customers about their pain points or researching competitors then you are most likely getting bogged down.

How you respond is dependent on your role within the organization. If you are an individual contributor such as a product manager or senior product manager, let your manager know that you are getting bogged down in tasks that aren't contributing to your core mission as a product manager. Give concrete examples of what you are asked to do and how much time this is taking. Work with your manager to gently push back on other teams that are requesting your time on all of these tasks.

If you manage product managers or own the product function at your organization and this problem is either happening to you or your direct reports, it is up to you to solve it. One key is to clarify the tasks that Product is responsible for, versus other functions like Customer Success or Product Marketing. 


Here are some examples:

  • Who owns RFPs at your company? Product wants to contribute to the success of the company by helping with RFPs but another group such as Product Marketing or Customer Success typically owns them. This other group needs to take responsibility for incorporating Product's responses into RFP boilerplates and using less of Product's time.
  • Who owns sales enablement? This is typically handled by Product Marketing or a similar team. This team needs to get more up to speed on the product so they can regularly handle tasks like creating bullets describing the product's unique value proposition. Product can help but this isn't part of their core job.
  • Who owns ensuring that docs are technically accurate? This typically isn't owned by any one group but it shouldn't fall all to Product. Engineering should get involved. If no one else is reviewing docs then this should be escalated to a manager or director within Engineering.
  • Who owns the beta process? Running a beta involves an extensive amount of project management and would ideally be handled by a dedicated project manager. Product may manage some projects as part of the feature development process but running a beta shouldn't be done by Product just because they are good at managing projects. Usually someone within Engineering should own the beta process but explicitly make this decision rather than having Product do it by default. 

The Importance of Ownership 

Note that I use the word "own" a lot in these examples. This is key to figuring out how to solve this problem. As a rule of thumb: 

  • Spend more time on functions owned by Product like roadmap planning and market or customer analysis.
  • Spend less time on functions owned by other teams. If you are spending too much time here then go to the owner of the function and clarify to them that you are glad to help but this isn't part of your core job and you need to spend less time.



  1. wonderful article. Very interesting to read this article. I would like to thank you for the efforts you had made for writing this awesome article. This article resolved my all queries. producthunt


Post a Comment

Popular posts from this blog

Building a Hadoop cluster

I've recently had to build a Hadoop cluster for a class in information retrieval . My final project involved building a Hadoop cluster. Here are some of my notes on configuring the nodes in the cluster. These links on configuring a single node cluster and multi node cluster were the most helpful. I downloaded the latest Hadoop distribution then moved it into /hadoop. I had problems with this latest distribution (v.21) so I used v.20 instead. Here are the configuration files I changed: core-site.xml: hdfs://master:9000 hadoop.tmp.dir /hadoop/tmp A base for other temporary directories. # Variables required by Mahout export HADOOP_HOME=/hadoop export HADOOP_CONF_DIR=/hadoop/conf export MAHOUT_HOME=/Users/rpark/mahout PATH=/hadoop/bin:/Users/rpark/mahout/bin:$PATH # The java implementation to use. Required. export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home hdfs-site

Working with VMware vShield REST API in perl

Here is an overview of how to use perl code to work with VMware's vShield API. vShield App and Edge are two security products offered by VMware. vShield Edge has a broad range of functionality such as firewall, VPN, load balancing, NAT, and DHCP. vShield App is a NIC-level firewall for virtual machines. We'll focus today on how to use the API to programatically make firewall rule changes. Here are some of the things you can do with the API: List the current firewall ruleset Add new rules Get a list of past firewall revisions Revert back to a previous ruleset revision vShield API documentation is available here . Before we get into the API itself, let's look at what the firewall ruleset looks like. It's formatted as XML: datacenter-2 ANY 1023 High 1 ANY < Application type="UNICAST">LDAP over SSL 636 TCP ALLOW deny 1020 Low 3 ANY IMAP 143 TCP < Action>ALLOW false Here are so