Links

I wanted to follow-up on the theme of my last posting by asking: when is less invention more or less innovation? One of the things that I referred to was the company 37 Signals. As you probably know, there has been a terrific debate about 37 Signals and their widely-publicized call to arms against feature complexity (eg. “Bloatware”) in software. Basically, they are the “less is more” poster child for the world of software. Probably the best example that I have found of this debate flowed out of a blog posting way back in 2006 by my friend Dharmesh Shah on his phenomenal blog: OnStartups.com.

The Debate: Basically the debate can be boiled down to this:

The 37 Signals school of thought is that the mere act of reducing features can add value to software for many if not most users, and is its own form of innovation.

The counter-argument articulated by Dharmesh is that most of the interesting problems that software can help solve aren’t simple enough to be solved by simple software. His argument is that software should be no more complex then is necessary to meet the need.

What vs. Who

I actually think that both “sides” in this debate are saying something true, and that the tension between them is actually artificial in that it is mostly based on another factor. As Dharmesh himself points out in his post, “Many can (and have) argued that nobody uses more than 20% of the features in Word. That’s likely true. The issue is that it is a different set of features for each user, and within that set, one or more features are very important.” So I think that the question is not how many features to offer, the correct question is how many people to offer the features to.

The example of Word (and a lot of other software from the past 20 years), is of a product that needed to fulfill the needs of most everyone and therefore had to include a lot of functionality to meet everyone’s needs. But this requirement is really driven by the business model which led to loading every conceivable capability into a single, gigantic product. When you look at any particular person or group, it is much easier to identify what my friend Clayton Christensen calls “jobs to be done“, and the features and capabilities that are needed naturally fall out of that. More importantly, using the “jobs to be done” concept clarifies which dimension of performance defines the correct innovation trajectory.

It’s the Business Model

I would argue that for 37 Signals and others in the new generation of Web 2.0 and Software as a Service (SaaS), what has changed isn’t really the philosophy - it’s the business model. These companies build and deploy software in a completely different way (as internet services) and into much more sophisticated and heterogeneous markets. The result is a different software business model with very different economics. It enables, and I would say even encourages, software companies to form solutions around much more homogeneous markets defined by common “jobs to be done” and a shared vision of the dimension of performance.

What this leads me to is the concept of “requisite complexity” which I first encountered many years ago while I was studying innovation at Cambridge University. The idea is that solutions will not be less complex than the problems they solve. I would hypothesize that neither side of the debate would disagree with this idea (I hope - anyone out there want to speak to this?).But, the only way to reconcile the very real conflict between these ideas is to understand that they represent different business models (eg. the traditional mass-market software application vs. jobs/market-specific software).

Many in the Web 2.0 world are very enthusiastic about Christensen’s “Disruptive Innovation” thesis because it appears to offer a roadmap for success. I think that they are right, and I am satisfied that the success of Salesforce.com is an example of classic disruption. But I also think that this new generation of software entrepreneurs would be wise to take another page out of Clayton’s book (literally!), and make sure that they understand and align their solutions with the “jobs” that their customers “hire” them to do.

So this may be a starting formula for software success right now:

identify the “jobs to be done”
(and understand what that “market” looks like”)

+

build solutions of “requisite complexity”
(not “less” or “more” - but “just right”!)

+

wrap them in the right business model
(and delivery mode etc.)

To me, Web 2.0 is really about a new business model for software, and not really about technology (though technology has been a key enabler). This helps explain the profusion of smaller, more specialized, software companies and the blurring of the lines between software “products” and “services”. My own company offers IP management software and represents this trend. As a specialized vendor, our solutions have come to be defined by a unique “jobs to be done” profile. Ultimately, our evolution toward the SaaS business model has been driven by the economics of serving these kinds of specialized markets. This model allows us to deploy many different versions or “flavors” of the product to address the need for requisite complexity for each “jobs to be done” profile - and make money. Said more simply: our objective is to profitably offer everyone with IP just the software they need to effectively manage their IP. Simple to say - difficult to do!

