Top 3 Things You Forget When Building Your SaaS Product

Here are the top 3 things that product teams often forget as they chart the course for their SaaS product.

While the number of product management roles in the US has grown by more than 30% in two years, according to LinkedIn, the responsibilities of the job are morphing.

But we can all agree that the product team is ultimately responsible for every decision made in product planning and evolution. So, what does that mean for the data that they use to validate and de-risk their conclusions?

1. Most tools sold as product analytics barely scratch the surface

Some event-based product tools are too rigid to analyze user behavior, and don’t allow analysts to manipulate the data in the way they need. They provide very fast ways to answer predefined questions (or questions of a predefined structure), but make it very hard to answer questions outside of those bounds.

Other product tools collect all event data so that product analysts have the raw data they may need. However, an analytics tool is still required to analyze the data that these tools collect and, when unmanaged, can lead to higher cost.

Product analytics tools only go an inch deep when it comes to analysis. They provide out-of-the-box, surface-level metrics on user behavior, but can’t tie it back to any other data sources to give you an idea of what your customers are doing.

They are also incredibly rigid: if you have a question outside of their pre-built charts, it is almost impossible to answer.

In addition, few of these product tools work well with standard BI tools — users tend to resort to sending screenshots back and forth via Slack or email rather than integrate them with a model.

BI tools typically fail for product analytics use cases because they require a pre-built model or dataset that someone can then manipulate to answer the questions they want. This model doesn’t exist yet for new or planned features, and doesn’t accommodate their dynamic nature.

2. Other teams have relevant data

Product data doesn’t live in a silo and if it does, it isn’t telling you everything you need to make strategic decisions. Product data is most relevant when connected to data from other teams across the business.

The marketing team will have data to tell you where your users are coming from, and how they are engaging with your company’s content. Product teams can use this, along with their own usage data, to build clarity around successful users.

The support team will have data on what questions are being asked most frequently, which areas of the product are causing the most friction, and which customers are running into the most issues.

A feature request may take on greater meaning when you know that it has come from a power user at one of your most important customers. This information can be used to help product teams determine whether to work to optimize a feature, or deprecate it.

And Engineering teams may have data in log form that’s not otherwise in your product database.

The data from product analytics tools is important–it tells you how your users are engaging with your product, down to every click, swipe, and conversion. But the important insights come from connecting this user behavior data to relevant data from other teams, and being able to analyze it in aggregate to make decisions.

3. It’s easier than you think to connect them all and collaborate

Despite the product team’s daunting ownership, product decisions are made collaboratively. To get the most-informed answers to product questions, data scientists, product management, growth teams, and other domain experts should weigh in. This means giving them the ability to easily view, edit, and share work all in the same tool.

Sometimes you may share your work early to get input on strategic product decisions from stakeholders. And if BI tools require everything to be modeled in order for stakeholders to give input, you risk having to go back and rework the analysis.

In an advanced analytics tool, analysts can quickly get started in a commonly available, standardized language, while other domain experts can explore using code-free features. Sharing work back and forth enables all stakeholders to weigh in on the big decisions. This is important because answers to product questions require cross-departmental context.