There are many types of marketing collateral that companies produce now days: web pages, datasheets, brochures, whitepapers, blogs, online videos, etc. Since customers are bombarded by information, most marketing collateral tends to be short, succinct and focused on “benefits”. Whitepapers are an exception to that rule, and therefore deserve some special attention. But first, what are they?whitepaper

As the name implies, whitepapers are mostly textual documents with a few key illustrations. They are normally 6-8 pages long, but you can occasionally find longer ones. Whitepapers can be a bit more technical in nature. They don’t necessarily need to get into the nitty-gritty details of the technology, but they can offer a sense of what the underlying architecture is.

Whitepapers can and should address a mixed audience: business buyers who wish to understand a bit more about the solution and technical buyers who wish to understand a bit more about the business value proposition. Most whitepapers are designed to answer the following key questions about a product/service offered by the company:

  • What is the need/problem addressed by this product/service?

Products or services are usually purchased in order to address a specific customer need. At times the business need is clear to the customer, but often it should be clearly articulated. The whitepaper goal is to “associate” the product/service with an important need the customer has.

  • What are the alternative solutions to this problem?

Customers prefer to have a choice when it comes to selecting a product or a service. A vendor can let the customer discover their choices by themselves, but it is far more effective to set the context for these alternatives yourself.

  • How does this product/service address the problem?

Most customers don’t like mysteries and prefer to know more about how your product/service operates. You don’t have to spell out confidential intellectual property; simply providing a high level description of the solution architecture will be sufficient to build customer confidence.

  • Why is it better than other available solutions?

As stated, buyers prefer to have choices. Needless to say, you prefer they choose your product or service. This is the right place to articulate why your alternative is better than the others.

A simple whitepaper “template” can help address the questions above: Start with an ‘introduction’ that describes overall market trends, then zoom- in to a specific problem/need your solution was designed to address. Follow with a list of alternatives used to address that problem/need today. Pay special attention to the “current way of doing things”, especially if the status quo is your main competitor… Next provide an overview of your product/service including a hint of its underlying architecture. Finally explain why your product/service addresses the need/problem better than any other alternative – and you’re done!

Well, writing a whitepaper sounds easy doesn’t it? To be honest, whitepapers do involve quite a lot of work and require a range of skills – both business and technical. To be effective, whitepapers must integrate several key business-technical elements:

  • Customer needs: the author must thoroughly understand the customer needs in order to describe them in the whitepaper. Those are the very same needs that came up during the gathering of product requirements. Once those needs are well understood, there is also the challenge of describing the key ones in a succinct and compelling manner.
  • Alternative solutions: the author must be reasonably familiar with the competitive land scape. Other solutions should have been thoroughly analyzed and their pros and cons well understood. Once the competitive positioning is understood, it must be articulated within the whitepaper.
  • Solution architecture: providing details about the solution requires knowledge of the product/service underlying architecture. All too often the actual technical architecture is far too complicated, and a simpler version must be synthesized and used in the whitepaper. This simpler version is often referred to as a ‘marketing architecture’, or “marketecture”.

So who should write a whitepaper? Ideally, the product manager should. After all, he or she has reasonable knowledge of the market, customers and the solution architecture. However not all product managers have the skills, or the time to develop the concepts and put them into fine writing.

One possible solution is to employ the services of a professional marketing writer. While this may work, it does depend on close cooperation with, and supervision by a product manager. The process should start with developing a detailed outline, which covers the key points the whitepaper must cover. The product manager and the writer should plan on having multiple sessions to discuss items listed on the outline. Investing up front in developing the detailed outline and discussing every item on it will save a lot of time and many review iterations later.

There is also the possibility of hiring a market analyst firm to create the whitepaper. This approach holds two main benefits: First, analysts should be familiar with the market, customer needs and other solutions in your space. You don’t need to spoon-feed them with information before they can start working on the whitepaper. Second, if assuming the analyst holds certain credibility in your market, then a whitepaper authored by them will carry more weight in the customer eyes. There are however two challenges with this approach. One has to do with budget – leading analyst firms will charge a hefty sum for producing a whitepaper. The other challenge has to do with the analysts’ wiliness to create a “biased” piece. Leading analysts firms protect their vendor neutrality and position themselves as objective advisors to customers. Creating a whitepaper that clearly favors your solutions may conflict with their neutrality.

Assuming you have a designated author for the whitepaper, then when should the work start? It depends on your “collateral philosophy”. Some marketing organizations focus on generating the basic collateral first – datasheets, brochures, web pages, etc. This approach is driven by the fact that these collateral pieces are a must, and therefore it is best to get them out first. The more complex task of creating a whitepaper is deferred to later. Other marketing organizations choose to start with a whitepaper. It forces the integration and assures consistency of the value proposition, solution description, and competitive positioning. Producing a cohesive whitepaper first makes the production of “basic” collateral a straight forward process.

Given the complexity and time involved in producing whitepapers, are they really worth the effort? Well, it depends. If selling your product or service involves multiple decision makers – some technically inclined and others business inclined – then a whitepaper will be worth its weight in gold. If on the other hand you are selling a consumer product, then investing in cool videos is probably a better choice.

In the business-to-business (B2B) space, where vendors sell products and services to other companies or organizations, whitepapers are a must. They are powerful sales tools that can help accelerate your sales process. In the business-to-consumer (B2C) space, where vendors sell to individual users, whitepapers can help, but certainly are not a necessity.


One of the challenging marketing tasks I personally came across has been ‘naming’. Assigning a name to a product, a device, a solution, or a company has been much harder for me than it looks. This is especially true when the name has to be associated with online presence – a web address (URL), a search keyword, or a social media term. When you search for a name that is catchy, easy to remember, meaningful, easy to spell, and has an associated domain name – the process can be lengthy and frustrating.

Assigning a name to a product, let alone a company, is a serious matter. A ‘naming consultant’ I once met called the process “verbal branding”. According to her, a ‘name’ should be an integral part of the company branding strategy.

Marketers often make substantial investments in building their company/product ‘visual brand’ through careful selection of graphics, color schemes, etc. They hire design experts to build the elements of the ‘visual brand’ – logo, website template, presentation templates, etc. In contrast, the process of selecting a name, particularly a product name, is sometimes handled as a popularity contest among company employees.

In my discussion with the aforementioned ‘naming consultant’ she pointed out that there are generally three types of names:  Descriptive name, Suggestive name and Arbitrary name.

  • Descriptive names are a succinct version of what the product or the company does; for example: ‘Intelligent Business Machines’ (IBM) for a company or ‘Integrated Services Router’ (ISR) for a product.
  • Suggestive names provide a “hint” as to what the product or the company is about; for example ‘Qualcomm’ is a company that offers quality communication solutions, and ‘iPhone’ is a product that combines Internet services with a phone.
  • Arbitrary names do not directly or indirectly describe what the product or company does. However if properly selected, they could have an effect on the audience.  For example, the name ‘Verizon’ doesn’t describe a communication services company; however it resembles the word ‘Horizon’, and thus may benefit from a positive effect. Another example is the name given to the Intel microprocessor ‘Pentium’, which was a departure from the company X86 naming convention.

