There Will Be Data
This was prepared in prep for a guest lecture at the Daniels Business School in Denver. Thanks to MichaelMyers for the invitation, and the class for an interesting conversation. This is presented as some thoughts on building data businesses, and effective product management in such businesses.
Who are you, and what do you do?
My career has carried me through everything from engineering questionable accounting systems, to legal IT and light paralegal work, to finally my startup experience: managing data ecosystems and the products built on top of them.
Most relevantly, that would be as the Director of Platform, and later General Manager, for Klout at company that acquired them, Lithium. And today I am the SVP of Product at Tagboard.
Klout was a two-sided platform that provided simplified consumer insights on social media, and complex data to a data ecosystem on the other side. Popularizing an early form of what’s now commonly influencer marketing, you probably know it as “The Klout Score”, but we ended up generating a whole lot more than that across multiple networks. On the consumer side, we provided an early manifestation of “the quantified self.” A way of knowing how well you were growing a relevant audience of substance. Later we added a topical analysis based on natural language processing — but honestly, this was better utilized by the other side of the platform.
The B2B side of the platform leveraged that score and the topical analysis a number of ways. The first iteration was in creating relevant targeting for brands to connect with through Klout Perks — a program that opened a channel for brands to make offers to influential consumers. In addition, we offered data resulting from our analysis to social analytics, monitoring, listening, CRM, and other tools through an API program and channel partnerships with companies like Gnip (later acquired by Twitter).
My current company, Tagboard, is similarly built on aggregating data and content from multiple networks, and simplifying that into a discovery and display platform. In Colorado, you’d see the output of our work on KUSA 9 in Denver, during social segments. Not sure of the rivalries, but University of Northern Colorado Athletics uses us, too. Nationwide, however, we’re used by nearly 100 local news stations, major sporting teams in every major market, for events and brands.
How does The Data Industry work?
Data businesses are built through ecosystems. Ecosystems are segmented into groups that take some permeation of your Core Materials and turn it into value for a segment of the market. Those segments could be totally different than your core business — and your customers may be way removed from their customers. Ultimately, especially in the early stages, it’s important to share in delivering value to all three through the same transaction:
- Deliver value to yourself (revenue, user growth, press)
- Deliver value to your ecosystem customer
- Deliver value to your core customer, through that ecosystem customer
At times these can be done out of sequence, or if you’re a pure data business, your core customer is your ecosystem customer, or perhaps you created purely an ancillary data business that has no relevance to your core customers. But these are exceptions that play by different rules.
The Core Materials can be thought of in an oil metaphor, and the data products you can build from those originate at various levels of refinement:
- Your Crude (in some sense, it’s pure content: Name, tweet text)
- Your Derricks and Drills (software that makes the collection and storage of data easier)
- Your Transit and Transportation (software that moves data throughout your ecosystem, or between datasources or applications)
- Your Refining Network (software that combines, filters, and packages your crude offerings)
- And your Byproducts and Exhaust.
For a data business, I’ll focus more on the last two. Which is not to say that the other pieces aren’t important — entire empires can and have been built off of them. Gnip was built on the transportation layer, then it started layering in services (including Klout!) that would enrich and annotate that data to consolidate the products and values into a single distribution. As we enter more mature stages in a data ecosystem’s lifecycle, we’ll notice that companies very often perform multiple parts of this funnel at once — even the original Core Material provider.
If we look at Twitter as an example, a tweet has the content (your crude), but also personal information from the author. It has timestamps, location, other attributes. Sometimes pieces of this are also crude (I mean look at those Trump tweets!), but depending on focus, the metadata can be either crude or byproduct.
The Refining Network can analyze this crude in bulk, pulling out insights, creating alerts based on analysis, leverage it for customer service, supply chain insights. We’re more mature every day, but we still haven’t seen the ceiling here.
The magic really happens in the byproducts and exhaust, however. A lot of exhaust comes from the edges and analyzing the edges. By edges I mean the actions that take place between Core Materials. If Twitter’s core material is The Tweet, another core material is very like A User. And when a User interacts with (or even sees) a Tweet, it creates an edge of behavior. That edge is a byproduct, a vapor, coming from the mixing of raw materials. Impression. Like. Share. Retweet. Time on tweet. Time on profile. Click. Hashtag usage.
Entire products can be build at one or more of those stages — you could see that Klout was built at first on the exhaust of engagement, and then on the exhaust of analyzing the content (topics) at scale. That’s right — one of the benefits of this sort of ecosystem is that there’s a leapfrog effect:
What was once exhaust from one data provider (engagement) can be refined into becoming a Core Material for another company. And then the edges of interaction from that new Core Material itself has exhaust, and could create new business opportunities down the line. You could package that exhaust as another product, or let your own ecosystem create their own Core Materials and reap benefits from the whole downline. Especially if you kept the principal of delivering value to your core customer all the way through.
What does a product manager in the data industry do? What do you worry about, think about?
Without being all doom and gloom…we worry about ethics: what will be done with this? We worry about channel conflict: how does having this product affect our core business? Privacy breaches. Bad actors.
If you put yourself in the shoes of a PM at different places in the data chain, your worries are going to be different. Does a Twitter Data product manager worry that a data analyst or customer at Brandwatch would be able to identify a multi-million account strong botnet that would actually be quite damaging to Twitter?
What are some best practices in product management?
In Product Management specifically, I’d say there’s a mutli-dimensional spectrum of focus that product people operate in:
- Visionary and Product Design (find what’s new and audacious)
- Executional and Operational (pick a framework for the team to work under, be efficient and execute and deliver product on time and functional)
- Editorial (find new ideas in the edges of what is already done; hone the work being done to be more cohesive and thematic; set the direction, but not necessarily the target)
I personally lean more to the Editorial spectrum. That comes with advantages and disadvantages for the people and company I work with.
Product Management comes in many forms, under many names, and you’ll learn that it’s often not clear which practice a particular company is expecting or already operating under. That’s ok. We’re uncertain and embrace that.
I think the difference of Product Management and, say, a CTO, are the perfect place to try and draw the distinction:
A product manager focuses on What, and Why, and often tries to fit it into When.
A CTO focuses on How and shares the When. How is really complicated, and shouldn’t be taken as a slight, compared to the three sides a product manager operates in.
Central to the Why is the customer. And knowing your customer — their past, their present, and predicting their future — is key. This is part partnership with marketing, part intuition, part behavioral understanding. Data will help: be ready to create data loops that tell you how your customers found you, how they used you, and measure your success against it. I’ve told teams to be influenced by data, but don’t be run by data. Data is still flawed. Asking the right question is hard. Measuring the right spots is hard. Be iterative, accept failure.
Going back to being a data business: you’ll be thankful you were data-influenced and built for that when building your products, even if you aren’t a data business. Why? Because you might find exhaust in your product’s behavioral data that would be very valuable to some ecosystem function, and voila, you have a new line of business, a new market, maybe just a life jacket when the going gets rough.
In data products, you need to individually be, or collectively be, a master of all of these. Data products are usually delivered through an API: APIs are often considered “contractual product.” They ought to be right the first time (but don’t have to be). They need to be consistent. You’re building an ecosystem off the back of this pipe, and problems with it will echo and resound all the way down to your core customers. An Executional and Operational mindset is very important here, but so is being predictive, prescriptive, and seeing the ecosystem you have and are building way ahead of time. The Editorial side will help with bringing that together with the business goals, marketing plan, and package and guide the product(s) into a cohesive whole.
Interestingly, this can go many different ways. You’re working with an engineering team that doesn’t always understand the business. You have a business team that doesn’t always understand engineering constraints. You are the mediator. You are finding the best path from point A to point B, except the process itself probably uncovers A.2 and C, which you have to now plan for.
What does the future of the data industry look like?
You’d like to think that as time moves forward, we’d get more data, more availability. More oil barons, new veins. Sadly, this probably isn’t the case.
Regulation, both private and public, is the future of the industry.
We already see plenty of private regulation: you may have heard that the greatest lie ever told is “I have read and agree to the terms of service.”
The Terms of Service governs all. And most of the time, it doesn’t play nice with others. They’re very often one-sided, to the benefit of the data provider, and less about the intermediary or the end customer.
External regulation is more obvious: governments. Looming on the horizon is the GDPR: European data privacy law that has material impact on US-based businesses, with penalties for non-compliance. Fear of external regulation begets more private regulation, and so on and so forth.
Perceptual regulation is another piece: how does the public perceive what you’re doing, even though your terms of service may spell it out? Can you really release that data?
If you were starting a company focused on the “extremely large data industry” what would it be?
Hard to answer, and probably why I’m not yet a CEO somewhere. It’s hard to commit to any of these with the conviction necessary. As I’ve said, I’m most naturally an editor, and as an editor that means I’m critical. A CEO’s conviction needs to transcend the critical to see it through.
But, given the frameworks I’ve hinted at here: find where there’s un-mined raw materials, under-realized exhaust. Where transport of these goods isn’t well defined, and there’s an ecosystem with customers waiting for it. Maybe they don’t even know it yet. Identify what you think an ecosystem provider could give to those customers, and either build it yourself, or start building what they’ll need to build it. Then do the business development work to negotiate your way in the door. Good luck.
