ANALTYICS
Measuring User Behavior
Decision making was transformed, resulting in 6x more efficiency in product use
The Problem
McKinsey had an internally facing PowerPoint-enhancing product that they offered to all employees, and it was almost universally adopted. The team had implemented logging to capture usage on various dimensions. As the product grew incrementally over time, the analytics did not keep up, and by the time of the project the reports were impossible to use for anyone unfamiliar with the history of the implementation.
The Solution
As one of the main consumers of the reports in my work with the team, I instigated the project and convinced the product owner and stakeholders to prioritize it. A ground-up rebuilding of the analytics system, from data capture, to data structure, to pipeline, on down to the reports.
Project at a glance
-
​Initially I worked with the product owner to plan it out
-
Several engineers joined the effort as the implementation ramped up
-
The project unfolded over approximately a year, including some lengthy interruptions that stretched the overall timeframe
Deep Dive
Working on an analytics project means keeping your eye on the ball, in the sense that it is easy to fall into dealing with the data on its terms rather than as a means of answering the business question that presumably led to the project. I always try to keep that question, or questions, in mind on projects and then ask myself questions about what information is suitable to include in a frequently used dashboard, as opposed to a one-time analysis or report; about what level of information is presented; about what visualizations come into play. Then I work backward to what data is available and how fresh it is, and how it can drive the conception I have already developed.
This project was one in which I was also a stakeholder, in that I was working on a team that relied heavily on quantitative information for its decision making and had lots of dashboards. But we didn't have the best information in those dashboards, many of which were created at one time and never revisited, so they were essentially useless to us. In general, we had outgrown the dashboards, and as we starting discussing revamping them, we realized we had outgrown our entire analytics infrastructure.
​
The project was daunting to the team, who kept deferring starting it, so the early phases of this project involved discussions about the importance of the project and how the information was critical to our success as a team. Everyone agreed in principle, but it was too big a project for the team to slip it into an already busy schedule. We would have to lobby stakeholders, treating it as a project for them to prioritize alongside other enhancements and new features. I drove the process until we had some success.
​
Then I got to work with the product owner to explore the new report design; and with the lead engineer and data architects as they designed new data models and pipelines. Through the process, I ensured that the system supported the new concept.
​
Once implementation started, other engineers joined the effort, and ultimately the new reports launched​.
The Outcome
This was a rare project where we designed and implemented an analytics system from scratch, so the team didn't face the surprises and pivots that projects usually bring. In the end, the new reports transformed the team’s work, since we now had a much more detailed view of user activity, ways to compare across regions over time, and so forth. From the extra clarity we had on our product's use, we were able to make it 4x easier to get up to speed on first use, and 6x faster for users to create common types of slides.
Contact me if you are looking for more detail. I can provide it privately.