Innovation 2.0: Seizing opportunities in an open landscape

Web 2.0, open source, open standards.  These are concepts that many executives don't understand -- and they need to.  They are related in what I will call Innovation 2.0 opportunities.  These opportunities are different from others in one important way: they challenge companies to cede control of part of the value chain in order to play a role in a larger value chain.  Now this concept in general is a well-accepted business strategy -- moving from a big fish in a smaller pond to a smaller fish in a bigger -- or, more importantly, growing -- pond.  But those who are used to being big fish in a big pond lose sight of how to adapt when the big pond starts shrinking.  Innovation 2.0 speaks to this challenge and provides insight into how to seize new opportunities.

 

First, let's start a definition.  Innovation 2.0 is defined as innovating as part of an interconnected ecosystem of suppliers and buyers that service customers by working with other players in the ecosystem collaboratively.  Innovation 2.0 puts the customer in the driver's seat, letting that customer assemble the solution they need from the available components.  Those components are provided by members of the ecosystem -- and usually not just one provider.

 

Second, let's address the issue of why a successful company with a proprietary stronghold would be willing to give up control to other companies servicing its customers.  Well, if we go back to the "pond" metaphor, what executives are really looking for is not "big ponds" but "ponds that are growing big."  Once a pond is just big, it stagnates, and it gets competitive, and investors lose interest.  And, what's worse is being in a big pond that is perceived as shrinking.

 

Investors love fast-growing ponds that are becoming big.  That's where most successful folks in a capitalist society make hay.  And, while being a big fish in a small pond is not very interesting for those with thoughts of grandeur, being any fish in a growing pond is probably a good thing.

 

Here's the problem for big-pond big-fish, though.  They get comfortable being in that big pond, and they forget the scrappy ways that got them to be a big fish in a big pond.  When I say "forgot", that really means they are not applying the same kind of entrepreneurial principles that they must have applied to get them to a position of incumbent stature that they have enjoyed in the big pond.

 

And what are those scrappy ways?  They are the "do what it takes to reach as many customers as possible in a fast-growing market."  If a market is growing at 50%, you want to grow as fast as the market.  To do that, you must be relevant to as many of the participants in that market as possible.  You must make yourself part of their being in that market.

 

In some markets, the customer's choice is fairly discrete -- they choose from a short list of similar suppliers.  If you win a certain portion of those customer choices, you hold that share in the market,.  But other markets are not so simple.  Customers may even start making choices of other suppliers, and you need to find your way into those deals.  Maybe you are a complement to the winning supplier.  Maybe you are in a co-marketing deal, or cross-selling deal, or a partnership where you share revenue.  These are all ways to attach yourself to the growth of that market.

 

Well, what Innovation 2.0 recognizes is two things.  First, it recognizes an important customer behavior that is being driven by web 2.0, open source and open standards.  That behavior is customer-designed solutions.  They want to choose and "mash-up" the solution that makes sense to them based on available pieces.  They want to "create-rip-mix-burn" as Richard Baraniuk proclaimed at a recent TED conference.   They don't want to be forced to live within the constraints of a single supplier.  Second, it recongizes that the expectations of customers towards suppliers have changed.  Be "mixable" with other suppliers I am likely to choose.  Support standards to make that happen.  And be "flexible": don't make licensing of your proprietary stuff an impediment to me, or I'll just use someone else who is more mixable -- even if you have a better product.

 

Mixability and flexibility, then, are two product attributes of Innovation 2.0.  If your business design or product concept limits or prevents mixability or flexibility, you will lose Innovation 2.0 opportunities.

 

Let's look at the example of IBM, who has taken this journey successfully.

 

In the early 1990s, you could hear the last echoes of "You can't get fired for buying IBM."  Those echoes started to get drowned out by CIOs who didn't know how to play in a world moving toward the web and client-server computing that was an order of magnitude cheaper and faster-to-market than its dinosaur-like predecessor, the mainframe.  When Louis Gerstner arrived at IBM in 1993, pundits were reading it last rites.  But Gerstner did many things that turned around the company.  One thing he did was to turn upside-down IBM's strategy when it came to its product investments.  This move, in my opinion, saved IBM.

 