There are additional subtleties associated with company or product naming.  But starting with a choice between a descriptive, suggestive or arbitrary name is a good place to start. Whatever you do, keep in mind that names tend to stick with a company or product for a while. The cost of changing those names increases dramatically over time. So don’t leave the name selection process to the very end…

Usually a lot of thought is given to choosing a company name. However product names are sometimes handled as an afterthought – a task left to be tackled right before the public launch. A “working name” is selected at the beginning of the development process, and that name somehow finds its way into the code, software menus, documentation, etc. Uprooting the “working name” and replacing it with the chosen “marketing name” can be a challenging task, especially when time is running out before the launch. As a product manager, you should invest in selecting the proper name early on, and make sure that all the teams involved get on board with the selected name.

Anyone in the company can come up with a product name, but it is important that a marketing professional is tasked overseeing the selection process. The team can follow the ritual of announcing a ‘naming contest’ where the winner gets a small prize (a free pizza…). Alternatively, you can hire a naming consultant, and task them with coming up with a list of recommended names. The process for name selection may depend on budget and timeline, but regardless – it should start early!

There is no single recipe for name selection; however there are a few common tasks involved in the process:

–       Desired attributes: define the set of attributes the selected name should possess.  This should preferably be done before any naming candidates are available. Think carefully about the desired attributes, list them, and if possible – prioritize them. Having a set of attributes will greatly help evaluate the proposed naming candidates. Some of the attributes are generic, while others are company/product specific.

  • Generic attributes: these include elements such as: easy pronunciation – in target languages, straightforward spelling, avoiding negative connotation (in target languages), availability of domain name, etc.
  • Specific attributes: related to the company or product at hand. For example: should the name reflect performance? Quality? Trustworthiness? Luxury? Affordability? Also, if there is a theme already adopted by the company (e.g. flower names), then new names must comply.

–       Naming candidates: generating a list of naming candidates can be done in multiple ways. For example: brainstorming sessions; or theme-based searches (e.g. Greek mythology gods); team contest with prizes; or hiring a naming consultant. Regardless of the process chosen, it is useful to communicate the desired attributes as guidelines for suggestions.

–       Top candidate(s) selection: using the list of desired attributes as a benchmark, the suggested names should be prioritized and top candidates selected. It is important to select more than one top candidate, since the subsequent approval process may disqualify some.

–       Legal screening: the top naming candidates should go through a legal review process. Any trademark contention issues should be reviewed and resolved. The candidate list should be pruned down to those names that can withstand challenged from other companies. Note that the legal screening should be done in all key target markets.

–       Internet screening: check if the candidate names can be associated with relevant domain names – especially important for company names.  They should also be tested in multiple search engines and social media sites to detect potential contentions with existing names/keywords.

–       Final selection: hopefully at this stage there are a couple of names which passed the screening process and can be presented for final decision by marketing and senior management.

As you can tell, the above process can become lengthy and convoluted. You may encounter barriers such as trademark issues or contentions in a particular target market – hence the suggestion to start the naming process early and in earnest. A good name can be a powerful branding asset, so it is well worth the effort.

While choosing a name is important, one must avoid the risk of “over naming”. This is particularly true for small companies, where the company name and its product name can be easily interchanged by customers. An example of blurring product and company names is Oracle Corporation. It was founded as Software Development Laboratories (SDL), later renamed as Relational Software, Inc. (RSI) and eventually named Oracle Corporation after its flagship product.

Likewise, if your company has a broad product line, naming every sub-product can be superfluous. Customers may remember the product line names, but sub-products names will be lost in the noise. You may still need to assign names to sub-products for logistical purposes (e.g. order processing), but those names should not be viewed and treated as a brand. The branding emphasis should be on the main product line, while sub-products can be simply given “descriptive names”.

At the end of the day, the product manager must decide where to put the emphasis on naming. Naming is part of the overall branding strategy, and should fit right into it. Spend the energy, time and budget on names that are critical to your brand – e.g. company name, or key product line name. Keep in mind that customers remember only a handful of names, so choose your battles wisely.

We discussed the importance of messaging and the impact it has on the perception of your product/service by customers (i.e. its positioning). I would like to discuss two examples, where the choice of words used in the message had a profound impact on the product positioning. Let me start with the ‘bad’ example:

I used to work for a company called Daisy Systems where I was part of the marketing team responsible for a new product called the “VHDL Design System”. VHDL is a ‘hardware description language’, which is used by integrated circuit (IC) engineers to describe the intended behavior of the chip they are designing. Using VHDL, engineers can simulate alternative design approaches, and detect potential flaws early on. Once the functionality (aka “logic”) of the chip is accurately captured in VHDL, it is semi-automatically converted into fabrication-ready format. The conversion process is called “logic synthesis”.

When VHDL was first introduced, it held the promise of increasing engineers’ productivity, improving chip reliability, and reducing the overall design time.  The “old process” involved manual creation of detailed, low level electronic schemes of the IC, which were later converted into fabrication format (aka “layout format”). The “new process” involved the creation of a high-level model of the IC (much like writing a software program), which was then “synthesized” into low level electronic schemes, which were converted into fabrication format.

[Note: I realize that for those of you who are familiar with the IC design process, the description above sounds very simplistic. But hopefully it provides some context for those who do not deal with IC design on a daily basis.]

Now back to the messaging story. Our team was excited to launch the new ‘VHDL Design System’. It was fully integrated with existing IC design tools our company offered, and thus became the first end-to-end VHDL-based IC design solution. This was a great message and we expected the market to react very favorably. There was one catch though…

VHDL is a very rich and complex language, and it was designed with many potential uses in mind. In reality, IC designers could use only a small portion of the language constructs VHDL offered. Our technical team reviewed the language thoroughly, and chose to support the “subset” that was applicable for IC design. Unfortunately, the word “subset” was used in our marketing collateral.

I don’t remember the exact phrases, but we have mentioned somewhere in our collateral that: “Our VHDL Design System supports a subset of the language which is fit for real world IC designs”. The ‘s’ word wasn’t in the headlines, but it was visible enough for customers and competitors to pick up. That was enough to create a marketing disaster.

Shortly after our product was launched, it became known as the “VHDL subset” solution. Our competitors were quick to declare that their product was a “Full VHDL” solution. And who wants to buy a “subset” when they can get the “full” thing?

The reality was that none of the competing products supported the full VHDL language – they simply chose to claim otherwise. Customers had no way to test whether a specific product had “full” VHDL support or no, so vendors could get away with making such claims. It took a couple of years till customers started to realize that a definition of a “VHDL subset” was needed in order to support real-world IC design. And standardization bodies like the IEEE started working on such definition.

But the damage cause by the initial miss-positioning of our ‘VHDL Design System’ was already done. Just one word prevented us from attaining the leadership position we believe we deserved.

Now to a different use of words, with a different outcome:

Years later, I worked for a company called Cadence Design Systems. The product I was responsible for was a “system level simulator”. It was a tool used for IC design, which allowed architects to capture, simulate and test algorithms before proceeding to the next stage of actually designing an IC. This was a “next generation” tool, which again promised a lot of productivity improvements for the complex process of IC design.

