To the sales people, you are just a chicken

In my first post on this blog, I mentioned that I had taken on a full-time sales role for the first time. Every one of you should consider a role in sales for a year or two … it is a real education.

It’s not as though I hadn’t “done” sales before. In product management and corporate strategy, I participated in countless sales engagements starting at the first conversation and leading to the roll-out / deployment planning. I have trained dozens of sales people on my products, and after taking Customer Centric Selling myself, I have even been a coach in a CCS seminar put on by Philippe Lavie, a consumate sales person himself.

It is so easy to criticize a sales person, and how many times have I done that myself? Oh, we used to make truly geeky jokes that sales people are like Stateless Session Beans (thankfully the sales people didn’t understand why this got such a laugh). They’re so coin operated. Just order takers. They don’t even understand the product.

I still do believe that the really good sales people are very rare, and I have strong opinions about what makes a good sales person. But I am beginning to understand, in my bones, the real difficulty of the sales job, and it gives me a lot more empathy for the coin operated people in sales. Every phone call matters. I am constantly negotiating. When people don’t call me back, what do I do? (Next!) How do I set up this relationship so that I maintain my own power and not give it all away to the propsect? Will the deal close in time? Forgetting to log my activity in salesforce. Forgetting the status of an account when asked by my boss.

I really do enjoy selling and sales, and I will be doing this for some time to be sure. Personally I think I’m good at it and I’ve had some wins, along with some errors that led to failures. And certainly some failures that were not my fault, and wins for which I should take no credit. There is a certain Tao to it all.

But I caution you … the next time you get upset with a sales person, think again. It’s like the man said: When it comes to the breakfast, the chicken is interested, but the pig is committed. And when you are sitting in product management, the pigs in sales look at you and all they see is a chicken. Drop off your eggs and keep moving buddy, I’m making some bacon here.

I am personally glad that I started on the product side. But after sitting in sales for just about 9 months now, I can’t recommend it strongly enough: At some point in your career, take a commissioned sales position, and not just an SE role. Be the seller, and stay there for a couple of years. Stay there until you get it right.

Come on, what are you? Chicken?

- Alan

How to be a GREAT Product Manager (part 5)

Be an integrator, translator and communicator. Don’t be a terminator.

I’m sure you’ve heard the phrase that Product Managers are “the hub of the wheel”. I really don’t like that line. Who wants to be the hub of any wheel? That’s like saying someone is the hinge of the door or the latch of the hood. Boooring! And not true.

Product Managers are collectors, analyzers and dispensers of information. They are routers of information flow. And being a great product manager means understanding how to optimize the information flow so that other teams in your company who are directly or indirectly dependent on you for information get it in a timely manner and in a form they can understand and use.

The following image is a coarse example of the major communication paths that exists in a software company. The blue are internal teams and the red are external.

[click to enlarge]

I say a coarse example, because it really only represents a high-level view of how information flows. Not all links in the diagram contain the same amount of information flow; not all nodes contribute as much information as they receive; and to keep the diagram from becoming cluttered, a number of links that rightfully should be shown are not.

I call these communication pathways the Information Supply Chain. And as a Product Manager, you are directly or indirectly responsible for a lot of the product and technical information that flows throughout your organization. How many times have you been asked if certain functionality is in an upcoming release? Or when a particular release is coming out? Or the details of a beta program? Or whether any pricing or packaging changes are being made to address market needs?

People are asking these questions because they are making decisions and need information to decide wisely. You can have a significant positive impact on those teams if you understand what information people need, when they need it, and in what form they need it? If you can do that for them, they’ll be able to make educated decisions sooner, streamline their work and be more effective. Deliver meager, late or difficult to understand information, and the opposite occurs. There is a real top-line impact to poor information flow in a company.

If you really want be analytic about mapping out the flow, you can do that. You need to look at all the stages of the product development cycle, from conception to completion to launch and beyond, and map out what information different groups need and when they need it. One way to represent it is via a heatmap that may end up looking something like this.

[click to enlarge]

The coloured cells represent areas where communication happens during the development cycle. The deeper the colour, or higher the number (from 1-3 in this case), then the more activity and information flow that happens. As you can see, Product Management is deeply involved in the information flow through all phases of the development cycle, but most heavily early on and in the middle, whereas Marketing and Sales, for example, really start toward the middle and have heavy information flow from the launch stages onward.

By understanding this, you can determine what information you need to produce and deliver to those groups to optimize their activities and decisions. Keep in mind that this is not solely a task for Product Management. Ideally all groups in the company use this analysis to optimize their communications. But, if you want to apply an 80/20 rule (80% impact for 20% effort), then teams like Product Management and Product Marketing must be the first ones to optimize their information flow to other downstream groups.

