Part A: Business lessons
1 - Technology is easy, people are hard.
The vast majority of people can learn - and even master - any technology, even the most complicated, with support, motivation, and time. Technology must be repeatable and predictable to be safe, much less useful. Consider composing on a mobile keyboard: complicated technology completely alien to even the most erudite barely half a century ago, but so ubiquitous today as to be globally influential.
The vast majority of people (myself included) also have: hidden agendas, biases individual and collective, mad political motivations, and normal human failings. This makes us challenging, unpredictable but influenceable, and fun! Working with the raw public has been the best and most consistent part of my entire career, from hosting and waiting tables at Big Boy, up to my most impactful consulting engagements.
From another perspective: tech skills as a general rule are teachable and learnable, but people skills must be practiced.
2 - The devil is in the details.
Demos and proofs of concepts are one thing; Implementations are an entirely different animal. I've worked on complicated analytics solutions that stalled and sometimes failed based on unavailability of a font, or the incorrect direction of a drop shadow. At the same time, I've seen huge business deals go south when a customer realizes they don't have the data needed to build a solution that looks like the fancy demo that inspired them to buy the product in the first place. Those were hard conversations, and the practical wisdom I took from it was simply to never underestimate the complexity in the seemingly small details.
3 - Development/Programming/Computer Science is 10% algorithms and 90% naming things.
I often wonder how many industries this applies to, but holy crap is it central to anything related to software or data. A well-named interface, schema, markup, or piece of code can be nearly self-documenting, and maximize our ability to expand, maintain, and reuse our creation.
Part B: Technical lessons
1 - Let the math of the analytics use case imply the data grain(s) of your dataset(s).
I really wish I had a snappy way to say this one. When we create data structures intended for long-term storage, the grain is a secondary, descriptive consideration. When we create data structures intended for driving dynamic visualizations or for machine learning-based predictions, we as designers choose the grain, and thereby optimize for numerical analysis at that grain. If we understand this idea before we start building datasets, we can both streamline our field set for best performance, and create overlap between our datasets only where we need it.
2 - You can have your data in real time, or you can have it enriched, but not both.
Operational Analytics and Business Intelligence and separate, albeit related, use cases. OA usually has built in query and performance limits based on the traditional relational database structure (a fair trade-off for long-term storage and entity relationship preservation), but you're going to be able to get up-to-the-moment numbers when that query returns. In contrast, BI based on purpose-built datasets can include data from multiple sources of varying structures, can be enriched with historical trends and smart derived fields like sentiment analysis or automated clustering, and sets you up for much more dynamic "what if?" kinds of forecasting and insights. Those numbers are going to be updated daily, maybe hourly if you're lucky, though. Modern businesses need both, so the trick here is knowing which analytics questions fall into each realm, and therefore what kind of tool to use.
3 - Machine learning can only predict where historical data exists.
This one sorta rhymes, it's a bit snappy. It's not common knowledge yet, though - machine learning still looks like magic to a lot of people. It's not magic: it's automated math applied to historical data to illustrate patterns we can use to predict future data. We should know this both as business users looking for drivers to the variables we care about, and as end users understanding how our actions are tracked, and how that data is being used.
Comments
Post a Comment