2 Easy Ways to Fail at Product Management

The Product Manager sits at a crucial place in the company.

They are the voice of the customer to the developer and the voice of the developer to the customer.

They balance customer needs, business goals, technical capabilities, and scarce resources to ensure that Developers can build products in confidence that their time and expertise are being well spent.

As you can imagine, Product Management is a demanding job, and the stakes are high.

As you can also imagine, there are common traps that many Product Managers step into that hold a product back and can lead to outright failure.

Let’s explore two of the most common, and how to avoid them:

Way to Fail #1: Not Getting Technical

Product Managers are not Developers, and are generally not part of the Development team. True, they may have a development background or training, but the primary value they add is a business value. A Product Manager earns their paycheck by making sure the products meet customer needs and achieve business goals (like profitability, retention, competitive edge, etc.).

That said, it can be a major oversight for a Product Manager to ignore the technical details of their product.

Why?

I was once working on a product that presented service locations on a map to customers based on their address and the address of the service provider. By default, we searched within 20 miles of the customer for locations with the inventory to meet their needs, and then we displayed the options to the customer as pins on a map.

Some of our service location managers asked us to increase the search radius for their locations because they we located in a rural area, and many of their customers lived further than 20 miles away.

This seemed like a simple change, and so the Product Team agreed to make it.

When the requirements were handed to the Development team, they responded that the change was impossible.

First, the variable to increase the search radius was not configured per service location, it was set at a company level. If we increased the search radius, a customer in rural Utah may finally see their service provider listed 35 miles away, but a customer in Boston would now see dozens of pins on their map. We could limit the number of results returned, but the backend system would still need to check the inventory of all locations in the radius, causing major system lag, and thus causing us to fail our Service Level Agreements (SLAs) for website performance.

Essentially, the “simple” change, would cause a major program failure and poor user experience for the vast majority of customers, to solve a problem that was definitionally impacting a very small number of customers.

Ultimately, we did come up with a solution, where we ran the initial search on the original 20-mile radius, and if no results were returned, we gave the option to search again in a 60 mile radius.

The new solution worked, but even then the scope was much larger than originally thought and the Product Team that had committed to the “quick and simple change” at the beginning of the process, was forced to go back to the requesters and tell them that we could not do exactly what they asked, and the alternative solution would take much longer to deliver.

What could have improved this situation and preserved the credibility of the Product Manager? Technical knowledge.

If they had gone into the meeting with a strong understanding of the logic and architecture of their product, they would have known that supporting the customer request by increasing the search radius was not the right approach.

Depending on how deep their technical knowledge went, they may have been able to propose the exact final solution, but this is actually not the expectation.

The Primary value of technical knowledge in these contexts is to be able to understand the capabilities, limitations, and quirks of your product and your Developers.

It is generally acceptable for a Product Manager to get a request in a customer meeting that they recognize needs more evaluation, and to take an action to follow up on the impact and feasibility of supporting the request.

If a Product Manager knows in advance that they will be in a meeting where topics may go beyond their technical depth, and taking actions to respond later is not an option, they can bring in their development leads, but be careful: Developers may or may not have the experience needed to avoid accidentally exposing too much information or committing to a poor business strategy. IF you are going to bring in the Development team for a customer meeting, make sure to brief them in advance on the nature and goals of the meeting, and the need to check with you in a sidebar chat before sharing information with the customer.

I have found that having more technical knowledge allows me to think on my feet in customer meetings, gives me credibility, and allows me to evaluate the impact of requirements and even propose alternative solutions.

Also, the process of seeking that technical knowledge requires building a strong relationship with your Developers, which is a critical asset for success in Product Management.

If you, as a Product Manager, think of yourself merely as a translator between the customer and the Developer, and fail to invest in a technical understanding of your product, you will end up in situations where you lose credibility and damage your relationships with the customers and the Developers, and you will cause confusion and delay to your product, if not outright failure.

Way to Fail #2: Creating Solutions Instead of Goals

This is a VERY easy trap to fall into, because it is how we naturally think.

When we have a problem, we think of a solution.

As Product Managers, when we have a solution, we turn that into a requirement… right?

Wrong.

When you work as a Product Manager, you are surrounded by experts in their own domains. Design, Data Science, Development, Architecture, Marketing, Business Development, Customer Support, and others.

Product Managers have to know a lot about each of these, but they generally do not possess the education or experience for each domain necessary to actually do the job these other teams do.

Designers design. Don’t tell them where to put the button and what color it should be; instead tell them what you want the user to be able to do and why it is important, and let the Designer create the Design that accomplishes that goal.

Developers develop. Don’t tell a Developer that you need to add an event logger to track session progress and status; instead, tell them what data you need visibility into and when, and let them define the solution to meet that need.

Requirements should point to desired outcomes, and share any known context and constraints, but they should NOT outline the solution.

Not only does “solutioning” as a Product Manager fail to leverage the expertise of the professionals around you, but it also undercuts their opportunity to contribute and erodes the possibility of mutual respect between you.

Do you want to work in a job where you are simply handed instructions and told to follow them? No creativity? No problem solving? No Strategic input? No big-picture insight?

You don’t.

I don’t.

Big surprise: nobody else does either.

When you give Solutions instead of Goals, you rob people of the opportunity to shine, and you lose the opportunity to benefit from the brilliance of the people around you.

___

It may seem that I’ve outlined a spectrum, where the extremes at either end are too little and too much technical knowledge, and either one leads to failure, but this misses the point.

While it’s true that too little technical knowledge is a shortcoming that you should strive to improve, the actual need is to be able to recognize the limits of your technical knowledge. Don’t make assumptions, and don’t make commitments you don’t understand.

Bring in the experts.

The more knowledge you gain, the less you need to call for backup, but you ALWAYS need to be aware of your limits.

On the other end, there is no such thing as too much technical knowledge. You can focus excessively on technical knowledge, to the detriment of your business knowledge. The trap is not the knowledge, it is taking it upon yourself to do the jobs of the people around you.

Let your colleagues prove their value and exercise their creativity: you show them the mountain and let them climb it. You will end up with better products, better relationships, and more capacity to do YOUR job.