5 Steps to Build a Data-Driven Product Development Culture

Early stages of product development are one of the most exciting times to be a part of the company as a product manager. One of the most important factors that drive the growth and success of the product is how quickly it acquires a large and loyal base of customers. You want these customers to use your product as frequently as possible with minimum friction.

To achieve that, you need to continuously monitor the product usage data to identify the user pain points and improve the product experience incrementally to help them find maximum value from your product.

But is your product team proactive to look at this data and identify user pain points early? Is the product data easily accessible to your team? Have you built a culture of data-driven product development? Do you spend enough time and resources to run product analytics as a part of your development process? If the answer to any of those questions was no, then keep reading!

Based on my personal experience, I will describe how you as a PM can drive data-driven product development and a step by step journey to building an internal data platform using minimum engineering resources. We’ll use the example of a product conversion funnel throughout the post since it is one of the most common metrics measured across SaaS software products.

So one of the challenges initially is the lack of product usage data since you have just launched your product. As a PM, you can only rely on qualitative data gathered from customer discovery interviews, feedback AND your intuition. Once you start acquiring users, you will need to start looking at and analyzing product usage data. Below is how you can start doing that organically and build a data-driven product development culture.

The first step is to identify and list your assumptions. Then create a list of data points you need to prove or disprove those assumptions. For product conversion funnel, identify the steps in the journey of the user and list the data points that represent the steps in that journey.

The second step is to ensure you can access and query your product data. In the beginning, you need to start querying the listed data points and model them manually to find insights. This will help you do two things — first, you’ll be able to identify gaps in data points being stored and second, if you are able to work through your assumptions with the given data or not. In the initial days, key steps in the user journey and required data points change frequently and hence you’ll have to do this manually till you have finalized those key steps and data points you need to look at.

The third step is to build basic APIs to query the data and model it in the required format. This will reduce your time to access and use the data as it will bundle multiple queries and data modeling into a single API call. I found it convenient to build these APIs using Python or Java but you can use any language that you are comfortable with.

The fourth and most important step in the journey is to start sharing the product usage data with your team. Until now you were the only one looking at the data and making decisions, but now it is time for your team to look at the data and understand your analysis deeply. Keep in mind that different stakeholders consume and understand data differently. They will try to interpret data that relates to their own function and will find it difficult to look at data holistically to understand the bigger picture.

For e.g. A salesperson might be interested in conversions from users to paid customers whereas a marketing person might want to know about users who signed up on the product from a landing page on the website. Hence, it is necessary that you communicate the insights that you want people to focus on along with the report that you will share with them. This communication should be simple, understandable and free from jargon.

You want your team to inquire and become proactive in asking for these insights. Once you get the ball rolling, you do not want to become the bottleneck between your team and their need to look at data before making a decision.

Finally, the fifth step is to connect the APIs with a visualization tool like Redash, Metabase, Looker, Tableau or Klipfolio. Access to a visualization tool like this can be shared across the team without compromising the security of your data or database. This has multiple benefits — first, these dashboards can be accessed by anyone on-the-go without any dependency.

Second, data on these dashboards will be updated in near real-time as you can specify the update frequency. Third, ease of access will ensure that product usage data is being looked at constantly and is no longer an ad-hoc activity.

You now have an internal data platform that supports one use-case. You can use the same methodology to extend it to any number of use-cases. This journey might take anywhere between 3–5 months. You need to start small and build only what is required. Premature optimization by creating an internal data platform directly is bad as it consumes an unnecessary amount of time and resources. It never gets adopted because your team never had the opportunity to look at the data when the product was getting built and data-driven product development is no longer a part of the culture.

While you are trying to use data for your improving your product, here is how you can avoid bias in decision making.

As a product manager, you are responsible for defining the DNA of the product and how the team operates!

Have any thoughts, comments or feedback? Feel free to share it below :)

Previously published at https://medium.com/@tanayagrawal19/5-steps-to-build-a-data-driven-product-development-culture-fff0d32fe624