Browsing Tag


It’s time to get your Ph.D. in Sales Comp

A few years ago, I was working for a large company here in Austin.  This company had recently acquired a series of software startups and was attempting to integrate them into their larger hardware portfolio.  The product team I managed was responsible for the integration, product management, and transition.  What I learned during this time about Sales behavior was a shock to my system – and may help you as well.

Imagine a Fortune 100 company: large, established, incumbent.  Also stale, bogged down in red tape, and struggling to innovate.  A typical move for a large company is to inject innovation through the acquisition of a smaller company.  Often, this makes great sense on paper – the bigger company gets access to technology and talent they don’t have, and the smaller company now has an opportunity to both cash in their hard work and take their products to a much larger audience via an established sales channel.  If you’ve worked in the industry for any length of time, you’ve been through this cycle from one side or the other.  Unfortunately, what looks good on paper can quickly go astray if you don’t understand Sales and the tools you are giving them.

In this case, my team had responsibility for four to five smaller acquisition company products and portfolios.  Luckily, the larger company had done a good job acquiring companies in the same area who had complimentary products, both to each other and to the larger company’s hardware devices.  Essentially, our new software portfolio provided ongoing systems management for the hardware that made up the mainstay of the larger company’s business.  If we could simply start to attach our software to the millions of dollars of hardware deals that were already happening, there was a great chance of success!

To make this picture even more attractive, the larger company’s hardware business was undertaking a long, slow decline both in revenue and profitability.  They were averaging single digit gross margins on hardware, whereas our software was achieving typical software margins in the 40-60% range and higher.  By all rights, it was going to be an easy win…until we starting training the larger company’s Sales teams.

The long, slow decline of established business

Our decline wasn’t this pronounced…but it was close!

The first time we trained one of our hundreds of new Sales teams, we knew we had an issue.  We did a “lunch-and-learn” where we fed the team pizza and spaghetti, while one of our product managers did a demo of the product and talked about how it was complimentary to the products they were already selling into their accounts.  The Sales team was polite and listened while they ate for about thirty minutes.  Then, everything went wrong.

Do you ever want to scream when working with Sales? It doesn’t have to be that way if you know how they’re motivated.

At the end of the presentation, the Director of the Sales team stood up.  He looked straight at my product manager and said:

“John1, I want to thank you for that great presentation.  I think we all now have a clear understanding of your product, its pricing and competitive positioning, and how it can help the company.  I understand that the CEO has identified this as a strategic product.  And you know what?  We are never going to sell it.”

Needless to say, that was not the reaction for which we were hoping.

John tried to recover by asking the Director why he felt that way, and the Sales Director responded by saying:

“To your credit, this does seem like a really good product.  But, it doesn’t match up with how my team is rewarded.  Right now, software sales represent 10% of our quota, and hardware is 90%.  If one of my guys blows up his software number and misses his hardware number, he is fired.  If he blows up his hardware number and sells zero software, nobody cares.”

Very quickly you can start to see the problem – even though the company had spent millions of dollars on this acquisition, they had not put the tools and behavior modification in place with their existing teams to make it a success.

At this point, we needed to get educated (quickly) on how Sales at this company was motivated.  Our next stop was Finance.  We scheduled a meeting with someone that Finance identified as the “Genie of Sales Compensation.”  When we sat down with the Genie we asked her to show us how Sales was motivated, quota’d, and bonused.  That was when she opened her manila folder, and took out a taped-together 3×3 matrix of legal sized paper, upon which was printed in 6-point font an Excel spreadsheet containing approximately three dozen rows representing the different sales teams, and about fifty columns representing various ways the Sales teams were measured.  Some Sales teams had thirty or more variables to determine their quota attainment.2  In short, you needed a Ph.D. in Sales compensation to understand this system.

Yes, it was almost this big.

Many people refer to Sales as “coin operated,” by which they mean that Sales operates in whatever way will help them get the most coins.  This is exactly how you want Sales to act, but it reinforces that if you aren’t very clearly part of their compensation, they won’t spend time worrying about you, regardless of how strategic or important to the business you think your product should be.

