MSBA practicum project reveals lessons in product management
You’ve heard of the new kids on the block, but how about the cool kids on the block?
Product management has joined data science as the coolest career kids in town, as demand for these roles explodes and they gain popularity among college students and new graduates. Data science followed that same path a few years ago.
I originally thought of product management as largely confined to customer-facing products. “Oh is she a product manager at Google? She must be the CEO of maps or something.” “Product manager at Lyft? Must be handling their bike rentals”.
However, my perception lacked scale and nuance. Products can be layered inside a larger product, such as various functions of a single app. For example, the payments layer of Amazon shopping is a product and has a product manager.
I have also come to realize that products in a company need not face only external consumers. Companies sometimes create products for internal use as well. That includes software and data products for internal analytics and these products span across business functions.
Through my practicum project, I realized that a self-serving and scalable source of data is a product in itself. And it needs as much thought, design thinking, scalability and customer obsession as an external product does.
These products also require constant feature additions, deployments, extensive engineering and focus on user interface and experience (UI/UX). Development, enhancement and management of data products are a product management vertical in itself. In fact, according to Harvard Business Review, the development of a data product follows all the components of the lifecycle of a traditional software product.
Knowing this really gave us an edge in our Master of Science in Business Analytics practicum project.
Building an Internal Tracking Product
Our team was fortunate to work in the highly-exciting and growing field of esports, assisting the Pittsburgh Knights team, which fields players in seven different competitive video game titles.
The data product that my talented team and I built is end-to-end. It scrapes data off of an API, incrementally pipelines it to a warehouse, which in turn supplies self-serving dashboards for stakeholders to gain insights on their players and teams.
This system is designed to operate at scale with the pipelines and dashboards developed being mindful of large amounts of data potentially being available in the future. The product pertains to only one game and therefore also aims to serve as a template for future data products intended to be built for other games.
Here’s how we did it:
- Gathering requirements: This is the birth of any product. Start with who needs the product? What is the problem that the product would solve? The industry-approved way of dealing with this step is to prepare what we call a product requirements document (PRD).
- SWOT analysis: If this product were to transpire, what would be its strengths and weaknesses? What are the opportunities for current and future enhancements? What are the threats that it could face, is it in danger of being a short-term requirement?
- Success metrics: What constitutes success for this product? How do we measure it? What are the trade-offs for these success metrics?
- Design, at scale: Now that we have gathered requirements, performed SWOT analysis and defined success, the next step is designing the product end to end. What should the customers’ journey look like? How do we make the product not only visually appealing but also experientially easy and intuitive to use?
- Infrastructure: What are the infrastructural requirements of the design? Where does the engineering happen, on-premise or in the cloud? Where should we host the warehouse? What are the pros and cons of using Tableau for data visualization? Infrastructure needs money which is why it is important to identify the right infrastructure for the product without spending stray money or undersupplying the necessary infrastructure.
- MVP: Once the necessary infrastructure is obtained, we start building. We build a minimum viable product for our stakeholders to tangibly utilize, experience and provide feedback.
- Build, build, build: The MVP is out of the way and we have obtained actionable feedback. Now it is time to build the actual product. This takes time and effort, and it is important to not lose sight of our stakeholders, their needs and the bigger picture when we get into the black hole of building.
- Test: Every stage of building needs to be accompanied with a round of testing. Test individual units, test the system as a whole and also involve the necessary stakeholders in testing to ensure that the product is working as expected.
- Productionize: It is time to put your product out there in the wild. Let its wings unravel and fly into the abyss as a self-serving and scalable solution to people’s problems.
- Document: While the product is working in the outside world and gaining traction, use this time to document every line of code, every calculated field and every visualization of the dashboards that can be documented.
- Support: Add post-operative care to your product, and for our stakeholders after deployment.
We established that data products are necessary and important, but remember to treat them as assets. Invest time, money and resources in them. Do not compromise.
Any company that wishes to leverage data for their day-to-day decisions across all business functions (e.g. marketing, sales, operations, human resources) can benefit from a centralized data team that focuses on building scalable products.
If the company’s maturity is conducive to it, add product managers as well. They serve as a liaison between the development-minded engineers, analysts and scientists, and the business-minded business managers.
Understanding requirements, how data can solve problems, and how data products can solve these issues are skills that I believe are needed in data-driven organizations.
The next step would be to open up avenues for data governance and security.
The importance placed on data products can vary from one company to another depending on the nature of the industry and the startup’s own lifecycle. But the importance of early adoption and following the above steps is second-to-none. We’re thrilled we had this opportunity with the Pittsburgh Knights.