J.D. Meier's Blog : Innovation

Lessons Learned from the Most Successful Innovators

J.D. Meier — Mon, 25 Feb 2008 10:34:28 GMT

What practices can we learn from the leaders in innovation? How can you improve the success of your R&D efforts? In "Smart Spenders, the Global Innovation 1000," an article in strategy+business magazine, Barry Jaruzelski, Kevin Dehoff, and Rakesh Bordia write about the key practices that the most successful innovators use.

About the Study
In the study, Booz Allen Hamilton set out to find which companies have been getting R&D spending right, and then to identify common attributes. They analyzed the data for the Global Innovation 1000 using seven performance screens: sales growth, gross margin percentage, gross profit growth, operating margin percentage, operating income growth, total shareholder returns, and market capitalization growth. They analyzed the following industries: Aerospace & Defense, Auto, Chemicals & Energy, Computing & Electronics, Consumer, Health, Industrials, Other, Software & Internet, Technology, and Telecom.

Lessons Learned
Jaruzelski, Dehoff, and Bordia identify some of the key practices for successful innovation:

Deep pockets can be dry wells. Money simply cannot buy effective innovation. There's no significant statistical relationships between R&D spending and the primary measures of financial or corporate success. Gross Margin is the single measure for which a relationship between R&D expenditures and corporate performance can be statistically demonstrated. The 500 companies that have the highest rates of R&D spending as a percentage of sales are more likely than other companies in their industries to achieve superior gross margins.
Less than 10 percent of companies are high-leverage innovators. Only 94 of the companies in the Global Innovation 1000 produced significantly better performance per R&D dollar over a sustained period.
Companies are getting better at squeezing benefits from R&D spending. Spending rose, but revenues rose more.
Bigger can be better, even if it doesn't boost break-throughs. Scale provides advantages to R&D spenders. For the largest 500 companies, ranked by revenue and indexed by industry, median R&D spending was only 3.5 percent of sales in 2005, compared with 7.6 percent for the 500 smallest firms.
Patents generally don't drive profits. Boosting spending can increase the number of patents that a company controls, but there is no statistical relationship between the number of patents that a company controls, but there's no statistical relationship between the number or even the quality of patents and overall financial performance. Very few patents are truly significant -- just as only a handful of books become bestsellers.
Master of the innovation chain have an edge. The typical problems are good ideas get stuck in developmental bottlenecks and promising innovations never get to market because of flawed understanding of customer's needs, and poor marketing and investment planning. The high-leverage innovators and the companies with best overall performance distinguish themselves not by the money they spend, but by the capabilities they demonstrate in ideation, project selection, development, or commercialization.

There's No Silver Bullet
Jaruzelski, Dehoff, and Bordia dispell the idea that there's a silver bullet:

"How did they do it? There's no silver bullet; we found examples of many different models and approaches. If these high achievers have one thing in common, it seems to be a focus on building multifunctional, company-wide capabilities that can provide them with sustainable competitive advantage. They design their innovation investment for the long run, and create superior growth and profitability over time."

Innovation in the Nonprofit Sector
Jaruzelski, Dehoff, and Bordia shine a spotlight on St. Jude Children's Research Hospital as both a success story and to compare and contrast with corporations. Here's a rundown of the key points:

Many nonprofits spend significant amounts on R&D, and although the metrics they use to measure performance are different from those of corporations, the challenges their leaders face in maximizing the benefits of innovation investments are often similar.
St. Jude Children's Research Hospital is widely recognized as an innovation leader in catastrophic pediatric diseases such as leukemia. It's overall cure rate is 70% up from 20% in the 1960's and it's current goal is to raise the rate to more than 90%.
Innovation in St. Jude is intimately linked to delivery of service.
Strategic decisions on R&D are made by St. Jude's executive team and are based on an assessment of where the hospital can be most productive.
"I think we can do things that other places can't do because of our focused mission." - Scientific Director James Downing
At the ideation phase, researchers are given wide latitude. "In this business, the worst thing you can do is try to direct basic science and discovery, because you really don't know where the advances are going to come from." - William E. Evans, CEO
St. Jude is also an innovator in breaking down silo mentalities. Conscious effort is made to cultivate people in cross-disciplinary collaboration. The hospital has been designed so that employees in different disciplines -- researchers, clinicians, pharmacologists, nurses, and geneticists -- all work interactively and in close proximity.
One result is that St. Jude is recognized for its skill at translating medical research into effective treatment.
The bottom line for a nonprofit research hospital is different from that of a corporation. Instead of gross margin, net profit, and shareholder returns, St. Jude tracks such results as the decrease in mortality rates for specific diseases, the reduction in harmful side effects of treatments, and the number of times that studies by St. Jude researchers are cited in other research.
"The most important thing we do every day is to provide unsurpassed care for kids who come here. The most important thing we do for tomorrow is our research, which will change that treatment to something better. Innovation, in and of itself, is the ultimate product of this organization." - William E. Evans, CEO