In the end, we found that adjusting the Sales teams compensation models to account for our products was so fraught with politics and peril that it was doomed to failure.   Prioritizing our products in terms of comp meant deprioritizing someone else’s products, and every Sales comp line had an advocate in the form of a powerful executive for some other product.  That is when we realized that we needed to sidestep the issue by creating our own overlay Sales team that was only measured on our products.  This worked, but only after a lot of pain and suffering.

This month, Pragmatic Marketing’s bloggers are going to be writing a lot about various Sales tools and ways we can enable Sales teams.  Remember however that the number one most powerful Sales tool in the Product Team’s bucket is the compensation model.  If you get this wrong, or your product is not represented in it, it will not matter how slick your competitive training is, or how good your positioning is, the strength of your competitive analysis, or how well you priced your product.  As the CEO of your product, you must understand how your team is motivated – and take corrective action where required.

What other challenges have you run into with Sales, and how did you overcome them?  Weigh in below in the comments section.

1 Name changed to protect the innocent
2 This is when I realized that I prefer smaller companies to larger ones

Becoming a Platform

Turning your product into a platform is en vogue.  From, to the Apple iTunes App Store, to Valve’s Steam, many companies are attempting to open the architecture of their product to the World in the hopes of building the critical mass that becoming a platform provides.  Making a platform play is hard, and most companies fail – how many of us have added “API” or “SDK” to our roadmaps and been unsatisfied with the results?  Let’s explore what makes a product succeed or fail as a platform, and the decision criteria you can review with your business as you decide to commit resources to a platform project.

I have led platform building projects at several companies, including my current role.  At each, we had an in-market product with an established customer base, and some number of interested 3rd party developers who wanted to extend our product with their own ideas.  Some of those projects failed, and some are (or will be) very successful.

Why Be a Platform

The allure of becoming a platform is easy to understand: your product gets the benefit of other companies investing time and treasure in extending its functionality for you.  Platforms are even more interesting when you factor in their positive feedback loop – as more developers add their products to your platform, the value of your platform increases to customers and attracts new customers, which increases the value of the platform to developers, in turn attracting even more developers.  Eventually, your platform has such a rich set of unique applications and services available through it, that customers have a hard time imaging getting the same experience through any other source.  They’re effectively locked in, not through force, but by choice.

Planning a Winning Platform

As you build a platform, you quickly understand that you have a new set of customers with new problems you need to solve: your development partners.  The brass ring that every company reaches for with a platform is OPM and OPT: Other People’s Money and Other People’s Time.  Some have made it work.  Others have failed miserably.  Many just fade into obscurity.

Platforms grow up in two ways: out of existing products, and as developer-to-developer programs.  Platform programs are dangerous because they are usually under-stated in time and resource commits – they have the potential to touch every part of your existing spaghetti code.  The urge in the development team to re-architect during a platform build is irresistible.  Product Managers: talk to potential partners, understand their needs and desires to work with you, find out which objects they want to interface with, and facilitate discussions between their developers and your development team.

Just as important when planning your platform is to understand your business strategy.  Me-too platforms almost always fail.  Look at your platform from your potential development partner’s eyes:

The value of your platform to a partner and the likelihood of their developing to it is directly proportional to the amount of business the partner is able to capture through the platform.

Questions to Answer:

  • Are you building a platform as a competitive blunt, or to extend your core product?
  • Does your company have the development resources to build a strong and deep API and SDK?
  • Does your company have the development resources to support partners with integration questions
  • Does your company have the marketing resources to publicize your platform?
  • Can your product management team handle a massive increase in communications to partners whenever you make platform revisions?

Strategic Decisions

Business Model

Companies build platforms for two reasons: to increase sales of existing products (e.g. iPhone), or to make money on applications sold through the platform (e.g. Steam) – sometimes both.  One of the first decisions you need to make is will your platform be for free or for fee?

