Archives for category: Uncategorized

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.

Of all the activities product managers are engaged with, understanding customer needs and translating those into product requirements is probably the most strategic one.  Developing new products or enhancing existing ones, is a time consuming and resource intensive process. There are few things more devastating to a business than releasing a new product only to find out it fails to meet customer expectations. Furthermore, in today’s highly competitive markets, it is not enough “just” to meet customer needs – your product must also shine against competing products who aim to fulfill similar customer needs.

So how does a product manager go about gathering market requirements? Should he read market research? Follow the trade press? Talk to customers? Listen to what sales people have to say? Study competitors’ products? Evaluate suggestions and ideas coming from various departments within the company? YES he should. These are some of the wide ranging sources a product manager can tap into to gather product requirements.

But first let me emphasize what I believe should be the key focus for gathering requirements. I want to paraphrase a statement I attribute to the former CEO of Cadence Design Systems – Joe Costello. Those of us who worked under Mr. Costello may remember his saying to product managers eager to come up with new product ideas: “Find a Customer Problem and Solve It!”

This may sound somewhat simplistic, but I can’t even begin to describe the number of times I have seen product managers, and even companies get fixated on their own ideas and in the process forget it is all about the customers. It is all about addressing customers’ needs; solving customer problems; offering customers a better way to accomplish what they want to accomplish.

If you are a product manager tasked with gathering requirements for the next release, or the next product, then make sure you get as close as possible to “the customer” and understand their needs. Find a customer problem and solve it.

There are many sources with ideas on what to do next with your product. The engineering team usually comes up with clever, technology driven suggestions. Sales people interact with customers and competitors and love to tell marketing what should be done. Customer service receives numerous customer calls with complaints and requests. Other companies you work and cooperate with have ideas on where your product should be heading. Market analysts publish reports and offer their insight on where the industry is heading. These are all good sources, but remember to get in touch with your customers directly. Don’t get lost in translation.

So how do you get in touch with customers and find what they need? Well, if your company already has customers, the task is much easier. You tap into the customer database, get in touch with sales people who can make introductions and arrange to have direct conversation with customers. You can even run surveys with your existing customers and ask them to specify or prioritize their needs. Go on sales calls with existing or potential customers. Build trust relationship with key customers, so that you can discuss your ideas for new products, or how to evolve existing products, and hear what customers have to say.

Most importantly – get out there to the field. Go on road trips, sales visits, phone calls, tradeshows, and seminars – whatever gets you in front of customers and allows you to have a dialog. Make it a priority to have regular customer interactions, even if it burdens your already busy schedule and overflowing task list. Having direct customer contact is what keeps you (and the company) honest when it comes to developing and evolving products. Most product trouble begins when that contact is lost.

But what if your company or product doesn’t have customers yet? How do you gain that invaluable customer insight? This situation is especially common in the case of startups. My experience and advice is to wear your salesman hat and go out and meet potential customers. And if you don’t have such a hat, than “grow one” – go out there with sales people, engage and learn.

Too many startups, and far too many established companies, keep their new products “under wraps” till the designated launch date. By then it is far too late to gather customer feedback, or change anything material in the product. You may be one of the lucky ones that hit the mark, and your product happened to match what customers need. Unfortunately, this is the less likely scenario… And the risk associated with missing the mark is far too great. I believe that you should discuss product ideas, under great discretion, and with hand-picked customers as early as possible. There are many customers who love to participate in driving future product direction and know how to keep a secret. Find them.

But what if the customer doesn’t really “know what they need”? What if you are working on a revolutionary product, a breakthrough technology that customers simply cannot relate to, yet? How do you get input from customers under these circumstances? In marketing lingo this is referred to as the “unarticulated needs”, unlike what I discussed earlier which deals with “articulated needs”.

People love to talk about products that “created demand” once they were introduced. Products that met needs that customers weren’t even aware existed. I think that you have to be careful before talking about “creating needs”. My belief is that customers, individuals or businesses, usually buy products that satisfy their needs. Now the product may satisfy a need in a whole new way and thus create a category. But it stills satisfy a need.

Take for example smartphones: several years ago hardly any users would have described the set of features and functions smartphones offer today. Yet the need to stay connected, gain access to information, take pictures, etc. existed. The desire to carry as few devices as possible when leaving the house was always there. The ability to connect those dots and offer a product that addresses these “unarticulated needs” is what made smartphones such a huge success.

To me it all boils down to the very same advice I got from Joe Costello years ago: “Find a customer problem and solve it!