The first major move he made in this regard was to stop investing in IBM's multiple operating systems, realizing that it couldn't beat Microsoft (which should, by all accounts, have been an IBM technology), who made its living selling Windows licenses.  And worse, a new, free operating system called Linux had emerged which was fueling the growth of this new thing called the World Wide Web.  So, Gerstner pulled off one of the great chess moves of computing history.  He said, in effect, "Let's stop spending billions on multiple redundant operating systems that compete against each other -- and paying lawyers lots of money to defend our technology through patents.  Instead, let's take a fraction of our spending and use it to underwrite Linux as a legitimate competitor to Windows.  We'll save money, we'll be the kingmaker of Linux, CIOs and CEOs will trust Linux because we're behind it, we'll buy a generation's worth of goodwill and we'll vault ourselves to the front of the line in being the servicers of the enterprise Linux market.  Heck, we can even package and sell our own copies of Linux that come with our tools and add-ons." 

 

It worked like a charm.  Linux competed with Microsoft successfully to take a significant share the enterprise server market.  They made billions servicing Linux without having CIOs have to pay a per-server license fee (like they had to with Microsoft) for their fast-growing web server farms.  They stopped internal competition across product teams and got everyone working together in a world of "enlightened self-interest" -- making Linux better as a public good, which made their role in that growing marketplace more and more attractive.

 

IBM did this two other times, a second dig at Microsoft and one at Oracle, too -- both companies who relied heavily on revenues from proprietary software license sales to fuel them.  IBM purchased a company with a great next-generation developer desktop (called an Integrated Development Environment, or IDE).  Now, Microsoft owned the developer market for IDEs.  They were not expensive, but the majority of developers used Microsoft.  IBM, in a bold stroke, offered this new IDE as open source, worked with competitors to form a non-profit consortium around the technology, and started giving away -- for free -- the IDE to anyone who wants it.  Now, it is important to know that the IDE framework is a highly strategic platform when it comes to the developer.  Not only do end-developers need to use one, but developers who build dev tools need their tools to integrate with an IDE.  By open-sourcing Eclipse, as IBM's open source contribution was called, they gave every dev tool builder a free platform to which could house their innovation.  No longer did dev tool companies have to get special deals with IBM or Borland or Sun or Oracle or Microsoft.  They could bundle with Eclipse and look like a suped-up IDE out of the box.  It became the de facto development tool for open source projects, too.  This drew millions of developers towards Eclipse and relegated Microsoft, Sun, Borland and others to a secondary position in the IDE market.  Furthermore, IBM shut down internal competition across its many IDEs (it had an IDE for each different operating platform it supported), lowering its operating costs and gaining both goodwill and market share the way it did with Linux.  It commanded each team that had value-added tools to re-tool them to be Eclipse plug-ins -- sold separately, of course.

 

The last example I'll mention -- I'm sure IBM has others -- is with application servers, the heart of any web site.  IBM had its own Websphere application server that it licensed.  Soon, though, it realized that Websphere could not differentiate significantly from open source application servers like Apache Tomcat.  So, IBM again chose to embrace open source and wrap its tooling around these open technologies.

 

The results for Gerstner and IBM of this strategy are clear.  He jumped out of the stagnant shrinking pond that IBM dominated and jumped into the smaller but fast-growing pond of open source, which gave IBM a commanding position in the ecosystem of the internet marketplace.  They could compete everywhere Linux, Eclipse and Tomcat found themselves.  They could be the collars to grab for the CIO.  They could be the solution partner that made all of the open source stuff work together.  And, they could be the heroes of the industry -- as opposed to the stuffed-shirt goats they were perceived to be when Gerstner first took the reins.

 