This spring I had the pleasure of lecturing at MIT in two different courses on innovation - both taught by the always fascinating Eric Von Hippel. The first was to a group of MBA students and Sloan Fellows at the MIT Sloan School of Management as part of a course entitled, “Innovation in the Internet Age: Emerging Trends“. The purpose of my lecture was to provide a real-world example of a company struggling to rapidly evolve an innovative web platform using as a case study, Knowligent’s IP Portfolio software for managing innovation and intellectual property.

In my session, I briefly recounted Knowligent’s experiences innovating a complex enterprise system and the way that customers essentially negotiate to introduce their ideas into the design of the product. Eric’s objective for bringing me in to lecture was to provide proof for his overarching thesis - which is essentially that a lot of innovation comes from end-users, and companies that embrace this reality are better off for it. Of course this is absolutely true, and Eric has become a sort of collector of cases and evidence in support of this “Open Innovation” idea. The students were very intellectually engaged and a lively discussion ensued over the basic issue of whether customer-driven ideas can be trusted to lead a company’s innovation in the right direction. It was typical of MIT - very probing, questioning, and spirited - and it was a lot of fun! A few things came out of the discussion and my subsequent pondering after that I feel are particularly interesting and useful…

1. Enterprise software is actually a pretty good example of an industry where innovation has been heavily user-driven. Many if not most business software companies originated out of home-grown IT projects within companies for from corporate “wish lists”. Even after a project has spun-out, the vendor tends to be dependent on a small group of corporate customers for at least the first few years of their development, and these customers can exercise enormous power over the development trajectory of the product.

2. However, although a majority of ideas for new features and capabilities originate with end-users, only a small subset tend to have broad appeal. That is, customers can quite easily produce a large volume of ideas for new functions mostly because they have so many jobs to do. But these features make for complex, and usually expensive, software. If the vendor isn’t vigilant in controlling the code base, this significantly restricts the appeal of the software and I think that this can be a very dangerous trap for a software company to fall into.

3. More importantly, it is arguable that these user-driven features aren’t really “innovation” at all. Just because a customer demands certain features doesn’t mean that they are innovating for you. Much of the time this is really just “invention” (as distinct from “innovation”), and often it isn’t even that. The danger is that companies may come to think that they are innovating because they are adding a lot of new “features” to their products.

4. Enterprise/business software seems at the moment also to be a good example of another interesting theory of innovation - namely Clayton Christensen’s idea of “Disruptive Innovation”. Disruption usually happens when new products are introduced that actually offer less of the kind of functionality traditionally demanded by the existing (and influential) customers. So, running counter to the urge to create customer-driven “bloat-ware” is an urge to create software that is actually less functional but which may be easier and cheaper to deliver and use and is frequently innovative in other dimensions. For examples, I point to Google Docs, 37 Signals, and Mint.com as just a few of my personal favorites demonstrating this kind of disruptive innovation in the world of software. In other words, the current tide of “innovation” in software seems to be moving in the opposite direction than the one that big and influential enterprise customers may want to go. As the theory predicts, over time these offerings will likely become ever more functional and ultimately displace their predecessors. It’s this changing of the dimension of innovation that makes disruptive innovation so powerful.

The question that comes out of all this is whether your biggest and most influential customers are likely to lead you in a direction that makes you more or less innovative. My own feeling and experience (from the world of management software) is that involving customers and end-users in driving your product design usually makes you more inventive but can make your products less innovative overall. It is probably true that this will be different in other sectors. However, at the very least this supports the idea that there is a need to carefully evaluate the direction your customer input is driving you and to distinguish between “inventiveness” and “innovation”.

I have been working on a couple of software projects recently, and I have been reminded once again why IP management software implementations so often fail. So, I have come up with five (facetious) things any organization can do to doom its new IP management software to failure.

1. Hold-on to the past
Redesign your new IP management software until it works exactly like your old IP management software.