There weren’t many companies out there who offered such tools, and the market converged on two main vendors: ourselves and another company. Both offered a ‘system level simulator’. Naturally, both companies needed to position themselves in the mind of the customers. The other company promoted their solution as being “event-driven” simulation. Our solution was “cycle-based” simulation.

Without getting into all the nitty-gritty details about simulation technology, I’ll just say that event-driven simulation has certain efficiency advantage over cycle-based simulation. As you can imagine, our competitors were quick to point those advantages in front of customers. We started feeling the competitive pressure on a daily basis.

We couldn’t go back on our ‘cycle-driven’ position and claim that we too are ‘event-driven’. First, it was technically untrue, but even more importantly it was mentioned in all of our collateral. We had to find a way around the positioning trap our competitors set.

After much research and brain storming, we came across the answer. The vast majority of ICs designed in our target markets was “synchronous”. They used one or more on-chip ‘clocks’ to synchronize operations. Everything on the chip happened based on clock cycles. Hmm, cycles… that rings a bell, doesn’t it?

We decided to position our simulator as the best fit for ‘clock-based’ IC designs. While one could perhaps simulate an algorithm faster with an ‘event-driven’ simulator, mapping the algorithm later into a ‘clock-based’ IC design would be very difficult, and involve lots of re-work.

We simply claimed to have a ‘cycle-based’ simulator which is ideal for ‘clock-based’ IC designs. The connection between cycle-based and clock-based did wonders for our positioning. Most of the customers planned to use a system-level simulation tool as part of their IC design process. They didn’t want to deal with the complex mapping of ‘event-driven’ designs into ‘clock-based’ ones. We won the competitive battle – fair and square.

So there you go – messaging and positioning are indeed important. Choosing the words used in your product/service message can greatly influence its success (or failure). As I said earlier – resist the temptation to skip the messaging process. The exercise will be well worth your time.

One of the important roles product manager has is to help craft the ‘messaging’ for their product. By ‘messaging’ I am referring to the set of messages a company puts out there to influence how customers perceive its product or service. Those usually take the form of website content, datasheets, presentations, advertisements, etc.

I used the phrase ‘help craft messaging’’, since in some organizations messaging is the responsibility of a separate ‘product marketing’ and/or ‘marketing communications’ team. Regardless of the formal organizational structure, I believe that a product manager must be intimately involved in the process of positioning and messaging. But before we get too much into organizational dynamics, let’s discuss what ‘positioning’ actually means.

So what is ‘positioning’? While there are several definitions for the term ‘positioning (marketing)’, most agree that it is something that happens in the customer’s mind. Specifically, it the way the customer perceives your product vs. other products in the market.  If you are looking for a simple, yet powerful explanation of positioning, I highly recommend you read a book called “Positioning – the battle for your mind” by Al Ries and Jack Trout. It is an easy read and full of examples that illustrate the concept.

I realize the concept of positioning sounds a bit elusive, so let me try to illustrate it through a simplified perception model. I’ll use car models as the ‘product’:

Let’s assume that customers take into account only two attributes when choosing a car: price and performance. In order to establish their opinion of a particular model, they mentally ‘rank’ each it based on these attributes. A customer who evaluates two car models – Toyota and Porsche, may rank them as follows (see Figure 1).

Positioning Diagram

Figure 1: Perception grid

In the above example, the ‘positioning’ of Toyota is low price – medium performance, while Porsche’s is high price – high performance. Each car occupies a different ‘position’ in the customer’s perception grid.

While positioning ultimately happens in the customer’s mind, marketers strive to influence it. In our little example, the Toyota marketer may strive to increase its perceived performance, while the Porsche marketer wishes to decrease its perceived price. They both try to do it through ‘messaging’ – namely the set of messages a company puts out in order to inform and influence customers.

As stated, this was a simplistic example. Often there are more than two attributes a customer takes into consideration when establishing their view of a product. In such cases, we are talking about a multi-dimensional perception grid. The basic positioning principle still holds: 1) understand the key attributes your customer cares about 2) figure out how your (and others) product ranks 3) “map” the products on a multi-dimensional grid.

When dealing with hi-tech products, especially in the business-to-business (B2B) space, there are multiple attributes that influence the ‘positioning’ in customers’ mind. Examples for such attributes are:

       Price: how cost effective is the product? How does it compare to similar or alternative solutions in the market place?

       Performance: what is the “performance” of the product compared to others? Performance is obviously defined based on the product category, and may actually be broken down to multiple sub-attributes.

       Quality: how reliable is the product? What is its failure rate, or MTBF (mean time between failures)? What do other customers say of the product reliability?

       Functionality: what are the key functions the product provides? Depending on the product category and the market landscape, there may be multiple key functions that customers take into account when ranking a product in their mind.

       Support: how is the product supported? How dependable is the service? What are the costs and schedules associated with repairing the product?

       Company: how solid is the company that offers the product? What is their financial longevity? Who are its key management personnel? What is their market share?

But before delving into complex multi-dimensional perception grids, let’s not be quick to discard simplistic positioning models. In the “noisy” communication environment we all live in, it could be effective to focus on just a handful of attributes. The messaging efforts would focus on establishing your product positioning along these few attributes.

A classic example is “market leadership”: all things being equal, customers prefer to pick a “market leader”. If you can substantiate a ‘market leader’ positioning, it may be the primary message you emphasize with customers. If we go back to the “car models” example, then consider for example BMW’s positioning – “The ultimate driving experience” – which emphasizes one “attribute” in customers mind, their driving experience.

Figuring how your product ‘positioning’ is framed in customers’ mind is just part of the task. You also need to develop the ‘messaging’ that will reinforce, evolve or perhaps change your product positioning. The ‘messaging’ of a product, or a company for that matter, manifests itself through any form of communications the company puts out there, for example:

       Presentations: overview of the product, its features and use cases

       Datasheets: outlining product functionality and key benefits

       Whitepapers: how to apply a product to benefit a customer

       Success stories: how a particular customer benefited from the product

       Website: sections that deal with specific products, or solutions

       Press Releases: contain news about the product, or uses of it

       Interviews: conversations with news editors, analysts, etc.

       Blogs: containing specific references to the product

       Social media: posts that reference the product or its use cases

Ideally, the underlying key messages in every form of communication should be similar, or at least consistent. To achieve that, a “messaging document” must be developed with all the key messages. The messaging document should be reviewed and approved by all the relevant stakeholders before any communication piece is developed, let alone distributed. Unfortunately, due to constraints and deadlines, there is a tendency to “skip” the messaging exercise and jump straight to creating the content at hand. The outcome is inconsistent messages which may lead to a sub-optimal or even incorrect positioning. 

There are many different formats and templates out there for “messaging documents”. Frankly, doing the exercise and thinking thoroughly about the messaging and the desired target positioning is far more important than the actual format you choose… But just in case, I am enclosing a potential template for a messaging document below.

I.        Background information:

Setting the Stage
Purpose Statement This document provides overall ‘to-customer’ messaging and positioning for the company solution. This message framework should be used as a guide to develop consistent marketing communications by internal marketing teams, by agencies, and whenever the company solutions are referenced in customer-facing communications. This document is for internal use only and is not intended for distribution to customers or partners.
Summary of Customer Needs Summarize what the key customer needs are in your space.
Market Landscape Describe the market landscape: what are the key trends that influence it? Who are the key players?
Target Audience Who is the target audience? What type of companies are you aiming for, and what type of individual positions/roles you wish to target?

