Negotiating with Engineering

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