As technology workers, we exist in an information economy. And just like the manufacturing world, where materials, parts and inventory requirements are optimized for efficiency and minimizing costs, information needs can be understood and delivery processes optimized for greater efficiencies. And because of our role in defining product direction and driving strategy, Product Managers can play a key role in optimizing the Information Supply Chain. The question is, are you up to the task?

Saeed

Part 4 - The 4 Cs of leadership

Part 6 - Own the product from conception to completion and beyond 

How to be a GREAT Product Manager (part 4)

The 4 Cs of leadership: credibility, commitment, communication and courage

Product managers need to be leaders. A truism no doubt. But what does being a leader really mean and how can a product manager be a great leader? Let’s start by talking a bit about authority and responsibility. Both are words related to leadership.

Responsibility: noun. a form of trustworthiness; the trait of being answerable to someone for something or being responsible for one’s conduct; “he holds a position of great responsibility”

Authority: noun. the power or right to give orders or make decisions; “he has the authority to issue warrants”

Responsibility is both a trust and a duty. Authority is something you are given or possess related to your responsibilities. The two are clearly inter-related. If you have the responsibility to do something (e.g. uphold the law), you are given the authority to do the things that need to be done to deliver on your responsibility (e.g. issue warrants).

In cases such as law enforcement, both the responsibility and the authority are explicitly defined. In the case of many business functions, particularly matrix functions such as product management, the responsibilities may be explicit, but the authority is implicit in the role. It’s up to the individual product manager to understand that and not get caught up by the lack of a hierarchical reporting structure with other teams.

In my first PM job, after a frustrating product strategy meeting with senior management, one of my fellow product managers let out the famous line:

Product Management: All of the responsibility and none of the authority!

It was the first time I’d ever heard that line, and that afternoon, I couldn’t have agreed with him more. I had faced my own battles with the CEO over product direction issues.

When the first bullet point of the first slide of your product strategy presentation quoting a well-known industry analyst is brushed off by the CEO, and the analyst called “an idiot in a monkey suit“, you know it’s going to be a rough meeting. And when the CEO regularly plays a game called “If you guess what decision I’ve made about your products, then we’ll be in agreement on that issue“, it’s hard to feel empowered.

But, in the intervening years, I’ve learned a little bit about responsibility and authority and don’t agree with that line anymore. The fact is that, regardless of whether you have a CEO (and/or management team) that “gets it” or not, you’ve got a job to do, and whatever frustration you may be feeling about lack of authority is probably shared by your peers in other teams. So what can you do to use the authority that you do have and be the leader that you must be?

Welcome to my 4Cs of Leadership.

Credibility
Leadership begins with credibility.

credibility: noun. the quality of being believable or trustworthy.

If people aren’t willing to believe you and trust what you say, then there is no way you’ll be given authority to do anything significant.

How do you become credible?

For a PM, the best way is to be viewed as having the most thorough knowledge in your organization of what is needed to help make your product successful. That is what everyone is expecting of you (you are the product manager!), and if you can exceed those expectations, you will have credibility when you speak with people. Some things to put on your “How do I gain credibility?” checklist are:

• Know your product as well as your users know it
• Understand the architecture well enough to know it’s strengths and weaknesses
• Talk to more customers and partners than others in your company
• Collect more hard data about customer and market needs than your peers
• Understand the needs and dependencies of your internal teams (sales, support, marketing, engineering)
• Help those teams in their efforts where reasonable and valuable

Gaining credibility takes time. You’ll have a bit of a grace period when you start a new position, so use that period to get up to speed. Then, continue to work at it and ensure that once you have credibility, you don’t lose it.

Commitment
The second C of Leadership is commitment. The definition I like is:

commitment: noun. the act of binding oneself (intellectually or emotionally) to a course of action

Look at that definition closely. The words are very specific: “The act of binding oneself…” You must demonstrate commitment to your product’s success. In your current job as a Product Manager, have you bound yourself to the success of your product? Or are you just going through the motions and simply doing the job? People want to see that product managers truly care about product success and figuring out what is right and best for their product. If they don’t see that commitment to success, you will quickly lose credibility.

Communication
The third C of Leadership is communication.

communication: noun. the art and technique of using words effectively to impart information or ideas.

No amount of credibility can be retained if communication barriers exist between a leader and his/her followers. Leaders must be able to communicate their thoughts, ideas, visions and strategies clearly and succinctly, and in such a way that those listening are inspired to want to be part of the plans the leader is proposing.

Note that communication is both an art and a technique. Simply conveying information in documents or in rote form is not sufficient to be deemed communication. People need to understand what you are communicating to them and realize why it is important to listen to you.