II.            Positioning Statements:

To-Customer Positioning

Positioning Statement



 1.     Fordescribe the audience within your target customers.

 2.     Whowants to <describe their key needs>

 3.     What describe what the company does for its customers.

 4.     Howdescribe how it does what it does, including unique technologies.

 5.     Competitorsoutline key competitors

 6.     Differentiators outline key differentiators:

  •          Differentiator one: details
  •          Differentiator two: details
  •          (3-6 differentiators in all)


Customer-Facing Statements

100-Word Description

Description of what the company does, customer benefits and key differentiators, in no more than 100 words.

50-Word Description

Subset of the above, in no more than 50 words.

25 Word Description

Subset of the above, in no more than 25 words.

 III.           Supporting Pillars:


Pillar 1 

Pillar 2

Pillar 3

Audience Focus

Describe the audience

Describe the audience

Describe the audience

Pillar Benefit Statement Pillar key benefit statement  Pillar key benefit statement. Pillar key benefit statement 
Pain Points – Customer pain point(s), related to the pillar

Customer pain point(s), related to the pillar

– Customer pain point(s), related to the pillar

 – Customer pain point(s), related to the pillar

Customer pain point(s), related to the pillar

– Customer pain point(s), related to the pillar

 – Customer pain point(s), related to the pillar

Customer pain point(s), related to the pillar

– Customer pain point(s), related to the pillar

Support Points

Supporting point 1

– Details of the supporting point.

Supporting point 2

– Details of the supporting point.

Supporting point 1

Details of the supporting point.

Supporting point 2

– Details of the supporting point.

Supporting point 1

Details of the supporting point.

Supporting point 2

– Details of the supporting point.


Completing the first section – Background Information – should be straight forward. I assume a product manager has full understanding of his/her target market. However the purpose of this section is to help get other marketing related teams (e.g. Marcom team, PR agencies) on the same page.

The second section – Positioning Statements – is where the hard work begins. And this is also where most of the time will be spent in the messaging exercise. The message creation process is broken (sometimes artificially) into several steps. Multiple iterations of those steps may be required until convergence is achieved. Let’s go back to our simplistic example of car selection and attempt to fill the details on behalf of the Porsche product manager:

For: upper middleclass customers

Who: wish to enjoy performance driving on everyday roads

What: our company offers performance cars at affordable price

How: based on our unique automotive technology tested on challenging race courses


  • Acceleration: sub-5sec acceleration from 0-60mph
  • Transmission: 7-speed gear; 1-6 with sports ratio; 7 with fuel-efficient ratio
  • Electro-mechanical steering: extremely precise yet comfortable at high speeds

The next challenge involves building the integrated positioning statements – a long, medium and a short one. Use the text crafted in the For/Who/What/How/Differentiators sections as building blocks. I suggest you start with the 100 words statement and then prune it down to get to the 50 and 25 words ones. As I stated before, the process will be iterative, and you will have to go back to earlier parts and continue to refine the positioning statements.

Finally, the Supporting Pillars are just that: they outline the more detailed proof points that support the positioning statements above. Each pillar includes a benefit statement, the related customer ‘pain points’, and supporting evidence to the pillar benefit claims. When dealing with more complex sales, there are often multiple audiences, each interested in different benefits. For example technical buyers interested in features/functions, and financial buyers interested in costs/ROI.  Going back to our small Porsche example:

Audience: car buyer

Benefit: top performance, at affordable price, on everyday roads

Pain point: enjoy high performance driving on a daily basis, yet at reasonable cost

Support Points:

  • Highly efficient, state-of-the-art engines <details here>
  • 7-speed manual gearbox <details here>
  • Electromechanical power steering <details here>
  • Efficiency enhancing measures <details here>

I hope the simple example illustrated the general structure of a messaging document. But don’t let the simple structure deceive you. Converging on few, powerful and consistent messages can be a challenging process. It requires participation from key stake holders, and involves multiple iterations till agreement is achieved.

It might be tempting to skip the seemingly trivial task of messaging document creation, and go straight to marketing content writing. Resist that temptation! Go through a messaging process first, and trust me, the payoff will be very high. And the extra bonus: your marketing content will be consistent and far more effective. 

Setting the right price for a new product is always challenging – even more so when you deal with a new product category. That was exactly the situation we encountered at Actona technologies.

We came across a problem which hasn’t been solved before. It had to do with accessing files across a wide area network (WAN). Let me explain briefly:

Imagine you have a Microsoft Word document stored on your PC. You double-click on the file name, and within a few seconds the document is open and ready for editing. Now move the document to another computer (i.e. “file server”) located on the local area network (LAN) at your office. Again, double-click on the file name and it will still open within seconds. It may take a bit longer than before, but you will hardly notice the difference.

Now imagine the file actually resides on a computer located in another site, perhaps even across the Atlantic Ocean. If you try to “double-click” on that file, you will be forced to wait minutes before it opens, and the Microsoft Word application on your PC might even “freeze” without even opening the file. The reason is simple: your WAN is much slower than your LAN, and that causes long delays in opening the same file.

We decided to tackle that problem, and developed a solution we named Virtual File Network (VFN). The technology isn’t that important, but the end result is. If you installed our VFN software at each site, then opening files across the WAN would happen faster, much faster. You will feel only a minor difference between opening a file on your PC, compared to opening a file across the Atlantic Ocean.

We tested our VFN product with a handful of potential customers, and they loved it. We realized we had a solution for a problem people care about; we just didn’t know how to price it. Time was of essence. We were a small startup that needed customers, and fast. It was time to set a price for VFN.

At the beginning, we offered VFN as a software package. It was installed on computers the customers already owned. That meant we couldn’t follow any “cost-based” pricing approach. Our cost of goods sold (COGS) was close to zero – a CD and a few documents. We couldn’t establish any pricing strategy based on “reasonable margins”.

There were no other products on the market that offered a similar function. At least not at the time we contemplated how to price VFN. Without any competitors to compare ourselves to, we couldn’t adopt a comparative based pricing approach. Essentially we were left with a “value-based” pricing approach. We faced a dilemma: how do we establish the value of VFN in the customer eyes?

We could have taken the approach of calculating the “productivity gains” from speeding the process of opening files. For example, let’s assume a user opens 30 files a day remotely, and saves about a minute each time. If an employee hourly rate is $50, than savings 30min a day amounts to $25/day, $125/week, $6250/year. We could have developed a financial model around these assumptions and calculate ROI to justify our product pricing. But there is a problem with that approach… It’s called “soft ROI”.

In most organizations, “productivity gains” and “time savings” fall under the ‘soft ROI’ category. Companies have no assurance that time saved in opening remote files will actually translate into increased revenues or higher net profits. The extra time may just as well be used for taking longer coffee breaks… Financial buyers definitely prefer to see ‘hard ROI’. They are looking for a tangible connection to revenues or cost savings.