You need new software because the old has made it very difficult to do your job. It has become a problem in virtually everything you do. After literally years of struggling with it, you have finally built-up enough organizational will to go through the pain and expense of moving to a completely new platform. But, as we all know, change is difficult (see #4 below), and there is always a countervailing pull to return back to the familiar. There are always people who will oppose change, and the pressure to remake the new system in the image of the old one will quickly be overwhelming. Give-in to the urge, and start pressuring your vendor to “adapt” their system to your “needs”. This is the most effective way to make a project expensive and time-consuming. Most importantly, this is how you make really bad, bloated, and buggy software.

2. Delegate
If you want to end up with IP management software that can’t support your IP management, then don’t involve your IP managers.

Make sure that you assign the project to your lowest-level support staff. Remind everyone that these are the people that are directly responsible for most of what the software does anyway. Because these people have no real authority, they will never be able to consolidate the necessary resources (see #3 below), make essential changes to the organization’s management processes (see #4 below), or compel anyone to use the software (see #5 below).

3. Focus on the cost
IP management software should be viewed merely as another cost of doing business that must be aggressively contained.

Other major expenditures such as patent filing fees and management salaries are obviously investments which ultimately are expected to produce tremendous returns. In this light, make sure that you find the cheapest vendor, or if not, then make sure to bully the vendor you do select into subsidizing your implementation. Remind them that you are a very important customer and that, if they make you “happy”, their business will ignite with the white-hot fury of a thousand melting suns. Later, when you are shouting at them for “under-delivering” be sure to hang-up before they remind you that you paid them for only about a fifth of their actual effort. Although you have plenty of direct evidence that this is true, you must balance this with the fact that everyone knows software vendors are notorious scam-artists.

4. Don’t change a thing
Avoid making essential changes to your IP management practices and processes.

Obviously most of the benefits of your new software cannot be realized without matching changes in how you do things. Your IP management processes have to change, or they won’t be any better than before. (It reminds me of the TV ad where the people think that their life will change because they have new telephone service.) But once you start down that road it can lead to a lot of unsavory outcomes. It can even mean changing people’s assignments! Of course, this cannot and must not happen. Change must be something that occurs only in the abstract - in the “software” realm.

5. Don’t turn it on
Ultimately, the most effective thing you can do to prevent a successful implementation is to simply refuse to turn the new IP management software on.

The most common, and easiest to use, method for doing this is to tell the vendor that you are not “happy” with the software. If they get pushy and want to know why you are unhappy, or what they can do to resolve it, just tell them that the whole experience has been “bad” and that you don’t “like” it. Remember that most of the pain of moving to new IP management software is the change that it will cause (see #4 above) - the monetary cost is nothing compared to that. So, even if you have gone through all the trouble and expense of getting new software, rebuilding it to match your old system, and bullying your vendor into doing most of the work for free, remember that most of the pain comes after you “go-live”. Just don’t do it

Managers tend to misunderstand the difference between what kinds of value patents can create (practice, license, litigate, and deter), and the kinds of business models and strategies that they can be used to support. In a previous post, I said that this is the difference between motivations and modes. In a recent article in the MIT Sloan Management Review, there is some research that demonstrates this. The author and colleagues conducted a survey asking managers to describe the “purposes that IP rights served for their business-area strategies.” What their analysis revealed was not purposes at all, but a series of 5 “IP strategy scopes” which really just described how far the company would go to pursue IP protection.

1. Full-fledged IP Protection
2. Patent and trademark control
3. Trade. IP is mainly to be licensed out or sold off.
4. Pure branding.
5. Support core R&D

What is interesting about this is that numbers 2 and 4 really don’t relate to patent strategy at all - but to trademarks and branding. Therefore, there really are just three distinct “scopes” for patent strategy here. The first basically refers to the method of trying to protect every possible thing in an effort to block entire spaces. Scopes 3 and 5 are coherent in that they clearly identify their motivations and the kinds of value they are trying to generate. For scope 3, it is Licensing, and for scope 5 it is Practicing.

So, I found all of this interesting for the way that it demonstrates how murky IP management remains, and just how rare it is for managers to think clearly about how to integrate IP into their business models and strategies. It’s also interesting that a major conclusion of the study is the strong shift toward scope 1 (trying to use IP to block entire spaces) as the new “dominant practice” in IP management.

In a previous post, I outlined four ways that patents create value for their owners. I realize that this can be confusing, because patents have become integral to so many different business models and strategies. In fact, there has been such a profusion of IP/patent strategies and schemes and a so many flavors of innovation management, IP management (IPM), and intellectual asset management (IAM), that it is difficult to believe patents create value in only four ways. On the other hand, many people correctly point out that patents only create value in one way: by blocking others from doing something. The question is: do patents create value in one way, four ways, or a whole bunch of ways? In my mind, the answer to this question is more than academic. It really ought to form the basis for how any company or organization deals with intellectual property, and particularly patents.

Luckily, finding the answer to this question is not as difficult as it might appear. We simply have to return to what we know. A friend of mine is a professor of engineering at MIT and an expert in metals and structural failure. He likes to recount a story to his students that illustrates what I mean. On September 11, 2001, as he drove home from work he was pondering why the World Trade Center towers had completely collapsed. His first thought was that he would need to examine and analyze the details of the engineering of the WTC buildings in order to answer this question. But, he quickly remembered that he already knew everything necessary to understand what caused the collapse (and what didn’t cause it). When he got home he wrote out those things (he calls them “fundamentals”) in a list - things like the temperatures at which aircraft fuel burns and steel melts, and the weight of the airplane relative to the weight of the building. The list was surprisingly short, and formed the basis for a paper he wrote that has become the most highly cited on the subject and of a subsequent NOVA program.

My point is that it is easy to become confused about how to think about intellectual property. But a review of the “fundamentals” can be very helpful. So, here is my attempt to return to what we know.

What We Know (the “fundamentals”):

1. MECHANISM: First, we know that intellectual property provides the owner with the opportunity to prevent others from using or doing something in business. This is literally how one goes about enforcing the rights of a patent and is fundamentally a legal process. I like to think of this as the mechanism by which IP delivers value.
2. MOTIVATION: Second, that opportunity can produce different kinds of value for the owner. In other words, there are different benefits that IP owners can receive by preventing someone else from doing something. In my mind, these as the motivations for owning IP. In case you are wondering, this is where my “Four Kinds of Patents Value” fit.
3. MODE: Finally, there are a lot of different contexts, business models, and strategies that these motivations can support or be a part of. To me, these are the modes in which IP owners leverage IP to pursue their business objectives. Although there have been a few traditional modes, there seem to be more and more lately, and they are probably limited only by the human imagination. Incidentally, this is really what most people are referring to when they talk about IP strategy (or “innovation” or “IAM”).

What it Means:

I believe that there are two conclusions from this that are of immediate and tangible value:

First, this clarifies why it is so important to involve different people with different skills, knowledge, and perspectives in IP management. Said another way, this makes it more obvious why companies that bring people from across the organization together to participate in IP management are consistently more successful.

Second, it is essential to remember that the mechanism and motivations of IP management don’t change over time (or, not much anyway), and they are not something managers have any control over. What managers have control over primarily are the strategies or modes they use to leverage IP.

The benefit of this realization is that it allows managers a relatively simple framework for evaluating any IP strategy. To produce value, an IP strategy (mode) must combine enforceable IP (mechanism) with the promise of generating at least one type of value (motivation).

Unfortunately, what I see too often is management that hasn’t identified its specific objectives (motivations). In other words, they haven’t decided specifically what types of value they want from their IP - usually they want to pursue them all. This kind of IP management is expensive and largely pointless mostly because it doesn’t provide any way to decide which IP to pursue (or not to pursue), or for that matter, when, where, and how much. And, isn’t making those decisions mostly what managers do? It is impossible to visualize effective management in this situation.

I also think that the failure to define the core motivations for IP strategy explains why we are seeing such a strong shift towards what Markus Reitzig calls the “Full-fledged IP protection” strategy. He defines this as the pursuit of IP for “every possible minor invention in order to block entire technology spaces”, and his recent research shows that nearly everyone is moving in this direction. In other words, this is what “IP Management” has come to mean to most corporations. I have a friend who calls this strategy, “spray and pray”.

This is not only expensive and unfocused, but it also shifts the competitive efforts increasingly toward speculation and guesswork. It is also one reason why many view IP strategy as a “dark art”. Personally, I am deeply skeptical about this as a viable IP strategy for any company. I strongly favor making informed decisions supported by knowledge, and that kind of IP management takes place where mechanisms, motivations, and modes converge.