IBM is my favorite example of Innovation 2.0.  They did so many things right.  And the stakes were high.  This was bet-the-business stuff.  A lot of companies can learn from what they did.  Innovation 2.0 is a way to understand what IBM and other companies -- such as Salesforce.com, Google, Facebook and LinkedIn -- are doing to establish dominant positions in the fast-growing ecosystem of a Web 2.0 internet.

I am at the New Marketing Summit 2008 conference at Gillette Stadium in Foxborough, MA, today. The first speaker sent condolences to Jive Software (a vendor of ours), for the 40 or so folks who were cut from the company. I went over to the Jive booth to inquire.

The person there told me that their company is in good shape, but their VC -- Sequoia Capital -- have warned all of their CEOs to slash costs now, in preparation for a gloomy next couple of years for tech companies.

Here are some articles about Sequoia's meetings with their CEOs:

• http://www.alleyinsider.com/2008/10/sequoia-s-startup-advice-save-cash-slash-costs-stay-alive
• http://venturebeat.com/2008/10/08/report-sequoia-has-emergency-meeting-tells-startups-to-try-to-survive-downturn/

Money can't buy you love -- but the right roadmap can

I am at an open source software conference this week, called JA-SIG. JA-SIG is a community of technologists in higher education that has developed uPortal, a standards-based portal for higher ed. It recently announced its version 3, which is a significant milestone in setting a course for the future of the community.

Getting to version 3 was pretty dicey. One key reason was that the original plans for version 3 included a rewrite from the ground up of the architecture. But the rewrite was not demanded by the community. Instead, it was the response of some in the community to funding that it had received to enable uPortal to integrate with Sakai, an open source Learning Management System that ostensibly would compete with Blackboard, the commercial leader in the space.

One seasoned community member told me the cautionary tale of how that happened, and what he learned from it.

At the time, uPortal 2 was really getting traction in terms of adoptions, use and community members investing in making it better. But the architecture really didn't easily allow it to integrate well with Sakai to be its portal -- a goal that the Sakai funders had in exchange for providing uPortal more funding.

The result was that the market for uPortal -- the uPortal 2 adopters -- were disconnected from the funding for uPortal's future. This gap could have been bridged, but it was a painful way to get there. I asked him why.

His take was that the community lacked the governance to marry the joint goals of innovation (funded by the Sakai project) and support for the customer base. By "governance" he meant the ability to set goals for the project as to how to use the funding provided to accomplish two seemingly divergent things: improve the software and transition the legacy stakeholders in the process. The new uPortal 3 does this, but it took a lot more time and money as a result.

I think that governance would resulted in a different roadmap -- one that better aligned the legacy and the future. But, in retrospect, it seems that there was another factor that has played in over the years: the world has changed. And that changing world included some important market forces that may have shifted the legacy uPortal adopters away from their old architecture.

The most notable market force may have been web 2.0, AJAX and the concept of mash-ups. Before web 2.0, portals were highly relevant as the integrator of the user experience. After web 2.0 got hot via MySpace, Facebook, Google and others, portals -- and the technology issues they thought were important -- seemed to fade in significance. As the director of portal initiatives myself, I started to wonder whether we needed to move to a new technology.

These conversations about the relevancy of portals were happening with uPortal folks, too. uPortal 2 couldn't handle AJAX -- the new web 2.0 user experience that allowed for a much richer web applicatino experience -- which put its future into question. And the original uPortal 3 could, but it couldn't easily enable uPortal 2 users to come along for the ride.

I think it was a combination of three things -- the leadership's recognition of the need to move to new technology, with the market impetus forcing legacy users to get with the times, as well as an innovative "Solomon's choice" of cleverly compromising the goals of uPortal 3 -- that resulted in this new uPortal 3, which has given the community a viable path forward. The proof of the pudding is still in the eating, as institutions are just now starting to migrate to uPortal 3. But I think most in the community sees the path forward. And because that path forward has uPortal 3 aligned with the industry's best technology practices, the future looks bright for both legacy users and newcomers to the community.

---

