Bridging Data and Product Management Practises and Patterns with Juha Korpela
AgileData Podcast #52
Join Shane Gibson as he chats with Juha Korpela on how to adopt patterns and practises from Product Management and apply them to the data domain.
Listen
Listen on all good podcast hosts or over at:
Read
Read the podcast transcript at:
https://agiledata.io/podcast/agiledata-podcast/bridging-data-and-product-management-practises-and-patterns-with-juha-korpela/#read
Google NoteBookLLM Briefing
Briefing Document: Bridging Data and Product Management
Source: Excerpts from "Bridging Data and Product Management Practises and Patterns with Juha Korpela - AgileData.io" Podcast
Introduction
This briefing document summarises the key discussion points from the Agile Data Podcast featuring Juha Korpela and Shane Gibson. The podcast explores the application of product management practices and patterns to the data domain. The conversation highlights the need for data teams to adopt a product mindset, moving away from reactive ticket-taking to proactive value creation, and applying established product management methodologies to the data space.
Key Themes and Ideas
Product Management Principles Applied to Data:
Strategic Alignment: Product management involves understanding the organisational strategy and ensuring products align with and enable that strategy. As Juha stated, "How do we get where we want to get, what is the vision of the whole thing? How do we get there?"
Strategic vs Tactical Product Management: In larger organisations, there are different levels of product management.
Strategic: Focus on the 'where are we going?' aspect.
Tactical: Focus on 'what do we do next?'.
Data's Role: While product companies have the product as their core focus, data typically supports other strategies. However, Juha argues, "the gap between kind of business strategy and data strategy shouldn’t be as wide as we usually see it." The business strategy should inform the data products.
Understanding the Business: Data professionals must understand how the business makes money. As Juha put it, "everyone should actually understand that." They need to see the inputs, processes, and outputs to make informed decisions about data product development.
Focus on Decisions, Not Just Data: The focus should be on "what decisions should we support?" and providing decision-makers with the data they need for better outcomes. This means "ask[ing] why enough" to link data products to actual business decisions that create value.
Moving Beyond Ticket-Taking:
Reactive vs. Proactive: Traditional data teams often act as "ticket takers," responding to requests for data. A product management mindset shifts this to being proactive, identifying opportunities and problems to solve. As Shane stated, "We don’t approach it with that product management mindset of let’s go find. The opportunities in the organization. Let’s see where, things are broken. Let’s find something we can fix."
Feature Factory Mindset: Avoid building just whatever is requested. The podcast warns against becoming "feature factories that take in requests and you just keep building," without understanding the ‘why’ and if it applies more generally than a specific case.
Finding Value: Instead of just pushing data, focus on "actually understanding the problem that we need to be figuring out."
Data Strategy vs. Product Strategy:
Business-Driven Data Strategy: A data strategy should be derived from the business strategy and focused on how data can support specific business goals.
Technology is Not Strategy: Data strategies should not just focus on technology and architecture but "clearly identified value creation points." It is not just about "we want to play around with these tools," but identifying how data can help the business.
Internal Market Segmentation: Treat internal business units as customers and segment the organisation to determine areas of focus, considering who will be most open to support. As Shane proposed, "We can do segmentations of our businesses, our organizations to treat them as separate companies."
Product Roadmaps for Data:
Importance of Roadmaps: The existence of a roadmap is "one of the key aspects or signs that you’re actually doing product management." Without a roadmap you are in that reactive ‘feature factory’ mode.
Pathway to Vision: Roadmaps should be a pathway towards a long-term vision, solving problems in a logical order, rather than just a list of features.
Balance between Value and Platform: There should be a balance between delivering "user-facing things that actually solve problems" and "platform things" that enable future capabilities. As Juha says, "You have to be doing something that is short term also valuable."
Platform vs. Data Themes: Roadmaps can be segmented into platform capability themes and data themes, aligned to domains or business processes.
Team Topologies: Consider applying Team Topologies for team structures.
Funding and Resource Allocation:
Clear Value Articulation: The product manager should clearly articulate "what you can do with the budget that you have been given," explaining how changes to funding affect delivery and timelines.
Focus on Value Delivery: Product managers should focus on the end of funding for a piece of value, and move onto the next most valuable thing rather than just 'doing it till its done', taking accountability for delivering that value.
Product Owners vs Product Managers: Consider the difference. Product Owners are more focused on the delivery, whereas the Product Manager role is more forward-facing and accountable for the value.
Team Design:
Data Team Structure: Organisations may not have the structure that is conducive to data product thinking, and may still have centralised engineering teams. This needs to be addressed in some way. Applying a product-based approach highlights the need to rethink the structure of data teams and how they're organised, rather than just sending tickets to engineering.
Product Management Led Team Design: The data product manager should be involved in how the team is structured rather than another leader. If a team is not involved in how the product is built, how can the team run the product?
Prioritization and Decision-Making:
Input and Balance: Product managers gather input from stakeholders but are ultimately responsible for balancing priorities and making decisions on what's next. As Juha said, the product manager "has to take all of that in."
Stack Ranking: Consider a strict ranking system to focus the team. This allows for flexibility of reprioritisation of lower priority items while protecting the current work in progress.
Proactive Engagement: Product managers should actively seek input from users and influencers to generate ideas and proactively seek opportunities instead of waiting for requests to come through.
Accountability: The data product manager should be making decisions rather than pushing it to a committee.
Product Requirements:
Lightweight Requirements: Start with light requirements to understand the scope of work, prior to deeper analysis. Use a 'just in time' approach to prevent wasted effort.
Focus on 'Why?': Prioritise the ‘why?’ questions instead of focusing on the specifics of what datasets are needed.
Understanding User Needs: Understand the user's job, what they need to do, and how data can support that. Don’t over specify based on what people ask for, which may not be the solution they actually need. As Shane says, "I don’t need a jug because all I’m going to do is get the jug to boil water to make a coffee. I just want an espresso machine so it makes me a coffee and just happens to boil water when it does it. The job to be done is have a cup of coffee".
Requirements Match the Way you Work: Ensure that the level of requirement documentation reflects the way the teams are structured. The more handovers in the process, the more detailed the documentation needs to be,
Documentation for Posterity: Focus on maintaining documentation that allows users to understand the data product, its purpose, and its meaning.
Product Market Fit:
Solving Real Problems: This involves identifying and solving actual problems, and ensuring the problem is big enough to warrant a product.
Adoption Curves: A sign of product market fit is a demand and adoption of your product. If you're still having to 'pimp' your product or 'beg' for people to use it, then it doesn't have product market fit.
User Journey Focus: Understand the entire user journey, from problem identification to data utilization to identify how your product can assist the user more fully. Consider service design to create an end to end experience.
User Experience:
Both User Journeys: Map not just the user's job to be done, but also map the journey to purchase and utilise your product.
Data Catalog Experience: Ensure that a user can find a data product in a simple way. For example, that they can search for the types of data needed for a specific problem, and then be guided to use it. This means thinking about a glossary that does more than just a technical dictionary.
The Product Manager Role
Jira Ticket Warden? The role isn’t to play around with Jira tickets. The main point is to figure out how to deliver what is next, and if Jira is how that is managed then ok.
Vision: Should be in charge of the product vision.
P&L: Ideally, yes, but realistically, this can be difficult to track, unless data is directly being monetised.
Access Management: Should automate as much as possible, using policy-based access. If you can't automate, then the product manager can make these decisions if they are combined with the content ownership.
Prototyping: They should be involved in the decision to prototype, rather than the ‘how’.
Technical Role?: They should understand the ‘why’, but not need to be a deep technical role.
Not VP Role?: Often will be a role lower in the hierarchy, not a VP or C-level executive. It’s more about ownership of the product lifecycle than it is position in the organisation.
Differentiation: There is a different between the product owner (more delivery focussed) and product manager (strategy, roadmap, funding, prioritisation).
Knowledge Needed:
Software Development: A software product manager needs to understand the development process, but not necessarily the mechanics of it.
Data Development: The same applies in the data realm. The product manager should understand the process and basic logical architecture. They don’t need to understand the inner workings.
Mindset: The main thing is the mindset, and the best practices will follow from that.
Key Quotes
Juha: "How do we get where we want to get, what is the vision of the whole thing? How do we get there?"
Juha: "the gap between kind of business strategy and data strategy shouldn’t be as wide as we usually see it."
Shane: "We don’t approach it with that product management mindset of let’s go find the opportunities in the organization. Let’s see where, things are broken. Let’s find something we can fix."
Juha: "feature factories that take in requests and you just keep building,"
Juha: "actually understanding the problem that we need to be figuring out."
Juha: "what you can do with the budget that you have been given,"
Shane: "I don’t need a jug because all I’m going to do is get the jug to boil water to make a coffee. I just want an espresso machine so it makes me a coffee and just happens to boil water when it does it. The job to be done is have a cup of coffee".
Juha: "the mindset and then you go from there."
Conclusion
The podcast emphasises the importance of data teams adopting a product mindset. This involves proactively identifying opportunities, aligning data products with the business strategy, understanding the end user, and focusing on value delivery over simply providing data. Data teams can leverage established product management practices to become more effective and create greater value within the organisation. The key takeaway is not just about process, but about shifting the mindset.