Juice Analytics

In my previous post, I mused on the subject of edge cases and the learning opportunity they provide. I want to touch on how this applies to customer analytics.

This weekend I read a blurb in the Washington Post Food section. A customer by the name of Anne Monahan complained about the “dark blue menus printed in black ink” at a local restaurant. “In dim light, the menus were nearly impossible to read,” she remarked. The restaurant co-owner said that she hadn’t noticed the problem before, and vowed to change the hue of the menus the next day.

It would be easy to dismiss Ms. Monahan as an outlier and a whiner. After all, this complaint was rare. An edge case. But the restaurateur decided to respond to the issue. Perhaps other patrons were bothered by it, but hadn’t commented.

This is not to say that companies should be a slave to the edge case. But don’t throw them out. Listen to what they have to say and be willing to respond, because:

• They may be the canary in the mindshaft — telling you something that others haven’t yet realized

• They may be an extreme case of common behavior that shows up more subtly amongst other customers. Recognizing this behavior can only help you better meet customer needs in the future.

• They may offer new ways to think about the business or customers. As I said in my last post, edge cases help define the boundaries of reality.

• Collectively, outlier customers provide a service: they stress test the product and highlight unrealized strengths or weaknesses.

Of course, there is also much to learn from the ordinary cases — the mainstream customers. I think most companies already understand the ordinary. In fact, the ordinary is already deeply embedded in the business’ assumptions.

Most statistical analysis tells you: watch out for outliers. They are the data points that can screw up your averages. Because of their rarity, they aren’t deemed worth focusing on. I disagree.

I hope to return to this topic as we find ways to apply it at our clients.

In his article Eyes Bigger Than Stomachs: Data Glut , Jim Meskauskas observes that there is “a frenzied gathering of bits, collecting any and all manner of jetsam and flotsam. There is a subconscious belief that the marketer will know what it is that they are looking for once they find it.“

He recognizes that more data isn’t better. In fact, it can be worse. Vast expanses of data have a way of lulling organizations into a false sense of security. It is easy to believe that the answer to virtually any business question will be available because all available data has been collected.

This reminds me of a data gathering process I recently observed for a software release. I watched (and participated) as the organization collected more than 160 “reporting requirements” through brainstorming by a wide-range of stakeholders.

The repurcussions of this massive list aren’t good:

1. Reporting requirements are often the first things to get dropped as software development schedules get tight. With little prioritization, these requirements get dropped in a relatively random order.
2. No one was challenged to ask: what are the truly important measures of success? The assumption was that somewhere in these 160 data elements, the answer would be found at some later date. But is there any guarantee? The organization has an illusion of future flexibility. In truth, the resources necessary to manage the sheer bulk of data gathered reduces flexibility.

I couldn’t agree more when Jim says says: “you’ve got to have a thesis around which your experiments are structured or you don’t discover anything because you don’t know what you are out to discover.“

You know that slide in a presentation that makes you wonder: what am I supposed to be getting from this page? Am I missing something? Why are my eyes hurting?

Here’s my take at a top 10 list of slide writing mistakes:

10. Poor labeling — lack of titles, units, sourcing

9. Long lists — most people can’t absorb lists that are longer than 5 items

8. Stock clip art — “screen beans” are particularly played out

7. Too many arguments — one argument per slide, don’t be afraid to break into multiple slides if necessary

6. Repetition of the argument — people sometimes feel they need to hammer a point home with various different attempts to say the same thing. Have faith in our audience

5. Errors — the smallest errors can undermine an otherwise strong argument

4. Distracting aesthetics — too much color, too many picture or graphics, confusing or cluttered layout

3. Too many words or excessive detail — your audience is looking for the high points

2. No point — a purely descriptive chart or table. The first responsibility of a slide author is to make an argument

1. No evidence — the author’s second responsibility is to support that argument with some objective data

Any others?

Have you ever seen that movie scene where the wizened old cowboy tames the impossibly wild stallion? The wise frontiersman takes his time, careful not to frighten the horse, and gradually shows it what he expects. He uses a soft voice and doesn’t ask too much at first. Once he has established trust, it isn’t long before he hops on the stallion and lets it do what it wants to do naturally: gallop into the sunset.

There is a metrics lesson in this scene.

If you have successfully defined and tracked a few critical metrics for your business, you’ve made admirable progress towards life as a metrics-driven organizations. However, without specific goals for these metrics, you can’t create the optimum focus and accountability. You’ve got your peanut butter, but no chocolate…

Don’t be daunted by the task of getting executives to agree on target levels of performance. It will come naturally if you approach the problem with patience.

First, invest the time and energy to socialize your success metrics. The challenge is to offer a clear definition of what is being measured and demonstrate its importance. Do not initiate discussions about goals at this point. You will probably be dealing with a jittery cast of characters—no sudden movements or loud noises.

