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?

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.

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).

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:

II.            Positioning Statements:

 III.           Supporting Pillars:

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

Differentiators:

• 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. 

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

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. 

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.