Help! I’m demo boy for sales people

Or, Be careful what you teach your sales teams

call meA VP wanted to improve the visibility and perception of product management with the sales people so he created a series of video introductions of his team. The videos included the product manager’s background, areas of expertise, and contact information. Once they were distributed, sales people asked, “Can we share these with our clients?”

In my early days as a product manager, I really enjoyed doing product training for the sales people. I was good at presenting. I enjoyed it. And I wanted them to see the presentation and demo done correctly at least once. Yet all the sales people said, “Man! That kid is good. I’m going to take him on all my sales calls.”

In a similar story, the VP of sales distributed the home and mobile phone numbers of all product managers to the sales channel (including international). Within a week, all of the product managers had gotten new, unlisted phone numbers.

These scenarios—with all the best intentions—resulted in sales people perceiving product management as the go-to resource for all things product.

Is that what you want your product managers to do?

How to fix it

The key to fixing this is to listen to what your sales team is telling you. They need a go-to resource and they need tools they can share with their customers. When your sales team doesn’t have deep product expertise, you need to empower them with sales tools that do the heavy lifting. Here are some suggestions.

Sales enablement tools

When sales people ask, “Can we share these with our clients?” they’re telling you they need more and/or better sales tools. In fact, they’re so desperate for sales tools that they want to share videos of the product managers! What’s that about?

Put on your product management hat and evaluate the implied requirements. What are your sales people requesting? Break it down into the sales funnel and strive to understand which steps need supporting tools. Develop these tools and share them broadly. And make them a key element of your product training.

Product training

Many product managers feel their sales teams need deep technical knowledge of their products so they try to educate the sales people on their years of experience. But the sales people quickly realize they’ll never have this level of experience. Their solution: just call on the product manager when the client needs deep knowledge.

Make product training less about transferring your knowledge and more about finding information.

Here’s an alternative approach to product training. Make the agenda about the buyer’s journey and the sales funnel. Start with a definition of the markets and personas. Explain the compelling events that typically cause a client to initiate a project. That is, explain what a qualified prospect looks like. Once you’ve profiled the buyer, distribute a list of sales enablement tools, organized by step in the sales cycle, with links to where the content can be found on your sales portal. Show them how they can help themselves.

When it comes to product, get one of the sales engineers to deliver the presentation and demo. Sure, the sales engineer might not do quite as good as job as you would but it will show the sales people that their own field resources are knowledgeable about the product.

Sales engineering

Perhaps the best way to support the sales effort in your company is to be an advocate for sales engineering. Sales engineers are product experts in the field. For sales people, the SE should be their first call. In my experience, most companies with complex products and a direct sales force require one sales engineer for every two sales people. What’s your ratio? Unfortunately, many teams have understaffed and sometimes underskilled the sales engineering group. And when sales teams don’t have access to the skills they need, they’ll call on product managers.

Set up a sales support desk

If you continue to get product support calls from sales people, maybe it’s time to formalize your team’s sales support. Create a sales support desk and staff it with a junior person who knows where to find answers. Put this person front-and-center in all your communications. Put this person in charge of the product content areas of the sales portal so he or she knows where to find sales tools and content.

And maybe it’s not just one person. Another approach is to set up a dedicated mobile phone and a general email account for the product management team to share. Each product manager takes charge of these for one day and then passes the responsibility (and the phone) to the next person in the queue.

As with anything else, you should track the number and nature of these communications. Whenever the support desk gets repeated requests for a certain type of information, it’s clear that you have to develop and document a solution.

What next?

Considering all the typical company asks of sales people—relationship building, navigating the complex sale, negotiation—it’s really surprising that we also expect them to be technically adept. And maybe yours are. But if not, empower them not with education on the technology but with education on how to provide answers. The more you know about how buyers buy and sellers sell, the more you’ll know how to support your sales teams.

The Five Scariest Words a Product Manager Can Hear

By John Mansour

“We’ve created an innovation team.”

scaredOh, great! Just what every product manager needs – more shiny new objects competing for the same resources that should be going toward product improvements needed years ago.

Innovation is great, but too many organizations define innovation to be synonymous with new products. And that generally leads to expectations that over promise and under deliver.