Second, introduce the success metrics into periodic meetings and other venues. You want these metrics to become part of the organizational vernacular. Again, have patience in getting people accustomed to the metrics and their implications about the business

Now here is the wonderous part: having built a foundation of awareness and understanding, you can reasonably expect people to start coming to you wondering why there aren’t goals associated with the success metrics. In all likelihood, they’ll ask this question as if you hadn’t thought of the concept. Resist temptation and let it be their idea.

Soon you will be conducting meetings to define reasonable yet aggressive goals for your metrics.

Seth Godin identifies a common problem of large organizations in The Myth of the CMO. “They don’t get to be the chief of the stuff that is really what marketing is all about today,” he says. CMO is just one example of a situation where a functional owner doesn’t get to influence all the factors that matter to their success.

To some extent, this is an inevitable issue. There is an undeniable logic and efficiency in building an organization along functional dimensions. The entire customer experience (i.e. acquisition, product experience, customer service, etc.) only comes together at the CEO.

In our opinion, one way to address Seth’s concern is through customer-centric metrics. Most companies make the mistake of evaluate performance along functional activities. This perpetuates the silos that don’t allow Judy Verses, Verizon’s CMO (in Seth’s example) to influence the call center. Marketing becomes focused on driving revenue. Operations focuses on driving down costs. Product development is a success if new features appear on time. The externalities for these incentives are obvious: Marketing brings in customers who have low life-time value; Operations squeezes customer service costs at the cost of satisfaction; Product Development doesn’t bother to deliver the features that will help marketing bring in new customers.

One alternative is to define success metrics that cross the organizational structure and put customer experiences or processes at the forefront. Happy and high-value customers are at the center of your businesses success—but require multiple functions to work together. A commonly accepted metric with strong CEO support and real accountability can be a catalyst to get these groups working together.

James Governor draws a nice analogy between learning how to cook and learning to rely on your staff to develop and implement IT infrastructure. In either case, you can get pre-packaged solutions. But these solutions won’t solve long-term needs.

Next time a vendor pitches you a “solution” ask yourself what are they afraid of? Is this science or an illusion of science? And if you choose this “organic IT solution” what are you missing out on? What nourishment? What experience? What set of skills that you can apply in other areas?

I think he’s exactly on point about the slippery simplicity of buying comprehensive solutions. Naturally, this also applies to analytics solutions (like an Cognos or Business Objects implementation), instead of developing capability in-house.

It’s better to teach a man to fish than to give him a fish. And it’s better to know the data and how to manipulate that data, than to learn a “solution”. It’s better to concentrate on solving your concrete problems than to implement a solution that solves all problems.

There are wonderful, cheap tools available now. The dynamic languages: Perl, Python, Ruby. JMP. Even something as simple as Excel with our DTP framework can do powerful things. At Juice, we’re learning ways to cook up concrete solutions out of cheap componentry and teach them to your staff so that the next time a need arises, your staff can cook for themselves.

We met with a prospective client today—the meeting went very well.

This client, a former consultant, first asked us: “so what am I buying here; what’s your methodology”. Crafting and intellectually protecting a “methodology” is how consultants mass market what is essentially a one-to-one service. Methodology is a shield and a sword that allows an inexperienced MBA to go into a situation and start hacking and slashing.

We feel that it is better to have principles and experience. Two things, admittedly, that we are continuing to develop.

No, we don’t have a methodology yet. But we know in our gut that there is value in a light approach to analytics. We seen too many hours and too much talent wasted on analysis of the wrong problem. We know of frustration among business leaders because their business simply does not know what’s going on. We’ve seen the waste caused addressing the wrong questions. We’ve felt the loss of repetitive grunt-work. And we’re excited to show the world something different.

But this methodology; our approach as we learn it and craft it in the field is not a secret. Like RedMonk’s business principles, or the Agile software manifesto, we strive to openly recognize those who have helped us and the projects from which we draw our inspiration.

Sometimes, for reporting or exploration, you need to create tens to thousands of identical charts in Excel. The best way to do this is to have a single chart, and repeatedly change the data that’s underneath the chart.

We’ll be showing you some powerful techniques for doing this in upcoming weeks, but today we want to get started by showing how to dynamically change graph titles as the underlying data changes.

Dynamic Chart Titles in Excel Screencast

You need analytics in your organization:

• to help you make a decision
• to understand what your customers are doing. If your understanding is correct and deep then you will be able to come up with appropriate new ideas.
• to identify sudden trends which may indicate a process failure or shift in the market

We will be posting over the next week on how the practice of analytics today shortchanges these bottom-line needs and how some of these shortcomings can be addressed.

We are very pleased to announce our presentation development guide. It’s 20 pages long and will help you create compelling, well-structured presentations.

Get it here.