My Related Posts

Innovation Life Cycle

J.D. Meier — Mon, 25 Feb 2008 09:53:43 GMT

What are the key stages in the innovation life cycle? What is the end-to-end value chain for bringing innovation to market? In "Smart Spenders, the Global Innovation 1000," an article in strategy+business magazine, Barry Jaruzelski, Kevin Dehoff, and Rakesh Bordia write about the four key stages of innovation that the 94 high-leverage innovators have in common.

Four Stages of Innovation
According to Jaruzelski, Dehoff, and Bordia, the four key stages of innovation are:

Ideation - Basic research and conception.
Project Selection - The decision to invest.
Product Development - Building the product or service.
Commercialization - Bringing the product or service to market and adapting it to customer demands.

High-Leverage Innovators
Jaruzelski, Dehoff, and Borida write:

"Based on press coverage and interviews with executives, we conclude that each of the 94 high-leverage innovators has built sufficiently strong capabilities in all four links of the value chain, and has seamlessly integrated them, to provide a high level of performance over time."

Key Take Aways
Here's my key take aways:

Use the frame to analyze improvement opportunities. I found this frame helpful for thinking about the end-to-end cycle for innovation. After all, what good are ideas if you can't bring them to market. A lot of ideas get stuck in the ideation stage.
Walk your innovation cycle. By walking your end-to-end system for bringing your ideas to end-users, you can find ways to reduce friction or find places to build synergies.
Optimize your system over a stage. Debottlenecking your end-to-end system is more effective than optimizing just a single stage.

My Related Posts

High-Leverage Strategies for Innovation

High-Leverage Strategies for Innovation

J.D. Meier — Mon, 25 Feb 2008 09:26:37 GMT

What are the high-leverage strategies that the leaders in innovation use? In "Smart Spenders, the Global Innovation 1000," an article in strategy+business magazine, Barry Jaruzelski, Kevin Dehoff, and Rakesh Bordia write about the successful strategies that the 94 high-leverage innovators use.

Example High-Leverage Strategies
Here's a sampling of the high leverage strategies:

Have systematic ideation processes, including involving senior management in the conception and definition of new ideas.
Have competence at all stages of your value chain.
Involve end-users in your innovation strategy. Spend a lot of time focusing on where they work, where they play, where they buy, and where they learn. This helps to increase your efficiency of your new product introductions.
Favor flatter and nimbler management structures that make the innovation process more transparent to your executive team.
Keep R&D costs down by keeping R&D focused and closely aligned with your business units. This allows you to target your R&D efforts to meet specific customer needs versus doing a great deal of early-stage, academic research.
Keep an internal innovation engine running efficiently through a core engineering team that designs and developers a variety of product lines (this helps provide common engineering and design as well as actual code reuse.)
Place greater value on economies of speed, scope and skill rather than simply economies of scale.
Look outside your organization for partners, suppliers and customers for new and innovative ideas.
Build capabilities along the innovation value chain to generate significant improvements in return on your research and development spending.
Pick the elements to generate a competitive advantage based on your industry, competition and internal capabilities.

Predictions for 2008

J.D. Meier — Wed, 02 Jan 2008 06:40:12 GMT

Here's a quick rundown of my take on key trends. Trends are different from fads since they're longer-lasting and more pervasive. I don't have a crystal ball or a magic 8-ball, but I have 20/20 hindsight with the customers I work with and an eye for patterns. Last year, I saw more virtualization, more agile/scrum adoption, and more distributed collaboration, as well as adoption of more social software practices in the Enterprise.

Key Trends
Here's a quick list of trends I'm paying attention to (some more pervasive than others) ...