It became clear that calculating the value of VFN based on time savings and productivity gains will make justifying its price during a sales process very difficult. We had to take a different approach. The clue came from a question we asked a prospective buyer: “If you didn’t use our VFN product, how would you solve your problem?” The customer explained that he would have to upgrade the speed of his network links. That upgrade would have cost him around $10,000 per month for international links, and around $1,000 per month for domestic links. Granted, it was a few years ago, but premium network links cost money even today…

We had our answer: VFN helps customers avoid spending extra money on premium network links; here’s a hard ROI for you. We could have developed an elaborate pricing model based on network link types, but we opted for simplicity. We wanted our product to pay for itself within 6 months or less. With domestic premium links costing about $1000/month it meant VFN should be priced at $6,000 or less. We set the price for $4,995 per site. It worked.

But our pricing dilemma didn’t end there. Our assumption was that VFN will be bought by customers who need to open files from a distance. For example: engineering companies with development teams spread around the globe who share design files amongst themselves. While we found customers who met those criteria, we soon realized they represent only a small portion of the companies out there.

We had to expand the range of problems we address with VFN, and re-examine our value-based pricing strategy. Fortunately, we came across a much bigger problem our technology could address. It was a time when companies started to actively “consolidate” their information technology (IT) infrastructure into fewer, larger locations called “datacenters”. Consolidation of servers into fewer datacenter locations improved the ability to manage and support them, and significantly reduced operational costs.  

However as companies started migrating more computers and servers from remote offices to their datacenters, users at those remote sites started feeling the pain of network delays. Corporate IT teams faced a tough choice: leave those servers out there and continue to incur high operational costs, or ‘consolidate’ those servers, saving costs but facing the wrath of end users and their management.

We stepped right into that consolidation conflict. We realized we can help corporate IT “have their cake and eat it too”. Our technology enabled them to consolidate remote servers into datacenters while ensuring good performance for their end users. Voila – hard ROI that applies to just about any company out there.

We decided to re-position the product and change its name to Wide Area File Services (WAFS). We also reexamined its value proposition. Our “new” WAFS product helped companies succeed in their datacenter consolidation initiatives. Therefore, its value stemmed from the fact we helped eliminate the costs associated with continuing to deploy, maintain and manage file servers at remote sites.

We calculated the costs we saved with our WAFS product: the server hardware, related software licenses, ancillary equipment (e.g. backup tapes) and came up with pretty significant number. And it was all ‘hard ROI’. The new pricing we set for our WAFS product was more than double its predecessor – VFN. Interestingly enough, we had more potential customers, a much bigger market opportunity and higher revenue potential.

In this example, pricing strategy was closely tied to the product value proposition and the customer problem it addressed. As the market evolved, competitors entered the space and volumes grew. Pricing strategy required doing also competitive analysis and margin calculations. But value-based pricing remained the foundation on which the product price was set. 

True, we build products to serve customer needs, and sometimes even to change the world. But unless you work for a non-profit organization, you need to keep in mind that at the end of the day, a product must generate profits for your company. Yes, there are cases where products are sold at a loss (i.e. loss-leaders), and some products are given away for free. But I am referring to the majority of cases, where a product either becomes profitable, or gets terminated.

There are many factors that impact a product financial success and the amount of profits it generates. The price of the product is one of those key factors. Price it too high – and few customers will buy it. Price it too low, and you are leaving money on the table, or worse – losing money on every sale.

I remember the epiphany I had during an introductory economy class I took at business school. The professor explained the concept of the “demand curve” and the “supply curve”. It was brilliantly simple: as you increase the price of a product, fewer people buy it and aggregate demand diminishes. Conversely, as you increase the price, manufacturers are incentivized to increase production and aggregate supply increases. The right price for the product is determined by the intersection of the supply and demand curves. If only life were so simple…

There are few real-life situations where a product manager has visibility into the “supply” and “demand” curves. So while the theory has some merit, it is hard to put it to practice when trying to determine the optimal price for a product. So how do you determine the right price for the product? Let me count the ways:

Cost based pricing:

This is one of the simplest, yet effective approaches I came across. The general idea is to calculate the cost of producing the product, and then add an appropriate margin. The question is what is an “appropriate margin”? If you work for a company with some product history, or in a reasonably mature industry, then desired margins can be derived from analysis of past products performance.

Let’s assume you know what the desired ‘gross margin’ is (i.e. the margin before taking into account other expenses such as G&A, headcount, taxes, etc.). And you know the raw cost of your product, often referred to as COGS (cost of goods sold). Then you can use the formula:

GrossMargin=(Price-COGS)/Price → Price=COGS/(1-GrossMargin)

For example, if your COGS=$100 and your desired GrossMargin is 60%, then your product should be priced at $250.

I realize this looks like a rather simplistic way to determine the price of a product, but in many cases, this approach gives the product manager a first good estimate of what the target price should be. Then he/she can apply other consideration to refine the actual price point.

Competitive based pricing:

If there are other vendors who offer similar products to yours (i.e. competitors), then you can analyze their pricing and determine your product price relative to theirs. But first you need to assess how your product stacks against its competition. For example, how do your product capabilities (or features) compare to competing products.

Once you have completed the product comparison, you should map the various products on a “price/performance” chart. The use of the term “performance” represents more than just “speed”. It is supposed to represent the relevant capabilities of the analyzed products. But let’s start with a simple case, where speed is a key function.

Let’s say that you wish to price a new communication device, and you know that customers judge these type of products by their connection speed – in Megabits per second (Mbps). Then a price/performance chart for products in your market will simply have speed in Mbps on one axis and price on the other.  As you determine your product price, you need to ensure it “fits” into the chart properly next to other products.

This was indeed a simple example. In many cases there are several capabilities to take into account when doing a “price/performance” comparison. This is where some creativity in chart building comes into play. For instance, you could rate the respective capability of every product (e.g. 1-10), then calculate a weighted average as the “performance” of the product (i.e. SumOf [CapabilityWeight * ProductRatings]). This synthesized product “performance” can now be placed on a price/performance chart, and help determine how to fit your product into the competitive landscape.

There is no fixed formula how to do competitive based pricing. But you get the general idea: compare your product to existing products in the market and make sure the price you set fits the perceived “performance” of your product relative to others.

Value-based pricing:

The idea is simple: price the product based on the “economic value” it delivers to the customer. However as with other pricing methods, the implementation of this method can be a bit tricky. How do you actually determine the “economic value” of your product? There are various methods to approach this problem, and they all depend on the type of product (or service) you offer, as well as your customer environment.

A common approach to calculating the ‘economic value’ of a product for a customer is to assess its impact on the customer top and/or bottom line. The assumption here is that a product either helps reduce expenses (i.e. saves money), and/or increase revenue (i.e. makes money). What’s left to do is to calculate that impact… In order to do that, you need to have reasonable understanding of your customer business processes.

Let’s say that your product helps reduce expenses associated with a certain business process. You should compare the expenses a customer incurs without your product, to those with it. Presumably your product will significantly reduce those expenses. Put in a spreadsheet the difference in the customer’s periodic expenses (i.e. monthly, quarterly, or yearly) before and after using your product. That difference represents the positive cash flow your product will generate for the customer. A similar process can be applied to products that help increase revenues. You calculate the difference in the customer’s periodic income before and after using the product. That difference represents the positive cash flow your product will generate for the customer.

