In this article I refer to BI reports and dashboards as data products. What makes data products unique is that they focus on the people and process side (Mohan). According to Jones, a data product is something that delivers value to hundreds of business users day in day out. The data product manager defines the product vision by articulating the problem the data product solves, who the target users are, the key benefits the product provides (Agarwal).
A data product manager should be concerned with whether a data product supports end users to deliver value in their roles and with low-friction user experience. Data product managers lie awake at night, staring at the ceiling and asking themselves, "Is what I designed delivering the maximum possible value? Could I have improved the user experience better? Are there people using my product frustrated by the interface?"
This article will cover how to deliver business intelligence products like a product manager. First, a data product developer must develop a roadmap to follow in the development process. Next, the developer must gather inputs to follow within the roadmap through the user interview process. Finally, the developer will follow the roadmap to deliver a data product that solves the user’s problem.
Create a Roadmap to Follow
The roadmap is critical to successful product development since it prevents divergence from the path to execution. Create a data product roadmap to guide your long-term development plans about the kind of data products you want to create for the business and users. Remember, the goal of a data product is to engender higher utilization of “trusted data” by making its analysis easier by a diverse set of consumers. (Mohan). Start with the business goals, and blend that in with the user needs and requirements. In my roles, the most common business goals and objectives were customer revenue growth, customer acquisition and retention. Other company goals could be reduction of costs, increasing profit margins, decreasing surplus stock, lessening customer churn, creating a sales incentive program, or monitoring market share.
Now that the goals are defined, determine the steps required to build a data product that answers the specific questions generated by those goals. For example, if an end user wants to use a data product to answer questions about customer acquisition and retention, then list out the types of questions that need to be answered. That list of questions will guide the developer where to source the data needed for reporting. You can see how understanding the goals guides the steps in the development process. Identify the questions and then trace back those questions to the data warehouse to confirm all required data is available. Partner with IT to access available data sources while negotiating a timeline on obtaining currently unavailable data sources. Return to the business to inform them of what data is available, what isn’t available, and recommend ways to address information gaps. Once there I consensus on what can be built with available data sources, the developer gets started on the development process.
When an end user comes to you with a data product build request, do not skip the discovery! As a data product creator, you are responsible for asking and understand WHY a user wants a data product, so you can build the best version that suits their needs. You should be able to be able clearly explain the benefit to users if you want them to use it, and how it meets their needs. The roadmap is critical before any data product development begins. It will lead to less confusion, faster development times, and less rework during the process. Since consensus with the business was committed to earlier in the process, there is no surprise product delivered in the end. Users get what was expected leading to lower dissatisfaction post-deployment.
Conduct User Interviews to Enrich the Roadmap
Now that objectives are defined, we must have difficult conversations about whether each data product is delivering its expected value in a seamless way. Osian Llwyd Jones, Head of Product and Platform Experience at Stuart offers three simple questions to ask each time a new dashboard is created:
1. Is what we're doing truly adding value?
2. Do we know our users and their needs?
3. Are they getting insights in a fast and reliable way?
Being objective and honest about how effective your data products are empowering end users to reach company goals is the differentiator between good and bad data products.
This mindset needs to be long-term too, meaning we can't get caught up doing low value work that distracts us from building and delivering great data products. Setting service level objectives for your PBI products keeps developers focused on building high value products.
Leaning into the end-users
Juan Sequeda1 states we need to include people and processes in addition to technology to modernize and enhance our data management efforts. When building a data product, it is critical to define objectives along with the users, and defining the purpose ahead of building.
Jones recommends being in a state of continuous discovery of user needs, pain points, and desires then shape your data products around those needs. Once you understand their motive and intent, then you can build a product that aligns with the way they work and the information they need to know. Once you deeply understand the users and their needs, use that knowledge to guide data product development. It’s best to obtain feedback during the development phase and prioritize must haves, nice to haves, and not required based on the value they deliver to the business.
User interviews are a terrific way to partner with users because developers learn how the user works and what they want to achieve. An additional benefit to user interviews is users feel engaged in the process and have a sense of ownership of the final product deliverable. I genuinely want to understand who the consumers are, how they will use it, and what outcomes do they want to achieve when using it. Having a list of prepared questions can make the process more efficient by reducing the amount of time spent discovering the true purpose of the data product.
Follow the Roadmap During Development
Before you build anything, make sure you're clear on the purpose of the data product. If a sales team is trying to drive sales growth, then evaluate the final product that delivers insights into sales growth trends and tracking. Clearly define how an objective is measured and design the product to be insightful about the direction that objective is headed. Review the requirements up front to think about different user persona's experience with the product. Evaluate different proof of concepts with different personas and scenarios in which the product can address the pain points expressed.
Sequeda recommends a data product framework that guides the development process. The framework is meant to highlight the challenges involved in product development. It offers recommendations on how to address each issue as it arises. People and processes are identified to handle the problems. Having resources committed to eliminating issues during the development process leads to higher probability of successful execution. The components of this framework are
Accountability - ownership and responsibility for the data product
Boundaries - defining the Data Product and its interfaces
Contract expectations - defining what makes the Data Product "good"
Downstream consumers - understand the users and programs that depend on the data product
Explicit knowledge - making the meaning and semantics of the data product clear
The project is not finished after the first iteration because follow up is required to iterate and improve the data product. A data product is not complete until the intended users can do their work effectively and efficiently while staying aligned with department and company goals.
Conclusion
A data product manager isn't content until the product they oversee delivers the ultimate user experience. The job is not always easy and requires support from multiple stakeholders. A data product manager not only has to guide the development process to success but will then be expected to sell the benefits of said product to drive adoption. If you want to deliver an amazing data product experience, then be prepared to fight for what you know is right.
A data product development project is a multi-phased process where users are interviewed, innovative ideas are generated, product ideas are prototyped, users engage in multiple stages, and finally a product is assessed to ensure alignment with a clear definition of success. The data product manager needs to gather feedback from customers, create requirements and use cases from end-users, define a roadmap, create a plan, and manage releases (Sequeda). Only when the data product delivers the full agreed upon value is when it is truly finished.
References
1 Sequeda, J. (2022). Data Science Central. The Data Product ABCs – A Framework for Bringing Product Thinking to Data. Datasciencecentral.com. Accessed on 09/16/2024 at https://www.datasciencecentral.com/data-product-framework/
2 Mohan, S. (2022). Forbes. What is a Data Product and What Are the Key Characteristics. Forbes.com. Accessed on 09/16/2024 at https://www.forbes.com/sites/forbesbusinesscouncil/2022/09/21/what-is-a-data-product-and-what-are-the-key-characteristics/?sh=77ea0f6162c5
3 Jones, O. (2021). Medium. How We’re Building Our Data Platform as a Product. Medium.com. Accessed on 09/16/2024 at https://medium.com/stuart-engineering/how-were-building-our-data-platform-as-a-product-f89142b6547f
4 Moses, B., Gupte, A. (2020). Monte Carlo Data. How to Build Your Data Platform Like a Product. Montecarlodata.com. Accessed on 09/16/2024 at https://www.montecarlodata.com/blog-how-to-build-your-data-platform-like-a-product/
5 Agarwal, A. (2023). Medium. Product Roadmap Vs. Data Product Roadmap. Anujxagarwal.medium.com. Accessed on 09/16/2024 at https://anujxagarwal.medium.com/product-roadmap-vs-data-product-roadmap-7117c79aa199