More information overload. More ways to get lost, more ways to find what you need, more info at your finger-tips.
More focus on authority sites and authorities. Cut your info overload, by looking to people and sites you trust.
More focus on accuracy, relevancy, and timeliness. A must for social software.
More personalization / customization. One idea behind Guidance Explorer was to focus on personalization and customization.
More slicing and dicing of information. Tree-views, tag-clouds, Mind Maps, visuals. My tags, your tags, everybody's tags.
More engaging and conversational marketing over interrupt marketing. In-context, relevant, value add, and personal.
More focus on user experience. With too many choices, user experience wins. The apps that make you feel good, make you personally effective and connect with others win.
More globalization of software development. Any time, any place, anywhere, crowd sourcing, outsourcing, virtualization.
More social software in the Enterprise. Wikis, blogs, ...etc. More online consumer experience slides over to the Enterprise.
More Lean, Agile, and Scrum.
More virtualization. Virtual worlds, virtualized workspaces, Virtualized labs, virtualized hosting, virtualized workshops.
More distributed teams and remote collaboration.
More consolidation.
More specialization. When a market saturates, specialization happens. Lots more choices. Specialized devices and apps.
More Visual Studio Team System. This is The year for VSTS. With The Team Foundation Server Guide available and a new version of VSTS ... it's the year.
More Agile Security and Performance. I can help here. Most of the customers we worked with had flavors of agile practices, so we designed our techniques to be adaptable. For proven practices for security, see Security Engineering Explained.
More focus on personal development. Maybe you get what you focus on, but I see a trend here.
More principles, patterns, and practices.

Key Links for Predictions and Trends for 2008
Here's a few links I found useful:

Quick Tip
One quick tip for your trend studies -- knowing demographics helps and consumer trends tend to lead other markets so they're a good place to look. It also helps to understand the Four Stages of Market Maturity to help rationalize why you see what you see. The real value of trend watching though is anticipating and taking action, even if it just means being prepared versus surprised.

Human Shepherds and the Law of Relevancy

J.D. Meier — Sat, 10 Nov 2007 23:14:00 GMT

Yesterday, Ed helped me word a "law" that I use for important decisions and that I see show up quite a bit in a number of places. It's the law of human relevancy.

The Law of Relevancy
No matter how relevant the information is, it's more relevant with the help of the right people.

The Human Shepherd
All this law really means is that no matter how well you organize and display information, at some point, there's a glass ceiling on how much easier you can make it for somebody to find what they need. There's always a place for the human shepherd.

Usage / Examples

The obvious example is the Web 2.0 movement -- where people are the shepherds of the read/write Web. There's lots of needles in the world wide haystack and I'm glad there's people, voices, blogs there to help.
I like the pattern on the Web where sites have a live chat to use a human to help you match their info to your needs, in real time.
I like how Second Life provides the ability to "invoke a human" over just self-help and forums. (I proposed some models for "human help" in Visual Studio and as a general platform some time back I need to revisit)
There's lots of implications for an Enterprise 2.0 world, but I'll save that for another day.

A Story
In an early version of Practices Checker (a tool meant to verify your solutions against patterns & practices recommendations), we tried to figure out relevant guidance based on the type of project (Web, winForm ...), what technologies (ADO.NET, ASMX ...) you were using, ... etc. We did this automatically and generated what I considered more harm than help (it missed things that were important and created a lot of noise.) I applied the law of relevancy and argued that we'd be better off figuring out how to leverage the user's own relevancy engine and pattern-matching ability over auto-magic guesswork. We then created a tool to help smart people, rather than a "smart" tool that gets in the way.

Scenarios in Practice

J.D. Meier — Mon, 15 Oct 2007 05:21:00 GMT

Scenarios are a practical way to organize and focus your product design, development and release. (We use scenario-driven engineering in patterns & practices)

Key Benefits

