What does it take to be a good product analyst? (No, it’s not a data science degree.)

Good product teams know their users inside and out. They understand how they use their product, how long they stay, why they drop off, which cohorts will monetize, and where they should place their big bets. 

They get to know all of this by using data as a strategic asset—because good product teams are made up of good product analysts.

Does this mean every product team should be packed with data science degrees? Not in the slightest.

In my time building and leading product orgs at companies like Google, Nest, and Out of the Blue, I’ve seen a rise in product managers and data scientists alike playing analyst-like roles to help make the most important decisions product teams are faced with. Access to data and analysis tools is what is driving this change: So much of the data being leveraged to solve product problems these days can be retrieved from a self-serve product analytics tool like Mixpanel, not laboriously large batches of SQL queries.

All of this means the characteristics of what makes a good product analyst have become a lot more ground-level and comprehensive. The big ones, in my experience, are:

Here’s how and why.

Though you don’t need a formal quantitative education to be a good product analyst, gaining an understanding of how data plays a role in the big picture of product development is bedrock. And you’ll need to be good at communicating that, as well.

Mike Sall, co-founder at Goldfinch, writes about his ideal product analyst: “We need the essentials: strong attention to detail, excellent written and oral communication skills to articulate insights, and great problem solving with thoughtful approaches.” Yes, it helps to have technical depth (knowing how to calculate the significance of an a/b test, for example), but with self-serve product analytics tools on the market, it’s more about the way you think than the way you program. “We really need people who ask great questions,” Mike writes. “Product scientists don’t take numbers at face value but maintain a healthy skepticism. They’re passionate and curious about data, with a natural inclination to keep digging deeper to truly understand what’s going on.”

These days, product analytics is less about who can return data requests the fastest and more about who can bring their own quantitatively informed insights consistently. Self-serve product analytics tools don’t just enable product teams to answer questions on their own—they give people at all technical levels the ability to run reports and interpret the results independently. A product analyst just brings focus to the function.

“Asking developers to pull data isn’t an efficient use of their time. Furthermore, getting back the data can often lead to more questions—and more data requests. Pulling an initial set of data could take 1-2 days, but iterations involving further questions would take even longer. That’s where the power of Mixpanel comes in—you can dig through data in seconds and pivot as needed. In the past, that wouldn’t have been feasible.”

Ajit Kahaduwe – SVP Carrier Strategy and Product Management Platform & Services, PGI

Long story, short: The most valuable product analysts might know some SQL, but it’s far more important that they have a firm understanding of how data points turn into strong product recommendations.

Of course, data-driven product development that doesn’t consider business ramifications is only going to go so far. That’s why business-product sense is another important skill for product analysts to have. 

Here’s a quick example to explain why: Sending users notifications about features can result in increases in DAUs, but there’s also the risk of inflicting notification fatigue and hurting retention in the long run. Business and product-savvy analysts know not only what questions to ask, but also how to apply the learnings in a practical way.

Product analysts should consider the big picture, pulling from data that’s coming from the product and from other parts of the business. “You don’t need a data background to be data-informed,” says Rohit Gossain, former Sr. Product Manager at Shutterfly. (There’s some more validation for the non-technical nature of a modern day product analyst.) “People get stuck in thinking that data is reports and charts, but data is actually available everywhere in all sorts of forms: NPS scores, customer emails, talking to other members of your team. Learning how to be more data-oriented is not easy. But it’s much easier than it used to be.”

Say you’re looking to launch a new subscription service. It’d be bananas (I don’t use that word lightly) to leave a question like “Which features should we include at launch?” to the data alone. Sure, a raw numbers approach could easily rank the most popular features and provide an answer—but they’d still be off. A good product analyst dives into business context and product data to get the answer: Customer Support may know what features lead to frustrated users calling in, Sales may know what the competition is planning to launch, and UX may know what drives NPS in survey responses.

Knowing the ins and outs of how to do surveying like this also comes from business sense. A good analyst needs to understand when to zoom in or zoom out.

Sometimes, the business-case proof you need can be found from just a few customers, whether through conducting small UX studies and focus groups, reading colorful customer support tickets, or by actively dog-fooding and testing nightly-builds of your pre-released product. Other times, it come from looking at competitive market data, testing rival products, reading industry reports, or attending conferences where people who have encountered and overcome the same obstacles as you generously share their experiences.

Even if you have a high-quality, well-vetted product recommendation, you can’t assume that getting the insight “out there” is all it takes. 

You need to be able to get buy-in—and that’s typically from members of the product team and other org stakeholders outside of the product team.

While bringing fellow product team members in early on new projects and features can help to spread ownership, looping in cross-fuctional members later in the process can take some extra steps.

A lot of the answer here is knowing the touchpoints to communicate. The best product analysts know how to walk external stakeholders through why getting a particular product solution across the finish will positively impact us (the company) and them (their team).

Sometimes, getting things done across teams is simply asking for favors. For this, Stuart Diamond, author of Getting More, suggests “making an emotional payment.”

For instance, if a stakeholder from another part of the company has a last-minute CEO product review and they need a quick custom visualization, a product analyst should make the sacrifice and drop whatever they are doing to help out. Likewise, the product analyst should make time to grab that team lunch, go for that happy hour, and discuss that weekend hike. And it’s not bad practice for a product analytst to loop in cross-functional members when they don’t necessarily need anything, either: Give others a chance to pre-read an analysis before presenting it to the VP, or take time to craft that Friday-afternoon weekly update email to communicate progress. 

These might all sound like soft skills, but this human element can be a hard part. By demonstrating empathy you humanize the individual at the other end of the decision, making it easier for them to support you.

Cranking away at a model in a bunker accomplishes nothing. The same thing happens when product analysts design great ideas but don’t learn how to team up to get them built.

Mo is a former product manager turned data nerd. He has led analytics at prominent companies like Opower, Nest, and Google, successfully using data to build products, launch features, and grow users. Today, he kitesurfs, consults, and writes about data science management. He has an MBA from the University of Chicago, Booth School of Business and a BS in Engineering from University of California, Berkeley.