Bringing a Business Analyst Onto a Product Team

Data team
Product Team

2 March, 2020

Jon Fan

Jon Fan

VP Product at Box

Jon Fan, VP of Product at Box, advocates for viewing customers with a wide-aperture and resolves that having someone who can analyze data on your product team can help you do so.

Problem

It’s easy to take notice of your largest and loudest customers. Particularly in large enterprise B2B software and SaaS software, the conversation tends to focus on those folks who talk the most. Alternatively, what you should be concentrating on is your broad group of customers. This is especially true when viewing and handling data. Here I explain how we ensured that we had the widest perspective and how we properly utilized the data.
 

Actions taken

First, we brought onto our product team a business analyst. We didn’t want to put the burden on the product managers and more so we wanted an external point of view. So we decided to bring in someone with a data background. We then started embedding this person into everything we did as a team. She attended team meetings, was on every email, became deeply involved in the product, and was included in the decision cycle. This way, rather than have her simply pull the numbers or keep the data for us, she had context around what we were trying to do. We were able to provide her with a problem statement that we wanted solved and she could then decide where to take it from there, instead of having already resolved which numbers should be observed. This method proved to be successful because she was then able to pull in thought processes from across the team aiding in a horizontal exchange of information. What's more, as she got more involved she helped the team frame a broader picture.
 

After we had our business analyst on-board, we then wanted to connect the data back to the customers. We wanted to scale out and view what they were actually doing. The idea was that we didn’t want to use the data to make a decision up front but instead use it to validate a decision later so that we could know what was going on. Once we had statistically significant usage we then used it to predictively determine what features being used correlated with retention, lack of usage, or lack of churn. For example, early on we wanted to figure out which features to build using “What if” problem statements. Then we validated those using the data and eventually incorporated them into the broader issue that the company had around scoring customers.
 

Lessons learned

  • Analytics should be thought about early in the product development process. On the other hand, they should also be used later on. Once you have made decisions you should come back and validate those decisions using data.
  • I believe that every company wishes it had better instrumentation, but it’s always possible to get started with what you have already. As we were doing this we found that if you take someone who has broader statistical thinking, who looks at the product with a wide lens, you usually have enough data somewhere to start to get the answers that you want.
  • Incorporating analytics onto the team can become a habit only if the manager cares about it, inspects it deeply, and asks the same questions over and over. As a manager, you should be checking in so that people know the value and importance of it all.
  • Making this a habit has a longer time frame because you need to see its value over several projects and integrate it into your process. What we did is built it into our strategy reviews and team check-ins so that it was a standing item that needed to be addressed.
  • There were only two standing agendas items on my weekly team meeting and one of them is reviewing whatever our data person has been working on. What this does is help each person get exposed to, reinforce, and extend the information. This has led to some of the most useful discussions where individuals think through aspects of the product and share information with others. Furthermore, it has helped the team continue to be more data-oriented.

Related stories

Proactive Alerting System
2 April

Nicolas Bonnet, Former Head of Product and Data Science at Branch, explains why and how he built a system that allows the product team to be aware of problems before the customer does.

Prioritization
Data team
Users Feedback
Nicolas Bonnet

Nicolas Bonnet

Sr Director of Analytics at Audodesk

Creating Startup Product Feature Processes During Market Expansion
1 April

Satendra Pratap, Founder of WakeupBasket, talks about the need to create a product feature process as the company expands into new markets with new demands.

Changing company
Product Team
Product
Scaling Team
Users Feedback
Internal Communication
Reorganization
Satendra Pratap

Satendra Pratap

CEO and Founder at WakeupBasket

Focusing Engineers on KPIs Versus Short Term Fixes
1 April

Chris Rude, Senior Engineering Manager at Stripe, talks about focusing engineers on core KPIs over the feeling of being a ‘hero’ and fixing ad-hoc problems.

High Performers
Managing Expectations
Building a Team
Handling Promotion
Personal growth
Company Culture
Productivity
Convincing
Product Team
Chris Rude

Chris Rude

Senior Engineering Manager at Stripe

Tracking Engineer Time To Allocate Engineering Teams Better
1 April

Chris Rude, Senior Engineering Manager at Stripe, talks about some techniques to restore sanity, and get on the path to sanity if your team is overloaded with more “must-haves” than you can handle.

Managing Expectations
Productivity
Internal Communication
Dev Processes
Product
Product Team
Roadmap
Chris Rude

Chris Rude

Senior Engineering Manager at Stripe

Applying Agile to Data Science Teams
31 March

Jason Fama, VP of Engineering and Head of Innovation Lab, shares his experience of introducing Agile to data science teams emphasizing some of the benefits it brings.

Agile / Scrum
Team processes
Data team
Jason Fama

Jason Fama

VP of Engineering at Talkdesk