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.
1. Every activity is part of a sale
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:
- Gain credibility with people and earn their trust
- Understand their needs and objectives
- Know why they would disagree with or block you
- Know their influencers and allies
- Know who or what else is competing for their time
- Determine how to convince them that what you are proposing is in their best interest.
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:
2. Nail it, then scale it!
The fundamental principle here is to get your product right for one problem space, one market or one set of users, get the rest of the company including Marketing and Sales executing well against the product, and then expand into other problem spaces, other markets or user communities.
One of the most notable examples of a company that failed to understand this principle was Webvan. Webvan was a San Francisco Bay Area based pioneer of online grocery retailing. It was a pretty good service. Orders placed one day before noon would be delivered the next day. They had an easy-to-use website, a broad range of products, fresh produce and reasonable prices. They even had a fleet of slick, modern delivery trucks.
So what was the problem? The grocery business has razor thin margins, and setting up warehouses and acquiring trucks is quite expensive. The Bay Area location wasn’t yet profitable but Webvan expanded to seven additional cities with plans to expand out to about 26 in total. If it wasn’t working out in the Bay Area—one of the most web-savvy and wired regions at the time—why would the other 25 locations be any better? Needless to say, Webvan failed miserably. Total cost of this mistake? $375 million dollars and over 2,000 jobs.
On a more positive note, one of the best examples of a business that does understand this principle is Craigslist.com. Craigslist was founded by Craig Newmark in 1995 as an email newsletter to keep friends aware of San Francisco area arts and technology events. Craigslist evolved into an online community and classified ad site serving the San Francisco Bay Area. Craigslist gathered a loyal following (my wife and I included) of people who would post items for sale, search want ads for jobs, view housing notices, lookup local events and more. Craigslist avoided becoming more than what its users expected and needed. While other web properties were offering their users free email, web search, games, chat, downloadable tool bars and more, Craigslist eschewed such clutter and kept its focus. Today, Craigslist has scaled its service to over 50 countries and hundreds of cities, and is one of the top sites on the web.
This principle applies to software products in general and not simply web properties. Common reasons for not “nailing” it, include:
- Incorrect and unclear understanding of customer needs
- Missing key functionality in the product
- Flawed understanding of the competitive landscape
- Improper pricing model relative to market expectations
- Unaccounted changes in the market landscape
There may be other reasons, but if you look at all of those listed, two things are clear:
- Additional work would need to be done to the product or company processes after the product was released to address the issues.
- All of the issues could be addressed with basic research and analysis, and likely a little extra time added to the development and/or launch cycle.
But telling senior management, or your investors that additional research is needed to ensure the target audiences are properly served, or a product needs to be delayed a couple of quarters (or more) to ensure it is functionally complete is akin to committing professional suicide.
At one startup, an investor asked me, out of three choices for products we were investigating, what was my “gut feeling” of the one that we’d eventually build. I indicated my choice, but added that we needed to finish the research to have a much higher level of certainty. The investor later asked why we weren’t building out the “gut choice” versus completing the research. Mind you, this was one month into a three month research project to identify new products. I was stunned. You’d think the investor would have applauded us for doing our homework before spending the investment dollars.
Sadly, given these types of pressures, rushing to market and subsequent retrenchment to address problems are quite common in software companies. Yet for whatever reasons, few companies actually measure the cost of this type of behavior. And the cost can be quite high. Aside from the extra effort needed by engineering, there is the cost and effort of marketing and selling the incomplete product, and of course, the lost revenue potential from launching a product that was not ready for market. Don’t fall into this trap. Do the homework up front, get the product right and then scale the business to grow revenues.
Some people view change as an opportunity to make things better. Others view it as a threat to the status quo. Some people adapt to change well, others don’t. People’s experiences, backgrounds, biases and comfort zones all play a part in how they view change. People adapt to change better when they feel they have control over the change occurring. If they feel they don’t have control, or feel it is being forced onto them, then it is less likely they’ll adapt. This leads to the next axiom:
3. Change is a process, not an event
It is critical for product managers, who often act as agents of change, to understand the full impact of their actions on fellow employees, customers, prospects, partners and others, and create plans to manage that change and minimize negative impact.
Think of it this way—what’s another word for a sudden change event? Revolution. Now, that might be a great word to use in a marketing campaign, but in the real world revolutions tend to be chaotic, and often times, bloody. Rapid change creates uncertainty for people and organizations, and for most of them, that’s not something they want.
Any type of change, whether it is a price change, a positioning change, or a product change, needs to be clearly defined, its implications understood, executed and then managed over time. If that is not done, the impact of the change will be reduced, and additional time, effort and money will have to be spent implementing the change correctly later on.
When interviewing Product Management candidates, I like to ask the following question:
If you were to describe product management using only one word, what word would that be?
This sometimes catches the candidates off guard, and it’s interesting to watch them think about their answer. Some of the responses are: “requirements,” “customer,” “listen,” “product” and “repeatable.” While some of these answers are better than others, there actually is no right answer to the question. The answer I would give were I asked the same question is: “optimize.”
I view Product Management as a job of optimization. Get the most valuable product to market with a limited set of development resources and generate more revenue than any of your competitors. The question for the product manager is how best to do this? This leads to the final axiom:
4. Think horizontally, optimize vertically
This axiom looks very similar to the well-known phrase “Think globally, act locally,” but needs some explanation.
Companies naturally tend towards silos of activity and knowledge, usually aligned along departmental lines. Product managers need to look across the departments to see how the activities of those departments can be improved to achieve product or product line goals.
Product managers are theoretically the CEO of the product. If that is the case, then their job is to ensure that all related product teams are working as efficiently as possible, and all product-related decisions drive towards the product or product line goals. I’m not advocating that product managers tell others how to do their jobs, but lead disparate functional groups in alignment through the product development and release cycles.
Thus, product managers have to look horizontally across the different silos to identify where things could be more efficient, but any process improvements or other necessary optimizations made must be done vertically—that is within one or more particular silos. Why? Because the silos are the departments such as marketing, engineering, and sales where work gets done and optimizations are possible.
But, product managers cannot simply point out areas of inefficiency to managers in those departments. The product manager needs to make sure that those managers are sold on the change and commit the necessary resources to make that change happen. Recall the example in the first axiom: while Kenji and I had the same goal, Kenji’s approach worked because the sales team was sold on making the change, not for overall company benefit, but primarily because it helped them achieve their goals.
Good product managers need to be part engineer, part marketer, part sales person and part psychologist. And while frameworks and methodologies definitely help product managers in their roles, there are foundational rules that exist independent of those frameworks. I’m sure over time, a few more axioms will become evident to me, but until then, I will continue to use these to guide me in the work that I do.