Skip to the page

Plainly Put

One sentence about building things, taken apart

Product

More features, less weight

Salesforce was built on the promise that business software could be as simple as a website. Twelve years on, the promise and the product have both grown.

Customers want new functionality, but they don’t want the traditional complexity that has marred products in the past.

Marc Benioff

When Marc Benioff founded Salesforce in 1999, business software meant large licenses, servers in the customer’s own building, consultants to install it and projects that ran for months before anyone used it. Salesforce offered its customer management software through a web browser, paid for by subscription. Its logo was the word “software” with a line through it, and in its early years the company staged a mock protest outside a rival’s conference to make the point.

The line describes what customers asked for and what the model delivered. They wanted more capability: forecasting, reports, integration with email. They did not want what used to come with it: upgrade projects, servers to maintain, IT departments deciding when new features arrived. By running the software itself and updating it for all customers at once, several times a year, Salesforce moved much of that complexity from the customer to the vendor. That is the real content of the promise. Complexity was not removed. It was relocated to the place best equipped to handle it.

The market noticed. Siebel Systems, the leading vendor of the older kind of customer software and the target of that early mock protest, was bought by Oracle in 2006, by which time Salesforce was growing much faster. Customers had shown which kind of complexity they were willing to live with. Last year Salesforce added Chatter, a social feed for colleagues inside its product, and existing customers received it without installing anything, which is the promise working as designed.

The same model does not make complexity disappear from the product. Every new function adds screens, settings and choices, and a product that serves large enterprises accumulates them quickly. Salesforce itself now supports a large industry of consultants who configure and customize it for big companies, much as older enterprise software did. Customers who asked for flexibility received it, along with the complexity that flexibility brings.

This is the tension the line points at without resolving. Customers ask for features one at a time, each reasonable on its own. Together, they produce the complexity customers say they do not want. No customer requests a cluttered product. They request fifty additions that make one.

The companies that manage it best treat complexity as a cost to be paid for each feature, not an accident. They say no to requests that serve few customers, hide advanced settings from those who do not need them and remove what nobody uses. That discipline is harder to sell than a new feature, and it is what the line actually requires.