Wednesday, November 7, 2007
The perils of intrapreneuring
I have presumed that intrapreneuring would be less perilous, but with less of an upside. But you learn something new every day. To sum up today's lesson: any time you venture to create something out of nothing, some people will go "wow!", some will go "what?", and some will cry "wait!" as they dig in their heels. The question is, in the ecosystem in which you are creating, which voices will win out?
When "wow!" wins the day, there is the most fertile ground for intrapreneurship. If you intrapreneur in a market-leading company, it means you're wowing the key influencers in the market -- because they're in your company. Wowing them means they want to carry the message to their customers (when the time is right), and they create the lift and the life that will give your creation meaning.
When "what?" is the siren song, it means you need to unpack your idea. Maybe you have too much there. You have to figure out where the "wow!" is, and you have to make sure you don't have any "rude cues" in there. Those are the things that signal "there's something about this that makes me uncomfortable." If you can extract the rude cues, you have a good chance of getting to "wow!". Otherwise,...
When "wait!" wins the day, it means there's an incumbency that either needs to be won over or will kill your creation. Wait means "I'm not ready for your creation to be born." It means the new thing you are introducing puts the incumbency in peril. Sometimes, this is a bad thing (be careful not to kill the "cash cow" that funds your intrapreneuring). But other times, this is a good thing, because the cow has hoof-in-mouth and needs to be put to rest -- or it will infect the rest of the farm.
Now entrepreneurs have similar kinds of reactions from their customer: wow, what and wait. But there's usually a big difference. A customer base in a free economy is an open system, while a set of internal customers is usually a closed system. The closed system usually suffers from an inability to reinvent itself to accommodate change. An open system can much more easily accommodate change, because it is intrinsic to the design of an open system.
I don't think there's any silver bullet here, but there is a cautionary note for intrapreneurs: know your audience and where they fall in their response to you. And, know your company's culture to understand whether you can get the wows you need for your innovation to win.
Sunday, November 4, 2007
Flexiblility: How much is enough?
In my thesis, I studied the value of investing in a biotech license (which is the right to develop sell a particular family of biotech formulations, but not the formulations themselves). The license cost about $500K, which would be lost investment if the company never chose to "exercise their option" and market a biotech product that used the license (unless the value was in prventing someone else from having that option). The question was, is $500K too much to pay for the license?
The answer depended on a series of risks and how they played out. They were:
- Scientific risk - could the product be engineered? Was it feasible at all?
- Regulatory risk - could the product be legally manufactured and sold? To what markets?
- Manufacturing risk - how much would it cost to manufacturing the product? How long would it take?
- Industry risk - how much competition will there be for the opportunity we are trying to seize? Will only a few entrants duke it out, or will there be a lot of players
- Market risk - how much demand will there be for the product? What price can we get for it?
I look at software innovation, and the risks are similar, but their significance and costs are sometimes different. For example:
- Scientific risk - This is pretty much the same. People who are experts in either field will be able to tell you quickly whether there's any risk here at all. And, if there is, it means an R&D effort just to play in the game.
- Regulatory risk - In biotech and pharma, the costly clinical trials process process (4-5 phases) determines this risk. In software, the risks usually are answerable by lawyers: patent infringement and patentability, privacy and other information legality concerns, etc.
- Manufacturing risk - In software, this is where the game is usually won or lost. Historically, more than 90% of projects go over budget by as much as 50% (this is a stat from 10 years ago; things may be a little better now, but probably not much, based on my observations). Embedded in the manufacturing risk for software, I believe, is a much more complicated set of issues regarding architectures, which are probably resolved much sooner in the process when dealing with biotech / pharma.
- Industry risk - This is another area where understanding the possible scenarios and how they will play out has much different effects in software. For example, if everyone is rushing to build something, that may create a new opportunity in itself (sell shovels to gold diggers). Another possibility is to collaborate on standards or open source, allowing for lower overall development costs across the board and competition on a basis other than exclusivity (which, by the nature of pharma/biotech today, is somewhat inherent in the product).
- Market risk - This risk is consistent between biotech/pharma and software, though it looks very different. Both ultimately worry about things like: who will pay and how much? Will someone subsidize payment (insurance for pharma, advertising for software)? Both worry about different abilities to pay in different regions of the world, and how to price discriminate.
In software, the market innovator really holds the cards on industry and market risks; engineers know best on scientific and manufacturing risks. It depends on regulatory risk. But, in software, all of these risks are best resolved in the product conceptualization process. In that process, one can get a handle on feasibility issues, regulatory/privacy issues, degree of difficulty and cost to build as well as uniqueness in the industry and market opportunities.
To answer "how much is enough" flexibility, one needs to put together a product conceptualization process that facilitates the kind of dialogue that clarifies and resolves a lot of these issues and risks. Once a software product is conceived, it can be tested against all of these risk areas, and engineers can better understand what options the market innovators will want to exercise through flexibility over time.
The "over time" part is important, too. Usually, all flexibility is not needed immediately. The market risk needs to resolve -- who is going to use this product and how -- before one feels comfortable investing more. So the architecture of the product system is only one part of the design. The other is the architecture of the product roadmap. The clever sequencing of the roadmap can allow questions of risk to be resolved over time, reducing the number of options one needs to worry about investing in. The product roadmap and the product system together define how the product can evolve over time. I'm sure Darwin has something to say about what kinds of products will withstand evolutionary processes better than others...
Saturday, November 3, 2007
The challenge of building flexible solutions
But our conversation was not about how passe his platform is. Instead, it was about how many times in the past two weeks we have decided to incorporte his platform into our next-gen solutions for business units. His platform is tried and true, people in the business know how it works, and it makes introducing new innovations easier to digest when there's a strong whiff of the familiar as part of the new solution.
His platform is quite flexibile -- even more so than most of his internal customers take advantage of. Yet, this platform has not been getting the credit it deserves in driving innovation forward. That got me to thinking why.
I realized that the platform team did a great job of designing a very flexible platform. Yet, without people educated on that flexibility and how it is relevant to new innovations coming from the business, that flexibility could lie forever dormant.
Great software developers and architects know how to design software that is flexible, but they don't always know how to market that software so the flexibility can be harvested and achieve the benefits it could.
This caused me to think back to my Master's thesis on the topic of applying options theory (like stock options) to management decision-making. Basically, the theory says that any project or investment that has embedded options is worth more than one without options. That makes sense intuitively: if you're "locked in", that's worth less than if you have the ability to choose among outcomes. And, flexibility means you have embedded options. Options to take advantage of opportunities with less or no investment that, if you didn't have the option, you'd have to spend a lot more money and take a lot more time to seize the opportunity.
It dawned on me that building flexibile platforms (with embedded options) not aligned closely with market innovators means those options will likely expire worthless. That's bad. It means you have paid for these options but never got to take advantage of their value. So, you just overspent. This is a reality that does not often occur to engineers and architects. They often see their job as designing something that is flexible (modular, open, interoperable, etc.). That flexibility is expensive, and they often find themselves fighting for the funding to "do it right." What they mean is they want to build something that will last, and to do that, it needs to be flexible -- and you have to pay for the options of flexibility while the thing is being designed or built.
But market innovators (to engineers, these are "the business people" ) who don't understand the nature of these embedded options are like investors who buy stocks that come with options, but they don't know how to exercise those options in such a way as to get the value from them. A financial manager who let that happen would be fired, but the disconnect between market innovators and options-building architects and engineers is all too common in my discipline of software.
I often see engineers asking business people, "What do you need? What will you need in the future?" as if these business people had crystal balls back in their offices. And I have seen market innovators become very frustrated when they ask for a solution from engineers who implement what the innovator has literally asked for -- not what they actually want. As hockey superstar Wayne Gretzky would say, they are skating to where the puck is, not where the puck is going to be.
I feel I've made some progress on thinking through this disconnect, but I don't yet have my finger on how to articulate it...
Intrapreneurship and Boston Driving
I have colleagues who don't necessarily take the same point of view, but I find that this perspective (while not the official corporate policy) helps me focus my activities and platform strategy more effectively than any other construct I could operate in.
One of the challenges of doing my job in particular, and probably of being an intrapreneur in general, is that the marketplace that I play in is a lot more insular, and I am more constrained in how I operate than if I could be a disruptive force to an industry -- an approach that a VC might take in trying to make hay with the next billion-dollar business that turns an industry on its ear in the process.
We're a $12-billion-dollar business, and while we are constantly innovating, we have a franchise to protect. Using a highway analogy, I'd call that the "slow lane." It's full of big trucks full of customers that pay the freight for everyone. There's also some experimental innovation going on -- strategic investments that don't need to be connected to the slow-lane activities. But, they are disconnected from the day-to-day parts of the business -- and they have no revenue goal responsibility. I call them the "fast lane." They go somewhat unencumbered by the current state of the business. The state troopers are out with their radar guns, though. Those are the people who want to make sure that the franchise is not disrupted by these fast-lane activities. Innovate, but don't kill the cash cow in the process. So, they look at partnerships and acquisitions that extend or reinforce our core business, but they refrain from redefining the business.
But I'm not in either situation. I have to launch new products (not the slow lane), but what I do must be quickly relevant to the business, enabling us to deliver value that justifies the year-over-year investment in my platform. I am in the "passing lane." My goal is not to go arbitrarily fast. It is to incrementally move the business forward -- like passing one or two cars. Sometimes, it's to get us into open road by passing that huge truck with its blinkers on that is holding up traffic. An example of that is a project I'm working on that creates a new web capability that brings together many pieces of our new strategy. It will not disrupt our industry, but it will enable our company sieze key opportunties and reinforce our market-leading position.
So where does market disruption come from -- the Clay Christiansen kind that redefines an industry? I think it actually comes from the "breakdown lane."
In Boston, driving is permitted in the breakdown lane during rush hour. Ostensibly, this was done to accomodate the overcrowding or undersizing of our highways. Usually, the breakdown lane is for the more adventuresome. There's no value in driving there when traffic is moving well (in fact, it's dangerous, as the breakdown lane intersects in arbitrary ways with on-ramp and off-ramp traffic). But, when the regular lanes are locked down, the breakdown lane is usually moving. Often, Boston drivers see their comerades even passing in the breakdown lane.
So, how is disruptive innovation like the breakdown lane? First, its importance shows up when regular traffic is blocked -- sort of like when an industry of incumbents bogs down. This happened to the record industry, which was disrupted by the iPod and digital music. Apple zoomed through the breakdown lane while the incumbents were jammed up in trying to figure out how to respond to innovations like the web, MP3s and Napster.
Right now, I like being in the passing lane. Some of my business partners are in the slow lane. I need to help them "pass the car ahead of them" without putting the franchise at risk. Some of my business partners want to be in the passing lane and zoom ahead a few cars. They're not established enough with an existing franchise to worry about stepping on the gas. And there are even some who are ready to race ahead in the fast lane. With them, I want them to understand in what ways I can help them achieve their goals, and in what ways they need to just zoom ahead -- I'll catch up later.
But I have my eye on the passing lane, too. If traffic bogs down to the point where "passing lane" innovation is not enough, I may have to scoot over to the far right and drive like a Bostonian...
What's the Huge Idea?
The Goliaths included IBM and Arthur Andersen, and David was Unix and the Cambridge Training Center. Twenty years later, I look back and see billion-dollar industries that have emerged -- client-server computing (hardware, software and profession services markets, in fact), internet computing and others. These industries were significantly impacted by some wet-behind-the-ears college grads, some ingenious academics (including the requisite mad scientist), some major companies fighting to be relevant(among other places), some technologies that had been around for a while but never valued relative to their potential, a common out-of-scope feature (lack of Y2K support) that resulted in billions spent to overhaul our computing infrastructure, and a myriad of other forces.
Having participated actively in two market disruptions (mainframe to client-server, and business computing to web computing), I have spent a lot of time thinking about what happened and why. I talk about it with colleagues frequently, and thinking about it sparks my current activities and future plans.
As a kid from a working-class family that read The Daily News, not The Wall Street Journal or the NY Times, the nature and concepts of business were new to me until I entered the workforce. So, I look at these ideas somewhat like an alien who visits our planet and is trying to translate observed phenomena into a language he understands.
My language is one of pictures, concepts and dynamics. When I look at something that is working well or poorly, I try to understand the underlying nature of it to explain its performance. For example, when I look at the New England Patriots and their success, it is not enough for me to say "Bill Belichek is a genius," or "Tom Brady is the next Joe Montana." There are a lot of smart NFL coaches and talented NFL quarterbacks. But what is the reason for their success? And will it last? What can others do to compete more effectively against them?
I asked the same questions at every point in observing the client-server and web revolutions: who was winning and why? who would be the next winner and why? and, how could I give the thing I'm working on a better chance of winning? I have learned that some of the most financially successful people asking and answering these questions -- (good) venture capitalists -- realize that it is too hard and fraught with peril to codify answers to these questions. Instead, they master the ability to identify opportunities worth going after (they keep their thinking to themselves, mostly) and finding people who know how to take an opportunity and make it into a success.
For the past several years, I have focused on being the latter kind of professional. I am what I call a "business architect." I listen to a vision for something that could be built -- typically a web-based software product, which is my field of choice -- and I transform that vision into something that is real, compelling, enjoyable and valuable. In the course of the latter, I am getting a little better at the former -- knowing how to identify opportunties that are worth investing my time, talent and treasure in.
I also think in economic terms. Not in terms of "it's all about the dollars." But, on the contrary, trying to understand how to value things, what gives them value, what things cost, how those costs can be managed. Having served on a number of non-profit boards, I have found that the keys to success for a non-profit have their roots in economic theory: it's all about achieving your goals given an ultimately limited set of resources.
Finally, I am most interested in the creative process. Managing something incrementally along does not interest me. I am captivated by creation. The magic of "first you don't see it, now you do." The birthing process of something that starts as an idea and ends up as something real -- I believe that is at the core of who and what we are as humans.
All ideas can be huge. Which ones we choose to make huge, and how we do it. That is what I am passionate about, and that is what I will write about in this blog.