Free usually doesn’t mean that all partner apps are free, otherwise they’d have no incentive to develop, rather that the developer has the option to offer free functionality through the platform.  You can see this model in action today in the App Store, with free apps vs. their “pro” upgrades.  The advantage to free is that end users get functionality at no cost, which entices them onto the platform.  If you sell the platform, like, you can use free partner services to add value to your core app and sell more at no direct cost to you or your customers.

Another common model is revenue sharing.  In this model, the partner sets their own pricing and the platform owner takes a share of the top-line revenue.  For example, Apple takes 30% of all apps sold through iTunes.  You have to strike a delicate balance between the amount of sharing you demand from partners and the incentive for partners to develop through the platform.

Packaged resale is a model that we are using at Dell.  In the packaged resale model, we purchase apps in bulk from our partners to provide them with stability.  We setup volume tiers, much like a traditional distribution model with price breaks as we move up.  Then we turn around and repackage partner apps to our customers, pricing them as we see fit to be competitive.  The advantage of this model is that you get more control and flexibility with the pricing of apps through your platform.  The downside is that partners may fear losing control of their pricing models.


How open will your platform be?  Will you adopt a model of being an “open field,” meaning that there is a relatively low bar a development partner must pass in order to offer their application?  Or will you model your platform after the “walled garden” that is Apple’s iTunes App Store – and require that partners meet certain guidelines for functionality?  Or will you be more restrictive still and have an invitation only “planned community” approach?

The open field model means that you want a high volume of partners and you want to offer them low-to-no touch.  Facebook is considering opening their platform to partners and will probably adopt this approach.  Salesforce has used this model to great effect, attracting thousands of independent developers to their platform.

The walled garden approach raises the bar for partners enter your platform.  It may mean setting guidelines about what applications can or cannot do, like Apple has done.  Depending on how strict the guidelines you set, you can throttle partner demand – just be consistent in your application of the rules.

A planned community is another approach to platform building.  In this model, you go for quality over scale.  It may mean setting very strict requirements that partners must meet in order to play on your platform, such as security or functionality requirements.  The tradeoff is that you as the platform owner have more control over what is offered through the platform, and can stand behind any partner offering.  This model may be appropriate for co-delivered services or SaaS.

Customer Ownership and Branding

By virtue of owning the platform, you are bringing customers to the table.  Depending on the model you choose above, you may allow developers to use their own brand, co-brand, or re-brand partner apps as your own.

If you are co-delivering a service through your platform with partners, co-brand or re-brand works well.  This model is popular with telecommunications companies who use their broadband platforms to offer re-branded partner services such as online backup or anti-virus.

Factors for Success

As you consider launching a platform, there are key metrics you should consider.  Number of partners, number of applications or services, revenue derived from the platform are all good starts.  Even before you set metrics, there are some key success factors that you can whiteboard that will let you know at a high level if your platform will fly.

The most important consideration that will make your platform succeed or fail is how much business a potential partner can capture from the platform.  All of your other strategic decisions must line up to the reality of this number.

Next is the strength of your target partners.  Depending on the platform model you choose, you may be targeting anyone from individual developers to large, established ISVs.  The key is that you match your target partners with the level of investment required by a partner to develop to your platform.  You can’t ask independent developers to operate a service out of SAS70 Type II data centers, for example.

Consider the problem that end customers solve by buying partner applications or services through your platform.  If there is marginal added value to buying through you, your platform will not be sustainable and you will churn customers, and eventually collapse.  Remember when every new PC you purchased had an AOL icon preinstalled on the desktop?  There was no value to customers in purchasing AOL this way, in fact it annoyed most people to see it there, and created a negative perception of the “platform (the PC).”  You don’t see that as much anymore.  You have to add something other than a channel to the customer – Apple adds a great user experience, Saleforce adds great analytics to hard-to-manage data, Steam offers digital gaming management so you never have to find a CD again.

