AI only continues to grow and drive not just the hiring aspects around the world, but the way we advance and progress. The most interesting uncanny valley has emerged between data and the stakeholders that make the insightful decisions. Whether it's a C suite, a VP of Marketing, or a GM overseeing an international expansion, there's a huge need to leverage insights and growing impatience with analytic groups to solve the problems facing the typical business (gaming or not.)
On the one side are stakeholders that expect specific answers to their questions. On the other side, there's a need to build out lots of solutions to process transactional data and produce these specific insight points.
I was surprised to see so many companies hiring for the same role: merging Product with Analytics. Luckily for me, this is my wheelhouse. So let me share some thoughts on how we get there and how we drive ahead with insight and data driven changes.
One side of the data uncanny valley: How complicated are the questions being asked?
Pretty damn complicated. I've implemented data and insight solutions for 25 years. The first days were how to consume a massive amount of data. Just structuring data to be analyzed was incredibly difficult. Let's exhume the body of data, creating an analogy to hospitals that need insight to treat their patients. The body is the data, the patient is the customer, and the hospital and all its equipment are the stakeholders unified to the analytic solution providers.
- Transactional Data: Data as it arrives from our systems are like circulatory systems in the body. You go to read data and you can cause a major bleed that takes down your entire production system. Data cleanliness, ability to serve data in the format needed by your live systems and the need to drive experiences are the priority. None of this is about measuring any of this data. Extending this analogy of a body, the body is happily humming along, we have no way of measuring key KPIs like circulation, blood pressure, expected norms of key hormones, etc.
- Ingestion Systems: Pulling in data and preparing it for analytic processing is a key task. We've made great strides with RAID and replication, we know how to process massive amounts of data and we know how to structure them. The key to ingestion systems is an extension of the transactional data, we still need to focus on data cleanliness, synchronization of data across multiple systems, and we need to deal with the reality of privacy, compliance, and careful storage of data. Like our bodies, the KPIs are private. We need to protect this data at every point we read the transaction data. How do we maintain the encryption, the safety of data as it's the biggest asset the company has? Really, ingestion through to creation of insights drove the creation of roles like CIO, VP of Data Security, VP of Compliance, Privacy, etc.
- Building out your Architecture: I'd say most companies expect the above. There's a massive underestimation for ingestion and how to get to compliance. The most dangerous part here is the architecture for your insight grounded solution. This is where we get a bit specific with our analogy. Stakeholders are doctors. They're looking for tools that let them prescribe the life saving treatment to the patient. That means the entirety of the hospital, except for the minority of doctors working there are part of the analytic team. Just like hospitals, there are specializations, emphasizing oncology, physical therapy, trauma, and clinics. Each of these have their buildouts that massively change the environments that patients and doctors experience. Analytic systems are the same way. We'll deep dive into this below. Every company's architecture will reflect that specific company. Netflix's core data architecture bears almost no similarity to Amazon's, same is trust even of Boba Bliss, a mom and pop shop down the street. Whether you architect a data lake with specific data marts, or verticalized systems with layers of middleware that keeps highly distributed dataflows aligned, every data solution can be a specific snowflake or fingerprint of that company.
- Insight and Communication Channels: Insights today can be delivered to mobile apps, SMS, into third party tools like TikTok, GitHub, you name it, Email, and desktop alerts (embedded within Chrome, or other tools.) This is the final solution. Product Marketing can brand and manage the communication of these tools, but at the end of the day they are analytic solutions delivered by the analytic teams.
The key point of translation, turning insight needs into business requirements.
The core of the uncanny valley that is generally either a big meeting lead by a department lead, with analysts sitting in a corner with furrowed brows because they've been tasked with too much work, and other departments like marketing, CRM, etc saying completely contradictory statements to each other regarding the most important data points. Everyone leaves the room without a clear sense of what will be delivered, when they'll have anything to look at, and if they can get a promotion this year or not.
The area I'll focus on is delivering a solution architecture. This is where Product really shines. We can spend time with the business and understand their core needs, understand what tangentially affects them. It's the same as analyzing competitors, looking at market conditions, it's just different point and a different nomenclature that you'll communicate in.
Product person can then highlight a bunch of key requirements and work with a solutions group to build that product. The following is a high level break down of how to look at your business and needs from this perspective.
- Outline the Department: Identify the departments and the resources that drive success in these areas. Maybe your Sales team is the most important, maybe it's Design like Apple, maybe Research and Development like Microsoft. Pick these most important groups.
- Identify Daily Needs: Hiring someone in a big role is nothing, if they can't get accurate data in time to make decisions. The first part of this is to determine the daily reports you ingest. Maybe it must be mobile accessible, maybe this data must be connected to an internal tool to enable customer support, all of these things need to outlined and met right away. This is the easy task. The highest role should define the specific reports down to the column, the timezone, the font even of the given numbers. There is no reason that every one of these requirements are not met. The Product, or Project Manager even, can gather requirements, bring together the resources to deliver the solution, and deliver them in a nice portfolio. This gives you my approximation of 30% of a given department's needs.
- Mining the Unknown, the Dangers of the Crystal Ball of Visualization: Here's the big danger. Data is a fabric. It can be stretched, it can be cut, it can be designed for a specific. Whether this is good or bad, is a major issue. We don't need to break why data can be manipulated (inherent bias, axis manipulation, % and mean issues), what we do know is the difference between "fake news" and a world changing discovery is a razer thin line. It's even more dangerous when we take visualization into account. Visualization is a crystal ball. You ask it question, you look at answers, you ask more questions. This is incredibly sensitive. The cold reality is that most visualization tools are no more accurate than a magic eight ball. How you ask the question, how limit the response, how you follow up, these can lead to major distortions in the data. The likelihood that any given stakeholder can actually reach a reliable answer in a visualization tool is very rare. The more time someone spends in a tool, the confidence in the solutions they find go down. This is the hard role, I feel everyone is hiring for. The Product Management role is to connect the requirements of a given stakeholder group and iterating through solutions as we evolve them in to fully defined tools (moving them into #2). Generally, visualization should never be widely open. Whether it's Looker, Tableau, PowerBI, there is really very limited options you can give to any stakeholder. The risk of finding a combination of variables that is not reliable, not accurate, or unclear requires a inordinate amount of QA. The safest solution is to connect a Product Manager with their defined customer, in this case the stakeholders defined in point 1, and create and iterate. As a team, we should get better and better with each solution, delivering value and insight, and managing the risk of solutions failing or falling short.
- Insights, the final solution: The final solution of insights comes from a successful implementation of all the steps above. How is this defined? The happiness and efficacy of the stakeholder. This is the final interaction between the doctor and the patient, the doctor serves up their advance, and the patient's care is delivered. Nothing here really involves the rest of the hospital except for the implementation of the tools to read the insights. A nurse first takes in a patient and gets their blood pressure, maybe their temperature, their circulation. All of this is the day to day running of the insight system. We deliver the core KPIs, we deliver them in a way that is most geared to solving their problem, and we maintain the solution over time. This inherently means there are definitely folks just maintaining the platform you've built. The stakeholders can focus on their most important jobs, and everything is solved for them. No one has to answer to questions about security, privacy, ransomware, etc. The heart here is that insights are the key results of a system. These solutions are running and are being maintained. The Product Manager can treat them like a launched product, with clear health indicators, and a clear staff that owns the operations of them.
Let's go back and take that terrible meeting with key data that people are throwing around, and let's imagine what a successful solution would look like.
A leads meeting of a small group regarding the most important part of the company meet. The Product person knows the key resources and needs of each person in the room. The meeting progresses with an opening of looking at the current Dashboard. Everyone has access and is aware of it. Key question are brought up specific to their knowledge area. The Product person takes note of key requirements to roll in the next version. Everyone has the data they need, and a clear wishlist with a clear data of when they'll receive that next version.
Suddenly everyone is speaking the same language. Product Managers, just as they do traditionally speaking up for customer experiences and prioritizing investments, can leverage these skills to understand the insight needs of a given group and how to translate that into solutions to be built.
For a guy like me, Gaming, Analytics, and Product, this is called a dream job.
