MSFT Office in the cloud: a user's perspective

I know a lot of PMs cruise through some of the technology industry forums, such as Slashdot, for the occasional useful feedback about products. However, for products like Microsoft Office, you have to go where the less techie folks hang out.

In that spirit, I thought the letters section for this post on Salon's technology blog was actually more interesting that the original post itself. The topic: Microsoft's plans to put Office in the cloud.

What Do You Say When the CEO Asks "What Do I Get For My Investment in Sales Enablement?"

When your CEO asks, "Why haven't we realized the sales performance boosts we expected when we (insert investment of your choice)

...implemented our SFA system?
...trained our sales organization?
...launched our sales portal?"

How will you respond?

If you (and the CEO) thought that investment was "the answer" to improving sales performance, we have some bad news. There is no such thing as a sales effectiveness silver bullet.

While, there are many different types of organizations that claim they can help you improve your sales productivity, few of these solutions can offer measurable gains in productivity on their own. For example:

•CRM vendors argue that implementing their software will help you drive more business by providing better structure to the sales process and improving the accuracy of your forecasting.
•Sales training firms suggest that you can improve your sales fundamentals by teaching a common sales methodology and best practices.
•Market intelligence firms claim that better and more up-to-date information about market trends and your competitors' actions will do the trick.

However, companies that have implemented these solutions report that they are not realizing the desired impact of these investments.

And now that you find your firm in this same situation, how will you respond?

Potential Response #1: "We Must Have the Wrong Salespeople"

While it's true that many executives who feel they have been burned by these investments view missed sales quotas as a performance issue, I don't necessarily agree.

Perhaps from an ivory tower, one might assume it's a simple task – selling your wonderful product to customers who must have it. While this might be a reasonable expectation when selling an item that people are familiar with (like a luxury car or laundry detergent), this perspective is dead wrong if you provide complex offerings and sell primarily to businesses. In fact it could be argued that selling B2B solutions is fundamentally harder than any other business model in the market. The basic reality is that you are demanding a lot more from your field selling organization than you may realize, which I touched on in earlier. (See “Are Your Salespeople Stupid" http://blogs.forrester.com/product_management/2008/08/are-your-salesp.html)

Potential Response #2: "We're not meeting our sales team's needs"

Brutally honest, I will admit. But probably true.

According to the American Marketing Association, 90% of marketing collateral is never used by the sales force.  Any deep study on how sales people use their time reveal only a fraction of their day is dedicated to valued-added, client-facing activities.

The rest of their time is spent on a combination of tasks including, internal meetings, paperwork, researching customers and account profiling, coordinating internal resources, looking for or creating relevant content to advance opportunities, etc. Before we examine areas to make investments in sales productivity, lets first get a sense for what we ask sales executives to do each day (either intentionally or unintentionally).

•Understanding the customer's needs. Identifying the true customer is challenging enough. With most technology purchases, there are many buyers involved. Business sponsors, IT executives, requirements analysts, financial analysts, enterprise architects, and application engineers are all common participants in an enterprise solution purchase decision. It is almost impossible for a typical sales person to understand the business goals of each stakeholder and translate your offering so that it is relevant to each of them. And, even those that can have to perform this time-consuming activity from scratch for each opportunity.

•Following up on leads and prospect opportunities. What happens when marketing passes a lead to sales? All too often these leads only contain contact information and a list of products the customer may be interested in. The sales person who is tasked to follow up on that lead does not have insight into the business goals of that prospect, nor a compelling way to engage in a conversation with them. If given a lead from your marketing organization today, how would you follow up? What would you say when you called the contact? How excited are they going to be to hear from you?

•Advancing opportunities through the pipeline. Sales people are expected to continually advance opportunities through the sales process towards closure. Methodologies allow sales executives to focus their skills on various stages of the selling process and define key milestones to help determine how soon an opportunity will close. However, your customers are not making decisions based on the artificial milestones that your organization sets – they have their own buying process and very few sales people have insight into how the customer will really make the decision.

•Translating product knowledge into business advantages. A lot of time and energy is invested in training sales people on the functional attributes of the offerings they sell. However, sales professionals lack the personal experience of working with your offerings and have difficulty understanding why the features and functions are important to your clients. Meanwhile, your clients are less interested in the features. They want to know how your products or services will help their business. Since most sales people have difficulty making their offerings relevant to business issues, they rely on the product demo to tell the story and hope the customer will connect the dots themselves. \

Unfortunately, today IT organizations are less interested in technical merits because standards are improving and they have architectural processes in place to help them better understand the strengths and weaknesses of certain technologies. They are much more interested in the elements of the business relationship. For example, they want to know how you can help them implement the solution, how it relates to their business, how you can help them justify it, what you can do the help gain buy-in, and what it will take to maintain the system.