Having calculated the positive cash flow generated through using your product, add the actual product cost to your spreadsheet. It will be represented as an investment (i.e. negative cash flow) that drives the positive cash flow you calculated above. Now choose your favorite investment analysis method, for example: Return on Investment (ROI), Breakeven Point, or Net Present Value (NPV).

For example, let’s assume that your product generates an extra income of $500 per year for the customer – either through cost savings or additional revenues. We can now examine different options for pricing the product. Let’s try a price point of $1000.

Table 1: Cash Flow from Product use



Year 1

Year 2

Year 3

Cash flow






Product purchase

Gain from use

Gain from use

Gain from use

If we look at breakeven point, then the product will pay for itself by the end of the second year of use. If we look for return on investment over a period of 3 years, then the product generated $1500 and cost $1000. That translates into a 50% ROI in nominal terms. You could take into account the time-value of money and calculate the value of future cash flows based on the cost of capital (i.e. interest rate). If the customer’s cost of capital is 5% annually, then the present value of future cash flows and ROI are:

Present value of cash flow: $1362=$500/1.05+$500/1.05**2+$500/1.05**3

Discounted 3yrs ROI: 36%=(($1362-1000)/1000)*100%.

You can examine options to price your product so that its economic value meets or exceeds customer expectations. In our little example, a 36% adjusted ROI may be fine, but if the customer expects a higher ROI, you may need to lower your product cost.

While value-based pricing seems like a perfectly rational approach, real life calculation of customer value can be far more complicated. Actual business processes and costs aren’t always clear even to the customer himself. And the impact of a particular product on future revenues is a conjecture at best. Customers often differ from one another in terms of business processes, costs and efficiency.

But don’t let all these caveats deter you from attempting to use the value-based approach. Developing a general model for your product ROI is a very useful exercise. It can generate a descent estimate for what the product price range should be, and will serve as a powerful justification tool when negotiating price with customers.

Alternate pricing models:

The pricing methods discussed above pertain to “traditional” pricing strategies, where customers actually pay for products they purchase or services they use. There are several alternate pricing methods that have been adopted by some companies. Let me touch on those briefly.

Freemium pricing:  this is a model that combines a free basic product (typically software or service) with the option to upgrade it to a ‘premium’ product for a fee (Free+Premium=Freemium). The difference between the free and the premium product is usually based on capacity, performance and capabilities. The ‘free’ product is a marketing/sales tool designed to lure customers into using the company product/service. The ‘premium’ product is the actual revenue generator. Pricing strategy and analysis should be applied to the premium product.

Alternate revenue source: a model where actual users of the product/service get it for free. Revenues are effectively generated from an alternate source. A prime example is advertising-based model, where advertisers pay the company for the rights to “reach” its product/service customers.

Let me summarize this short discussion about pricing.

Setting the right price for your product (or service) is critical; after all it is one of the key “four P’s” in marketing (Product, Price, Position, Promotion). There are multiple approaches to determine the target price for a product. I briefly described a couple here – Cost, Competitive, and Value-based. Whether you choose one of these, or any other method, it is important to do the analysis early on. I recommend you analyze the product price using multiple approaches. For example, start with a cost-based analysis, then look at competitive pricing and finally build a value-based model. If you are getting reasonably consistent results across multiple approaches, you are probably aiming at the right price point.  I know it sounds like a lot of “mundane work”, but remember that a solid pricing strategy could make the difference between a successful, profitable product line and a dud. 

