I started Faire's Product Strategy & Analytics (PSA) team and built many of our processes from scratch. This was a process we built early on that codified the end-to-end analysis approach to make sure every project we take on is truly answering the question at hand in the most efficient and effective way.

Prior to this process, analysis was often done in a silo, which would sometimes lead to less than ideal outcomes. This process introduces early checkpoints with key stakeholders to ensure we are aligned on the approach and potential impact every step of the way.

On the analytics side, people were really excited to have this process. I run a session introducing this process in onboarding for every new hire on the Product Strategy and Analytics team, and everyone clearly understands the value right away. Many of them have been burned in the past from spending hours or days on something that they later realized was answering the wrong question.

It was a bit harder to get adoption on the PM side initially because we’re known as the team that gets the answers. But once they did one or two reps, they realized it was a much more efficient process. We also have a very data-driven company and PM culture in general, so most PMs really like being involved in analysis; this process formalizes and encourages their involvement.

I wanted to establish something similar to our product development process but for analytics. Using that as a basis, I created this five-step process to establish the right checkpoints, break down our problems, and get a lot of buy-in and alignment up front to ensure we were always sprinting in the right direction and were confident in our results.

You’ll see a bunch of smaller checkpoints with PMs throughout this process, since they are the people who are accountable for the roadmap and the metrics and will ultimately make decisions based on the work that we do. My team is under the Strategy & Analytics arm, separate from product, but we consider ourselves close thought partners. Each IC is mapped to 2-3 product pods and owns all their end-to-end analytics needs. Essentially, they’re guiding the product strategy and roadmap with data.

This is first step in Faire’s analysis process — and in many ways, the most important. For a deep dive into how and why we spend time on scoping, check out the 

Analysis Scoping Template at Faire artifact.

 you can also see an example of how we scoped a real analysis 

At the end of each stage, we have a set of questions you can ask yourself to make sure you have the information and buy-in you need to move to the next step of the process. It is very important to take these stage gates seriously because as the process progresses, the analysis gets higher fidelity and harder to pivot. For more complex or ambiguous analyses, it is common for steps to take a few iterations, especially the scoping stage.

Once you’ve written your scoping doc and aligned on the analysis plan, the actual data exploration piece should be pretty easy. You’ve done a lot of the hard work already by determining the list of metrics that you need to pull — if you don’t scope, you have to think about, “What should I pull next?” And it becomes a big, daunting task. But here, all you need to do is write the queries. I personally like to put my headphones in and listen to some tropical house music while I do this — I find it to be a fun, mindless task that I do at the end of my day when I’m a little burnt out.

You don’t need a full-fledged analysis here, but jotting down a few concise top-level key takeaways ensures you don’t go too far down the wrong synthesis path before you’ve touched base with your PM.

The PSA team at Faire is known as a team that gets to the answer. We’re much more than data analysts (as shown by our titles). We want to ensure we're adding that unique value by not just throwing data over the wall, but synthesizing it and understanding what it means. We won’t go much farther than the first pass at this point, but we definitely want to have a point of view on the data before sharing.

This is usually a live meeting with a pre-read. It’s a good time to really pressure test your insights to ensure there isn’t any confounding data one layer deeper.

The stakeholder check-in is also really important when the answer is controversial. Analysts are often slightly less biased than PMs, who are understandably invested in their features being successful. If you drop a very polished doc on them, it could be a bit jarring. It’s better to bring them in early so that they feel like they’re a part of the analysis.

Analysis synthesis and polish is critical to ensure all the hard work to this point actually has the intended strategic impact. Communicating insights in a clear, concise, and leveled up way makes sure that these insights can be internalized by the right people at the right altitude.

Given the importance of this step in our analysis process, we are very keen on bringing on new team members who showcase strategic problem solving and communication skills. We actually often skew more strategic with our hires (vs. technical) given we believe the hard technical skills can be learned on the job.

t for an example of what this looks like in practice.

Most of our analyses are done with a product manager end-to-end, and it’s easy to forget that there are other people who should know about what you've learned. So in this step, we wanted to explicitly call out the importance of sharing an analysis broadly.