Handling the various aspects of product management requires a broad set of skills. For example, when negotiating product requirements with engineers, product managers must understand the feasibility and implementation costs of various features. On the other hand, when working with sales, product managers need to be conversant with business lingo and understand sales processes. The “ideal” product manager in a hi-tech company must possess the following skills:

  • Technical skills: have basic understanding of the technology and tools (e.g. software, hardware) used for developing and manufacturing the product. This becomes valuable when assessing what can be accomplished within a given time frame and a set of resources.
  • Negotiation skills: product managers do not directly control the resources required for their product success. They need to negotiate and build alignment with other company managers and sometimes with partners.
  • Communication skills: verbal and written communication skills are essential for any product manager. They become invaluable while communicating with internal teams, customers or partners.  
  • Presentation skills:  product managers are asked to present on a regular basis: updates to upper management, training and motivating sales teams, briefing customer executives or briefing news editors – all require high-impact presentations.
  • Financial skills: understanding cost structures, calculating margins and profitability, building return of investment models are but some of the financial tools a product manager needs to use.
  • Sales skills: while product managers may not be directly responsible for selling, their involvement in key customer deals requires they understand the sales process and master some of the related skills.

I am sure there are a few other skills I left out…

But raw skills aren’t enough. A product manager must rely on some prior experience to be able to do their job. Very few people start their career directly in hi-tech product management. Many of the product managers I personally came across started their career in a technical position. They moved into product management after working for a while as development engineers, test engineers, support engineers or field/system engineers. Interestingly enough, almost every engineer who moves into product management expresses a similar desire: to be able to drive the product direction. But clearly being an engineer is not the only path into product management. There are many other skills and experiences that a person can leverage into becoming a product manager.

The diversity of skills and tasks associated with product management makes it difficult to find people that can handle the full spectrum of activities. This leads many companies into dividing the product management responsibilities into different roles. Of course having multiple people handle different aspects of product management – for the same product – does occasionally create overlap, conflicts or gaps. It is the organization management responsibility to ensure that those do not hinder product success.

There are many different ways to define “roles” that fit under the umbrella of product management. The most popular division lines I came across were: ‘inbound vs. outbound’, and ‘technical vs. business’. The titles may vary from one company to the other, but the roles are fairly similar:





Technical Marketing

Systems Engineer


Product Manager

[Product] Marketing Manager

Inbound roles tend to focus on the interactions within the company: working with engineering, manufacturing, etc. Outbound roles focus primarily on interactions outside the company: with the media, analysts, customers, channel partners, etc. There must be close collaboration between the inbound and outbound teams: the former has intimate product knowledge, while the latter knows how to broadcast the message to the outside audience.

Technical roles tend to focus on the “how” – the inner workings of the product, while business roles focus on the “what” – the benefits and utility customer gain from using the product/service. Here again collaboration is the key to success. For example, on the inbound side, the ‘business’ person prioritizes high level requirements based on market needs,  while the ‘technical’ person works with engineering through the fine details involved in implementing those.  On the outbound side, the ‘business’ person may craft the benefit statements for the product, while the ‘technical’ person builds splashy demonstrations to illustrate them.

Whether you are on the inbound, outbound, technical or business side of things, the common objective you should strive for is the product’s success. As long as each member of the “product management” team understands the strategy and how their activities fit into it, the product will succeed. The challenge with distributed roles is to maintain open communication and close collaboration between team members – especially when they report into different organizations within the company. 

Developing, manufacturing, promoting, selling and supporting a product involve multiple departments within a company. A typical division of responsibilities may look as follows: The engineering department designs and develops the product – be it a hardware device, a piece of software, or a service. Manufacturing is responsible for building products in quantities to meet demand. The marketing department promotes the product using vehicles such as public relations, advertising, tradeshows, etc. The sales department is responsible for selling the product to potential customers. And finally the technical support department resolves any problems customers encounter while using the product.

With multiple departments involved in each product life cycle, coordination and alignment become critical to product success. Orchestrating the activities of all the departments involved is the primary responsibility of a product manager. In many respects, the product manager is the ‘Chief Executive Officer’ (CEO) of the product.

The challenge that every product manager faces, is that unlike a CEO, the various departments involved in the product lifecycle do not report to him. A product manager is rarely in a position to “order” a manufacturing manager, or an engineering manager to do the right thing for the product. The secret to a product manager success is the ability to convince the various departments to march in the same direction and effectively collaborate to ensure product success.

The product manager primary job, and a key to his /her success, is to build a leadership position; a status that will grant them authority over the various departments. The process of building product leadership requires the use of political skills – in a positive sense. It certainly helps if upper management provides the right backing for the product management team. But at the end of the day, it is the product manager who must handle the daily challenge of maintaining his/her product leadership status.

