Product Management Axioms
Fundamental rules to understand when working in Product Management
NOTE: This post was originally written in 2007 or 2008. I honestly don’t remember. It was one of the first blog posts I wrote and was published in the Pragmatic Marketer magazine and also on the web. You can find the original here. The examples in the article may seem a bit dated, but I think they are still relevant as the issues are timeless in my opinion.
Over the years, I’ve used these axioms in some of the work that I do. If you know of or use other axioms (or fundamental rules) in your Product work, please share in the comments.
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 principles that have broad applicability in a variety of situations.
The 4 axioms are:
- Every activity is part of a sale
- Nail it, then scale it
- Change is a process, not an event
- Think horizontally, optimize vertically.
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 or assist you in some way, and to get that, you have to understand their motivations, drivers, goals and objectives.
Case in point
In my first Product Management job, I worked in a software company that had three product lines that were sold by a single sales team. 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. The response:
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 sales promotions, discounts and other incentives. Sadly over those two quarters, Unix sales declined significantly.
Someone else takes over
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.
I told senior management my solution to the problem. Kenji sold his idea to the sales team and the company. The results show the importance of understanding how to sell, even for Product Managers.
2. Nail it, then scale it!
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.
- 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.
- 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
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 customer segments.
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 (especially for the time), 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? 2,000 jobs and over $1,000,000,000 (one BILLION dollars).
A success story
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.
NOTE: Another more recent example of Nail it, Then Scale it, is Amazon Web Services. From very humble beginnings in the mid 2000s (SQS, EC2, S3 etc.), AWS has grown to over 200 individual services and is a hugely popular and hugely profitable part of Amazon’s overall business.
What Stops People From Nailing and Scaling?
This axiom (Nail it, then Scale it) 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 for 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 (Nail it) and THEN scale the business to grow customers, revenues and profits.
3. Change is a process, not an event
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:
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.
4. Think horizontally, optimize vertically
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 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:
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 cross-functional leaders of the product.
And thus, 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 success.
I’m not advocating that product managers tell others how to do their jobs, but lead disparate functional groups in alignment through the product discovery, planning, 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, by those teams.
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. i.e. a vertical optimization.
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.
A little feedback please
If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.
===> Click Here <===