There are two main groups we think about. First, the entire engineering, product, and design org. It’s good for them to understand what they’re marching toward; analysis is often the tip of the spear in figuring out what we want to work on. The second group is the PSA team more broadly. We sit embedded, so we don’t always have visibility into each others’ work. I can’t tell you how many times I’ve shared something, and then an analyst from a totally different end of the business pings me to say, “That framework was really interesting; I’m actually going to adopt something similar for this other problem I’m solving.”

Faire has a big doc culture, so the polished Notion doc is sufficient for probably 90% of our projects. The slide deck is really only used for analyses that are informing huge strategy updates or being presented in an all-hands.

Jolie Kemp Zwick

This document codifies the Product Strategy & Analytics team’s end-to-end analysis approach. This process ensures we are using our analytics resources wisely by maximizing the impact and efficiency of each analysis we take on.

For Use by Product, BizOps, Data Science, Marketing, and Finance Teams

When creating longer form analyses, these are the 5 fundamental stages that will ensure the analysis owner is looping in the right people, asking the right questions, and maximizing impact:

I wanted to establish something similar to our product development process but for analytics

 aligning on the hypotheses, the analysis plan to validate those hypotheses, and the impact of the analysis

 pulling initial set of data points and starting to develop actionable insights based on the data

 discussing preliminary analysis with key stakeholders to align on insights and any in scope follow ups

 creating an artifact that tells a story with the data with compelling visualizations and relevant product recommendations

 communicating and evangelizing the analysis to ensure insights and recommendations are understood and implemented

The analysis scoping stage is the best and cheapest time to align with stakeholders on the hypotheses we are trying to validate, the data we are going to use to validate or invalidate those hypotheses, and the impact of the analysis. This ensures the analysis will achieve the desired outcome, does not balloon in scope, and is appropriately prioritized against other work.

What are the motivations for this analysis? Why does it matter?

How does this analysis fit into what the team is working on?

When is this information needed by? How does that impact prioritization (p0, p1, p2, p3)?

What is the exhaustive and prioritized list of hypotheses the team is trying to validate?

How will the team use this data to make decisions?

What will next steps be based on this analysis?

What are the questions we need to answer to validate these hypotheses?

What data will we use to investigate these hypotheses and answer these questions?

Analysis kickoff meeting with key stakeholders

Prioritization and project timeline estimation

At the end of each stage, we have a set of questions you can ask yourself to make sure you have the information and buy-in you need to move to the next step of the process

The data exploration stage is where the majority of the analysis happens. 

This is how one follows through with the analysis plan outlined in the scoping doc and starts to formulate actionable insights based on the data. This stage should still be lightweight — there is no need to start polishing visualizations or documenting learnings.

Does this data validate or invalidate the hypotheses?

What actionable insights can I draw from this data?

Is there any additional information that could help support my key takeaways?

Is there an alternative explanation to why I am seeing certain trends?

Do I need to go a level deeper in my analysis?

The stakeholder check-in is a way to ensure the analysis is actionable before codifying and distributing insights and next steps. During this time, the analysis owner and stakeholders can discuss any caveats or data limitations and formulate / align on the key takeaways and recommendations. This is also an appropriate time to discuss if there are any additional data cuts that could make the analysis even stronger.

Does the data answer the original question?

Do we have have a deep understanding of the full picture?

Is there any follow up analysis in scope for this project?

Initial data review with PSA and stakeholder

The analysis polish stage is where insights and recommendations are clearly communicated in a source of truth document. This document tells a story using data with clear and compelling data visualizations. In this step, we need to make sure that the analysis has a clear opinion on next steps and that it will be understandable by all audiences.

What are the best visualizations to get my point across?

How can I level up my insights and clearly articulate the so what?

How can I ensure my insights and recommendations understandable to all audiences?

Tying insights to product recommendations

Notion document with accompanying Mode dashboard

The analysis distribution step ensures that all of this hard work is actually seen and internalized by relevant Faire teams. This can include distributing the analysis to the relevant team members, adding it to the 

, presenting the key findings in a team meeting, or kicking off a brainstorm to decide next steps.

Who are the relevant people to share this analysis with?

How can I ensure my team understands the insights?

How can these insights and recommendations inform the product roadmap?

Analysis presentation to cross functional team

Analysis distribution to cross functional team / the rest of PSA

Analysis Template & Process at Faire

Analysis Process and Template at Faire

Process Overview

Sign up to see more