Innovation is most successful in organizations that see it as an end result, usually falling into one of three categories:

  • Finding a new way to solve an old problem because of a new method or process.
    • In 2005, BarCamp became a new way to put on a conference that ensured session topics of greatest interest to the participants.
  • Technology advances that enable new ways to solve old problems.
    • GPS location services on mobile devices that make a host of things easier for businesses and consumers.
  • Uncovering needs people didn’t realize they had until there was a solution, then it became all the rage!
    • DVRs in the United States, circa 2000.

How do these organizations consistently arrive at end results that are innovative? It’s a mindset, and it doesn’t start with looking for problems. It starts by understanding what your target customers are ultimately trying to accomplish and the obstacles standing in their way.

Since big data is such a hot topic these days, I’ll throw some love to a small technology company in Atlanta, GA – Emcien – that has taken a very innovative approach to big data.

Most companies hawking big data solutions are touting better ways to organize the data. They make it easier to ask complex questions of the data and get answers that offer better insights to running the business. It’s a strong value proposition.

Emcien has come at big data from a completely different perspective that goes something like this: “Your big data is so big you don’t even know what you don’t know. So stop asking the data questions and let it give you answers to questions you’d never think to ask.”

Emcien’s solution is predicated on pattern recognition. It finds patterns in the data you wouldn’t dream up on your best day. Talk about valuable insights! Emcien’s founder understood the ultimate goal of mining big data – tell me something useful and insightful I’d never think to look for that will ultimately help grow the business more profitably. That’s innovation!

A Simple Solution for Product Management

B2B companies don’t realize how easy it is to build innovation into their product management discipline (which may go beyond the product management department). It’s a matter of dedicating part of that discipline (10-20%) to understanding the goals of their target customer organizations from top to bottom and the biggest roadblocks preventing them from meeting those goals. With that level of domain expertise in hand, the other 80-90% of the team responsible for the products can deliver solutions that hit the bulls-eye every time.

Innovation teams don’t have to be a nightmare for product management if they’re integrated in a manner that aligns the goals for the entire portfolio to the goals of its target customers.   When that alignment occurs consistently, your organization experiences more profitable growth because everyone shares a common mission – the profitable growth of your target customers.


Tweet this: The 5 scariest words a Product Manager can hear - #prodmgmt #innovation

About the author

John Mansour is a 20-year veteran in high technology product management, marketing and sales, and the Founder of Proficientz, a services company focusing on product portfolio management.

It’s difficult to manage P&L…

It’s difficult to manage the P&L, when you don’t have control of the “P” or the “L.”—Rich Nutinsky, Pragmatic Marketing

It’s fairly common for product managers to be asked to act like “mini-CEOs” or “the president of the product. Good idea in concept but harder to implement in real life.

Even if you don’t have actual control over P&L, you can control reporting of P&L. Try using a scorecard approach.

I was working with a team on their scorecard but alas, all of their metrics were focused on development productivity: how many defects, how many hours, how many stories, how many features…?

But what about metrics on the business of the product from your perspective?

  • What are development costs against plan? Revenue against plan?
  • How many calls to support? Is that more or less than the monthly average? What is the trend?
  • How many leads from marketing? How many were rejected by sales?
  • What is your win rate and what are the top reasons by you lose?
  • What are the trends in Net Promoter Score or other loyalty-related metrics?
  • Fundamentally, what are some of the business metrics you should have at your fingertips? What questions are your execs asking that you should be able to answer? Be the source of metrics on the business of the product!

What other metrics would you capture?

Understanding the role of Product Manager

by Pandith Jantakahalli

whatdoesproductmanagerdoA product manager helps a company achieve its goals by helping customers get their jobs done in an unique and delightful way, and getting customers to pay in some form (money, attention, information).

Let me elaborate on the key responsibilities encapsulated in the above definition.

Getting jobs done: A parent purchases your app to keep her six year old daughter entertained over a three hour train ride. The parent did not purchase the app because it uses the latest technology or she liked how your app is designed/looks. A product manager must understand what “jobs” or outcomes a prospective customer is trying to accomplish. This can also be seen from the lens of solving problems. But I prefer the “jobs approach” as it provides a richer understanding of the context in which a product/feature will be used, why someone is using it, what outcomes they are hoping to achieve, and what they need to stop using to begin using your product. A product manager must ensure that the team builds something compelling enough for customers to switch away from an existing solution that they are currently using. This framework is especially helpful in understanding your real competitors or alternatives that the prospective customer has, to get the same job done.