What does politics have to do with product management? Actually, a lot! I realize that most people view “office politics” as a negative activity that involves shameless manipulation and occasional back stabbing. I shared similar views of office politics myself. But that changed after I attended a presentation at the Silicon Valley Product Management Association (

When the presenter got on stage, his first question to the audience was: “who amongst you likes office politics?” Hardly anyone raised their hand. He then asked the opposite question: “who amongst you dislikes office politics?” And the whole room was filled with hands in the air.

“Well, I’ve got news for you” said the speaker, “wherever there are two or more people – there’s politics”. He paused for us to absorb the news, and added: “Your only real choice is either to participate in the political process or to become a victim of it”. This was a moment of epiphany, and not just for me. I realized the speaker was right.

But wait, I am not suggesting that as a product manager you should engage in negative practices, start manipulating others, or back stab colleagues – just to promote yourself. I do however suggest that you become aware of the political processes around you, get familiar with the “rules of the game”, study the political power landscape and plan your moves accordingly.

Let’s take an example: suppose you realized that the product you’re responsible for needs a new feature urgently. Your key competitor just introduced a similar feature, and your customers give you clear indications that without this capability, your company will likely lose against its competition. The engineering team is hard at work implementing the set of requirements you’ve all previously agreed to, and the release date is quickly approaching. What do you do?

One option is to step into your weekly project team meeting and announce that the release plan must be changed to accommodate the new critical feature. Most likely, all hell will break loose as soon as you make this announcement. Fierce arguments will ensue, and chances of arriving at a decision to change the release plan are slim.

The other option is to assess who the key stake holders are, and devise a plan to get them on your side – before the critical project meeting. Let’s assume that your engineering manager is one of those stake holders. Sure, he is committed to the success of the product, but he is personally held accountable against key performance indicators (KPIs) such as delivering releases on schedule, within budget and of high quality. Changing the release plan will likely to impact some or even all these KPIs. In your discussion with the engineering manager, you reiterate the business motivation, but you also acknowledge the potential impact to the KPIs. You may propose to personally present to upper management the new market drivers for the release plan change, and ask for “readjustment” of the aforementioned KPIs. This one-on-one conversation is likely to put the engineering manager on your side. And when the subject of modifying the release plan is brought up in the project team meeting, you will have a strong supporter to back you up.

This was a fairly simple example. In reality, the political scene is often more complex, and so are the motivations of people involved. You could start feeling your way around by answering the following questions:

–       Who are the key stake holders whose support I need to gain?

–       What are their organizational objectives?

–       What are their personal objectives?

–       What objections might they have to my proposal?

–       What can they potentially gain from supporting my proposal?

Once you have mapped your key “targets”, schedule one-on-one session with each one. Come prepared with the background work you’ve done, and do your best to convince them to support you. Be fully prepared to listen, as you may uncover motivations and objectives quite different from what you envisioned. Where needed, negotiate a “win-win” agreement that addresses both their objectives and yours.

Granted, not all scenarios can be planned ahead. You are likely to run into situations or meetings where the political dynamics happen in real time. As you become more proficient in the “political process”, you will be able to handle the dynamics as they unfold.  Don’t just wait for the next political conflict – spend time regularly with other stake holders, understand their motivations and invest in building rapport.  The more you do it, the more you succeed in steering decisions your way.

As a product manager you simply cannot afford becoming a “victim” of office politics. Your ability to influence key product decisions depends on how politically savvy you are. So rather than trying to “avoid” office politics, make it part of the skills you acquire. There are plenty of books and websites that offer advice on office politics. Take the time to read about the subject, pick those tips that resonate with you, and start practicing…  

Daisy Systems was founded in 1981 by a group of ex-Intel employees. They identified a need for computer aided design (CAD) tools to be used for designing printed circuit boards (PCBs) and integrated circuits (ICs). Daisy pioneered the field of ‘computer aided engineering’ (CAE) and become a leading company in that space. I joined Daisy in 1988 as a technical marketing manager. My job was to “translate” high level marketing requirements into functional specifications that our engineering team could implement. It was my very first job in marketing, and I learned a lot. I had an exciting 2.5 years working for Daisy, until the company went bankrupt and shut down. Yes, shut down.

So how does a pioneering company in an exciting new market reach bankruptcy? There were many contributing factors to Daisy’s eventual downfall: some bad financial decisions, a botched M&A, and a new management team that didn’t quite understand the company or its market. However I want to focus on what I perceive to be the first blunder that led Daisy down a slippery slope.

Before I continue, I want to emphasize that what I am describing here is my personal view, and the lessons I learned. Keep in mind that I was just a “lowly product manager” in the organization. What I could grasp from my standpoint was quite different from what was seen from the top. I am also careful not to “lay blame” on anyone directly or indirectly. The phrase “the road to hell is paved with good intentions” certainly applies in Daisy’s case.

So what was the fateful misstep (according to me)? I believe it had to do with misinterpreting a key customer requirement.

Daisy initially offered a “turn-key” system: a hardware platform, an operating system and a set of CAE applications – all developed by its own engineering teams. In the early 1980’s, there was no other choice. If you wanted to sell an interactive computer workstation – you had to build it yourself. The ‘Daisy Logician’ was a black workstation with fast graphics engine that did wonders for large electronic designs. Customers loved those ‘Logicians’, and bought them in droves.

But the market scene started changing. A new breed of general purpose computer workstations emerged, offered by companies such as Apollo Computer and Sun Microsystems. These workstations ran the UNIX operating system and were referred to as ‘Open Systems’. In theory, you could run any application on it, as long as the application vendor supported the platform. However Daisy’s beloved CAE applications only ran on Daisy’s operating system, and its Logician hardware.

Daisy heard the customers demand for ‘open systems’. But migrating from a proprietary system to an open one takes a lot of work. Plus it meant losing the great margins it made on the ‘Logician’ boxes. Well, let’s given them something “similar” the company decided. Let’s make our operating system UNIX-like, and call it Daisy UNIX, or DNIX. That ought to do it. The company spent significant resources and time reengineering its operating system and adjusting all its home grown applications to it.

But DNIX was a failure. It wasn’t the ‘open system’ UNIX the market wanted. But moving to an ‘open system’ involved another major hurdle: a significant portion of Daisy’s software was written specifically for the Intel x86 processor family. Moving to a true ‘open system’ meant a significant rewrite of application code.

By now Daisy was desperate to jump on the ‘open systems’ bandwagon. It approached Sun Microsystem and the two came up with a ‘compromise’: the Sun 386i workstation. As the name suggests, the Sun 386i was based on the Intel 386i processor. Porting Daisy’s CAE application to this platform was much easier, since the code could remain Intel processor specific. Another major ‘porting’ effort resulted in the launch of Daisy’s “open system” solution on the Sun 386i.

It was another major failure. Sun Microsystems previously announced it will develop its own processor architecture – the SPARC. Its main workstation line started using the SPARC processor. It didn’t take rocket science for customers to understand that the 386i was a sidetrack for Sun. And nobody wants to buy a computer system that is a “sidetrack”. The Sun 386i failed.

It was only after two major iterations, each consuming significant resources and time that Daisy Systems finally caught up with the market. It eventually launched its CAE application suite on a true open system – a SPAR based Sun platform running the UNIX operating system.

But it was too late and the company lost its momentum. The superfluous platform releases cost time, engineering resources and money. They were done at the expense of developing competitive applications and new features. Daisy never made it back to the top. A series of failed attempts to recapture market share resulted failed acquisitions and eventually led to bankruptcy.

This is not a story about villains or morons.  Daisy had many bright, hardworking individuals who did their best for the company to succeed. To me it was an example of misinterpreting a key customer requirement and failing to embrace a market trend. It can happen to the best of us, if we’re not careful. I personally took a few lessons from this:

–       Listen carefully: to what customers have to say and what the market trends are. Missing a key requirement, or worse – misinterpreting it, can be catastrophic.

–       Identify pivotal requirements: while you may end up collecting dozens or hundreds of customer requirements, you must identify the ones that will ‘make or break’ your business. Make sure those are addressed first.

–       Make hard choices: compromises are fine, most of the time. But there are moments when you need to make hard choices – make them. It may involve “betting the company” or the product, but avoiding a hard choice will doom your product or you’re your company.

I believe you can learn a lot from mistakes (yours or others).  It took many years for me to internalize and accept the “failure” I experienced at Daisy; too many years. In hindsight, Daisy was a great learning experience for me. Many of the skills I developed as a product manager were first used at Daisy. The “fear of failure” is something we all need to learn how to live with. Especially since as product managers we are tasked with making decisions that can be fatal to the product we manage. Indeed, companies and products can fail, but if this is all you can think of – you should find another job. I comfort myself with the knowledge that avoiding a choice is much worse than making a bad one, and then try to make the best choices I can.

So you have done your research, gathered the requirements and managed to successfully prioritize them. Great, now the real work begins. In order to “translate” those requirements into an actual product, you need to reach an agreement with your engineering team on the content and schedule of an actual product release. Arriving at such an agreement entails quite a bit of negotiation. And to borrow from a popular phrase: “In business as in life, you don’t get what you deserve; you get what you negotiate” (Chester L. Karrass).

In some organizations, the process of negotiating requirements with engineering is done ad-hoc, through meetings, hallway conversations, side discussions, etc. Granted, you may achieve quite a bit through such informal means, but I recommend you combine them with a bit more formal process.

One of the more popular methods to submit requirements is a “Product Requirements Document”, a PRD. Some organizations prefer to use the term “Marketing Requirements Document” (MRD), but the idea is generally the same.  Whatever the template you choose, the document should at least provide the following information:

  • Market overview: the main dynamics in the market we are targeting
  • Customer needs: describing the “customer problems” we plan to address
  • Key requirements: a detailed list of features with sufficient explanations for each
  • Pricing & packaging: how are we planning to charge for the product and its features
  • Prioritization table: listing the names of requirements and their associated priority
  • Financial forecast: stating the expected goals for units/customers/revenues
  • Competitive landscape: other vendors targeting that space and how we can win

Once the document is completed by product manager(s), it should be submitted to other teams for review. Since new products or releases impact multiple functions within an organization, I recommend you submit the PRD to all relevant organizations: engineering, manufacturing, support, finance, etc.  The next step should involve formal review sessions, where product managers address questions raised by other members of the organization.

Once the requirements have been properly discussed and understood, it is time to start the release negotiation. At this point, the ball is primarily in engineering hands, but the product manager should stay closely involve. This is the phase where informal conversations, small group meetings and 1-1 conversations are very effective.

After performing the necessary requirements analysis, engineering should provide product management with a list of features they believe they can implement in the actual release. Some organizations refer to it as “Functional Specification” for the product, others may use a different term, but the message should be the same: “we understand what you requested, and here is what we plan to build”.

I described a somewhat “liner” process, where PRD gets written first and reviewed. Engineering then performs its analysis and comes back with a functional spec. In reality, the process is far more iterative, often involves prototyping, and a piecemeal approach where some product functions are implemented before others. However whether you work on the product as a whole, or some portions of it, the general approach should be requirements first, implementation second.

I have yet to come across an organization where what marketing requested was indeed what engineering built, and in the same order of priority… There are many reasons for these “gaps”: some are due to technology/resources constraints. Others have to do with misunderstandings. But unfortunately some have to do with disagreements between the two teams. Constraints need to be understood, and accounted for. Misunderstandings can be identified and clarified. It is “disagreements” I want to focus on.

When it comes to disagreements between engineering and marketing, it is important to identify the underlying motives. For a product, an organization, or a company to be successful, both marketing and engineering must be committed to its success. As long as disagreements arise from different views on how to achieve “success”, then these are healthy disagreements that should be addressed and resolved. However if there are other motives behind disagreements, than management must address the underlying team dynamics or personnel issues first. Let’s leave those aside for now.

So if both engineering and marketing are committed to the product/organization success, then what should they disagree on? Well, aside from “function” and “priority” there isn’t much left…

Some product managers prefer to work with a “passive” engineering team that simply follows their guidance. The engineering team accepts a list of requirements and priority and should simply “map” those to the available resources. The negotiations between marketing and engineering become a “resource scheduling” and “timeline” discussion.

I personally don’t believe that “passive” engineering organizations are the best path to success. Building a product is a creative process, and if the “craftsmen” don’t understand what the product should do or look like, then the outcome is sub-optimal. I prefer an “active” engineering organization, that comes up with ideas and suggestions, occasionally interacts with customers, and closely follows other vendors in that space. Most of the successful engineering teams I worked with where definitely much more “active” than “passive”. I say – bring it on, engineering!

So how do you handle disagreements with an “active” engineering team? Well, this is where a lot of knowledge and some negotiation skills become really handy.

Let’s start with the knowledge. Anyone in the organization may read magazines, follow websites and study analysts’ reports. But as a product manager you have the opportunity and responsibility to interact directly with the market place: to engage with sales, customers and partners. Remember what I wrote about gathering product requirements? The investment you made and the knowledge you collected while gathering those requirements will arm you in a debate with engineering. Your direct market knowledge significantly improves your odds when negotiating with engineering.  Remember: “find a customer problem and solve it!”

The other important piece of knowledge is the “cost” (i.e. resources and timeline) of implementing specific requirements. Implementation costs are somewhat elastic. Costs of features favored by engineering are sometimes underestimated, while costs of unfavorable features overestimated. I am not talking about deception, but rather human nature. It is therefore useful to sniff around (discretely), talk to rank and file engineers and get a sense of what the costs are. With this knowledge in your back pocket you can better negotiate the content and timeline of the release.

What about negotiation skills? If you haven’t read a book or took a class on negotiation, then please do. It will serve you in more ways than one. I am not talking about using “tricks” against other team members. I am talking about understanding the basic dynamics of negotiation, and using that know-how in the process. Remember: In product as in life, you don’t get what you requested; you get what you negotiate for”.

So you have done your research – met with customers, talked to sales, studied the competition, read analysts’ reports, brainstormed with engineering, etc. etc. You now have a comprehensive list of requirements (or features) which you can justify based on all the legwork you’ve done.  Surprise! Your product development team simply can’t implement them all…

A seasoned program manager once told me: “The three main attributes of any product release are Content, Schedule and Quality. With a given set of resources, you can only set two out of the three. The third one you just have to accept.”

For example: if you define a threshold for product release quality, and you select a minimum set of features, then you have to accept whatever schedule is dictated by quality and content. Or, if you choose minimum functionality, and set in stone the release date, then you need to accept whatever quality comes out (hint: be careful about compromising quality).

Since resources are always finite, and schedules are often determined by other considerations (e.g. we need a release in Q4 to boost sales…), then “content” is usually the biggest decision dilemma. What features should be included in any particular product release is probably the biggest element of contention a product manager has to deal with. The best way to tackle that challenge is through careful prioritization. Note that prioritization is time dependent, since market conditions and customer needs change over time.

I have come across and personally tried many prioritization systems. Personally I believe that any ranking system that has more than 3 levels may simply create too much “noise”. Dividing requirements into Priority 1/2/3 lists is hard enough. You don’t need Priority 4/5/6… A simple way to define those categories is:

  • P1: these features must be part of the release. You will hold the release till their completion.
  • P2: these are highly desirable. You will not “hold the release” without them.
  • P3: these features are nice to have. Should be implemented if there are extra time resources.

How do you go decide which requirement falls into what priority level? This is a process that involves some quantitative analysis, some qualitative analysis and a healthy dose of intuition. There typically several parameters that can be considered for each requirement. Some of them are:

  • Revenue impact: try to put a monetary value on each specific feature. Ask yourself the following questions: Are there new revenues that will be driven by this feature? Any potential lost revenues if the feature doesn’t get implemented? Is there a large deal the company might win, or lose based on this feature? Some of these questions may hard or impossible to answer for a given feature. However doing the “revenue impact” exercise will prove to be very valuable during the ranking process.
  • Strategic customers: list the main customers who expressed a need, or specifically asked for a given feature.  Each company has “must win” (or “must retain”) customers it considers strategic. Satisfying their key requirements takes precedence.  
  • Customer commitment: is there a commitment made to specific customers about implementing this feature? Was it a hard commitment or just a vague promise? What are the implications of not meeting that commitment?
  • Competitive positioning: what do competitors offer with regards to this feature? How will implementing it, or not, impact our advantages/disadvantages vs. key competitors?  
  • Implementation cost: this is a tricky one to assess at times. But if you can gather such information from your engineering counter parts, it can become extremely useful during the ranking order. As said, resources are always finite. And you want to avoid situations where too many of these resources are tied down with implementing a single feature.

The above list of parameters is not cast in stone. Each company business is different, and there may very well be other parameters to consider as part of the prioritization process. It is highly advisable however to adopt a “process” for ranking features. It enables product managers to justify the priority assigned to a feature, and makes the release content negotiation more productive and less contentious.

There are various tools that can be used for requirement tracking and prioritization. Some organizations adopt a “requirement tracking system” which includes a database and a set of tools for creating and tracing requirements. Clearly, for large projects and hundreds or thousands of requirements you definitely need a tool like that. However for most products, a properly constructed spreadsheet will suffice. You may start with a simple table that lists each feature, the associated ranking parameters (as listed above) and the assigned priority. This can evolve to include formulas that calculate “scores” for each feature based on values assigned to the different parameters, and so on.

I stated above that a healthy dose of intuition is also required. Let me elaborate: prioritizing requirements isn’t just a mechanical process – plug in the values and the desired release content comes out. Like Wayne Gretzky, the famous ice hockey player once said: “I skate to where the puck is going to be, not where it has been”. A product manager needs to make an “educated guess” about how the product will fair in a future market condition. In making that guess, there is certainly room for personal experience and intuition.