How user stories helped me in my data career

Many data analysts are surprised by the large amount of communication, soft skills, and project management involved in the day-to-day job. How do you deal with these situations? Data analysts can take away some great lessons from product managers in this area.

I’m currently part of the data strategy team at First Circle. I aim to help everyone in the company use data to learn more about their metrics, gather useful insights, and inspire different opportunities. Before my data role, I started my career out as product manager. Working in product management made me realize how data can be used as a tool to help different people, which motivated me to transition to a more data-focused career.

I’ve learned that working in product management often pushes you to think about things differently than you would as a data person. The concept of user stories has helped shape my thinking around how to manage the data role’s demands for communication and coordination that you would often find in a product role.

For product managers, user stories are the language used to communicate scope, priority, and impact across diverse teams of engineers, business folks, and designers.

User stories usually take on this structure: As a [persona], I want to [intent], so that [goal].

User stories are used to scope and negotiate product builds across teams. They are specific yet outcome driven, highlighting who and what teams should be building for instead of just producing a laundry list of features. They are used by engineering teams to align and prioritize on what needs to be delivered by a certain time.

While data teams work a bit differently from your typical engineering team, thinking in user stories can be helpful when doing data work. I like to narrow these down and look at them as “decision stories.”

We can modify user stories for an analytics project this way: As a [decision-maker], I want to [knowledge goal], so that [decision goal].

Sample Data User Stories

Decisions drive objectives. Information drives decisions. Analytics outputs are designed to give decision-makers the information they need, presented the way they need it. Framing user stories in the lens of the decisions you are improving helps you stay accountable to the primary outcome you should be driving as a data analyst.

I usually face a mix of these four challenges when I do data work: scope definition, communicating complexity, impact assessment, and innovation. How did decision stories help me deal with each of them?

Avoid noise and only focus on the necessary information

Data requests are susceptible to scope creep. Tasks that start out as query pulls for 4–5 key metrics can quickly evolve into dashboards with way more custom filters and calculations than necessary. These often result in noisy, information overloads that cause more confusion than clarity.

Pushing back on vague, heavy requests can be a challenging exercise. After all, how do you tell someone that you need to scope down without looking lazy? Discovering the underlying user story behind each data request is my productive way of doing this. When fielding new requests from teams, I first try to understand what decision they are trying to improve and discuss what existing data can be used to enhance it.

In concrete terms, asking questions directed towards shaping out the decisions stories of your stakeholders can be a huge help. This will allow you to scope your work properly even for those who are unfamiliar with this framework. Here are a few examples of questions I use to bring focus to the essentials:

Keep it as simple as possible

“Okay, I don’t need to know how you filtered for duplicates and automated the Airflow job, I just need to know what’s happening to our customers,” said the manager who requested for a quick report. I’ve experienced so many variations of this situation throughout my data career.

Talking to my stakeholders about data with just the right amount of technical precision is something that I struggle with. I never want to overcomplicate things, while I also don’t want to water things down. Where do we find the right balance?

The truth is, there is no clear sweet spot for every situation. Decision stories have helped me establish the proper context to guide my communication. When in doubt, I always go back to the question of “Is what I’m sharing going to enrich the decision that is going to be made?” If yes, then, it’s the signal to dive deeper into the details. If not, then I take a step back from potentially oversharing.

Did using your data work actually change things?

How do you know that your analysis or dashboard was effective? This has admittedly been a hit or miss for me. Is it enough that people look at my dashboard everyday and use the different features I set up?

I once built a dashboard that was tailored to improve the decisions of one person who managed a single section of our entire sales process. A few weeks later, I noticed very few people citing the dashboard during the weekly meetings where big decisions were made. What was the problem? My dashboard had been hyper-customized for one person, when decisions were really being made as an entire group. This was a signal to expand my story to include a larger audience of decision-makers, which led to a more big-picture dashboard that everyone eventually used.

Defining the decision goals and who you are helping at the very start helps you stay accountable to what your build intends to achieve. Sometimes, decision stories need to change to accommodate new people and patterns. Data teams are in the business of improving decisions, and you must constantly challenge how your tools and data can achieve that.

Achieve outcomes, not tasks

Whenever I receive heavy data requests, I get tempted to take the easy path and work on the list of tasks given to me without question. However, this approach leaves me uncertain about whether what I make actually helps people make better decisions.

When user stories aren’t communicated, you lose potential opportunities to increase the impact of your analytics work. The high-impact projects I am most proud of were often the ones that were grounded on a good understanding of people’s decision needs. Many of my greatest innovations took place when I knew exactly how my analyses were going to be implemented as decisions.

I recall a useful lead-targeting model I built that started out as a task to produce a manually filtered list of leads to target for promos. After weeks of repeated runs, I realized that the decision to improve was to maximize our limited weekly marketing allocation by targeting only the best people. This led to building a neat model that automated our logic to identify customers with high conversion potential. Essentially automating this repeated manual task, this model saved the team a lot of time and money.

Even if this was a huge win, I knew this could have been done so many weeks earlier if I had put in effort to uncover the decision story behind this request. Moving forward, I realized that I always had a much more productive discussion when I had clarity on what the outcomes, goals, and needs of my stakeholders were — even if they took some effort to talk about.

Decision stories help set the environment for analysts to think independently about the most creative paths to your desired outcomes. Who knows, that daily request for a spreadsheet report might have the potential to become an automated dashboard that makes your life easier.

Why do data teams exist? Data helps people make decisions, so the things that data teams build often focus on improving decisions within the company. Unlike conventional products, which are built for external customers, your end-users in a data team are often internal users.

Thinking of data as a product is one of the biggest mindsets our team adopted as we developed our infrastructure. Data is not only seen as a list of observations to be collected and analyzed, nor a list of coding tasks that need to be delivered to complete a project. Data is a key enabler of business outcomes, and it is something that we build around the day-to-day operations of those we work with.

This has shaped the way we plan and execute on many of our tasks. Instead of creating and following through on many one-time requests, we always aim to create tools that are sustainable and provide long-term value for the most number of people.

The entire data ecosystem in a company needs to be seen as a coherent whole. The job is not yet done when your dashboard is built, it is done when people can make great decisions around complete, accurate, and relevant data. Steps like data collection, storage, analysis, modeling, and consumption must all inform each other, instead of being viewed as completely separate project tasks.

When you view data as a product, all the methods and tools used to build them become means to the decision outcomes that need to be reached. Stakeholder and outcome management play a big part in getting that alignment right as a data analyst. Decision stories provide a guiding framework to improve, negotiate, communicate, evaluate, and innovate on many analytics tasks while staying grounded on what people need.

Related posts:

Berlin is one of the most colorful cities in Europe, East and West, old and new, beautiful and nasty, expensive and budget, modern and retro, after this day, you’re guaranteed to fall under its…

I recently had a visit with my current neurologist. When I left, my frustration was infuriating. She hadn’t been unkind in any way. She simply answered my questions like most medical doctors have in…

As cannabis cultivators who have worked in the industry for over a decade, we’ve tried multiple different growing methods to find what works best for us. We’ve had to discover where the perfect…