Put yourself in their position and think about what they need from you. Convey information in forms that those receiving it from you find valuable. This may mean a bit of extra work for you initially — not everyone needs (or wants) to read requirements documents — but once people see you understand their frame of reference, they’ll see the value in understanding your communications. Keep in mind, people are bombarded with information daily, and they triage what they read and what they put aside. Make sure your information gets top priority by making it easy for them to consume.

Once you have credibility with your peers, show commitment to your product, and communicate vision and details clearly, you have the hallmarks of being a leader. But what can truly distinguish a good product manager from a great one is courage.

Courage
Welcome to the 4th and most challenging of the 4 Cs.

courage: noun. to act in accordance with one’s beliefs, esp. in spite of criticism. to have the courage of one’s conviction

The difference between a leader and a manager is the leader’s ability to take risks, blaze new trails, and have people follow him or her down those trails. Leaders can be praised when they succeed, but will be criticized roundly when they don’t.

As a product manager, you are an agent of positive change in your company. Stand up for what you believe is right, but do your homework first and be able to support your positions confidently. Not everyone will take to your recommendations or initiatives, even if you are correct. But, over time change can happen, even in the most conservative or difficult environments.

In companies that are open to change, it is a continuous process. In other companies, it comes in the form of a revolution. Regardless of the type of company you work in, if you want to rise to be viewed as a great leader, then have the courage to take, as Frost put it so well, The Road Not Taken.

The last stanza of Robert Frost’s poem sums things up nicely in my mind.

I shall be telling this with a sigh
Somewhere ages and ages hence;
Two roads diverged in a wood and I-
I took the one less traveled by,
And that has made all the difference

Saeed

Part 3 - “Spidey sense” instincts are good. Hard data is way better

Part 5 - Be an integrator, translator and communicator. Don’t be a terminator 

Here’s the deal with Biz Dev (Part I)

Saeed has posted two fairly provocative items about business development. (Here are the first and the second.) Frankly, Saeed, you’re not following your own advice. To paraphrase you, “Enough with the missives about Biz Dev”.

If you’re getting annoyed by what’s going on in your company, then you have two choices — help fix it, or move on. There are a couple of other choices actually, such as do nothing, or complain about it on your blog, but to be honest, if that’s what you do, then you’re not as great a product manager as you think you are.

hmm.

Certainly it’s easy to poke a stick at biz dev, and I could tell a few stories of my own. Several years ago, Intel was courting my CEO to have us port my product line to the Itanium chip, and thankfully I got to meet the Intel guy with my CEO for espresso at the old Starbucks by Moscone before we committed to anything. We were interested seeing what Intel might offer us, and my CEO really wanted to ink a deal with them. As Saeed said, it was “strategic”, and the Intel logo would look really great on our investor slide deck, or so our CEO felt. As is well known, the Itanium chip was a failure. Thankfully we didn’t invest.

In fact when we poked at Intel’s proposal, we found that the market for our product on Itanium would have been tiny; it would have been a tool to help people writing apps directly to the Intel metal, a specious group who wasn’t likely to increase our revenue. I suggested that Intel could pay a very large sum for our source code with an exclusive license on its doomed chip, but Intel didn’t bite. At that point our CEO saw that the logo on the Powerpoint slide wasn’t worth the distraction.

But I have also seen business development add major value to a company. When I was at Wily Technology, I saw how business development could be used strategically to strap a rocket to the company and create the engine for the company’s phenomenal growth. (And it was phenomenal. Eventually we were acquired for $375M, greatly exceeding the multiples of our peer group.)
What’s the difference between Saeed’s experience with BD and the Wily success story? It boils down to strategy, alignment, and value creation.

I’ll elaborate in future posts on this topic, so please stay tuned.

Frames of Reference

You’ve heard of the Doppler Effect right? No, not the Doppleganger Effect, but the Doppler Effect. Probably the most common example of the Doppler Effect is experienced when a vehicle with a siren approaches and then passes you on a street. The pitch of the siren decreases suddenly as the vehicle passes you. Of course, to the driver inside the vehicle, there is no change in pitch. And to the person on the street that hasn’t been passed by the vehicle, the pitch has yet to change.

The Doppler effect is fundamentally about frames of reference. The frames of reference of the observers in the street are very different than that of the driver. Thus, they perceive and experience the same physical phenomenon (in this case the siren), quite differently.

So, what does this have to do with Product Management? Everything.

Being an effective product manager means, being able to get into the frames of reference of others, understand their experiences, needs and wants, and then assimilate that information and convey the necessary information to those around you who need it. If you can’t do that, then your product or release may get reinterpreted many times over by each team involved. One of the most famous examples of this problem is the famous tire swing series of cartoons.

