By Peter Longini, Managing Editor

Back in the mid-‘90s, Microsoft began marketing a collection of productivity programs under the now-familiar label: MS Office.  Although each program brought real value into the business environment, their bundling was more an anthology of individual applications than an integrated software package.  They looked different, they worked differently, they required individual installation, and in moving from one application to another, the user frequently had to re-enter the same data and redo the same operation.  It was a nuisance, and customers hated it.

That's a big no-no, according to Brandon Ekberg, business manager of the software & meters business unit of Eaton Corporation's electrical group and, until 2005, director of engineering and business unit manager at Rockwell Corporation's software division.  "Never make the customer enter the same thing twice," he said, reciting the watchword which has guided his career for the past decade.  That work has focused on crafting common software platforms which free the industrial users of Eaton's company's family of electrical control systems from having to do the same work over and over for different applications. 

"Ninety percent of the things I've been involved with have been based on that little mantra," Ekberg noted.  "When I was at Rockwell, we started building our platform about the time MS Office first came out.  And the Microsoft people admitted the same thing; that their customers were buying the set and wondering why they couldn't copy a photo or graphic from PowerPoint and drop it into a Word document.  It wasn't until some later versions Office came out that you actually got to the point where you could cut, copy, and paste.  And before you knew it, you had OLE with embedded objects.  Now Office works pretty cleanly together."

Integration and limitations

The essence of the platform strategy that Ekberg advocates involves breaking apart the separate silos of product technology which have proliferated at many larger firms and then rebuilding the various product lines around a common core that integrates their data sets, their interface, their access, and their other basic operations.  That pattern of fragmentation, and the heightened need to bring related applications under a single umbrella, has been exacerbated by the recent frenzy of mergers and acquisitions in the technology arena.  As a result, Ekberg notes, particularly in the software world, if you want to have an acquisition strategy, you'd better have a platform strategy in place as well.  But you'll need to keep your priorities straight.

For example, it is possible, once a common platform is built, tested, and proven successful, that the time to market for incremental new products based on that platform will be significantly reduced.  However, according to Ekberg, that advantage tends to exist more in the realm of theory than in practice.  "Problem is, I've never had the luxury of stepping back and building a platform from scratch without deliverables attached.  Instead, you wind up trying to build the platform and release the end user products at the same time.  If there's anything I've learned, is that if it's at all possible, go and build the platform, perfect the platform, document the platform, test the hell out of the platform, and then bring it back into your product groups for adoption.  Because what typically happens is that you have a December deadline and you wind up finishing that platform development at the end of October or November and still try to make your December release.  And that's really difficult.  That's hard on everybody."

There are even times when a platform approach can slow you down.  "I can go build a little software widget that does five or six specific things I need, and I can do that faster on my own if I don't have to take into account things that the platform is going to force me to do.  Or even worse, to wait for the platform to add that," he said.  "I can probably work faster as a smaller team." 

Cost savings can prove to be another illusion.  Although it would seem logical that having a common platform already built and tested would reduce the cost associated with new or updated products, that rarely happens either, according to Ekberg.  "I can't say I've ever seen a reduction in the engineering dollars spent," he said.  "It could be the Peter Principle - that the feature set expands to fill the available resources.  I don't know," he acknowledged.  "In any case, the platform strategy was not always driven by internal logic of cost savings or speed to market." 

Even so, the value of having a successful platform can have huge power in the marketplace.  "Look at the iPod," he suggested.  "There is a case where they had a platform strategy.  It was this super-small, easy-to-navigate music machine.  They standardized things like the adapter plug, and they developed the whole aftermarket of add-ons, accessories, and because they licensed that adapter plug, they created their own series of derivatives, different sizes, and now they're putting in phones and serving different markets." 

Not for everyone

Of course, there's also the case of General Motors whose J-Body auto platform, introduced in the 1980s as essentially identical Chevrolet, Buick, Pontiac, Oldsmobile and Cadillac models, backfired badly.  The Cadillac Cimarron's failure, in particular, was one of a series of events that drove the division close to bankruptcy and cost the company dearly in the eyes of its once-loyal customers.

Nevertheless, according to Ekberg, most customers will be pleased.  "It's the 80:20 rule.  Eighty percent of the customers are going to be very pleased."  But twenty percent won't be.  "The people that aren't going to be pleased are the customers that aren't buying the whole solution.  If you're serving markets where what you are doing is selling components and there is no benefit from buying a larger solution from a single vendor, I don't see a lot of value in a platform strategy; you'll just slow the individual component development cycles down. 

"If you're in a boutique market or playing into a commoditized product market where the connectivity level is so basic and the standards are so well defined, then interoperability is not as important.  You don't really need to be a system player to be a computer mouse vendor.  But here at Eaton, more and more customers want to buy breakers and meters and switch gear as part of an integrated solution.  They want to buy a power distribution system and they want to know that the whole thing plays together.  So in this case, for the customer, there's definite value because we're delivering a solution." 

Organizational changes

Companies considering a platform strategy will first need to put a number of organizational changes in place, according to Ekberg.  "When you decide to take on a platform strategy, you have to break the silos apart," he said.  "You have to have one product management team who has responsibility and feels true ownership for delivering all the products on one platform as opposed to each of the products individually.  And they have to understand the value of it.  If someone doesn't buy into it, you'll need to get rid of them. 

"The second thing is you've got to create a program management office with a level of authority to understand the deliverables of all the projects and how they come together.  And the third is that you have a common engineering team.  In fact, in some places I've seen architecture as a separate, fourth organization.  You could even have system testing as a fifth organization.  It all depends on how big you are."

And for any company contemplating a platform strategy, it is essential that top management give their full support because it's going to create disruptions.  "There is significant resistance at the individual team level," Ekberg admitted.  "Some of it is that people feel their work is being taken away from them and given to someone else.  But I would say that it's more about the complaint that ‘I've already promised my 30 customers I would add these six features and you're now telling me I can't because the resources assigned to my product are going to get applied to integrating the platform elements with the other products.'  It's typically the re-directing of resources that ticks the product managers off." 

In the end, though, it all comes down to following the mantra.  "Don't make a customer enter anything twice or do anything twice," he repeats.  "I've seen that kind of basic logic drive so much." 

About the Author:

Peter Longini is the Managing Editor for Inside Product Strategy™. He can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .

To read our latest articles in Inside Product Strategy™ click here.