Saturday, October 6, 2012

To Succeed with Big Data, Start Small

While it isn't hard to argue the value of analyzing big data, it is intimidating to figure out what to do first. There are many unknowns when working with data that your organization has never used before — the streams of unstructured information from the web, for example. Which elements of the data hold value? What are the most important metrics the data can generate? What quality issues exist? As a result of these unknowns, the costs and time required to achieve success can be hard to estimate.

As an organization gains experience with specific types of data, certain issues will fade, but there will always be another new data source with the same unknowns waiting in the wings. The key to success is to start small. It's a lower-risk way to see what big data can do for your firm and to test your firm's readiness to use it.

The Traditional Way

In most organizations, big data projects get their start when an executive becomes convinced that the company is missing out on opportunities in data. Perhaps it's the CMO looking to glean new insight into customer behavior from web data, for example. That conviction leads to an exhaustive and time-consuming process by which the CMO's team might work with the CIO's team to specify and scope the precise insights to be pursued and the associated analytics to get them.

Next, the organization launches a major IT project. The CIO's team designs and implements complex processes to capture all the raw web data needed and transform it into usable (structured) information that can then be analyzed.

Once analytic professionals start using the data, they'll find problems with the approach. This triggers another iteration of the IT project. Repeat a few times and everyone will be pulling their hair out and questioning why they ever decided to try to analyze the web data in the first place. This is a scenario I have seen play out many times in many organizations.

A Better Approach

The process I just described doesn't work for big data initiatives because it's designed for cases where all the facts are known, all the risks are identified, and all steps are clear — exactly what you won't find with a big data initiative. After all, you're applying a new data source to new problems in a new way.

Again, my best advice is to start small. First, define a few relatively simple analytics that won't take much time or data to run. For example, an online retailer might start by identifying what products each customer viewed so that the company can send a follow-up offer if they don't purchase. A few intuitive examples like this allow the organization to see what the data can do. More importantly, this approach yields results that are easy to test to see what type of lift the analytics provide.

Next, instead of setting up formal processes to capture, process, and analyze all of the data all of the time, capture some of the data in a one-off fashion. Perhaps a month's worth for one division for a certain subset of products. If you capture only the data you need to perform the test, you'll find the initial data volume easier to manage and you won't muddy the water with a bunch of other data — a problem that plagues many big data initiatives.

At this point, it is time to turn analytic professionals loose on the data. Remember: they're used to dealing with raw data in an unfriendly format. They can zero in on what they need and ignore the rest. They can create test and control groups to whom they can send the follow-up offers, and then they can help analyze the results. During this process, they'll also learn an awful lot about the data and how to make use of it. This kind of targeted prototyping is invaluable when it comes to identifying trouble and firming up a broader effort.

Successful prototypes also make it far easier to get the support required for the larger effort. Best of all, the full effort will now be less risky because the data is better understood and the value is already partially proven. It's also worthwhile to learn that the initial analytics aren't as valuable as hoped. It tells you to focus effort elsewhere before you've wasted many months and a lot of money.