Try something. When you are at work at your desk, get a chair and stand up on it (or stand on your desk if that is safe) and survey the area around you. Does it look different? What do you see from that frame of reference that you never noticed before?

Subtle changes in frames of reference can have a big impact on what you observe and what you understand. Consider people who work in data centers. To some, the most important part of the data center are the servers executing code. To others it is wiring, network cabling and switches that connect those servers to each other. To others it is the storage that holds all the data needed by the servers and transmitted over the network. To others, it is the cooling systems in the data center, without which the servers would overheat and shutdown. Each has their own priorities and their own frame of reference by which they view the data center.

The same is true inside the enterprise. Different teams view the world very differently. A CFO is focussed on net profit and loss and booking revenue. A VP of Sales is more focused on booking sales. Revenue and profitability are secondary concerns. A VP of Engineering is focused on delivering quality product on time. While each of these people are typically very concerned about the success of the company, their focus means they view success differently. Product Managers need to understand the differing frames of reference, and then be able to shift between frames as they work with members of different groups.

When I first became a Product Manager, I was having a tough time dealing with a number of the sales people in my company. I didn’t understand why communicating with them was so difficult. When I spoke to the VP of sales about the issues with his sales team, he gave me some advice.

“Salespeople are coin-operated. Remember that, and you’ll have no problem working with them.“

I took his advice and it worked wonders for my relationship with the sales team. Why? Because I stopped talking to them from the perspective of a Product Manager, and started communicating with them in their own language and in their frame of reference.

What’s the deal with BizDev? pt. 2

James McGuirk left a detailed comment on my original post that warranted a response.

Nicely written article and one that addresses the likely perspective of a product-oriented organization. Fundamentally they have interest in cultivating relationships with larger vendors which inherently increases the possibility (at least) of expanding the channel.

Thanks, and yes, correct, though I’d have to say it is from the perspective of a market-driven product organization. i.e. the clash between an overall market focus for products vs. a deal-driven partner/customer focus is the crux of the problem. As I mentioned in my comment to Mike Sabat:

In a sales driven company, product follows the transaction. i.e. the company builds the product to fulfill the transaction criteria.

…

In a market driven company, which is where Product Management looks at overall market needs (and not strictly at individual customer needs), the transaction follows the product. i.e. the company sells what is built with little or no modification.

While sales-driven and market-driven may not sound like they are too far apart, they are almost complete opposites when thought of from an operational perspective. But I digress.

James continued:

My perspective on business development however is derived from the vantage point of a systems integrator, where there are significant differences between services and product. As someone who has spent over 20 years within federal business development, the term implies an understanding of all aspects of winning business.

Companies that sell services, or sell products which include services, are almost always transaction-oriented, and therefore sales driven. I can sell you my generic product, but also sell you services to customize the product for you in some way. As soon as the services component comes in, even if the service is simply to help someone choose a product, the particular needs of the individual customer drive the activity.

In aggregate therefore, business development experts within the federal marketplace should have all those aforementioned qualities to be successful. Suffice it to say because of the level of comprehensive knowledge required, their expertise is always welcomed. Hope that helps. Jim.

The aforementioned qualities laid out in James’ comment are: Sales, Marketing, Capture Management, Proposal Management. What James describes is a different type of business development than what I was describing. In a product development company (vs. a services company), BizDev is usually part of of the Channels organization. It’s goal, as James mentions, is to expand the channel. But the issue that has frustrated me is the way many BizDev managers go about it.

Sales people are told to sell the current product. They can’t sell futures and they can’t make promises of future functionality, even if it is “on the roadmap”. But BizDev managers aren’t always held by these rules, even though they are fundamentally also sales people. I’ve seen too many cases where they sell futures (in the name of being strategic), and they discuss issues that are way off the roadmap — like the IBM mainframe port I mentioned previously. When this happen, serious misalignment occurs.

I have no issue with BizDev or Strategic Alliances in general. I see the need for them clearly. But I also have the responsibility as a Product Manager to do what is best for the product and the company. And much more often than not, that means saying “No” to rogue BizDev managers (and even, with some professional risk, Senior Management), when they go “off roadmap” and start looking for that “company making deal” (I’ve heard that phrase far too often) with some gargantuan organization that frankly, is going to waste a lot of our time, and is unlikely to ever close the deal from their end.

What’s the deal with BizDev?

I’ve worked in a few companies that had a role called “Business Development”. I have to say, this is probably one of the most poorly defined and managed roles I’ve seen in any of these companies. Usually “Business Development” means “Strategic Alliances”. Now what does that mean?