•Financially justifying investments. IT investments are under a tremendous amount of scrutiny. Organizations want to know how your offering is going to impact their business, when they will realize that return, and how that investment will impact their budget. Corporate financial metrics, cash flow outlays, and internal rates of return are all examples of topics common in evaluations of technology investments. Yet, most sales people lack the ability to have a meaningful conversation about these subjects – let alone prepare the tools to help your clients perform these analyses.

It's true that most organizations can improve their productivity with investments in infrastructure. Likewise, they can always benefit from a solid sales process and an occasional fine-tuning of their selling skills. And, no one questions that sales organizations require up-to-date information about market trends and competitor actions. These steps are critical to continuously improving sales effectiveness.

However, the fundamental sales need that organizations rarely provide is relevant, targeted content that is directly correlated to the customer's buying process and considerations. Additionally, optimum sales performance requires balance across each of the five disciples mentioned. Therefore, the best way to maximize sales performance is to view sales effectiveness as an ecosystem – one who’s governing dynamics are the unique needs of your targeted customers.

ssantucci@forrester.com

The King Of Empty Promises

A quick addendum to the previous post about customer advisory boards (CABs): Badly-conceived and infrequently-held CAB meetings make the customer feel like the protagonist in this clip. (Plus, it's an excuse to post one of my favorite Kids In The Hall skits.)

CAB rides to nowhere

In the small corner of the blogosphere devoted to product management, you'll often find musings about the value of customer advisory boards (CABs), such as this post from the Cranky Product Manager. In my own experience, CABs are frustrating beasts, which is why PMs keep talking about how to handle them:

• Development teams know that they should have some regular contact with customers.
• However, they view regular contact as a luxury--particularly if CAB meetings turn into an expensive boondoggle. (Fly in the customers, treat them to an all-day session, have dinner with them in the evening...)
• Therefore, CAB meetings often happen, at best, only once per year.

In short, CAB meetings happen just often enough to raise the customers' hopes that the development team will actually listen to them. Unfortunately, since the development team only meets with the customers once per year, the product direction is usually significantly out of whack with the customer's wish list. Therefore, the development team recoils from the substantial work needed to respond to these enhancements, so the requests into the "When we have time to get to these" memory hole. One year later, the cycle of mutual frustration starts all over again.

That's why, when I ran PM teams, my rule of thumb was, "Don't bother having a CAB if you're only going to meet once per year." CABs should be trusted advisors, which isn't possible with yearly "drive by" meetings. I'd rather have quarterly webinars with the customers than a yearly face-to-face meeting. The conversation might not be quite as good, but at least you'll keep in touch with them often enough to ask for clarification, get their feedback on ideas, and show them how their requests are affecting the trajectory of the product.

CABs have lots of other problems that I won't cover here, but are worth a short mention:

• Confusion of product marketing and product management goals. Not every good candidate for the CAB is willing to be a customer reference. Unfortunately, that's the entrance requirement for some CABs.
• Too many CAB members. You can quickly reach a point of diminishing marginal returns, past which you'll get only superficial discussions with CAB members.
• Too few CAB members. On the other hand, too few CAB members increases the risk that you're not really hearing representative requests.
• Skewed samples. Even if you get the right number of CAB members, you might pick too many from a particular vertical, too many of a particular size, or otherwise skew the sample.
• Talking at the customers. Many CAB meetings turn into a marketing campaign, in which the company tries to sell the next release to the CAB members, instead of listening carefully to what the CAB members really want.
• Hearing what you want to hear. I've also seen CAB meetings fail because the company has some strong opinions about the product direction. Development team members are therefore looking for confirmation of the product strategy, and generally tune out information that challenges the roadmap.
• Talking about features, not solutions. CAB meetings can quickly devolve into a prioritization exercise for the Big Honkin' Spreadsheet Of Features. That's a big mistake, since the CAB is a critical source of insight into the business problems customers are trying to address, and the necessary component of the solutions needed to address them. Features are details that need to fit into the solution, which the CAB members are usually eager to discuss.

The product team needs a CRM system?

Yesterday, two of my research interests, Agile and CRM, intersected during a briefing. The demo, which I'll describe in a moment, was a great illustration of one of my pet theories: integration will be the killer feature for software in general for the next several years. CRM in particular needs these benefits of integration.

Rally Software has a nice integration between their tools, designed to support Agile development teams, and the Salesforce CRM system. Salesforce users can record enhancement requests and product feedback that are fed automatically into the requirements component of Rally's suite of tools. Product managers then can refine this information (has anyone asked for this feature before? how does it fit into a user story? how important is it?) and add it to the backlog. The product roadmap, which now includes requests that start in the CRM system, can also have some visibility within Salesforce.

Very slick, particularly in how this example shows the value of integrating CRM with other things. As of today, CRM has a lot of untapped potential. As we discovered in the "product management tools" study earlier this year, the CRM system ranks at the bottom of requirements sources.

That just seems wrong. Salespeople, who spend their days talking to customers about their needs, should be a prime source of information for product managers. In theory, the CRM system should contain at least some information about these needs. But why not be more ambitious? CRM data should help answer many other important questions for the product group: Which features helped make sales? What missing functionality is the cause of losses to competitors? What are the most common configurations? And I'm sure you can think of 10 or 12 other questions you'd like to pose.

There's no replacement for the kind of insight you get from direct conversations with customers. At the same time, there's no substitute for the level of confidence you can only get from more aggregate data. Even if you're not using Agile methods, you'd rather hear about new market trends right away, as they make themselves felt through the customer conversations stored in the CRM system, instead of waiting for the yearly customer advisory board meeting. (Or, for that matter, hearing about them much later through the other side of CRM, the support desk.)

It'll take some further research to find out how effectively people use these sorts of bridges between CRM and the product team. In theory, at least, salespeople have more incentive to record customer requests, if they feel as though someone is listening. Product managers get more aggregate data on which to base product decisions. And CRM becomes more central to how the company operates.

Shameless, Agile-filled self-promotion update

Two new Forrester reports by Yours Truly are now available:

• "Agile Product Management Makes Agile Technology Companies." There's a bit more to this study than the title implies. The document also discusses how your approach to Agile sets the to-do list for product managers.
• "Inquiry Insights: Agile Development." Interestingly, a lot of questions we get from clients focus more on the type of product and organization implementing Agile methods than the methods themselves.

Also, I have a short piece in Computing magazine about the best practices foremost on the minds of development teams. As always, your observations, applause, or expressions of mild outrage are welcome.

A SPITR in the eye

A while ago, I published a piece titled "Beyond Innovation: Adding Adoption To Your Business Objectives," which started with the observation that we're damn lucky in the technology business. Innovation, particularly on the software side, moves faster than in other industries because of fewer physical constraints. Oh, sure, a few hard realities apply, such as the speed of light, or the amount of heat your overclocked gaming PC generates. Those constraints are trivial, compared to the limits of physics and chemistry that innovaters in other industries face.

As good as rapid, unconstrained innovation can be, it's not without its problems. Technology companies want to give the human source of these innovations, whom we'll call The Smartest Person In The Room, enough latitude to put their talent and creativity to work. And heck, since they're smart, why not put them in charge of things needed to bring their innovative ideas to market, such as the development team? Unfortunately, there is such a thing as giving highly intelligent people too much latitude.

Around the Valley, the Smartest Person In The Room (SPITR) often holds a title like CTO, Chief Architect, or Development Manager. The stereotypical SPITR is thirty-something, graduated from a school like Cal Tech or RPI, wears slacks with tennis shoes, and talks at a pace that's sometimes hard to follow. The SPITR has profound technical skills, and a creative mind that operates much like a pinball machine, lights flash and sirens sound when the SPITR hits a new idea, and it won't be long until the SPITR bounces to to the next possible innovation.

Obviously, every company needs to hire people like the SPITR and find the right role for that person. You'd be stupid to waste someone that valuable. However, even the smartest people aren't smart about everything. For example, Napoleon may have conquered continental Europe, but he didn't have the political acumen to know how to hold on to what he won. Symptomatically, he had a bad habit of putting his less-than-capable relatives and cronies on the thrones of defeated countries, with predictable results.

The same rule applies: SPITRs are good at many aspects of product or service development, but not everything. For example, just because a SPITR is smart doesn't mean that person will make a good development manager. Every team lucky enough to have a SPITR needs to be realistic about filling out the other roles with people that have complementary skills. The SPITR also needs a counterbalance, since not every idea from any human being is going to be a good one.

Unfortunately, some technology companies give too much unchecked power to the SPITR. You know you're working in one of those companies if...

• The feature list for the next release is completely under control of the SPITR.
• The SPITR has a secret feature list.
• The development team looks to the SPITR for guidance more than 80% of the time, and to the customers and partners 20% or less. (We might want to set the bar lower, but you get the idea.)
• The SPITR takes risks, such as last-minute check-ins of unreviewed code, granted to no one else on the team.
• The SPITR has a product vision that no one else on the team fully understands.
• The SPITR's projects are surrounded with so much mystery that no one in upper management feels competent to judge how well these projects are going.
• The SPITR does not have time to mentor other team members.
• If in a managerial position, the SPITR is not devoting sufficient time to management tasks.

Dealing with an unchecked SPITR is not easy. Companies fear that, by doing so, they'll squelch the SPITR's innovations, or drive the SPITR to look for a job in another company. But those are just excuses for bad management. If Eisenhower could make good use of Patton, a CEO or EVP in a software company can figure out how to harness the talent of a good SPITR who's responsible for too many things.