Beware of Specials

How many times have you seen the situation where a sales rep brings to the CEO a proposal from a prospect that says, “if you will just add these seven features to your product then we’ll buy your software and even pay you an extra $X.” Or, lest anyone thinks that this situation is unique to enterprise software companies, for consumer service companies, your ad sales person comes over saying that “a big prospective partner will sign a seven-figure advertising and sponsorship deal with you if you’ll just agree to these site integration and placement requirements.”

Either way, these are what are known as “specials.” A special is when a company gets a big check from a prospective customer or partner with the condition that you build into your product exactly what they say.

It is entirely understandable why large customers and partners may seek this arrangement. And if you’re a small company that’s strapped for cash, it’s also very understandable that your CEO might be more than a little inclined to agree. After all, you’re going to be adding features anyway, so “why not let this customer underwrite these features?”

So what’s wrong with doing a special? Well, one of the surest ways to derail a product company is to confuse customer requirements with product requirements. I’ve written in depth elsewhere about the reasons why you can’t count on customers to describe the product that they need, but to summarize: first, it’s extremely difficult for the customer to know what he needs until he sees it; second, customers don’t have the time to be constantly exploring what’s now possible; and third, customers don’t often interact with each other in order to identify common themes.

But even if the customer doesn’t have these issues, more generally it’s not clear that these are the best things to focus on right now. By pursuing these special features now, what work are you delaying? What is the business cost of that delay?

But even assuming these are not issues, it is still dangerous. How come? Because your job is to meet the needs of a broad range of customers. That’s what distinguishes product companies from customer software shops. If a year from now the market changes, you need to be able to quickly change and adapt. If you are contractually obligated to keep supporting a specific way of doing things, then your business will not be as nimble as it needs to be. Remember that every version of your product will have to be built, maintained, tested, released, documented and supported. It doesn’t take too many specials to weigh down a company to the point where it takes them months to do even the smallest release.

Don’t get me wrong. There’s nothing wrong with custom software shops. They provide an essential service for countless companies that need specialized solutions, and can often deliver that specialized solution at a fraction of the time and cost of in-house developed solutions. But custom software is a very different business than commercial product software.

So how do you avoid the pitfalls of specials? Undeniably it takes corporate discipline and experience to be able to recognize specials and be willing to walk away. This leadership comes from the CEO, but there is much you can do as product manager to help.

First, it is natural for any customer to want to describe their problem in terms of the solution they can envision rather than the underlying problem itself. But as product manager it’s your job to work with the customer to tease out the core issues and needs. You can help them to recognize that there may be other approaches to this problem that provide a solution they would like even better. Most customers do not really want to be running on a custom version of software. They want to be running on your mainstream product, the one that gets the most attention, support and improvement.

Second, consider looking at how you could keep your product general purpose but allow the product to be tailored/customized/extended by the customer or by a solutions provider. And then have ready the names of a couple system integrator/solution provider companies that can tailor your product to meet this specific need. You may need to partner with the solution provider so that your customer doesn’t have to manage two relationships and have to worry about finger pointing if there are issues.

So far the examples have mainly been in the enterprise software space. But the problem of specials is becoming increasingly severe in the consumer internet services space, where for many companies, advertising that is not aligned with the site’s objectives has significantly distracted or even damaged the user experience.

For many advertisers, their main objective is very simply to move traffic from your site to their site. If this isn’t your goal, you’ve got a strategic conflict. For some sites, like directories or search engines, this is fine, but for others, you end up trading short-term traffic for your site’s future. This really isn’t in anyone’s best interest. Consider the revenue model of LinkedIn versus Friendster. LinkedIn is providing value-added services to their members and partners, and keeping them even more engaged in the process. In contrast, Friendster was doing everything they could to get members to go learn about Pamela Anderson’s TV show. I completely understand why Fox might want to reach Friendster’s members, but have a harder time realizing why Friendster would want to make this such a prominent part of their user experience, other than for short-term advertising revenue.

I have found advertisers to be very interested in finding better, more synergistic ways to work together. When you have a strategy and a clear role for them, they are more than willing to work with you. They know that traditional internet advertising is of limited value, and they want something better as much as you do.

Whether it’s enterprise software or consumer internet services, it’s the product manager’s job to ensure that you’re building the right product, and that the product will be applicable to and usable by a wide range of customers.