Here is a small set of axioms to guide you in your job, bring focus to tasks at hand, and convey fundamental ideas and principles in discussions.
Over the years, I’ve worked in a number of software companies, small and large. While there were certainly many dissimilar things in these companies, I did notice some specific patterns related to product management that existed in all of them.
Based on these patterns, I developed a small set of Product Management Axioms to guide me in my job, bring focus to tasks at hand, and convey fundamental ideas and principles in discussions. These axioms are based on personal experience and empirical evidence. They do not cover all things I do as a product manager, but like all axioms, they are general precepts that have broad applicability in a variety of situations.
As product managers, we usually work alone or in small teams. We typically don’t have direct control over development, marketing or sales resources. And we certainly don’t have direct control over senior management. But a strong product manager must have the skill to influence what these groups think, decide and do. This leads to the first axiom.
More than simply influence, the ability to actually sell people on ideas is a critical factor in the success of any product manager. In my experience, sales is about truly understanding what others value as important, and using that knowledge to show how your ideas and proposals will help them acquire or achieve those things. This is true for both internal parties and external ones such as customers and partners.
To influence people, you must:
While this reads like a checklist from a sales training course, it is also exactly what a product manager must do to influence others.
Understand how you can help them and they will likely help you. The sale is in getting their agreement to do what you want, and to get that, you have to understand their motivations, drivers, goals and objectives.
Case in point: In the 1990s, I worked in a software company that had three product lines that were sold by a single sales force. The majority of sales were via the phone and web. The product lines consisted of one older, but very profitable set of Unix products, which for years had been the mainstay of the company, and two newer lines of Java products that were growing rapidly, but not yet profitable. Given that senior management was focused on growing the Java based products, the sales force focused disproportionately on those, to the detriment of the Unix product line. I was the product manager for the Unix product line.
Seeing the problem, I asked the sales reps why they weren’t selling more Unix product. Given the corporate focus on Java, none of them felt they’d benefit from time spent selling what they considered a legacy product line. I certainly didn’t see it that way.
I felt that creating a separate Unix-focused sales team would solve the problem. Several reps agreed with this logic as they viewed the Unix and Java customer bases and sales cycles as very different. We also had supporting empirical evidence from one of our VARs who had successfully done something similar. I proposed the solution to senior management and explained my reasons for wanting to split the sales team.
I was told in no uncertain terms that the company was fundamentally against creating separate sales teams and that I’d have to find other ways to convince the sales reps to sell more Unix product. I tried unsuccessfully for two quarters, with spiffs, promotions and other incentives. Sadly over those two quarters, Unix sales declined significantly.
Soon thereafter, I decided to move to another role in the company. The next Unix product manager, Kenji, facing the same problem, similarly concluded that splitting the sales teams was necessary. But instead of using my approach, he ran some numbers and convinced a couple of salespeople that they could make more money if they focused solely on selling Unix products. Given that the other sales reps wanted to spend all their time selling Java, the two reps went to the VP of Sales and convinced him to support the idea. The VP saw it as a way to increase overall revenue and also keep his salespeople happy. The VP of Sales then got the President to approve the change.
Lesson learned. People, regardless of who they are, are fundamentally driven out of self interest. This is not meant in any derogatory way, but simply to indicate that they will make decisions weighted significantly towards themselves or what they hold dear. In this case, while both Kenji and I had the same objective, the approaches were radically different. Kenji ensured that not only were his objectives met, but also those of the individuals whose agreement was needed to make the change.
When working in a startup or on a new product, there is a tendency to focus on time-to-market as a key measure of progress. Getting to market ahead of competitors is important, but is it more important than getting the right product to market, even if it demands extra time?
And what is meant by the right product? It means understanding what to build, who to build it for and why they would actually pay for and use it. It means knowing how much functionality is necessary to get you to market successfully without over investing on efforts that don’t provide a return on investment. It means understanding what your potential customers’ alternatives are and why they would choose your solution over others. Learning these things takes time, effort and money, but never as much time, effort or money as it takes to build the wrong product for your market and then try to sell that product into that market. This leads to the next axiom:
Saeed Khan has more than 15 years of experience in product management and has worked at both startups and public companies, in roles ranging from individual contributor to vice president of product management. He writes for onproductmanagement.net and has previously contributed to Pragmatic Marketing’s print and online publications. He has spoken widely on the topic of product management and product development at a variety of events, including numerous ProductCamps. Based in Toronto, Canada, he can be reached at firstname.lastname@example.org.