Business value. You can use scenarios to evaluate business value. What pain does that scenario address? ... What opportunity does it create? ... etc.
Chunking and prioritizing. You can use scenarios to chunk up and prioritize your product. You can think of versioning in terms of releasing incremental value or scenarios.
Effective design. Walking through a set of customers scenarios and "what ifs" will help you figure out your product's most effective design. It's not a silver-bullet, but it does help make requirements more concrete, or at least put them in perspective. It also opens the door to more precise questions about user experience or engineering challenges..
Focal point for perspectives. You can use scenarios as a focal point for user experience, business and tech perspectives.
Requirements in context. You can use scenarios to put requirements in context. A requirement makes a lot more sense when you see it in action.
Architectural trade-offs. You can use scenarios to evaluate and make architectural trade-offs. You can't evaluate an architecture in a vacuum; you can evaluate against concrete scenarios. There's several flavors of scenario-based evaluations you can leverage.
Customer value. Your customers can appreciate how well you did (or didn't) address their scenario.
Tests for success. You can use scenarios as tests for success. By measuring customer effectiveness against specific scenarios, you have a way to focus your improvements.

Chunking Up a Project Using Scenarios
If you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals. What's the minimum set of tasks your user needs to perform with your product? That's your baseline release. What's the incremental value from there? That's how you start to shape your versions and releases.

User Experience, Business and Technical Perspectives
Using scenarios is a good forcing function to bring together the user experience, business, and technical perspectives. For the sake of example, let's say your scenario is "User views the product catalog." From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait," From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership." From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc. Well, no wonder getting software right is tough! Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.

Constraints Make More Sense In Context
Constraints are boundaries to operate within, or what the solution must or must not do. In software, I see a lot of generic constraints passed down as policies. When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint. You can also measure whether that scenario is actually meeting the constraint. You can perform scenario-based testing against a set of scenarios with specific constraints.

Walking the Scenarios
Have you ever been sold on a great set of features, only to fall flat when you try to actually do something useful? Obviously, that's the extreme case, but it happens to me. It happens less now because whenever I go to buy something, I walk my usage scenarios. Doing a dry run against a scenario is very revealing. This approach works great on the engineering side too. It's one thing to have generic technical requirements for security or performance. It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective. Suddenly, generic technical requirements no longer seem as helpful, do they? They still have their place, but when you're engineering your job is to make the right trade-offs.

Scenarios and Solutions
Given part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation. As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.

More Information

My Related Posts

Task-Analysis Grid for Communicating Product Design

J.D. Meier — Fri, 09 Feb 2007 23:16:00 GMT

How do you communicate design decisions? … Srinath sent me a helpful link on the Task-Analysis Grid. A Task Analysis Grid is effectively columns of scenarios along with sub-tasks to complete the task.

Here's the key points:

The columns are organized by Before, After, and Future
The sub-tasks are prioritized and color coded.

In practice, I think the Task-Analysis Grid is useful for communicating user experiences and high-level product design. For driving engineering and project management, I use Scenario Grids. Scenario Grids are useful for figuring out baseline releases, incremental releases, dependencies, as well as doing scenario-based evaluations and competitive assessments. I'll post more on building Scenario Grids another day.

What Are You Optimizing

J.D. Meier — Fri, 02 Feb 2007 09:40:00 GMT

This is such a fundamental question. It has an enormous impact on your product design and how you structure your product life cycle.

For example, are you optimizing time? ... money? ... impact? ... innovation? ... resource utilization? If you don't answer this question first, it's very easy to pick the wrong hammer for your screws.

A few things I use to help me figure out what to optimize are I figure out my objectives, I figure out my constraints, and I look for my possible high ROI paths. I always want more out of what I do. The trick is to know when doing more, gets you less. Your objectives keep you grounded along the way.

What I like about this question is it universally applies to any activity you do, including how you design your day. Are you optimizing around results, or connecting with people? Are you optimizing for enjoyment along the way or for reward in the end?

User Experience, Tech Feasibility and Business Value

J.D. Meier — Wed, 06 Dec 2006 12:44:00 GMT

I found a way to explore more and churn less on incubation (i.e. R&D) projects. It helps to think of your project experiments and key risks in terms of these three categories and in this order:
1. user experience
2. technical feasibility
3. business value

Sequence matters. If you don't get the user experience right first, who cares if it's technically feasible? Once you get the user experience right, meaning customers get value, the business value will follow.

Here's how I learned this the hard way ...

My project was time-boxed and budget constrained. To keep our stakeholders happy, my strategy was to deliver incremental value. This translated to short ship cycles to test with customers. We used a rhythm of shipping every two weeks. This let us track whether we were trending towards or away from the right solutions.

While this was a relatively short feedback cycle, it wasn't actually efficient. Most of our prototyping was around exploring user experiences, although we didn't know this at the time. We were focused on shipping prioritized customer scenarios and features. Delivering these scenarios and features, mixed exploring user experience, tech feasibility and business value. It's not a bad mix -- it just wasn't the most efficient.

Necessity is the mother of invention. When we weren't "learning' at the pace we expected, we had to find a better way. We moved to rapid prototyping user experience with slideware and walkthroughs. This meant faster feedback and less do-overs than our software prototypes. It also meant, in our software prototypes, we would consciously and explicitly focus on technical feasibility

User experience was the real challenge and the most value. Spending a week to build a software prototype to test technical feasibility and identify engineering risks makes sense. Spending a week to build a software prototype to test user experience, sucks. In other words, what previously took a week or more to build out and test (the user experience), we could now do in a few hours.

In hindsight, it's easy to see that incubation was about user experience, tech feasibility and business value, even though I didn't realize it at the time. It's also easy to see now that the dominant challenge was usually user experience.

The moral of the story isn't that you can use slideware for all your user experience testing. Instead, the lesson I would pass along is be aware of whether you are really testing user experience, tech feasibility or business value. By knowing which category you're exploring, you can then pick the right approach.

Be the Software

J.D. Meier — Fri, 01 Dec 2006 11:01:00 GMT

When you're working on an R&D project, how do you shorten the cycles around testing your user experience models?
... Be the Software

That's the advise John Socha-Leialoha, father of Norton Commander, gave me and it worked like a champ.

We faced a lot of user experience design issues early in our R&D project. For example ....

how to filter a large picklist of items
how to optimize views based on type of item
how to integrate social software features (tagging, rating, ...)

Initially, we did a bunch of whiteboard modeling, talk-throughs, and prototyping. The problem was the prototypes weren't efficient. I had a distributed team so it was tough to paint a good picture of the prototype, even when we all agreed to the scenarios and requirements. The other problem was customer reviews were tough because it was easy to rat-hole or get distracted by partial implementations. The worst case was when we would finish a prototype and it would be a do-over.

We experimented with two techniques:

Build modular slideware for visual walkthroughs of task-based features.
Be the software.

This radically improved customer verification of the user experience and kept our dev team building out the right experience.

Mocking up in slides is nothing new. The trick was making it efficient and effective:

We prioritized scenarios that were the most risk for user experience.
We created modular slide decks. Each deck focused on exactly one scenario-based task (and scenarios were outcome based). Modular slide decks are easier to build, review and update. Our average deck was around six slides.
Each slide in a deck was a single step in the task from the user's perspective.
Each slide had a visual mock up of what the user would see
To paint some of the bigger stories, we did larger wrapper decks, but only after getting the more fine-grained scenarios right. Our house was made of stone instead of straw. In practice, I see a lot of beautiful end-to-end scenarios decks that are too big, too fragile and too make believe.

For example, here's the slide list for one deck:

scenario - User subscribes to a guidance feed
summary of steps (flat list of the steps)
Step 1. user finds a relevant item
Step 2. user subscribes to view
Step 3. user displays view in RSS reader

What originally took a week to prototype, we could mock up in an hour if not minutes. Do-overs were no longer a problem. In fact, mocking up alternate solutions was a breeze. The beauty was we could keep our release rhythm of every two weeks, while we explored solution paths in the background, with less disruption to the dev team.

The other beauty was we could use the same deck to walkthrough with customers and the dev team. The customers would bang on the user experience. The developers would bang on the technical feasibility. For example, show a catalog to customers and they evaluated the the best way to browse and filter. Sow the same screen to the devs and they would evalute the performance of the catalog. We would also brainstorm the "what-ifs", such as how will the catalog perform when there's a billion items in it ... etc. We got better at teasing out the key risks before we hit them.

Building the software became more an exercise of instantiating the user experience versus leaving too much to be made up on the fly.

To "be the software", it's as simple as letting the user walk through the user experience of performing that task (via the slides), and, as John put it, "you be the software ... you simply state how the software would respond." If slides are too heavy, draw on paper or use a whiteboard. The outcome is the user gets a good sense of what it's like to use your solution, while you get a sense of the user's more specific needs. The interactive approach produces way more benefits than a simple spec review or 1/2-baked prototype.