The lesson here for me is, "Money can't buy you love." uPortal 3 had the money, but not the love. uPortal 2 had the love of the community, but not the money to advance the platform. Thankfully for the community, something happened beyond them -- the success of web 2.0 -- that brought love and money together, eventually. If not for that outside influence, maybe uPortal 3 would never have seen the light of day.

As I think about other projects, I realize that the promise of getting them funded often makes people lose their heads. They lose sight of the whole equation that makes software innovation successful:

• The innovation must be funded (whether by cash or by sweat equity or whatever)
• It must solve a problem worthy of the investment in it
• When that worth is determined by adoption, the adoption must happen convincingly enough for momentum to build and be sustained
• The momentum is the result of solving enough people's problems at the right time so as to continually grow the base of adoption
• The timing of priorities is expressed in the product roadmap
• The roadmap must be a collaboration between what is desirable ("marketing") and what is possible ("engineering").
• The collaboration between marketing and engineering is the great challenge for successful technology innovation.

The "right roadmap," then, is a manifestation of the collaboration between marketing and engineering sensibilities. Sometimes that's embodied in a single individual. Usually, it's a partnership between close collaborators -- Jobs and Wozniak, Gates and Allen. Rarely is it the result of committee work -- not if it's innovation. Committees are fine for incrementally inching along something that is mature. But the kind of roadmapping that needs to happen for "love and money" to come together requires a creative spark and collaboration that is more organic.

Thankfully for uPortal, that spark and collaboration occurred amongst community leaders last year.

Hidden benefit of SaaS: Better investment psychology

A friend, who runs a software consultancy, and I were talking about Salesforce.com, its new Platform as a Service (PaaS) called Force.com and its Development as a Service (DaaS) environment called Apex.

I just came back from a "Tour de Force" seminar, and I must admit that I was slurping down the Kool-Aid. Salesforce has done a masterful job of implementing their CRM platform that can configured by anyone and programmed easily. I think of their concept as a 4GL for cloud computing. I know -- 4GL dates me. But there's not much new under the sun...

Anyway, my friend asked me why I thought Salesforce.com was more successful than Siebel, the dominant CRM platform for years that is sold primarily as licensed software. He described several Siebel implementations that were train wrecks, and he was curious as to whether I thought Salesforce.com would run into the same fate. After all, both are CRM platforms, and their designs (at least at the software object level) are not all that different. Yet, we have not heard of the same kinds of disastrous projects implemented using Salesforce.com.

After talking about it for a while, we stumbled upon an explanation for why there may be a disparity between Salesforce and Siebel -- a difference that has resulted in Salesforce's increasing success in the market.

The difference, I think, lies in what drives the cost of CRM initiatives, and the expectations that surround them.

To illustrate, let's consider two projects, each costing $10M over 3 years, with the following characteristics:

Project A

• Development life cycle: 18 months
• Time in use: 12 months
• Cost breakdown: $2.5M software license / maintenance; $5.0M customization and integration; $2.5M project management, requirements definition, etc.
• Number of users: 20,000

Project B

• Development life cycle: 6 months
• Time in use: 24 months
• Cost breakdown: $130/user/year; $0.250M customization and integration; $0.100 project management, requirements definition, etc.
• Number of users: Ramps up to 35,000 in year 3

Project A is a big project team working for a long time: at $150K/person-year, that brings the project in at about 50 person-years, about 15 person-years defining the system and managing the project, and another 35 person-years building and deploying it. That's a lot of time for a team to have on its hands. What kinds of expectations does one think there would be with that amount of resources? The temptation to add scope and complexity beyond the out-of-the-box solution is almost palpable. Sure the system can handle 20K users, but the real investment is in getting all the features the business can digest. Furthermore, the capital appropriation of $10M over 3 years means that we've paid for an asset, and most managers will expect that asset to have what they need from it -- again, irresistable urge for complexity.

Customizations and complexity increase project risk, however, so the failure rates of projects like Project A likely increase with the customizations and complexity -- driven by investor expectations of "value."