Lens of solving problems -“real problems”: A product manager must ensure she focuses the team’s effort on solving real problems that will help the company achieve its goals. “Problems” that are ignored are usually not worth working on. The pain killer vs vitamin framework is a useful for assessing the intensity of the pain/problem. Des Traynor’s perspective on “Making things people want”

Making things people want involves understanding a long standing human or business need and then using technology to:

  • take out steps
  • make it possible for more people
  • make it possible in more situations

Flawless execution cannot save a company (or a product or a feature) that chooses to focus on jobs/problems that nobody cares about.

Unique: Prospective customers will have an array of options to get their jobs done. The product manager must pick a customer segment and a dimension (like Amazon’s delivery of ordered items within 30 minutes) that is aligned with the most important outcomes/jobs that the customer wishes to accomplish. This decision is critical in ensuring prospective customers consider your product when they want to hire a product in a specific situation.

Trying to be everything for everyone or “unique” for the sake of uniqueness is usually a recipe for disaster. Choosing a dimension that is important to the customer and has very little competition helps build a defensible business.

Delightful: While thorough and thoughtful attention to detail helps, Kathy Sierra’s talk on Minimum Badass User provides sage advice. Focus on improving the user’s life and/or skills. What “badass” powers does the user get by using your product?

“People don’t use your app because they like the app or they like you, they are using it because they like themselves, and they tell their friends because they like their friends!” – Kathy Sierra

Establishing reference customers is critical for scaling any business, and you will have reference-able customers only if you have delighted them while getting their jobs done, using your product.

Pay: In a business context, the product must generate enough revenues to grow and sustain the business over the long term. The product manager must be adept at picking a business model that captures enough value for the business to thrive, grow, and remain viable.

Another critical responsibility of a product manager is validating that the solution (product) that is built is actually helping the customer get their jobs done and delighting them in the process. Some product management frameworks mandate that the product manager must focus only the “problem space”. I strongly disagree with this specific recommendation. Validation of the solution/product that has been built is as important as specifying what to build. I am not advocating the product manager specifies how to build. Does that mean the product manager does not validate other critical decisions like validating intensity of a problem? No. I am specifically calling out this aspect as a product manager plays a crucial role in deciding whether to ship a product/feature based on this validation.

Summary: Prioritizing which jobs/problems to work on, which customer segments to target, which dimensions to compete and excel on, how to access customers, how to capture value, determining what will delight users, how to scale the business, and validating what is built are key responsibilities of a product manager.

Two other perspectives on the role of product management that I like are one by Marty Cagan:

Discovering a product/feature that is valuable, usable, and feasible

and the other by Satya Patel:

“Product management isn’t a role or a function, it’s a set of skills. Those skills help remove obstacles and grease the wheels so that the functional experts can do their jobs best. Product management also balances the needs of users, the business and the team and makes the difficult tradeoffs needed to keep pressing ahead. In that way, Product Managers are very similar to CEOs. Very few would argue that a company doesn’t need a CEO. Product managers are simply CEOs of their products. No organization should be without someone who has ‘product management skills’ and works to make everyone else’s lives easier.”

Note: Every interaction that a prospective customer or customer has with a company is viewed as the “product”. It is not just the physical product or the service that is provided. Examples: looking for information about the product on the website, reading the user manual to understand different options/modes supported by a specific feature, response to an email query that was sent to the support address.

pandith-bwPandith Jantakahalli is a practicing product manager with over 17 years of experience and lives in Bangalore, India. He has helped craft a variety of web, mobile, and shrink wrapped products. In his spare time he enjoys birding and photography.



The Whole Product Manager

If you liked this post, please retweet: “The Whole Product Manager by @PGopalan via @OnPM”

This past weekend, I had the opportunity to give a talk on The Whole Product Manager at ProductCamp Austin.  My thesis is simple.  The traditional path to becoming a craftsman (or craftswoman) at product management, while paved with good intentions, often leads you to copy and paste territory – repeat the same and expect a different result.  Great products get created when there is a relentless pursuit to product excellence.  It is a life long journey rather than a formula that can be handed out in the form of a bunch of templates at a 3 day ‘product management training’ or a 2 year MBA program.

