Brooks Hamilton
brookshamilt@yahoo.com

A question was recently posed in a local product management forum. The question was: "How does one build strong credibility around the Product Management team in an environment where there is subtle tension between Product Management and Engineering? I am a Pragmatic Marketing advocate. Is there anything in addition to quantitative market/customer data?"

Unless you are in a rare situation, product management is responsible for everything while has direct control over very little. It is a job where one has ample opportunity to practice their lateral management skills where your main contributions are vision, organization and leadership.

I have previously served in organizations where there was either no relationship between engineering and the business or the tension was anything but subtle. If you are starting from zero (or ground zero) as the new person in an organization, I recommend practicing the following:

A. Define Product Management

Explain the role of product management to the engineering and business teams. Since product management is different in each company, your audience will likely have varied impressions of what a product management organization does. Everyone should understand what you and your team are responsible for and how you will interact with them.

B. Establish Personal Credibility

Establish the market requirements and feature requirements/description documents with engineering. These are the keys to your relationship with engineering and your control over the product. My experience leads me to believe that the engineering organization's adherence to your recommendations is proportional to the trust they have in you. As you lose credibility, you will lose control of the product. Credibility is built with each of your interactions with engineering. In this context, astounding feature concepts and brilliant market insights are not as important as solid research, complete & thorough descriptions and timely delivery on every commitment you make. The keys are consistency and quality.

C. Make the Big Changes

If you are new in an organization, you are an unknown quantity. In the beginning, this works to your advantage. When you first come into an organization you have the opportunity to survey the situation, find the biggest problems (every organization has them) and push for the radical change. Once you pass the honeymoon period, there is an unstated understanding that you are accepting those problems as your own. The change may be a misguided roadmap, unrealistic delivery schedules, disconnected messaging or individuals who are deadweight. Make the change as soon as you can identify and validate the problem. You won't have another opportunity to impact so much with so little retribution.

D. Educate Yourself and Engineering on the Market

It sounds like you have plenty of Pragmatic Marketing doctrine so I won't talk too much about this except to give my rule of thumb. You should always have more vision for the product's direction and a deeper understanding of how its serves customer needs. It is also your challenge to constantly bring engineering to your level of understanding. This knowledge and your unique vantage point in the organization will help you shape the product roadmap. It is an immensely helpful tool used for leading internal efforts, soothing customer concerns and occasionally beating over-promising salespeople with.

E. Deliver Customer Wins

Everyone wants to know that their efforts have a positive impact on the business. A measure of validity of contribution for engineering is whether or not their product is succeeding in the market. Simply put, are people using what they are building? As product manager and especially a product manager with P/L responsibility, you need to bring home the proverbial bacon. Engineering should have insight into customer wins and pipeline building activities. Think of it as symmetrical to the product roadmap.

F. Over Communicate

Product management maintains a dynamic tension with each part of the organization due to the design of the position. If engineering falls behind and the product suffers than sales will find you. If engineering is under pressure to build product under unrealistic expectations you will be the culprit. (Hence the need to make the big changes in the beginning.) You must describe the status of and plans for the product to each part of the organization more than you would imagine necessary. Training an organization is like personal training. It takes constant and consistent pressure. Keeping everyone's expectations aligned will help avoid misunderstandings down the road.

G. Be Polite and Professional

In dealing with engineering, content is more important that charm but you are managing a relationship as much as a product or documentation. This relationship comes with somewhat divergent interests. You want everything yesterday, they have resource constraints. Make no mistake that there may be disagreements, arguments, struggles and open questioning of other's parentage. This doesn't need to happen. Keep a level head, be polite and follow the process. Although content is more important, some tact and goodwill will make it go a lot further.

H. Examine the Organizational Framework

You may perform brilliantly as a product manager but the organization's framework for product management may prevent you from succeeding. There are three kinds of development organizations that you may encounter:

1. Market focused. These are usually in product companies, have a culture of receptivity to market needs (and product managers) and their primary interest is the commercial success of the product. If this is your company, thank your lucky stars.
2. Internally Focused/Propeller Heads. The culture of the engineering organization is not receptive to market feedback because they believe they know best or are interested in building something cool (a fine piece of engineering but irrelevant/tangential to the market). An engineering organization that has experienced poor product management in the past may not be immediately receptive. If their stonewalling persists than it is time to change the culture, replace the engineering leadership or leave.
3. Founder Knows Best. This is another case of an unresponsive engineering organization where a founder leads it, believes that they know best and sees little use for product management other than presales assistance. The founder may have had a good idea of the market needs in the past but have not kept up the process via instituting and reinforcing product management practices. There is often little opportunity to be an effective leader in this situation because the founder has complete veto power and you have no chance for recourse.

The lesson is to make sure you are in the first scenario and not the other two.

Brooks Hamilton is the Director of Product Management for ForwardVue Technologies. ForwardVue assists large chemical companies optimize their profits by modeling commercial contracts and to better project earnings. In addition to his work at ForwardVue, he has managed enterprise software solutions in the strategic sourcing and procurement, IT application infrastructure management and asset management spaces for companies ranging in size from seed stage to publicly listed. Brooks can be reached at brookshamilt@yahoo.com