Pursuing big data with small, targeted steps can actually be the fastest, least expensive, and most effective way to go. It enables an organization to prove there's value in major investment before making it and to understand better how to make a big data program pay off for the long term.


  • Get Started With Big Data: Tie Strategy to Performance
  • What If Google Had a Hedge Fund?
  • Can You Live Without a Data Scientist?
  • How to Repair Your Data
  • More >>

    Successful prototypes is certainly the key with a small but reasonable sample size.

    How to Present to Senior Executives

    Senior executives are one of the toughest crowds you'll face as a presenter. They're incredibly impatient because their schedules are jam-packed — and they have to make lots of high-stakes decisions, often with little time to weigh options. So they won't sit still for a long presentation with a big reveal at the end. They'll just interrupt you before you finish your shtick.

    It can be frustrating. You probably have a lot to say to them, and this might be your only shot to say it. But if you want them to hear you at all, get to what they care about right away so they can make their decisions more efficiently. Having presented to top executives in many fields — from jet engines to search engines — I've learned the hard way that if you ramble in front of them, you'll get a look that says, "Are you kidding me? You really think I have the time to care about that?" So quickly and clearly present information that's important to them, ask for questions, and then be done. If your spiel is short and insightful, you'll get their ear again.

    Here's how you can earn their attention and support:

    Summarize up front: Say you're given 30 minutes to present. When creating your intro, pretend your whole slot got cut to 5 minutes. This will force you to lead with all the information your audience really cares about — high-level findings, conclusions, recommendations, a call to action. State those points clearly and succinctly right at the start, and then move on to supporting data, subtleties, and material that's peripherally relevant.

    Set expectations: Let the audience know you'll spend the first few minutes presenting your summary and the rest of the time on discussion. Even the most impatient executives will be more likely to let you get through your main points uninterrupted if they know they'll soon get to ask questions.

    Create summary slides: When making your slide deck, place a short overview of key points at the front; the rest of your slides should serve as an appendix. Follow the 10% rule: If your appendix is 50 slides, create 5 summary slides, and so on. After you present the summary, let the group drive the conversation, and refer to appendix slides as relevant questions and comments come up. Often, executives will want to go deeper into certain points that will aid in their decision making. If they do, quickly pull up the slides that speak to those points.

    Give them what they asked for: If you were invited to give an update about the flooding of your company's manufacturing plant in Indonesia, do so before covering anything else. This time-pressed group of senior managers invited you to speak because they felt you could supply a missing piece of information. So answer that specific request directly and quickly.

    Rehearse: Before presenting, run your talk and your slides by a colleague who will serve as an honest coach. Try to find someone who's had success getting ideas adopted at the executive level. Ask for pointed feedback: Is your message coming through clearly and quickly? Do your summary slides boil everything down into skimmable key insights? Are you missing anything your audience is likely to expect?

    Sounds like a lot of work? It is, but presenting to an executive team is a great honor and can open tremendous doors. If you nail this, people with a lot of influence will become strong advocates for your ideas.

    This is the first post in Nancy Duarte's blog series on creating and delivering presentations, based on tips from her new book, the HBR Guide to Persuasive Presentations (October 2012).

    A skill that is highly needed in nowadays challenging business.

    Monday, October 1, 2012

    Are Entrepreneurs Really More Comfortable with Risk?

    Most people think entrepreneurs are willing to take on more risk than the average person. I've often wondered if that's really true. After almost three decades of working with large corporations and entrepreneurs, I've developed a theory. Now, this theory hasn't been vetted with controlled experiments and testing. It is based solely on experiential and intuitive data drawn from my life experiences. For instance, I have 12 years of working with entrepreneurs as an early-stage venture capitalist; 19 years working for a large corporation (Bell Labs & AT&T) and consulting to their multi-national, multi-billion dollar customers; 10 years of mentoring entrepreneurs; and created a carve-out start-up within AT&T.

    Here's my theory: most entrepreneurs aren't more risk-o-philic than anyone else — they just define risk differently.

    For some I've known, the risk of losing autonomy and control of one's "destiny" was far riskier than losing "guaranteed" income and benefits. Working for someone else's company, reporting to a boss, and living under rules they weren't sure made sense were a lot riskier than creating their own business. The risk of not pursuing their passion, of not making a meaningful and significant impact on the world around them, feels much riskier than starting their own venture.

    For them, risk isn't as defined by losing tangibles (e.g., income, benefits, "stuff") as it is by losing intangibles: fulfilling a passion that won't let go, defining their own sense of purpose, sating their own curiosity, looking themselves in the mirror.

    The difference here is between risking outputs and outcomes. Outputs (such as products, profits, etc) are necessary and good, but they have their most profound effect when driving significant, palpable outcomes — like reducing chronic pain, creating a prosthetic leg for an Olympic runner, or inventing an app that eliminates a time-consuming task. Most of the entrepreneurs I've worked with would gladly risk a few outputs for an outcome they believe in.

    For many entrepreneurs, another critical risk worth taking is making themselves vulnerable in order achieve the outcomes they envision. As John Hagel has said, the risk of embarrassment, ridicule, skepticism, perhaps even humiliation is much less than the risk of not putting oneself out there to try. Anthony Tjan astutely summarized it this way: "The willingness to be vulnerable isn't driven by the desire for exposure, but by the possibility of what that exposure might lead to — be it a meaningful role, the possibility to affect change, and, of course, greater financial gain."

    I've seen, heard, and felt so many entrepreneurs' intense passion and purpose for the outcomes they want to create. It is what defines who they are and why they're here. I know that risk-reward equation. While food, shelter, education, and health matter a lot, I need to see outcomes when I look my children, husband, friends and clients in the eye, not just outputs. If I don't see a positive, wonderful impact on their lives and the lives they are responsible for and encounter, then my life was just a series of outputs — maybe even large ones — but not outcomes; and I will have failed tragically.

    While this is a theory ripe for a more scientific validation, I'm pretty confident it will prove out, at least in some great part. The risk of not pursuing that passion, of not fulfilling that purpose, of having lived a life of stuff without also living a life of significance, is the greatest risk of all.

    They are more willing to take the risk to the level where cooperates aren't willing to go and could be yes, because they define risk differently as the article says.