To be successful at product management we need both maker skills and meta skills.  Maker skills are generally skipped by product managers and senior product leaders in their corporate ladder climbing activity.  As they get into management positions, they lose the curiosity to learn and start ‘managing’ instead of producing anything.  Even the PowerPoint slides they pitch are someone else’s work.  Without the basic maker skills these product leaders lose the respect of their own teams, not to mention their inability to guide their teams or add significant value to the product development process.  But maker skills alone aren’t sufficient.  There’s very little emphasis in any cookie cutter product management training or on the job training, on how to build influence and lead teams indirectly.  These are meta skills – the ability to scan the environment, sense various stakeholder motivations and needs, communicate effectively and lead the product to success.  We need a deliberate effort to learn these skills.

Product management is an interdisciplinary subject.  To excel at product management dedicating ourselves to the pursuit of excellence from the ground up is but one approach to craftsmanship.

Prabhakar (@PGopalan)

Professional development and succession planning

By Steve Johnson

The standard rejection letter claims “We’ll keep your resume on file.” But do you really?

Statistics on job tenure seem to be all over the map. Generally, high-tech workers seem to stay in the jobs for approximately 4 years. The median employee tenure at Google is just more than one year, according to the payroll consultancy PayScale. Executives in sales tell me they expect to replace sales people every 18-24 months. And with all the changes in marketing technology, you’ll need to re-train or re-staff to get skills in the areas of content marketing, marketing automation, mobile, and so on.

So you’re going to hire new people. Whatcha gonna do?

Every VP should have a “resumes” folder with people who are already (at least somewhat) vetted.

Think about the last time you recruited. Were there some standout candidates who didn’t make the cut? How about the folks you met at a conference? They should be in your “go to” folder for when you’re looking next time.

I attended a productcamp last year that was sponsored in part by a hiring manager. She figured the sponsorship fee was a fraction of what she’d pay a recruiter. And she’d have the chance to meet dozens of applicants in a single day.

As others have said, Dig the well before you’re thirsty.

In general, I don’t find that companies do a very good job of succession planning. How can you get promoted unless you have someone in the wings ready to take your spot?

If you’re a product manager or product marketing manager, you should be networking now for the job you want next year. If you’re a hiring manager, you should be building a database (or file folder) of people you can reach to fill a job quickly.

Both employees and employers should be networking. And a good place to do that in the tech biz is productcamp.

How to deal with a Zombie product

by Saeed Khan

zombie2If you turn on your television or go to the movies, or read books, it seems like zombies are everywhere.  And while those zombies are fictional, there is one type of zombie that is all too real, and that we unfortunately have to sometimes deal with. That zombie is not going to eat your brain, though you may lose some brain cells in dealing with it. That zombie is the “Zombie product”.

What is a Zombie Product?
As you know a zombie is someone who is neither dead, nor alive….undead as they say. A zombie product is a product that is not successful by any measure (very few customers, little market share, lacking needed functionality, buggy etc.) but also cannot be “killed” or removed from the market because of some reason or another. Usually the reason for keeping an otherwise failing product on the shelf is that it is viewed as “strategic” or “important” in some way to those higher up in the company.

The product is usually important enough to them that it needs to continue to be presented to the market, but not important enough to  devote funding in order to fix the issues it has, add needed functionality, market it to increase market share etc.

You may have just joined a company and were made responsible for it, or your company had a reorg and you drew the short straw or maybe you’re just a glutton for punishment, and you volunteered to take this product on. Regardless of the reason, this not-so-beautiful baby is yours. Now what do you do? You can’t bury it, but there are no development resources to fix issues and bring it back to life.

1. Treat it like an early stage product

If you’ve ever worked with early stage products — i.e. with few or no customers — you were in a similar situation to the zombie. That early stage product was weak or missing functionality and didn’t address many use cases, if any, well. But, that product had some core value to some group of people and that’s who you identified and targeted as early customers.

Use the same approach with the zombie. It’s not going to appeal to everyone, but it must have some core value proposition, even in limited use cases, that is meaningful to certain groups of people. Who are those people and what is that meaning/value?

2. Find the core value from current users

It’s easy to say something trite like “just talk to users” and find out why they value the product. If you are lucky, then some simple conversations may find the answers you are looking for. But what you really need to do is find the core problems they are addressing that *necessitate* using your (undead) product.  Get inside THEIR brains (pun intended), and get a clear picture of  why they they put up with the product’s limitations or issues.  Listen carefully to what they say, because something they might not think is important may be the key to defining a broader core value that could be applicable to broader audiences.

3. Keep the use cases narrow and focused

