Michael Wurzer This week is known as “Summit Week” around FBS, because we’re hosting a bunch of our MLS clients for several days for our FBS Summit. We’re usually running around like crazy the few days before but this year has come together pretty smoothly, so far, and so I thought I’d take a few minutes to write a post that’s been rattling around in my head since I finished reading Wikinomics a week or so ago.
The main theme of Wikinomics centers on “mass collaboration,” or the idea expressed in Bill Joy’s (co-founder of Sun Microsystems) often-quoted statement that “innovation happens elsewhere,” because no matter how smart you and others at your company are there are always more smart people elsewhere. There are two off-shoots of this premise: (1) companies today need to make their products customizable by the consumer (e.g., application programming interfaces (APIs), use of standards, open source); and (2) companies should focus on their core competence and out-source or out-collaborate with others on non-core products.
Considering these ideas right before our client Summit is particularly valuable for me because the Summit is and has been a platform for our strategic thinking at FBS for the last decade or so. We’re trying to engage our customers on both the big picture industry trends we see and also learn from them where they see the industry going and how they hope we respond to help them navigate through the changes to better serve their members. In this regard, we are engaging in mass collaboration. In fact, I think one of our strengths as a company is listening to our customers and isolating what’s most important.
This latter point often requires significant choices. We cannot make every change every customer wants. We have to choose the projects we believe will have the most benefit for the most users. We call this process Net Results, always trying to remember that we’re helping our customers sell more real estate. The point of Wikinomics, however, is that by developing products in an open and collaborative way, the choices can be expanded beyond the limited resources of any one organization. Put another way, the role of the organization is to organize, but what needs organization today is not just inside the company but also outside it.
The theory that great ideas can come from outside just as likely as inside is one of the reasons FBS has engaged in the RETS/RESO process, hopefully to create standards around which innovation can occur on an industry scale. We also hope to augment those efforts with our own APIs to enable more mass customization of our specific systems. The idea that you can’t do it all and that others want control over their own systems while leveraging yours makes perfect sense to me. There simply are too many examples today of the open web driving hyper innovation to ignore.
At the same time, balance is required. FBS’s core competency (how we add value) is providing excellent response to our customers’ needs. One of the reasons we’re so good at this is because we control our code and our support team works closely with our development team to ensure prompt and effective responses. This is what I mean by “defining customer support” in the title of this post. When many hear the words “customer support” they think of the folks answering the phone. Certainly, that human interface is critical and our team is the best. At the same time, when it comes to new feature requests or bug fixes, access to the developers is equally critical and often the difference between a satisfied and unsatisfied customer response. The more a firm outsources and ends up with code outside their control, the more difficult supporting customers becomes. And when supporting your customers is your core competence, having control of your code (building in-house) becomes a strategic imperative.
The most prominent example of this balancing act is Apple. Traditionally, Apple has created closed systems they tightly control to ensure the end-user experience is up to their expectations. They control the entire stack, from the hardware to the software and everything in between. In many ways, Apple has been the poster-child of what the Wikinomics authors decry when they state in their conclusion that “the monolithic, self-contained, inwardly focused corporation is dying.” And yet Apple has been terrifically successful with just this approach with the iPod, iPhone and Macs over the last many years, earning unwavering loyalty from their customers.
But there’s more to the story. Just yesterday, Apple announced the opening of their API for the iPhone to outside developers. This is a significant change in philosophy for Apple and is further evidence of the unstoppable trend toward mass collaboration. Turning inward again, however, Apple is putting some pretty tight reins on the developer program, trying to balance the quality of the applications against open development, by providing robust tools for testing and debugging the code.
This sort of balance is exactly where FBS needs to head in its development. Our customers expect both rapid innovation and excellent support. We need to build core systems on which our customers and their developers can innovate. I think this same balance should be considered by MLS organizations themselves. There is a very real trend in MLS system development and deployment today where separation of the back-end (database) from the front-end (user interface) is being advocated on the theory that the core competence for the MLS is the data and the rest should be left to outside innovation. This often is called the front-end of choice.
In theory, front-end of choice is a great idea — the MLS should be focused on data quality and data access and open development of the user-interface to broad competition to foster innovation. At the same time, like FBS, MLSs add value by supporting their customers and having many front-ends nearly forces them to outsource that support to the many different companies providing the front-ends. When MLS members have problems, they expect answers, not being routed from one vendor to the next with all pointing fingers at each other. Organizing the many different efforts and the quality of the applications becomes critical, just as it is for Apple.
The conclusion here is that balance is required. The organizations that succeed in the coming years will be those that develop open applications while maintaining high levels of support for their customers. This is a big challenge and one we aim to meet.