Finally, if you have created value for the customer, value for the partner, and settled on a model that makes sense, you are ready for the last analysis: how will you and your partners make money?  Is there enough margin to revenue share – or are you willing to forego revenue sharing and offer your platform for free to partners in order to get more apps or services in order to move more of your core product?  This analysis is hardest and will require talking to lots of potential partners and field testing your pitch.

Good luck, and let me know how it goes.  Happy platforming.

Changing Jobs in Product Management: Leaving, Starting, and Building Bridges (Part III of III)

This post is part of a three-part series about changing jobs in Product Management. Part one was about doing a self-evaluation and farming your network. Part two was about interviewing and evaluating offers. In this final part, we will discuss how to leave the right way, start on the right foot, and build bridges for the future.

A rock bridgeAfter you have gone through the entire process of self-evaluation, farming, interviewing, offer evaluation, and acceptance, you will probably be mentally exhausted. There are still important steps to take before you can close the chapter on your current company, which must be done with grace.

No matter what kind of relationship you have with your current company, boss, or peers, leaving the “right way” is critical. It is a small World, and people have long memories – you want to be the person that they remember for all of your good traits, not for storming out the door or telling your boss to “take this job and…” …No matter how good it might feel. Remember, these people are your future references, and there is a fair chance you’ll run into them again in another role, or on the street, and you want that to be a pleasant meeting.

Continue Reading

You Don’t Really Own Your Roadmap

Here's your sign!Sales people hate looking stupid. Unfortunately, we often put them in positions where they look very stupid by changing plans and roadmaps, which is our own fault. How do you keep the trust of your team when your business, roadmap, and customers are shifting in the sands around you?

There are lots of reasons that plans change, some good and some bad: the Market shifts, the competition makes a play, or the company dosen’t hit its goals and has to layoff developers, which pinch your resources. All of these create a refactor in your roadmap.

There are several tactics you can use to lessen the impact of changes to The Plan. I’ve written in the past about the importance of separating your Roadmap from your Release Plan. This simple change, and the cultural impact at the Executive level down to the developer level of thinking that “a product/feature on the Release Plan is locked in and cannot be changed” is huge. Remember that Release Plan’s mean that the product or feature’s release is imminent and committed – your Release Plan should never cover >6 months.

Also, realize that you don’t really own your roadmap. The best you can do with the roadmap is plot a general direction for a product or service, but when it comes down to it, the Market and the Business own the roadmap. The Roadmap is not yours; you are the steward of the Roadmap. I see products and companies fail all the time because they set their roadmap and expected the Market to bend to them; it doesn’t work that way.

One-off deals can also derail the roadmap. In a smaller company where there is immediate revenue pressure, the allure of a special deal that “just needs this one feature” is huge. Are you ready to turn down a million dollars in revenue? Most Executive teams are not. Be able to illustrate how any proposed feature or product changes to your roadmap delay or eliminate your entrance into new markets or buying personas. That changes the special deal conversation from emotion-based to data-based.

New Development VP’s also have a tendency to take roadmaps off course. The reason: they love changing technology architectures. I carry a cross on this one since I’ve been burned before, from a CTO who changed the team from Java to .NET…which meant retraining some developers, dumping other developers, and hiring new developers. We lost 12-18 months just spinning – it was stupid!

When you see the VP of Development pushing for a change in development platform or underlying technology, drill closely into the details of why. Most Dev VP’s aren’t dumb enough to say “it’s because it’s a fad” or “because I want to get quoted in CTO magazine!,” and they will come up with legitimate sounding reasons why the old platform sucks and we really, really need this new one. You need to provide the voice of reason – with today’s technology, you can build an adapter to and from almost any technology without having to rip up your entire platform. If it’s that strategic to change your platform, the company should be able to justify the expense of building a parallel platform next to the existing one without disrupting current development.

One type of project that can be completely immune to external forces taking them off roadmap is the open source project. Since developers in this model often develop for themselves and not for the Market, oftentimes they don’t care what their users are asking for. Other open source projects are more flexible to the wants of their Market and do adjust their plans.

What other reasons pop up for taking you off roadmap, and how do you combat them?