Once you get that core value identified, define a small number of specific use cases for the product that your sales and marketing teams (and prospects) can understand. Keep those use cases narrow and well focused. Given that you have no resources to fix issues, don’t set yourself up for problems later.  Remember, the company still needs to maintain appearances with respect to the product, and so the product needs to be relevant to sales and marketing. i.e. the company, and thus you, cannot simply ignore the product.

Those use cases form the basis for all downstream go-to-market activities. All sales/marketing collateral, training, messaging etc. should be focused on the core value and use cases. This is certainly true for most products, but especially true for zombies. You don’t want to waste any extra cycles on anything that is ancillary to your goal.  No extra effort expended. No extra cycles wasted.

That’s it. Until the company decides to either kill the product or invest resources, there are few other paths to follow.

Have you ever managed a zombie product? How did  you handle it? Let us know.


Tweet this: How to deal with a Zombie product - #prodmgmt 

About the author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership.

Alas, the one-hour meeting

If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be meetings.—Dave Barry

What would you do differently if meetings could only be 5 minutes, 20 minutes, 90 minutes, or all day? No hour-long meetings!

How many times have you really started to get into the thick of an idea only to find the allocated meeting time has expired? Or realized after only a few minutes that the subject doesn’t require an hour but you keep at it because that’s the time allocated?

It’s unfortunate that our calendar programs insist on booking one-hour blocks. Some meetings only need to be 20 minutes; others need to be two or three hours. But we tend to comply with our calendar programs and book everything for one hour.

Some meetings are too long

Status meetings and check-ins should be short. Really short! A popular idea today is the “stand-up” meeting. The goal of this meeting is to identify what various team members are doing and ensure that they’re not working in conflict. Make sure they’re not working on the same projects or using the same resources. Make sure no one is preventing someone else from moving forward.

Don’t let these become general status meetings—once everybody has their 3-5 minutes you’ve lost a whole hour! That’s why meeting gurus recommend an egg-timer for stand-ups. Keep it brief and move on!

Some meetings are too short

Problem-solving meetings should be long. These meetings explore an idea, solicit different approaches, and build to a consistent understanding with an action plan. They tend to need more than an hour.

Meetings that need to be longer include assessments, retrospectives, and planning meetings.

When it comes to meetings, one size doesn’t fit all issues. Don’t let your calendar interfere with doing the job!

What’s your advice or favorite story about meetings?

For more on meetings, read Death by Meeting: A Leadership Fable by Patrick M. Lencioni.

Your first days… as product manager

By Steve Johnson

You’re in your first days as a product manager. In no time, your calendar is full and you have a zillion emails. There’s so much to do. Where to begin?

Before the demands of others overwhelm you, you need to prepare yourself to be the business and market liaison to the product team. Your role as a product manager or product owner is to make the best business decisions for the product, working from the best available information.

Refresh your domain expertise

If you’ve been in your industry for years, you probably have strong domain expertise but you may not be up-to-date on the latest information.

Review the corporate pitch. Perhaps the fastest way to get up to speed on your company and its role in the industry is to review the product and corporate slide decks. Whether your company is a bellwether in the industry or on the periphery, what’s been said in the past will help you understand how your company and its products are perceived, at least from the perspective of your new organization.

Catch up on the latest blogs and articles. Take time to review the latest thinking in your industry. And even if you’ve been in the domain for years, it’s always helpful to take a new look from your new perspective as a product leader. Reports from industry analysts may reveal new industry trends, and perhaps show how your company and products are influencing them.

Fill out your technical expertise

You may have some familiarity with the product from your past research. Now it’s time to get into the raw details.

Know your new product. What documentation exists for your product? You can probably find some customer documentation and help screens, release notes, product plans, sales and conference presentations, white papers and ebooks, and sales enablement tools. Review them all. Learn the key capabilities, particularly those that are competitive differentiators.

Review the product roadmap. And where is the product headed? Has anyone developed a roadmap for the next few releases? How does what you’re seeing align with what you know about the domain and industry?

Understand the architectural themes and challenges. Talk to the developers about the technical challenges for the product. What percentage of development effort is spent on architecture and defects versus new functionality? And while you’re at it, interview the developers about their perspective on your role in moving the product forward.

Update your market expertise

You likely have some market expertise but it never hurts to give yourself a refresh.

