It’s World Statistics Day! To honor the theme of the day, the JMP User Community is having conversations about the importance of trust in statistics and data. And we want to hear from you! Tell us the steps you take to ensure that your data is trustworthy.
Choose Language Hide Translation Bar
Michael Schrage on experimentation, innovation & communicating analytic results

michael-schrageWe are delighted that Michael Schrage, Research Fellow at MIT Sloan School of Management’s Center for Digital Business, will be a keynote speaker at Discovery Summit 2014. I first encountered Michael when he skillfully moderated an Analytics Exchange Panel at the 2009 conference.

Earlier this year, Michael was the featured expert in an Analytically Speaking webcast. We spent extra time together thanks to the wintry weather in North Carolina! That enabled us to have some interesting conversations, and I'm pleased to share more of his perspective on some important topics: experimentation, innovation and communication of analytic results.

Why don't organizations do more (good) experimentation?

Michael: This is a deceptively difficult question. I see many organizations perform "tests" rather than experiments. The web has inspired a whole new generation of A/B tests and testing. You certainly see technical/engineering folks use Taguchi and Box/Fisher "design of experiments" statistical methodologies. But, no, I really don't run across that many organizations or innovation teams culturally committed to "experimentation" as central to how they learn, iteratively design or manage risk. I fear that DOE has turned itself into a "black box" for technical quants rather than a platform for "new value creation" and exploration by entrepreneurs and innovators.

But why? My empirically anecdotal answer would be that most business people think in terms of "ideas" and "plans" and "programs" rather than in terms of "testable hypotheses" and "experiments." Experimentation is for geeks, nerds and quants — not business management and leaders. Designing business experiments is what we delegate, not celebrate or see as strategic. A second reason that I've seen surface when organizations resist the fast, cheap and simple "experiments" option is that experimentation doesn't "solve the problem." It only gives insight. A lot of people in management are much more interested in paying for "three-quarter" solutions — or even half-baked ones — than genuine insights. In other words, they see the products of experiment as more interesting than compelling. Of course, when one sees the digital successes of the Googles, Amazons and Netflixs in using experiments to innovate, as well as optimize, you have to wonder just how much of this resistance reflects generational dysfunction, not simple ignorance.

You've said there is a tension between incremental and disruptive innovation. What are your observations on organizational cultures that foster both kinds of innovation?

Michael: Well, almost by definition, "incremental" is likelier to be easier and less disruptive than "disruptive" innovation. Remember, I'm not a fan of "innovation" for innovation's sake; I believe innovation is means to an end, and we want to make sure we understand and agree about which aspects of that desired "end" are tactical versus strategic. We need to have the courage and honesty to confront the possibility that "disruptive" innovations will be better for our customers, clients and us in the nearer or longer term. We need to be confident that our disruptive innovations will advantage us with our customers while concurrently disadvantaging our competitors. Culturally speaking, companies that are proud to the point of arrogance about their technical skills and competences tend to be understandably reluctant about truly "disruptive" innovation because it disrupts their sense of themselves and what they think they're good at. Organizations more focused on UX, customer service, client relationships and a broader/bigger "mission" seem more culturally comfortable with disruption because it is a means to a greater end rather than just an opportunistic tactic.

You've said sometimes we need to look for approaches versus solutions. Can you relate that to JMP?

Yes, I've largely gotten out of the "solutions business" both in my teaching and advisory work. Almost everyone I work with is pretty smart, so my focus now is less on the transmission of my expertise than on the cultivation of their capabilities. I want my students and clients to be able to embrace, understand, and exploit a new power and capability that lets them find and customize the solutions they want. I am not there to "solve their problems." I'm there to facilitate how they choose to bring both existing and new capabilities to bear on solving problems in the ways that are culturally and economically compatible with their needs, not my expertise and "experience." How does that relate to JMP? That's easy — I've been a part of the JMP community long enough to know that your best customers and users come up with novel and compelling ways to get value from your products. You learn as much from them as they from you. I'm comfortable arguing that mutual/collaborative learning is more about an "approach" than a "solution."

Share with us the importance of communicating analysis results to executives.

That importance can't be overstated, but the heuristic I look forward to offering and discussing is that the purpose of communicating analytical results should not be to make executives feel stupid or ignorant but to make them feel smarter and more engaged. If all your communications do is fairly and accurately convey useful results in an accessible way, you're underperforming.

We hope you will bring your own questions to ask Michael live in September. If you’ve never attended Discovery Summit, perhaps it’s time for you to experiment with a new conference unlike any other.

Note: This is the second blog post in a series on keynote speakers at Discovery Summit 2014. The first post was about David Hand.

Article Labels

    There are no labels assigned to this post.