Finding insights and answers to questions in data is a key skill in product analytics. And developing this skill is the area where analysts usually see their growth potential.
Talking from experience, I strongly recommend paying attention to another aspect of analytical work: communication skills. Key here is not only finding insights, but also turning them into projects and making sure they convert into real value for users.
Getting to this point requires building relationships with the team, participating in key discussions, gaining credibility, and learning to present information in an effective way.
This article provides a series of recommendations for product analysts. However, it will be equally useful for product managers and executives who want to maximize the impact of analysts working in their teams.
Test your product management and data skills with this free Growth Skills Assessment Test.
Learn data-driven product management in Simulator by GoPractice.
In the fall of 2016, I was working on a project called Workplace at Facebook. Our six-month milestone was drawing to a close, and we were sorely lagging behind our project goals. The analytics team, which at the time consisted of three people, started thinking about the different ways to accelerate progress and meet the goals at all costs.
In the process of evaluating different ideas, we noticed that among our customers were several huge companies where the proportion of employees who activated their accounts was significantly smaller than the average metric in the product.
If we could solve this mystery and make people in those large companies activate their accounts, we would have exceeded the goal we had set. The next day, we figured out what was happening at these companies. It turned out that the key problem was…
Curious about what was the problem? Sorry, I can’t tell you.
We humans have a tendency to create stories about the world around us. They are captivating, they draw attention to the matter, they immerse us in context. But in reality, most analytical studies are super-boring. They tend to simply dump facts, numbers, and information on the reader’s mind.
The good news is, many of them can sound much more fascinating than the best detective stories out there. You just need to work a little bit more on the presentation part. Turn them into stories!
Here’s an example: In 1854, English physician John Snow saved thousands of lives in London by putting a stop to an expanding Cholera epidemic. Snow’s story is an intriguing investigation that ends with the removal of the handle of the water pump in Broad Street, where tainted water was coming from. Snow’s heroic efforts have become the subject of novels and movies. But in reality, Snow went through tedious analytics and number crunching to discover the source of Cholera. It was boring work that had a very exciting story and outcome.
Turning analytic research into a story also serves another important goal. If the story doesn’t sound right, then probably there was nothing useful in your analysis, and therefore it is not worth telling it.
Analytical stories have their own traits. The protagonist is your product or user. The conflict is built around the character who wants to achieve a goal, but the villain (the market, competitors or low conversion rates in the acquisition funnel) prevents her from doing so. The climax of the story arrives with an insight made, some sort of an unusual view of the problem that allows the main character to achieve her goal.
In an ideal scenario, your analysis will help an audience who previously thought that the product stands on three pillars to understand that the product is in fact a kind of ball that rotates around the user, which means you can solve problem X by doing Y.
Deliver results like you would deliver a product
The most common way to communicate the results of some important analytical work to a wide range of people is to publish the study and send it to those who are interested. Don’t do this, unless you don’t mind the results of your work being lost among a bunch of other emails.
To draw an analogy from the product world, this approach would be like rolling out the first untested beta version of a new app to the whole world and follow up with a large-scale marketing campaign.
Like any other product, the results of your analytical research requires several iterations of tests and adjustments. Only when convinced that the study produces the desired effect on the target audience should you consider making the public launch. This, first of all, concerns important studies, which entail big projects and changes.
Start with a soft launch. Share the results with those who are interested, someone you have a trusting relationship with. You will quickly notice where your story works well, which arguments sound convincing, and which ones raise doubts and concerns. After collecting feedback, make a new version and fix all the problems you found. After several iterations, the credibility and efficiency of the presented results will increase significantly.
Another advantage of this approach is that you will find early adopters who will help you get the message across to a wider audience.
Stay in the context
Product metrics are highly dependent on the source of the traffic, i.e., where the users came from. So the conversion rate of an analytical research into real projects is highly dependent on how and where the research project started. If the subject of study is divorced from reality, has a low priority to the team, or has little to do with the rest of the company’s goals, then even perfect analytical work will produce no effect at all.
It is important for product analysts to be able to find the most relevant problems with the maximum potential. To do this, it is necessary to be in the context of what is happening in the company and the team. You need to participate in important discussions, maintain relationships with key people, and synchronize regularly with the teams related to the matter.
You may argue that analytics requires focus and immersion, and that being involved in all of these processes may turn out to be counterproductive. But this assumption couldn’t be farther from the truth. Integrating into the team gives you an understanding of what is happening. It also increases the relevance of the work you’re doing (you feel what is important and what is not), and simplifies the communication when delivering the results (because trust has already been established).
Another important consideration is that product analysts should always be a part of a specific product team. I have never seen an effective analytics or research department existing on their own, like a separate unit, without particular product analysts being part of product teams.
Look for a quick way to get first results
Another way to increase the efficiency of product analysts is to shorten the path between questions and first results.. Quite often, the potential impact of a product research is inversely proportional to the time spent on the analysis. The more time spent on finding and refining the answer to the question, the higher the probability that the team has already moved on.
Look for a quick way to get the first results, even if they don’t look perfect. Simplify. Calculate the first rough estimates that will give an approximate answer to the question posed. Usually, this can be done within one day. If you didn’t find anything useful and interesting, then try to approach the task from a different angle, or move on to the next one. If you did find something worth your time, then share the early results with the core team and continue to dig deeper.
If it turns out that you have found something important and big, then take enough time to work on submitting and turning the insights into real projects.
Share the results with the team during the study process, not after it’s ready
When a product analyst is working on a task, especially a large one, the classic approach is to keep digging into it for several weeks, and then come back with the final results and present it to the team.
But a more effective approach is to discuss intermediate results with the team as soon as they’re ready. The analyst can share this information regularly on a collaboration tool such as Slack and get the team’s feedback before making further progress.
First, the team will be able to ask questions, adjust your research direction, and share hypotheses or explanations on what is happening as the research progresses.
Second, your team will be with you through the entire process, from ideation to gathering the final results, observing the flow of thought and the logical transitions along the way. The final result will be the product of teamwork. If you go it alone and share the final results in the end, then expect the impact to be much smaller, especially if the results are very different from the current ideas the team shares. In this case, your new ideas won’t be welcome, which is quite fair and natural under the given circumstances.
Speak simple language
There is usually an inverse relation between the amount of jargon used in a study and the number of useful insights it contains. If you have something to say, then say it in the simplest language possible. Share what you learned about the user or product, not the research methods you used.
Using such terms as “variance analysis,” “Fisher’s variance ratio,” and “linear regression” has never helped to tell the story with interesting insights about your users and the product.
Make the team’s life easier, not harder
“It won’t work.” “It is impossible to calculate.” “It will take at least a month.” “You can’t do that.” “We don’t have such data.”
You’ll hear this from analysts that tend to be skeptical. Skepticism is good, but what is also good is being able to control it and turn it into something productive. Communicating with people who will give you a million reasons why something won’t work is very difficult. It is those who provide solutions that make the most impact.
Being able to look at things with a critical eye is a useful skill. But this skill becomes ten times more productive when the person who finds a problem immediately starts to think about the solution.
Be the one who craves for solutions, takes responsibility for projects and shares the risks with the team. Take my word, you won’t be disappointed!