Sit in on some customer support calls. Want to know what’s going on with your product in the field? Ask customer support. They know about technical problems with the product as well as customer implementation problems. Sit in on some support calls and listen to customers directly.

Go on some sales calls. It’s fascinating to examine the contrast between the product as perceived by the product team and by the people in the field. When you’re on a customer visit with your sales team, you’ll hear how the product is being sold—right or wrong. You’ll also hear unfiltered customers’ problems in their own voices. Listen to the language they use; listen to the problems they’re trying to solve. You’ll get plenty of ideas for how to improve the selling and promotion of your products. And you’ll get to know some sales people in a more social setting; they’ll be your contacts in the future when you need advice on sales enablement and product improvements.

Do some installation/implementation visits. For enterprise products, implementation is where all your sales and marketing promises meet the real world. Watch (or help) the implementation teams install the product; sit in on any customer training; examine closely the areas where the product must be configured or customized to work in the customer environment. You’ll definitely get some great ideas on improving the product.

Eventually, you’ll want to start visiting customers without a selling or support objective but get these initial customer touchpoints under your belt first.

Leverage your process expertise

Now that you have a strong understanding of the technology, industry, and domain, take a look at your internal product processes. What methods are used in your organization? Where are the company templates stored? And which of your favorite processes apply to your new situation?

Evaluate existing processes and systems. If you’re stepping into an existing job, you’ll likely find a set of methods that are already in place, formally or not. If you’re part of a new product management team, you’ll want to be a driver in defining your product processes.

What artifacts are necessary? What minimal set ensures success? Is your organization clear on what constitutes a requirement and what’s actually a specification? Which positioning technique is used, if any?

Start your own product playbook. Take all your methods and the company’s methods and put together a set of living documents. You’ll want your product plan and financials, buyer and user profiles, positioning, requirements, maybe a price list or pricing model, and any other documents that you reference often. Print them or store them in your dropbox so you’ll have them handy. For more on the product playbook idea, see

What should product managers do in their first days?

Look for high-impact deliverables that don’t require much up-front effort. Train the sales engineers and product implementation team. Develop informal product champions. Refresh or refine your product positioning, taglines, and blurbs so you can do “copy-and-paste marketing.”

Then focus on the methods to make sure you have a minimal set of effective processes that ensure product success.

What tips do you recommend? Add your thoughts in the comments area.



Is product marketing the same as marketing? (I say no)

I’m often asked to differentiate product marketing from marketing (or marketing communications, if you prefer).  This effort gets confusing for most because of the term “marketing.”

I’ve long been uncomfortable with the term “marketing.” For many of us, marketing is a philosophy. Marketing is looking at the business from the buyer’s point of view. It’s looking at the whole product, not just the software. Marketing includes packaging and pricing, and even how we answer the phone. But for others, “marketing” is a department, often associated primarily with advertising and branding.

Consider this: in marketing we use “greeking” to help people evaluate a design without getting distracted by (or obsessed with) the text. Product marketing owns the text; marketing owns the design.

For technology companies, product marketing managers are tasked with taking the product from the development team to the sales team and ultimately to the market. They are typically responsible for buyer profiles, positioning, and product information. Their focus is on product. In contrast, marketing (or marketing communications) is responsible for the execution of go-to-market programs. Their focus is on markets. They ensure programs are aligned with corporate branding standards, resonate with buyers, and empower the sales team.

It helps to think of marketing as a development organization. Product marketing managers bring requirements to marketing; marketing develops go-to-market solutions to address those requirements. Marketing is expert in designing programs that succeed and knows when to use those programs to address specific go-to-market problems.

As product manager is to development, product marketing manager is to marketing.

As a product manager brings requirements (or problems to solve) to development, product marketing managers bring go-to-market problems to solve.

A product marketing manager says, “The CIO needs to understand our infrastructure and architectural decisions to see how we align with their strategic technology direction.” Marketing replies, “We need a web page with a link to a white paper.”

Few organizations expect product managers to write production code. Likewise, product marketing managers should not develop programs, design brochures, or create web pages.

Product marketing identifies sales enablement PROBLEMS; Marketing designs SOLUTIONS.

How do you define product marketing? Add your comments below.

Related: See “Positioning, Messaging, and Ownership” at

Tweet this: Is Product Marketing the same as Marketing? (I say “No”) #prodmktg #prodmgmt #marketing

%d bloggers like this: