Go Beyond Solving Specific Problems. Create Capability.
by Hobart Swan
In Part 1 of our discussion with Ross Brown (“Say Hello to Channel Data Management and Goodbye to Gut Instinct”), Channel Management Insights asked Brown about the key practices behind good channel data analysis. One of the best practices, Brown said, is not to rely on one source of data (companies often rely solely on POS data) but to “integrate everything you can.” In this issue, we delve into the next step of creating the right data model, once you have identified key channel data sets. The trick, Brown says, is to develop a single model that correlates all of your data sets to give you the most accurate, useful insights into your channel business.
Brown is Senior Principal at The Spur Group, a Seattle-based consultancy that specializes in developing partner programs for Microsoft and Dell, managing messaging and partner conferences for Cisco and Juniper Networks, and providing recruitment insight and strategies for Autodesk and VMware. Formerly Vice President of Worldwide Partner Strategy at Microsoft, Brown has held leadership roles at Citrix, IBM, eEye Digital Security, and worked with more than 50 technology firms in a consulting capacity. In the process, he has become a leading expert on channel data management (CDM).
We touched very briefly on this at the end of the first article. Tell me more about what you see as the most common, real-life ways channel teams approach channel data management.
This is where I separate what I consider very senior-level practices from the beginner level.
It boils down to what I call the “app” model versus the “process” model. Someone using the app model says, “Okay, I’m responsible for partner marketing and need an application that allows me to do prior approvals and MDF allocations.”
Let’s say a partner wants to spend $8,000 in MDF funds to do customer seminars in three cities and expects $X in return. A beginner might take the app model approach that says, “I have a metric I have to hit, so I need an app that drives my functions to achieve my goal.” These apps are perfectly reasonable. They’re the right tools to do those jobs. But this is a beginner approach because it is based on meeting the specific needs of individuals.
A more senior process view looks at data structures differently—considering the entire marketing process from lead to close. The process model asks, “How do we track a customer that engages with us through a partner marketing activity all the way through their quote configuration to POL to delivery?”
If I’m building an app-oriented data model to manage MDF, the basic unit of thought is a marketing event. With a process-oriented model, the basic unit of thought is a customer engagement. The process approach creates a more relevant data set than simply capturing the results of one event in one city.
So it really comes down to thinking differently about the basic unit of data you’re tracking.
Right. The real data is the total cost of marketing into this customer across all the engagements they responded to. This kind of data can help you get to an efficiency metric, which can be a very valuable thing. The app model gives you incidental information that a customer went to an $8,000 marketing event.
For a typical channel leader at a major channel vendor, how realistic is it to expect them to be able to connect all these data points—given the restraints on budget, time, and IT resources? And is it worth it to try to do that? At what point do you hit diminishing returns?
Well, it all starts with creating a partner master record that pivots all the engagements that partner has participated in. Instead of seeing the partner as just another type of customer, you see them as their own entity, enabled by those many-to-many relationships.
That still sounds pretty overwhelming.
You don’t necessarily have to solve the huge “what’s every possible connection” question. You just start with the core elements—your products, customers, and partners—and make sure you’ve got clean data on all three.
Working in the indirect channel is complicated. But you can simplify it and start to deliver value just by looking at very simple connections. When managing clean data generated from simple connections, you can gain enough insight to be able to say, “The only way I’m going to give a partner incentives or MDF funds is if there’s a prior approval or a claim form that correlates back to that partner master record.”
To make this statement, your master record must contain information about what the partner’s intent is by product family. That way, you’ll have some idea of how sales in that family correlate back to results and point-of-sale by product.
And fundamentally, it requires that the partner organization shifts from the app view (I need this app to solve this problem) to the process view (here’s how we’re going to manage data). And that can be a challenge. From my experience, one of the challenges in creating process-oriented data models is that most channel practitioners don’t have deep data skills and most people with deep data skills don’t understand the channel. That’s why one of the big parts of The Spur Group’s business is helping companies connect these two competencies.
The Spur Group helps bridge that gap with its “Four Best Practices in Channel Analysis.” Can you talk about these best practices?
The first best practice is something we’ve already talked about: integrate everything you can. This is the idea of not relying solely on POS data—that the more relevant data sets you can look at, the better your analysis will be.
The second best practice is to get as close to the data source as you can. If you’re going to look at pipeline, get the data directly from your CRM tool. Don’t try to pull it from a PRM system that’s pulling from the CRM system. Build your primary data structures from your primary data source.
The third best practice is to remember that time is the most important dimension. Snapshots are interesting, but you need to look at trends over time. Just because someone is your biggest partner in December, doesn’t mean they are your biggest annual partner.
The fourth best practice is not to mistake correlation for causation. If one action causes another, then they are most certainly correlated. But just because two things occur together does not mean that one caused the other, even if it seems to make sense.
Let’s move from best practices to what you are starting to see in the channel. What are your top three next-gen approaches to channel data management?
The first approach is this idea of not devaluing point-of-sales data, but using it in concert with other data sets.
The second next-gen approach has to do with looking at incentives, especially incentives that require pre-registration—whether that’s looking at MDF dollars and how they’re being used, or at deal registration.
The third approach has to do with investments in social influence media. As I said earlier, the problem with this kind of data (Facebook likes, Twitter traffic, etc.) is that it doesn’t provide insight into what partners are doing with their daily time. So while social media data collection is cutting edge, we prefer to look at the information partners put on their own web sites. We think that provides much more useful data.
I’d like to end this part of the discussion by getting your thoughts on why implementing good channel data management practices seems to be such a struggle. Is it because it’s hard to get the IT resources you need to make it happen?
It’s not even an IT thing. I think the real problem is mental capacity and fatigue. It goes back to that app versus process issue. In process-oriented data modeling, you’re not thinking about a specific problem; you’re trying to build capability.
But most people in the trenches are, in fact, trying to solve specific problems. When faced with the task of building a process-oriented CDM model, they naturally think, “That model doesn’t solve my immediate problem. Why should I invest energy in something that solves problems other people may have sometime in the future?”
Good channel data management is hard because, to a large extent, it goes against human nature.