Bringing a Business Analyst Onto a Product Team

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.