From development to positioning and pricing, product management is an organizational function that keeps the product and its customers at the forefront of all decisions. They advocate for customers within their organizations, ensuring that their voices are heard.

Product teams routinely ship better-designed and higher-performing products because of this customer focus. More than ever, in the tech industry, where entrenched products are quickly replaced by newer and better solutions, a deep understanding of customers and the ability to create customized solutions are essential.

Below are some fundamental aspects of Product Management

• Understand Expectations
• Identify Your Stakeholders
• Identify Project Scope
• Gather Project Requirements 
• Identify Targets and Milestones
• Determine Reporting Needs
• Get the Product to the Customer

What product management is not

Many companies remain stuck in old, failed product management models and fail to recognize the importance of role definition in building effective teams and successful products.

There are numerous articles that describe what the job of a product manager entails, but in this article, we’ll take a different approach and emphasize what the job is NOT.

Pointing out these misunderstandings will help companies recognize where they’re going wrong and, hopefully, reconsider how they’re defining this role.

1. Product Management is not in charge of defining the business case.

Some product managers presume that their primary responsibility is to define the business case for why this product should be founded. Is the business case necessary?

Without a doubt. Specifically, management will use this to make investment decisions. However, this does not contribute to the actual creation of the product. In many organizations, the product manager creates or contributes to the creation of the business case, which is fine, but don’t confuse this with the product management job.

2. Product Management is not responsible for determining customer needs.

Many businesses believe that the product manager defines consumer demand and that technicians build products and services to meet those market requirements. The product manager produces an MRD (Market Requirements Document) that addresses what the product manager believes the market looks for, and then the reader is left to define the product that meets these requirements.

There are two issues to consider here.

So-called “market requirements” false dichotomy.

• Markets have no requirements. People do.
• The person who will be defining this product must speak with these people directly.
• If the engineer is the one who defines the product, he is the true product manager, and you can only hope that he understands that as the product manager
• He needs direct face-to-face conversation with actual consumers.

The delusion of separating market requirements from product requirements.

• The goal is to find a product-market fit, which necessitates a thorough understanding of both market needs and technological capabilities.
• During the discovery process, true market requirements and technical solutions that successfully address these requirements are identified.

Some corporations, particularly those with a direct sales organization, have a model in which the product manager’s job is to gather requirements from customers or potential customers, record them for engineering, and then ensure that those requirements are delivered by the dates the salespeople promised the customer.

This is not the same as product management. Project management of personalized technology solutions is what this is all about. True product companies understand that customers have points of discussion, but they do not have the authority to dictate product specifications. In other words, you must not confuse a customer’s requirement with product specifications.

Be cautious of anything that promotes the “requirements capture” or “requirements management” mindset. It is a very slick, steep hill and one of the most likely paths to product failure.

3. Product management is not the same thing as project management.

In some organizations, the product management group evolved from the project/program management organization, particularly when the company has an IT or custom software heritage. In this model, the product manager is regarded as the person responsible for gathering and documenting requirements, as well as managing the project from conception to completion.

However, the discovery process is more than just a task in a project plan. It is its own process, distinct from the product development process. Furthermore, because the nature of each type of person is so different, it is uncommon to find individuals who enjoy both product management’s discovery and delivery.

4.  Product Management is not the same as product marketing.

Product management is not concerned with pricing, promotions, positioning and messaging, or product launch activities. It’s also not about online marketing, customer relationship strategies, or influencer marketing campaigns. These are all critical activities, and the product manager will contribute to many of them, but don’t confuse them with product management. These are product marketing activities, and you will need a skilled marketing person dedicated to this for all but the smallest products.

 In contrast to product marketers, the product manager is in charge of developing a product that is useful, usable, and feasible. If he can accomplish this, he has completed his task. If he can’t, it’s pointless to spend the time and money developing and launching the product.

If your company commits any of the aforementioned errors, it might be a good time to speak up. Inquire if you could experiment with changing the role of your next product to see what happens. We believe that if you can focus on discovery, you will be able to demonstrate to your company what product management is all about.

The history of product management

During the Great Depression, a 27-year-old marketer proposed the concept of a “brand man”—an employee who manages a specific product rather than a traditional business role. The continued success of this function has resulted in the growth of product organizations across industries and geographies since the 1930s.

1931 — Neil H. McElroy, a marketing manager at Proctor & Gamble, writes a 300-page memo on the need for “brand men,” who manage specific products.

Late 1930s — McElroy is an advisor at Stanford University, where he influences two young visionaries: Bill Hewlett and David Packard.

1943-1993 — Hewlett-Packard sustains 50 years of 20% Y/Y growth by implementing the “brand man” philosophy in their new company.

Late 1940s — Toyota develops JIT manufacturing principles, later adopted by Hewlett-Packard.

1953 — Toyota develops the kanban method.

1970s — Tech companies in the U.S. start developing lightweight processes, in opposition to cumbersome processes that emerged from manufacturing industries.

1980s — Developing agile processes, combined with greater acceptance of “brand management” roles, takes hold in many technology and software companies.

2001 — The Agile Manifesto is written, which, in large part, broke down department silos and outdated processes, to make room for a unified product management role.

Visualizing the Future of Product Management

Product management is a multidisciplinary endeavor that is as elusive as it is straightforward. Product managers develop empathy for customers and communicate their needs to the rest of the organization. They collaborate most closely with development teams, but they also require support from marketing, design, and management. Their magic ingredient is their ability to understand and communicate with people who speak a variety of languages. In reality, product managers determine the future of product management.