Why Data Analysts Should Adopt a Product Mindset

There’s nothing more aggravating for a data analyst than sweating over a great analysis or dashboard only to have it go unused.

It’s easy to feel that the problem is your (ungrateful) users. Most of the time, it isn’t.

The real issue is that many data analysts haven’t discovered one of the most important lessons software developers have learned in the last few years: if you want to succeed, you can’t just work on individual projects, you need to structure development around building products.

It isn’t too hard to understand what a software product is. But what does it mean to organize a data analyst’s work around products?

In this article, we’ll explore how having a product mindset can help your company succeed and can help you shine.

What is a product mindset and why is it useful for analysts?

Most companies that produce products hire people for the role of product manager. A crucial part of a product manager’s job is to work with marketing, sales, customer service, and engineers to figure out:

• Who is the audience for this product? What are these potential customers' pain points? What are their hopes and dreams?
• What features should this product have so these customers will want to buy it? Equally important, what features shouldn't be part of this product?
• How does the company get the word out about this product? What messaging will convince people to buy it? Which channels should you target?

What if you used the same approach for at least some of your work?  What if you were to stop thinking of analytics work as an endless churn of requests and start thinking of it as creating "data products” for your “customers,” aka your company’s staff?  

What if you stopped thinking of analytics work as an endless churn of requests and started thinking of it as creating "data products” for your “customers,” aka your company’s staff?  

Here’s how this approach might pay off:

• After interviewing Sales staff, you may realize that the analytical tools you've built for them assumes they are too technically sophisticated, which is why the tools aren't getting much use. You also discover that there are a handful of Sales staff who are more comfortable working in SQL than you realized, and with some small tweaks to their existing solution you could dramatically expand the kinds of analysis they can do.
• After talking with Customer Support, you realize that although they believe they have a bunch of individual analysis requests, what they really need is a simple self-service tool that addresses 70% of their pain points.
• You realize you’ve spent so much time building solutions that you aren’t promoting what your solutions can do for users. As a result, users who could really benefit from these solutions haven’t been using them and may not even be aware they exist.

There are many aspects of a product manager’s job that aren't a good fit for data analysts—e.g., you don’t need market research to figure out pricing. The key is to pick and choose the aspects of product thinking that best fit your situation.

How to apply a product mindset to data work 

Odds are you already know more about product thinking than you realize. If you've worked at startups, for example, you've almost certainly heard of user research, MVPs, evangelization, and so on. But how do you use that knowledge when creating data products? Here are some examples.

User Research 

When you’re swamped, the idea of conducting user research—aka, gaining a better understanding of your users and their needs—may feel like a luxury you don’t have time for.

That's because you're thinking about user research like you're an analyst for Marketing.

You don't need to produce a five-page memo on user personas, pain points, and competitors. All you need is to spend just a little time to better understand your users' needs and sketch out a few conclusions that will help guide your analysis.

Start by asking yourself, what are my pain points? Then do just enough work getting to know your users’ needs so you can figure out how to create products that are likely to satisfy both sides.

Let’s say your biggest pain point is that Sales is running you into the ground with a never ending stream of requests. Some quick user research could give you a better handle on their biggest pain points.

Armed with that knowledge, you could negotiate with the Sales director to create a product backlog  that prioritizes their requests. The end result:

•  You can alleviate some of their most pressing needs with reports or dashboards that you can produce relatively quickly
• Your agreement buys you breathing room, giving you the time you need to build a more comprehensive self-service solution that reduces the number of Sales requests and eliminates the spreadsheet-scutwork-from-hell work Sales staff have to do to stay on top of fast-moving campaigns.

If you hadn’t done this little chunk of user research, you wouldn’t understand the impetus behind the seemingly unrelated flood of Sales requests.  And you wouldn’t have discovered the truly astonishing amount of time Sales staff are spending duct taping together their kludgey campaign tracking “system.”

In short: to help your company thrive and make your work more enjoyable, pick one of your pain points, do a little user research, make some changes, rinse, repeat.

Get early feedback with prototypes & minimum viable products

The heart of a product mindset is getting feedback from your customers. The only way to know if you’re really on track is by putting something in front of people and getting their response. For example:

• Nonfunctional Prototypes. Create a quick and dirty mockup in a spreadsheet or slide that isn’t functional but that gives users a more concrete sense of what you’re planning to build. 
• Minimal Viable Product (MVP). You can get useful feedback with nonfunctional prototypes, but users often don’t know what they really want until they have something to play with. This is especially true for folks who aren’t comfortable working with data. So create a version of the analysis/dashboard that has the bare minimum of functionality needed to get useful feedback.

Take advantage of Agile methodologies

Agile has been taking over the corporate world, and product development is no exception. Today there's an irritating amount of hype around Agile, but there’s no reason why you should let that turn you off from some of Agile's useful ideas like: 

• Iteration. If you are working on a complicated data product—especially if you are building your business's first analytics infrastructure—don't try to do it in one shot. Break it up into iterations so every few weeks you produce something of value and get more feedback from users.
• Product Backlog. If users have complicated needs—or a massive wish list—trying to spec it all out is often a mistake. You're better off creating a product backlog: a list of what users want from a data product where users' current high priority items are at the top of the list. As a result:
  • You always know you are producing something of value right now.
  • You can easily adapt as users add, delete, and reorder backlog items as they work with what you've produced so far and as business needs change.
  • You can use the product backlog as a useful tool for shaping expectations and structuring conversation around priorities and making trade-offs.

Communication, promotion, and evangelization

When companies create new physical products, they also figure out how they’re going to market them. For some of your work, promoting and evangelizing it isn’t necessary—your “customers” are already seeking you out. 

But if you’re setting up data infrastructure from scratch or if you’re trying to change the way a department or your entire company uses analytics, then communication is key. This is especially true if you’re trying to create a culture of self-service.

Unlike with physical products, you don’t need an elaborate communication plan. Just take a little time to think about who could most benefit from your work, who’s likely to be most receptive, and how you’ll persuade them to check it out. 

For example, you could consider:

• Setting up some one-on-one Zoom meetings
• Posting on Slack every few weeks
• Hosting a “brown bag” lunchtime Zoom session
• Doing a short demo at a unit’s weekly meeting

And if you’re not sure you can afford to spend the time on communication? Try one simple step (or two), see what works and what doesn’t, and then decide what to do next.

Conclusion

A product mindset is no panacea for analysts. But by helping you focus more on understanding your users' needs and on repeatedly taking a step back and looking at the bigger picture, product thinking can elevate your game and help your company thrive.