Transparency in Product Management

Transparency - (noun), an image, text, or positive transparent photograph printed on transparent plastic or glass, able to be viewed using a projector.

If you are as old as I am, you remember printing your powerpoint slides to transparency film to be used on an overhead projector during presentations. It was a dark time. However, that is not what this post is about. It is about how transparent you should be as a product manager in your communications with other groups in your company.

The saying is that sunlight is the best disinfectant (it isn't) - that the more transparent you are in your interactions, the more trust and faith others (individuals, groups, departments) will have in you. And in general, my experience has borne this out. As a product manager, you have access to an amazing amount of information, and data streams within the organization. It is not inconceivable that you (yes you) know more about how the business runs than the leadership team.

However, with this knowledge and access must come some restraint. Hence this post.

Knowledge is Power

In most of the companies I have worked at, knowledge was tightly controlled. Detailed business and operational metrics - Secret. Marketing numbers? - Secret. Competitive analysis? - Secret. Hell, you often have functional managers who hoard and hide their data.

Why the secrecy? A couple of reasons:

• Insecurity - alas, hiding data is often a tactic to protect someone (a.k.a. a 'leader') who feels inadequate. Thus, they try to shroud their team and their objectives in a cloak to raise their perceived value to the organization.
• Power Hoarding - If knowledge is power, then it is finite, and it is something to be coveted. This is hand and hand in conjunction with insecurity, but it goes beyond mere insecurity. The ladder climber will use their precious data and information to gain an advantage, an advantage that can be used to get ahead (next level, grow their domain, or other "benefit").
• Incompetence - sometimes – far too often in my experience – the shroud of opacity is used to hide gross incompetence. Someone who has been promoted into a position that they are wholly unqualified for, or who is terrible at building an effective team. So, they use a lack of transparency as a protective shell, often building a mystique about their domain, and a wake of seriously broken commitments behind them.

Product Management, at virtually every company I have been at has at their fingertips data and assets that can smash all these barriers. If you are really a product manager, you know enough about production schedules, about the infrastructure, about the customer acquisition costs, about the sales funnel, about the support hot-spots, about the markets and segments, about the typical (and atypical) customers. You know when Operations is struggling to meet specifications. You know when (and how far off) development is behind schedule. You know the profitability.

In short, you know everything there is to know (or at least you should) about your product.

But, how much should you share? A valid and reasonable question.

Knowledge wants to be free

As a product manager, I like to think of myself as the hub in a bicycle wheel, with spokes to all the other functional groups (and I truly mean ALL groups), balancing the forces and pressures throughout the organization. This is essentially the old adage of "All the responsibility, but none of the power" of product management.

Alas, if there isn't balance, the wheel can self destruct.

One way for it to get out of balance? You guessed it, information.

Often the power centers overly protect their data. A lot like the guild system from the middle ages in Europe that protected artisans, the functional groups will shroud their practices in mystique, frippery, and - quite frankly - nonsense. As if their daily duties are mysterious, and impossible for the mere plebes to understand.

Alongs comes this mere peon a product manager who not only understands their function, but can explain it in simple terms.

• Finance talks in terms of IRR, NPV, mapping, accruals, and other terms that seem created to confuse. But at the end of the day, money goes into the company, it gets allocated, and reported in disclosures, and profit and loss calculations.
• Operations likes to pretend that they're the kings, because the produce the widgets that generate the money and pay your salary so quit questioning them.
• Development is sure that they know what the company needs to do next, and that they don't need no meddlesome interloper (aka product management) to get in their way.
• Sales, well clearly they are the most important group, because without them, and their selfless sacrifice on the road, pounding the pavement, shaking money from reluctant customers, you would all be out of work.

The challenge is that all of these groups are partially correct. But if you have ever experienced a sales led, or engineering led organization, you will have a bird's eye view of an out of balance wheel.

Like a bicycle wheel, there are some tolerance for out of round, or some wobble, but if you go beyond the reasonable (as in it is so out of true that instead of truing the wheel, you just remove the brakes so they don't rub) it becomes an unsafe situation.

But there are limits

With great power comes great responsibility. The quote appears to have originated with the character from the Marvel Comics series Spiderman, and be from uncle Ben.

Regardless of its origin, it rings true, especially in the world of product management. Alas, as a product manager, you are supposed to have the big picture, the tie in between the revenues, sales, operations, and the development. Senior management looks to you to be the unifying thread keeping it all together.

You are able to circle at 30,000 feet (or 10,000 meters for the rest of the world), and divebomb down into minutia.

Finance wants to know why bookings are off on a product, they come to you to explain (was it competition, or the product is stale and needs a next generation, or is there a structural shift in the market) because you should know the reason.

Operations is planning their capital spend, and needs "real" forecast (not necessarily the rosy one that Sales produces), who do they call? GHOST BUSTERS - just kidding - they walk into your office for an informal chat.

Hell, you certainly know more about the actual operation of the business than the GM or CEO, and they know it.

Yet, it is possible to abuse this position, to abuse the trust that you have worked so diligently to gain, and that is to use the information, the knowledge in your position to gain advantage or leverage over others.

Sales is lying about their forecast, sandbagging like Hurricane Katrina is at the edge of town. You know they are full of ****. Do you call them out? Do you anonymously embarrass them?

Or operations made a critical change to reduce their costs, but that is leading to more failures, and an increase in returns/cancellations/support calls. Do you pin them to the wall?

Or development is chasing their tails, ignoring the PRD or the backlog, working on technical debt because they are certain that it is better than the user story you wrote. Do you berate them in the iteration planning session?

Or, you are at a trade show, and having drinks with friends, people you have worked with, who are also competitors, do you share war stories or inside information on how the business is running? Do you let slip that there is weakness in Asia, and costs are increasing?

These are all scenarios that product management will find themselves in, with access to hard, cold facts that can materially affect the outward image and performance of the business.

Where to draw the line(s)

Clearly, you need to build a working model for yourself. Sharing the knowledge you have is a powerful way to both increase your stature, but it also can help the rank and file see more clearly the true mission of your business (which - let's face it - is always deeper than the formal mission statement on your web page).

But, if you share too much, you will become a threat to other organizations (or guilds) where their silo of data and knowledge are the sources of their power and self worth.

And if you share too much in a tipsy meeting with an industry analyst, you can do serious damage to the business, and if discovered, you will be terminated, justly, and wondering where the hell you went wrong.

Product managers like to find solutions. Data and knowledge are the fuel we use to investigate, and propose those solutions, to build business cases, to fire up the teams, to build a realizable dream, and to evangelize this dream as important to the business.

Don't go too far, and don't let it go to your head. Remember: Knowledge is Power and power can and does corrupt. It isn't impossible to balance, but it is often tricky. Your mileage may vary, objects in the mirror are closer than they appear - and all that jazz.

Keep your head about you, and see you at the after party.

Coda

Personally, I make it a point to be available to anyone in the organization who has a question. If they have an honest question about the company, how it makes money, the business model, the customers, the competition, how our marketing works, how we solicit and validate the requirements, how I manage and groom the backlog, why people buy our product, who our customers are, are they happy, etc, I tell them the truth (as long as I am not sharing material information).

Truth is, most people in the organization want to feel more connected, to know more than their functional area, and it is a valuable service for product management to shine light, and increase the shared vision.