Heads up, we’ve moved! If you’d like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog
Product Analysts at Square leverage engineering, analytics, and machine learning to empower data-driven decision making in the full lifecycle of product development. We lead experimentation and growth initiatives, develop automation solutions to personalize product experience, provide insights to our sellers about their business, and much more. Square’s purpose is economic empowerment, and our team’s mission is to use data to understand and empathize with our customers, which enables us to build a high quality product experience.
Why create a product analytics team?
Today, Square has a whole suite of business-focused products and services, such as Marketing, Appointments, and Capital. But four years ago, we were primarily known for our credit card readers and payment processing. At that time, Square had one central analytics function that encompassed business intelligence (BI) developers, data scientists, and a newly emerging team of product analysts. I was the second member to join the Product Analytics team.
The BI team was experienced in building data warehousing components and creating tightly curated reports. The team of data scientists was hard at work solving problems where automation had the highest leverage, such as in risk detection and underwriting for our newly formed Capital loan team. Product Analytics, however, was tasked with solving a different problem.
With Square growing and its products expanding, developing, and launching, an analytics support gap emerged for our SaaS product teams. In their infancy, these new product teams needed to learn, iterate, and grow their reach. The SaaS products were not at the same scale as our payments business, which leveraged existing data infrastructure to automate decisions. Instead, product teams needed low-friction data access to make quick decisions. More importantly, they needed insightful analysis of seller behavior to drive product and marketing strategy. Addressing this gap was the catalyst for growing our Product Analytics discipline. We started assembling a small team to help our business partners move fast and make well-informed decisions.
What we learned in the beginning
In the earliest iteration of the team, we were not incorporating analytics into product decisions in a high-impact way. We found ourselves in SQL Monkey mode: stakeholders would give us precise requests for data points without context on how it would be used, so we would throw the resulting data over the fence and forget about it. Not surprisingly, this working model turned out to be ineffective. We learned that having product partners be too prescriptive about how to approach analytics problems ran the risk of requesting inefficient and tangential solutions, such as asking for a time-consuming, precise calculation to inform a decision where quick directional data would suffice. Similarly, product teams needed guidance on how to think about statistical principles, such as correlation vs. causation.
It made the most sense for analytics to define the approach for tackling business questions, with our knowledge of data and statistics. We also found that we were in the best position to provide recommendations to our product partners on what types of analysis would be most impactful. With this shift we were no longer throwing data over the fence without regard to how it would be used, we were invested in and accountable for making the ultimate decision. The added context and accountability helped ensure that we always went the extra mile to make sure decisions were as data-driven as possible. It also made us equal stakeholders in the business, motivating us to be proactive and engaged with our products.
Throughout the years, Product Analytics has optimized our approach of end-to-end problem solving, now a core competency of our team. Product analysts are responsible for taking a high-level question, developing the approach, conducting the analysis, and ultimately delivering an actionable recommendation.
Implementing Product Analytics Insights: A Case Study
A great example of end-to-end problem-solving was our early work on Square Appointments. Square Appointments is a fully standalone SaaS product that helped service-based businesses, such as a hair salon, take and manage bookings, particularly online. The launch went smoothly, but we discovered that our free-trial-to-paid conversion rate was lower than we expected. To investigate why, I segmented free trial merchants into three different categories: 1) existing Square sellers, 2) sellers who were new to Square and signed up for both payment processing and Appointments in tandem, and 3) sellers who were new to Square but signed up for Appointments but not payment processing. My hypothesis was that these different groups had drastically different intent and knowledge of Square that translated into different behavior. Some merchants predominantly wanted to use Square to take payments and saw business tools as a nice bonus. On the other hand, we saw merchants who were already using another company to take payments and were coming to Square specifically for our business tools. In fact, many of these sellers had very little knowledge of Square’s payments product and how they could leverage it. These differences translated into different behaviors in the subscription funnel.
My theory proved to be correct. Sellers who had high intent and knowledge of Square’s payments business, even if they were new, had a conversion rate three times as high as sellers who used Appointments as a standalone product.
This discovery was significant, but we weren’t quite done. In addition to the insight, I needed to provide the team with a call to action to solve the problem. What should my product team do differently, knowing this insight?
To figure out the correct call to action, I had to noodle over the above finding a bit. Why would a merchant be far more likely to convert if they also intended to use Square to take payments? For one, this smelled a lot like self-selection bias: merchants who rely on two Square services are probably more likely to subscribe than merchants who rely on just one. But could something else be contributing to this large gap? I found my answer when I went through the onboarding flow as a standalone Appointments business. It turned out that as soon as I entered my credit card information for the free trial, I was taken from the Appointments product and dropped into Square’s subscription management dashboard in our payment processing ecosystem. Not only was the branding completely different, but all of a sudden I was being asked to activate my profile, link a bank account, and take a payment, while being notified of a 2.75% payments processing fee! As a standalone Appointments user, I would have very little context on these fees for other Square services and why I would use them. This experience was very confusing and intimidating. We had to fix it!
As soon as we identified the problem, we were hard at work building a more delightful experience that made sense to an Appointments-only customer. The design and product teams created an onboarding flow that was localized within the Appointments product and shared the same branding. This flow was both more pleasing visually and more effective in practice.
Square Appointments has come a long way since then. Over it’s lifetime, we’ve equipped the team with insights and recommendations on a range of issues spanning onboarding, billing, usage, and engagement. In a recent launch they completely integrated the Appointments and payments experiences within the product.
Product Analytics is Evolving
This was an early example of product analytics work at Square, and a great example of end-to-end problem solving. Over the last four years, the frequency and quality of our insights and recommendations have drastically improved. We’ve added many tools to our toolbelt, including merchant-facing applications of statistics (UX analytics) and data science (Clustering).
Our discipline is still evolving. Product Analysts have both tremendous technical abilities and an understanding of the bigger picture of Square’s business. Over the last two years we have started to leverage these skills to create data products that we can give back to our sellers.
Earlier this year, David Feng published a blog post to describe how we used our own ROI data to form a ‘closed loop’ for our marketing and CRM products. I would encourage everybody to read his post, but in short, we used a seller’s return on investment from a punch-card-like tool called Square Loyalty to drive the pricing conversation in a way that felt fair and highlighted the value of the product.
Just another cool example: Corin Qi used ROI data for gift cards to show our sellers how much additional spend they might typically see by introducing a gift cards program:
As we take our SaaS products from newly launched, growth focused tools to mature services that are foundational tools in our sellers’ business, we are constantly looking for ways to bring more value to our sellers, either by making the product more delightful or more insightful.
If this sounds interesting to you, please reach out to us!