Project B, on the other hand, suggests about 2-3 person-years to make the project work. There are, then, much lower expectations regarding customizations and support for complexity beyond what the out-of-the-box package provides. Furthermore, the costs scale with the number of users, so the perception of value is per user. At $150 per user, there is not the same pressure or set of expectations as to what the software has to accomplish to deliver value to the organization. (In fact, more money is probably spent, per user, on training and effective use of the software than on the development and licensing / rental of the technology).

With lower customizations and complexity, the project risk for Project B would be substantially lower than for Project A that costs the same amount over 3 years. And, Project A folks, don't fool yourselves that the costs of Project A go down after year 3. If Project A succeeds, the next major version (including all those features that never made it into the solution) is just around the corner.

It would be nice to actually look at some data as to Siebel vs. Salesforce project success rates, but my friend's on-the-ground perspective seems to bear our this difference in outcomes. It is fascinating to me how the psychology of technology investing has so much to do with determining project success.

In any event, it seems that SaaS / PaaS / DaaS may have a hidden benefit to the sponsor of the initiative: by aligning investment cost with users, it may reduce the need for initiative sponsors to seek their returns in the investment in an asset (which investment, through complexity, increases risk).

The Epiphany

"I just had an epiphany!" remarked a friend of mine yesterday. What a great way to start the day. She had my attention. "Now I know what happened..."

Connie is a product marketing manager at a media company. Her job is to develop and bring to market media-based solutions for her specialty segment. She's incredibly bright, talented, hard-working and great to work with. Her colleagues are amazed at what she can get accomplished. But recently, she ran into challenges that seemed insurmountable.

Her last project was a the launch of a new technology product into a market segment where her company, a leader in the industry in general, has been trailing behind the leader of this segment, with a third of the leader's market share. Her hope was that this new technology product would launch the business forward to seriously cut into the market share gap she was facing. This product had the chance to be a blockbuster, a game-changer. And everyone knew it -- her president, her colleagues and even some of her competitors that got wind of the project. So, a lot was riding on this new product launch, and she was laser focused on its success.

Her company had committed to her that a new technology platform would be available for her new product, and that platform would have key features that distinguish it from the competition. Furthermore, she and her division president sat on the steering committee for this platform as it was being developed, to ensure that her product's needs would be reflected in the platform.

That was nearly two years ago. Recently, she sat frustrated at how things had played out with her high-profile project that was now struggling.

"Tell me about your epiphany," I said.

"Marketing and Engineering are like oil and water. I thought everyone was working together on the same team for the same goals. We had all of these great steering committee meetings, and they listened to all of my requirements for my new product. But when it came down to delivering what I needed into the market, they just couldn't do it. Their bosses were asking them to do things that were not aligned with my mission. It was like the whole world worked differently for them -- all the rules of what made the project successful for me seemed no longer to apply to them. And the frustration I am feeling right now is that our paths seem to have separated -- like oil and water."

I sat and listed to Connie's story, and I thought back to how many of them I have heard like this. But not just from the marketing people like Connie. I've also heard them from engineers like Mark.

"I thought this was a strategic initiative. I thought we had buy-in from the executives. I thought the business people had figured out where this thing was supposed to go and they had to be there as soon as possible. But now I can't get them to stick to a decision on any of the features of this platform. We were fine going into the final checkpoint, and now they're throwing everything up in the air again. We have 500 pages of requirements -- with their signatures signing off on them -- that we spent months hammering out. And now they're telling me that they can't launch with the features we have. It's maddening. I want to quit, and so does my team."

Oil and water. Sound familiar? It does to me. As someone who has been a product manager and an engineering manager and an executive and investor in new technology initiatives, I have lived in this oil-and-water world for several years. I have had my own epiphany, which is why I have started this blog.

My epiphany is that this situation is entirely predictable, and it is at the heart of most new ventures and new initiatives. Some learn to navigate it and some get smacked in the face by it. I'd like to explore what's going on, why it happens and what managers facing these kinds of challenges can do about them.

I've got to run. The morning commute beckons.