Assuming job #1 has been accomplished and the product manager has leadership/influence over the other departments, his responsibilities should include the following:

  • Product requirements: identify the key customer requirements engineering should implement in a new product, or subsequent releases of an existing product.
  • Feature prioritization: reach agreement with engineering on the priority and implementation order of features, and the actual content of a product release.
  • Release planning: plan a schedule of future releases that introduce new features and necessary fixes.
  • Pricing: of the various product offerings, options and related services.
  • Messaging: define the key messages and the product positioning. Work with the marketing department to deliver those to customers and partners.
  • Competitive positioning: analyze competing products/services in the market and define key advantages to be highlighted during the sales process.
  • Sales enablement: create educational materials and train the sales force on how to best position and sell the product/service.
  • Deal support: provide any required assistance to sales people; personally engage to help win strategic deals.
  • Crisis intervention: become involved with, and help resolve major breakdowns that occur at strategic customer deployments.

Product management is one of the most complex and challenging positions within the organization. As the saying goes – “Success has many fathers, while failure is an orphan”. When a product succeeds in the market place, engineering takes credit for building a great product, and sales will pride themselves on their ability to drum-up customers. But when a product fails, the product manager may find himself carrying the blame: feature requirements weren’t clear, or incorrectly prioritized; messaging was murky; sales were never properly trained; etc. So why should anyone wish to hold such a position?

If you love to drive a team, build consensus and watch it succeed in creating something new. If you like to deal with multiple disciplines, and interact with all parts of the organization. If you love engaging with customers and keeping your fingers on the industry pulse. If you want to exercise your analytical skills, communication skills, and people skills – then you will find the role of a product manager ideal for you. And if you dream of becoming a CEO of a company, there is no better training than a product manager job.

I never thought I would become a product manager (PM). As a matter of fact I never thought I would work in marketing. I actually didn’t know what marketing was, until my mid 20’s.

When I was about 13yrs old, I had a session with my elementary school counselor. She looked at my grades and told me that I could become either an engineer or a doctor. I didn’t like doctors. So I decided that I should pursue a technology route. I went to a vocational high school studying ‘electronics’ and proceeded to college to get a bachelor degree in computer engineering. With a BSEE in my hands, I embarked on an engineering career. It lasted for about 10yrs. I got to design communication systems, computer systems and even tried my hand at managing a team.

Most my colleagues went on to graduate school. Some got a masters degree in engineering (MSEE), others pursued a master in business administration (MBA). I couldn’t quite make up my mind which one to choose, so I signed up for both an MSEE and an MBA programs concurrently.

The MBA program really opened my eyes to another world. The world of business. I realized there are many fields I knew nothing about, and picked finance and marketing as my majors. I became reasonably proficient in finance, but fell in love with marketing. It became clearer as I progressed in my MBA studies that marketing was my destiny.

I was working as a computer engineer while attending school. I don’t know how I managed to juggle a full time job, two masters programs and start a family – all at the same time. Somehow it all worked out…

Towards the end of my MBA program I started looking for another job – a marketing job. I realized that a transition from an engineering role to a marketing role is a major career shift. So I decided to take a ‘baby step’ and move into a “technical marketing” role.

My job was to work closely with product marketing managers, and translate their marketing requirements into detailed functional specifications. I then worked closely with the software engineering team  to ensure that the functional specifications I wrote indeed matched the software products they developed. Kind of a “technical go-between” engineering and marketing.

Over time, I was requested to help train the field organization on the products we developed. I found myself traveling all over the world training technical field engineers, and meeting with customers who either considered, or were already using our products. It was a big, fascinating new world for me.

After my first step into technical marketing, I proceeded to fill roles in product marketing, corporate marketing, business development and sales. For the next 20+ years I worked for small companies, medium companies and very large companies. I worked in start-ups – some were very successful and some were not. I worked on hardware products, software products and even service products. I worked for Israeli companies, for American companies, for bi-cultural companies and for international companies. In short, I got to experience and participate in just about every facet of high-tech marketing.

Hi-tech product marketing is an exhilarating field, with hardly any dull moments. There is no other position within a hi-tech company that has more influence on a product success. A good PM can spot market trends, capture customer requirements, prioritize them properly, inspire the engineering team to build a world-class product, and evangelize it with sales to drive revenues and customer acquisition. A good PM is worth his/her weight in gold.

However every PM must learn to face challenging moments. Like facing a customer who is utterly disappointed with your product. Or trying your best, yet failing, to influence your engineering team to build the product the market actually needs. Or losing a major deal to a competitor, that simply did a better job. But for all these “down moments”, I find a PM role to be a very fulfilling one.

I learned a lot of lessons during my years as a PM, and as a leader of PM teams. Surprisingly, many of these lessons are not taught at school. There are many useful “tools” I picked up through my MBA studies. But none of them can substitute the “wisdom” required in a PM job.

I decided to write this blog and share some of my lessons learned throughout my own PM career. And if you have some of your own – do share.