Kevin Holland
Product Leader @ Holmusk | Data Products, Healthtech, Consulting | MBA @ Kellogg | MicroSaaS +SwaS
Beyond the Product Trio - Why Data Products Need a Squad
Data products need more than a trio.
Growth is driven by compounding, which always takes time. Destruction is driven by single points of failure, which can happen in seconds, and loss of confidence, which can happen in an instant. - Morgan Housel, Psychology of Money
The Team Behind Market Profiler
In my second year at Revive, I was tasked with turning a one-off healthcare market analysis project into a scalable product offering. We'd delivered a bespoke market analysis to a regional health system that had generated significant strategic impact, and leadership wanted to create a repeatable data product that could be sold to multiple clients.
Armed with a PowerPoint, Tableau workbook, and an analyst who'd crafted some impressive Alteryx/Python data pipelines, we gathered to map a way forward
The kickoff meeting included our typical product development cast: me as Product Manager, a Tech Lead responsible for implementation, and a Design Lead to craft the user experience. This tried-and-true "Product Trio" had successfully launched numerous healthcare marketing campaigns and products before.
But something wasn't clicking.
"How confident are we in the predictive model's accuracy across different market types?" asked the Tech Lead.
"What about demographic blind spots? Rural markets have different data coverage than urban ones," noted the Designer.
"And the ethical implications of giving health systems competitor intelligence? What are the elements missing between the claims, EHR, and other data sources we are considering? Are we sure about this?" I wondered aloud.
While I had the coverage and experience previously, I needed support and deep data expertise. Not just coding skills or database knowledge, but someone who who had seen healthcare data's nuances, limitations, and ethical boundaries.
The next week, I added a Data Lead to our core team - a data engineer. We moved faster and with more certainty from then on.
This was top of mind when building the next product and the team supporting it. We needed more than the standard trio of leads - we needed a squad.
The Traditional Product Trio
For years, the product development world has operated with a well-established core team structure known as the Product Trio:
- Product Manager: The voice of the market, business, and strategic direction
- Tech Lead: The technical feasibility and implementation expert
- Design Lead: The user experience and interface architect
As Teresa Torres describes it, "A product trio is typically comprised of a product manager, a designer, and a software engineer. These are the three roles that—at a minimum—are required to create good digital products."
This triad works beautifully for traditional software products. The PM understands what to build, the Tech Lead knows how to build it, and the Design Lead ensures it's intuitive and enjoyable to use.
For a typical SaaS product, this structure covers the essential disciplines needed to take a product from concept to market. Technical feasibility questions focus on software engineering challenges: Can we build this feature? How long will it take? Will it scale?
But data products are different beasts entirely.
Enter the Data Product Squad
Data products—whether dashboards, predictive models, recommendation engines, or AI-powered tools—have unique complexities that the traditional trio isn't equipped to fully address.
Enter the Data Product Squad:
- S: Strategic
- Q: Quality-focused
- U: User-centered
- A: Analytical
- D: Data-driven
At its core, the Squad consists of four essential leaders:
- Product Manager: Still the market and business expert, but with awareness of data's unique challenges
- Tech Lead: Focused on system architecture, API design, and overall implementation
- Design Lead: Creating interfaces that make complex data intuitive and actionable
- Data Lead: The data science, engineering, and ethical governance expert
The Data Lead isn't an optional add-on or a nice-to-have consultant. They're an essential fourth pillar in data product development—equal in importance to the other three roles.
The Five Risks of Data Products
Why is this fourth role so critical? Because data products face a risk profile fundamentally different from traditional software.
In his classic work on product risk, Marty Cagan of Silicon Valley Product Group discusses the "Four Big Risks" that all product teams must address:
- Value risk: Will customers buy it or users choose to use it?
- Usability risk: Can users figure out how to use it?
- Feasibility risk: Can our engineers build what we need with the time, skills, and technology we have?
- Business viability risk: Does this solution work for the various aspects of our business?
For traditional products, the Product Trio maps cleanly to these risks:
- The Product Manager addresses value and business viability risks
- The Designer handles usability risk
- The Tech Lead tackles feasibility risk
But data products introduce a fifth critical risk:
5. Ethical Data Risk
This encompasses:
- Accountability for algorithmic decisions
- Representativeness of data
- Fairness across populations
- Transparency and explainability
- Data privacy and governance
- Long-term impact and unintended consequences
This fifth risk doesn't map neatly to the traditional trio. While product managers might understand the business implications, designers might consider the user experience impact, and engineers might recognize some technical limitations, none are typically equipped to fully own this critical risk dimension.
That's where the Data Lead becomes essential.
Technical Feasibility Risk (Reimagined)
Even the nature of feasibility risk is different for data products:
In traditional software development, technical feasibility usually centers on engineering challenges: Can we build this feature? How much will it cost? How long will it take?
For data products, feasibility questions are more complex:
- Do we have enough high-quality data to train this model?
- Can we get acceptable accuracy across all key demographics?
- Is real-time prediction possible given our infrastructure?
- How do we handle data drift over time?
These questions require deep expertise in data science, data engineering, and the specific domain's data landscape. A traditional Tech Lead, while brilliant in software engineering, often lacks this specialized knowledge.
Ethical Risk (Expanded)
The ethical dimension permeates data products, especially those using AI/ML:
- Are we accidentally encoding bias in our algorithms?
- Are our recommendations creating harmful incentives?
- Do our visualizations inadvertently mislead users?
- Are we properly protecting sensitive data while still deriving value?
- Can we explain how our model makes decisions?
- Do we have proper measures to monitor, detect, and mitigate failures?
These aren't just hypothetical concerns—they're existential risks for data products. One ethical misstep can destroy trust permanently.
As the quote at the beginning reminds us: growth compounds slowly, but destruction can happen in an instant. For data products, that destruction often stems from ethical oversights that a traditional product team might miss.
Market Profiler: The Squad in Action
Returning to our Market Profiler example, adding a Data Lead transformed our approach in several crucial ways:
First, our Data Lead immediately identified critical limitations in our demographic data sources. Rural zip codes had significantly less reliable commercial data than urban ones, creating a blind spot that could lead healthcare clients to underinvest in underserved communities. We hadn't fully recognized this issue in our one-off project, but scaling it as a product would have magnified the problem.
Second, he challenged our machine learning approach for predicting service-line growth opportunities. Our initial model used classic propensity scoring, but she demonstrated how this could inadvertently prioritize wealthy, well-insured patients over those with greater needs. We pivoted to a more balanced methodology that considered both commercial opportunity and community health impact.
Finally, he designed a data governance framework that allowed us to provide competitive intelligence without crossing ethical boundaries around protected health information. This included specialized aggregation techniques that prevented reverse-engineering of sensitive metrics.
The result? Market Profiler evolved from an interesting analytics project into a responsible, ethical data product that hospitals could confidently use for strategic planning. Within a year, we had signed contracts with a half dozen health systems—far exceeding our original projections.
The NeuroBlu Experience
At Holmusk, I witnessed a similar pattern with our flagship product, NeuroBlu Analytics. When I joined, the team was structured around the traditional Product Trio model, with data scientists consulted as needed but not integrated into core decision-making.
Early versions of the product faced challenges:
- Data models were technically sound but difficult for non-technical healthcare researchers to use
- Visualizations were beautiful but sometimes misrepresented statistical significance
- The platform excelled at showing correlations but offered little guidance on causation risks
As we evolved toward a Squad approach, with a dedicated Data Lead as a core team member, these issues began to resolve. The Data Lead became our ethical compass, constantly asking questions like:
- Are we providing enough context for these findings?
- Could this visualization lead researchers to draw inappropriate conclusions?
- Are we properly communicating the limitations of real-world evidence?
This shift accelerated our platform's adoption among life science companies—groups that need a ton of support to over come general skepticism of our commercial real-world evidence approach. They recognized and respected the ethical rigor our Data Lead brought to the product.
Building Your Own Data Product Squad
If you're developing a data product, how do you implement the Squad approach?
1. Elevate data expertise to leadership level
The Data Lead isn't just a technical contributor—they need authority equal to the other leaders. They should be present for strategic decisions from day one, not consulted afterward.
2. Look for T-shaped data expertise
The ideal Data Lead has depth in one area (e.g., data science, data engineering, data visualization or data governance) but breadth across the entire data lifecycle. They should understand enough about each area to identify risks and ask the right questions.
3. Value domain knowledge
Domain expertise is particularly critical for the Data Lead. In healthcare, for instance, understanding HIPAA, clinical workflows, and healthcare economics is as important as technical skills.
4. Create clear decision rights
Define which team member has final say in which areas. The Data Lead should have veto power on issues of data quality, model performance, and ethical use.
5. Establish data ethics principles
Work as a Squad to define ethical boundaries before you're faced with difficult tradeoffs. Document these principles and review them regularly.
The Future of Data Product Teams
Marty Cagan recently published a thought-provoking vision for how AI might reshape product teams, predicting that "product discovery will become the main activity of product teams, and gen ai-based tools will automate most of the delivery."
But even in this AI-accelerated future, Cagan still sees the need for specialized roles: "product teams will need a product manager to solve for the many business constraints, a product designer to solve for the user experience, and an engineer to solve for the technology."
For data products, I'd argue the same logic applies to the Data Lead. As AI becomes more integrated into products of all types, the need for data expertise at the leadership level will only grow, not diminish.
The line between "regular products" and "data products" will continue to blur. Eventually, all digital products may need something like the Squad approach.
But for now, if you're explicitly building a data product—particularly one that uses machine learning, predictive analytics, or works with sensitive information—the traditional Product Trio isn't enough.
You need a Data Product Squad, with the Data Lead as an essential fourth pillar.
Because data products don't just carry technical and market risks—they carry ethical risks too. But at the end of the day - not much is different. You still need to figure out what and how to build and distribute something that users value.
The Questions Nobody's Asking
- How do we measure the impact of ethical data product decisions on long-term customer trust?
- What skills and training do Product Managers need to work effectively with Data Leads?
- How does the Squad approach scale across multiple product teams in larger organizations?
- In an AI-augmented future, will the Data Lead become even more critical as ethical risks multiply?
- How do we balance innovation speed with ethical risk management in data product teams?
Would love to hear your thoughts. Have you seen the need for a dedicated Data Lead on your data product teams? What challenges have you faced when developing data products with traditional team structures?
Why Data Product Managers Need Their Own Positioning Framework
"Positioning defines how your product is a leader at delivering something that a well-defined set of customers cares a lot about." - April Dunford
When I started my journey in data product management, I faced a reality that many technical folks encounter: we're really good at building things, but sometimes terrible at explaining why anyone should care.
I once watched a brilliant data science team build an incredible patient flow optimization tool for a hospital system. It used cutting-edge algorithms, beautiful visualizations, and could accurately predict staffing needs 48 hours in advance with 94% accuracy.
Nobody used it.
Why? The positioning was all wrong. The team pitched it as "a machine learning model that predicts staffing requirements using time-series forecasting of patient flow metrics." The hospital executives needed "a cost-saving tool that reduces overtime expenses while maintaining quality care standards."
Same product. Completely different positioning.
If you're a data product manager (or leading a team that builds data products), you face unique positioning challenges that traditional software PMs don't encounter. The frameworks they use simply don't account for the complexities of communicating data value.
Positioning as Context-Setting
Positioning expert April Dunford describes positioning as "context-setting for products" – like the opening scene of a movie that orients viewers to what they're about to experience. Note: April has an incredible quickstart guide for positioning available here. When you position your data product, you're setting off powerful assumptions about:
- Who your product competes with
- What features your product should have
- Who the product is intended for
- What the product should cost
Good positioning creates assumptions that are true. Bad positioning creates assumptions you'll spend months trying to undo.
For data products specifically, this is critical. Say "analytics dashboard" and stakeholders immediately assume certain things. Say "operational risk prediction system" and they assume something completely different – even if both descriptions refer to the same product.
Why Data Product Positioning Is Different (And Harder)
The uncomfortable truth is that most data products fail at positioning for some predictable reasons:
- The curse of knowledge - When you've spent months cleaning datasets and fine-tuning algorithms, it's hard to remember what it's like not to understand the technical achievement.
- Multiple stakeholder perspectives - A CFO, a frontline manager, and a data analyst will all see your product through different lenses, requiring different positioning.
- Invisible competitors - You're not just competing with other data products; you're competing with Excel, gut feelings, and the status quo.
- The capability trap - Data teams love to talk about what their product can do rather than what problems it solves.
I've seen brilliant data products die quiet deaths because they couldn't cross the positioning chasm. The good news? A structured framework can help.
A Customer-Centric Approach to Positioning
Traditional positioning exercises often start with a "positioning statement" – a fill-in-the-blank template that assumes you already know your category, competitors, value proposition, and target customers.
But as April Dunford points out in her work on positioning, this approach is backward. You can't create effective positioning by starting with the statement. You need to work through a methodical process to discover your best positioning.
For data products, this process becomes even more critical because of the inherent complexity and the technical-business translation challenge.
The Five Components of Positioning for Data Products
Dunford's framework breaks positioning into five key components that build on each other:
- Competitive Alternatives - What would customers do if your data product didn't exist?
- Unique Attributes - What do you have that alternatives don't?
- Value for Customers - What value do those unique attributes enable?
- Target Customers - Who cares a lot about that value?
- Market Category - What context makes your value obvious to those customers?
Let's apply this specifically to data products:
1. Identify True Competitive Alternatives
For data products, the most dangerous mistake is defining your competitors as other data products. In reality, your true competition is often:
- Manual Excel analysis
- Weekly status meetings
- Gut-feeling decision making
- Email-based reporting
- Outsourced analytics services
- Doing nothing at all
In healthcare settings, I've seen data products position themselves against "traditional BI tools" when they should have positioned against "the monthly manual chart reviews that PA's (physician assistants) hate doing."
With a Chamber of Commerce project, board members were using quarterly PDF reports, while business leaders were cobbling together information from multiple government websites. Two completely different alternatives that required different positioning strategies.
2. Highlight Genuinely Unique Attributes
Once you understand what you're replacing, identify what your data product has that those alternatives don't. For data products, differentiators often include:
- Real-time data processing capabilities
- Cross-system data integration
- Advanced anomaly detection
- Automated pattern recognition
- Predictive modeling
- Contextual recommendations
The key here is to focus on attributes that are actually unique compared to the true alternatives – not just features that sound impressive.
3. Translate Attributes to Value
This is where data product teams typically struggle most. Technical capabilities must be translated into value that business stakeholders understand. Instead of "faster" and "more accurate," frame advantages in terms of:
- Operational value: Saves time, reduces errors, simplifies workflows
- Strategic value: Enables new capabilities, uncovers hidden opportunities, reduces risk
- Transformational value: Changes fundamental business models, creates new revenue streams
When we repositioned our healthcare revenue analytics tool from "more accurate prediction" to "prevention of $3.2M in denied claims annually," suddenly the CFO started showing up to our demos.
4. Identify Who Cares Most About Your Value
Not all potential users will value your data product equally. Identify segments that care deeply about the specific value you provide.
When building a patient experience data product, we learned that Chief Patient Experience Officers needed radically different information than CEOs or nursing managers:
- For CEOs: Positioned as an executive decision support tool connecting patient satisfaction to financial outcomes and competitive positioning
- For Nursing Managers: Positioned as an operational improvement tool identifying specific service recovery opportunities
- For Chief Experience Officers: Positioned as a comprehensive analytics platform supporting detailed program development
Each required different language, different metrics, and even different UX patterns.
Remember: Data products that try to serve everyone equally end up serving no one effectively.
5. Choose the Right Market Category
Your market category creates the context for how people understand your product. For data products, the right market category isn't always obvious.
When working with a Chamber of Commerce on their economic development data product, we initially positioned it as "an interactive data visualization tool for economic indicators." After repositioning it as "a business expansion decision support system that quantifies market opportunities," engagement with local business leaders increased dramatically.
Be cautious about creating entirely new categories. As Dunford notes, while it can be tempting to create a new market category (like "Decision Intelligence Platform" or "Operational Analytics Hub"), most successful tech companies position in existing markets first before stretching boundaries.
Applying This Framework: Before and After
Here's the before/after transformation of a positioning statement for a healthcare data product:
Before:
"An advanced analytics platform leveraging machine learning to provide multi-dimensional insights into patient satisfaction across service lines."
After:
"A decision support tool for hospital executives that transforms patient survey data into actionable improvement plans, replacing manual report analysis with automated priority identification that reduces time-to-improvement by 60%."
The second version answers all four key questions clearly:
- What is it? (A decision support tool)
- Who is it for? (Hospital executives)
- What does it replace? (Manual report analysis)
- Why is it better? (Reduces time-to-improvement by 60%)
The SLC Framework for Iterative Positioning
I'm a big believer in the Simple, Lovable, Complete (SLC) framework for product development. Your positioning should follow the same principle:
- Simple: One clear value proposition that anyone can understand
- Lovable: Addresses a painful problem in a way that resonates emotionally
- Complete: Covers what it is, who it's for, what it replaces, and why it's better
Common Data Product Positioning Pitfalls
In my years consulting with data teams, I've seen the same mistakes again and again:
- The jargon trap: Using terms like "machine learning," "predictive analytics," or "AI-powered" without explaining the actual benefit to users.
- The capability focus: Listing all the things your product can do without connecting them to user problems or goals.
- The all-things-to-all-people problem: Trying to serve everyone from data scientists to executives with the same positioning.
- The missing "so what" factor: Failing to make explicit why users should care about the insights your product provides.
- The phantom competitor trap: Positioning against competitors that your customers don't actually consider, rather than positioning against what they'd genuinely do without your product.
A simple test: If you read your positioning statement to a non-technical stakeholder, would they immediately understand what problem you solve and why it matters to them?
Apply This Framework Today
Want to improve your data product's positioning right now? Here's a quick-start template:
[Product Name] is a [product category] for [specific target audience] that [key problem it solves] by [how it works] unlike [main alternative], which [key limitation of alternative].
For a healthcare claims analytics product, that might be:
ClaimSight is a denial prevention tool for hospital revenue cycle managers that reduces claim rejections by 32% by predicting likely denials before submission, unlike traditional claims scrubbing software, which only checks for technical errors after claims are prepared.
When working with your team, ask these questions:
- What would our customers do if our solution didn't exist?
- What unique capabilities do we have compared to those alternatives?
- What value do those capabilities create for customers?
- Which customer segments care most about that value?
- What market category makes our value obvious to those customers?
The Bottom Line
As April Dunford puts it, positioning is not just marketing fluff – it's the bedrock of your go-to-market strategy. For data products specifically, it can make the difference between a technically impressive solution that nobody uses and a business-critical tool that transforms organizations.
How you position your product determines what features you prioritize, how you design the interface, and which stakeholders you engage. Great data products speak human, not just machine. They translate complex analytics into language that resonates with real people trying to solve real problems.
The next time you're building something brilliant with data, remember: your sophisticated algorithms deserve equally sophisticated positioning.
Check out more of April's work at aprildunford.com
Building products and companies is about managing continuous uncertainty.
You never know enough about the customer, market, competitors, and world at a point in time. Technology and possibilities are constantly changing. The competitors are doing their best to cut you off at the knees and redefine a market. Your customer has personal preferences and is influenced by shifting tastes. It's impossible to understand it all at once.
"Managed chaos" is real in startups and products. The extremes of "plan and research every detail" and "YOLO" aren't the answer - it's somewhere in between.
So what does that look like?
Especially in complex product or startup markets (B2B, data, international B2C) - what do you do?
The 5D Product Framework: An Overview
The Design Council in 2004 released the Double Diamond into the design world. If you have been in design, startups, or marketing - you would be familiar with the Double Diamond.
It's a process of moving from exploring (divergent thinking) to defining (convergent thinking). It's a continuous process - never fully static - moving from discovery to decision then back as needed.
While the framework generally applies to any design scenario (which products and companies are inherently designed), it always struggled when I shared it broadly. The general applicability, a blessing in many ways, can be a curse. The Double Diamond often was met with "ok but how does this apply to me and what next?"
So introducing:
5D Product Framework
Define > Discover > Design > Develop > Decide
This framework is an attempt to put context, flow, and expectations to the inherently fluid process of "deciding what to build".
But the core is simple - talk to users, identify what to build, build, and repeat.
1. Define: Prioritize and Align
The first D is about getting your house in order. Just like in healthcare, you need a diagnosis before treatment. Define is your diagnosis phase.
Key Activities:
- Company + Product Strategy: Setting clear direction and scope
- Quarterly OKRs: Measurable goals that align with strategy
- Opportunity Solution Trees: Mapping problems to potential solutions
Tips for Effective Prioritization:
- Start with the "why" - what problem are you really solving? Why is this important to solve now for your users?
- A prioritization framework (such as RICE) is helpful to combat HiPPO (Highest Paid Person Opinion) issues but don't be a beholden to it. Prioritization requires looking at the full picture and making decisions - even if they seem irrational to someone on the outside
- Focus on one big bet per quarter - don't try to boil the ocean. You will do at best half of what you plan. It's ok.
Remember: There are only two criteria for product success:
- Does it solve a user's problem well?
- Does it help business move forward?
That's kind of it. Sorry 🤷🏻♂️
2. Discover: Problem Research and Solution Validation
- Activities: Customer Segmentation, Customer Interviews, JTBD Mapping
- Balancing problem discovery with solution validation
- Case study or example of successful problem research
This is where the rubber meets the road. Just like in data, garbage in = garbage out.
Key Activities:
- Customer Segmentation: Who exactly are we building for?
- Customer Interviews: What are their actual problems?
- Jobs To Be Done (JTBD) Mapping: What are they trying to accomplish?
The Discover phase is about balancing depth with speed. You're not writing a PhD thesis - you're trying to understand enough to take informed action. Get a sense of the use case and understand it deeply.
Case Study: Marketing Analytics Dashboard
When I was building analytics dashboards at a healthcare marketing agency, everyone wanted to "go big" - build flashy brand launches, complex visualizations, get perfect attribution, integrate external context.
But when we actually talked to users, they just wanted to answer simple questions:
- How are my campaigns performing?
- Where should I allocate budget?
- What's working and what's not?
Users don't "want the data" - they want insights and something to help them make progress in their decisions.
3. Design: Crafting the Product Experience
Design isn't just about making things pretty - it's about making them work. In healthcare tech, this is especially crucial. There is serious "low hanging fruit" in building intuitive data product interfaces and "giving people a dashboard" is not the answer.
Key Activities:
- UX Research: Understanding user workflows and pain points
- Design Sprints: Rapid ideation and validation
- High-fidelity Prototyping: Testing with real users
- Note: don't stop with 2-3 users, getting a diverse set of opinions from your customer personas needs to include 5-10 points of direct feedback. Don't lie to yourself.
The Iterative Process:
- Start simple
- Get feedback
- Refine
- Repeat
Pro tip: KISS (Keep It Simple, Stupid). Accept complexity when necessary, data products especially are by nature complex and you can't avoid this, but lean towards simplicity, design, and empathy. Run from "complicated".
4. Develop: Building and Preparing for Launch
Development is where ideas become reality. But remember - the goal isn't to build everything perfectly. It's to build enough to learn. Shoot for something that is Simple, Loveable, Complete.
Key Activities:
- Story Mapping: Breaking down features into manageable chunks
- QA/DevOps: Ensuring quality and reliability
- UAT: Testing with real users
- Feature Go-to-Market Planning: Preparing for successful launch
Common Pitfalls:
- Over-engineering solutions
- Perfectionism paralysis
- Feature creep
- Forgetting about the end user
5. Decide: Analyzing and Improving
The final phase transforms instincts into evidence, where your data infrastructure proves its real value and insights drive action. Success here means implementing systematic feedback loops that actually inform product decisions, not just collecting data for data's sake.
Customer Interviews: Getting qualitative feedback
- Run structured exit interviews with churned customers while scheduling monthly power user deep-dives to understand what works and what doesn't
- Track feature requests and patterns in a searchable repository, capturing verbatim quotes that illuminate real user needs - Interview Snapshots are gold for sharing this with leadership and others
- Build and maintain systematic feedback loops that connect directly to product planning > back to the beginning. Connect feedback into the Define phase.
Product Metrics: Measuring what matters
- Focus on actionable metrics that drive decisions: time to first value, core action completion rates, feature adoption velocity, and engagement depth scores
- Skip the vanity metrics (if you can) and build real-time dashboards with clear next actions, implementing anomaly detection that catches issues before they become problems
- Connect every metric to a specific product or business outcome that matters
Cohort Analysis: Understanding behavior over time
- Map usage patterns to revenue outcomes and monitor product stickiness to understand what keeps users coming back
- Build cohort analyses that reveal which user characteristics and behaviors predict success
Implementing the 5D Product Framework
Use it. Don't use it. Copy. Adapt it.
The goal is to "decide what to build", build it, and see if the market responds. Rinse and repeat.
Managing Uncertainty and Learning
- Strategies for reducing uncertainty throughout the product lifecycle
- How to maximize learning at each stage of development
- The role of experimentation and iteration in the 5D framework
Conclusion
Building products is hard. Building good products is harder. Building great products requires a framework that balances structure with flexibility.
The 5D Framework isn't perfect - no framework is. But it provides a path through the chaos, a way to manage the endless uncertainty of product development. It's helped me - hope it helps you.
Remember:
- Define, Discover, Design, Develop, Decide > repeat
- Data, LLMs, algorithms, systems aren't magic - they are tools
- Quality matters, especially in healthcare and other regulated industries
- Treat your users, data, and team well, and incredible things can happen
What's your take? How do you manage product development uncertainty? Let me know in the comments.
Additional Resources
Define
- Getting better at product strategy - Lennys Newsletter
- Product Strategy - Reforge
- Mission, Strategy, and Tactics - Boz
- Mission - Vision - Strategy - Goals - Roadmap - Tasks - Lennys Newsletter
Discover
Design
- PM - Design Partnership - Lennys Newsletter
- Building beautiful products - Katie Dill
- What is product design - Figma
Develop
- The engineering mindset - Will Larson
- Making better estimates with engineers - Jason Evanish
- Learning Track: Working with Developers - Technically Substack
Decide
Growth is driven by compounding, which always takes time. Destruction is driven by single points of failure, which can happen in seconds, and loss of confidence, which can happen in an instant. - Morgan Housel, Psychology of Money
Working with data requires holding two things true at once. You must constantly investigate, experiment, and explore while building certainty, understanding, and stability. It’s about trust. Bringing some order to chaos which is what data is.
General product management - a vague notion I know but think of any physical product or technical service - relies on the former truth with the latter coming as the investigation comes to a close.
When building with data, there is always something new with your input. The ground is shifting under your feet. It makes sense to flow with it.
Over the years of building data products and teams, I’ve found a couple of differences. Not massive but real. And worth talking about.
Core Focus & Responsibilities
- User-Centric DNA: Everything revolves around user needs and experiences
- Broad Scope: Lives at the intersection of engineering, business, and UX
- Qualitative Decision-Making: Heavy reliance on user feedback and market insights
Data Product Management:
- Data-Centric DNA: Data shapes every decision and feature
- Specialized Scope: Operates where engineering, business, and data meet
- Quantitative Decision-Making: Lives and dies by metrics and experiments
This is a dramatic simplification. A data product manager is a product manager first. Jason Cohen writes, “the role centers on deciding what to build.” It’s deceptively simple and a data product manager has to do the same. The difference lies in the material and constraints.
A SaaS PM is product focused and while they have to manage the business viability risk (can the business support and benefit from this product), they often have fewer hard constraints on what to build with.
The Skills Gap That Actually Matters
General PMs need:
- Market research chops
- Customer development expertise
- Business strategy understanding
- Basic technical knowledge
In addition to those core things, Data PMs require:
- Reasonable data science understanding
- Machine learning/AI experience
- Data governance appreciation
- Analytics proficiency
This is asking a lot of one person. True. Add in some element of data expertise and you have a future founder on your hands.
The demands are impossible. The job is technically impossible. That's why you are on a team. It's not on you but you need to bring context, creativity, and an ability to coach.
Team Dynamics & Collaboration
General PM Teams often include:
- Cross-functional squads (engineers, designers, marketers) helmed by the Product Trio (PM, Tech Lead, Design Lead)
- Customer feedback drives development
- Focus on feature shipping and user adoption
Data PM Teams:
- A similarly cross-functional squad but helmed by a Product Quad (Data PM, Tech Lead, Design Lead, and Data Lead) with data-centric specialists (data scientists, data engineers, analysts) added in
- Data quality drives development
- Focus on data accessibility and democratization
Data products are inherently more complex. Especially if they are B2B which 90% of them are. Balancing the quality risk along with the other four (value, usability, feasibility, and business viability per Marty Cagan) is just icing on the cake.
The Healthcare Reality Check
In healthcare, these differences become even more pronounced. When I was leading data product at Revive, we weren't just shipping features - we were shipping trust. We had to build the story for our healthcare partners while still maintaining strict controls on protecting patient data.
Healthcare B2B is "playing on hard mode". Building a data product in a regulated industry like US healthcare requires a focus on quality risk above all else.
Four Key Shifts That Nobody Talks About:
- The Risk Profile
- General PM: Ship (potentially) buggy code, push a fix
- Data PM: Ship bad data, lose trust forever
- The Success Metrics
- General PM: Usage, engagement, retention
- Data PM: Data quality, decision velocity, trust signals
- The Customer Journey
- General PM: "Wow, this is great!"
- Data PM: "I don't trust this yet... but maybe..."
- The Team Dynamic
- General PM: "When can we ship?"
- Data PM: "How do we validate?"
Looking Ahead
As AI and ML become ubiquitous, these roles will continue to merge. But the fundamental differences in approach - particularly around risk, trust, and validation - will remain critical. As noted in the lead quote, growth is compounding, in markets and products, but trust can be lost in an instant.
Every product will have data components. But not every product will be a data product. Understanding this distinction will be an important skill for the next generation of PMs.
The Questions Nobody's Asking
- How do we measure trust as a product metric?
- What does "move fast and break things" look like when data quality is non-negotiable?
- How do we build data products that balance innovation with reliability + trust?
Would love to hear your thoughts. What differences have you noticed between Data PM and General PM roles in your work?
What Meta's 2025 Restrictions Mean for Data and Product Leaders
Meta's new healthcare ad restrictions aren't just another privacy update - they're a fundamental shift in how we'll have to think about healthcare growth. Drawing from my years measuring health system campaigns at Revive Health, I break down what this means for data and product leaders, why CDPs mig
Risk is what you don’t see.
In 2021, when Apple dropped iOS 14.5 along with App Tracking Transparency (ATT), the digital advertising world scrambled. Folks adapted. But Meta's latest announcement about healthcare advertising restrictions feels different. More targeted - pun intended.
I spent years at Revive (FKA Revive Health) building and measuring ad campaigns for health systems. The game was always about precision - finding the right patients, measuring conversions, optimizing spend all while preventing patient health information (PHI) exposure. We obsessed over metrics like cost-per-acquisition and return on ad spend (ROAS).
But starting January 2025, that playbook is going through another big shift.
What's Actually Happening
Two weeks ago, Meta quietly dropped some shocking news on healthcare/healthtech advertisers. Through a series of targeted emails, they announced two levels of restrictions:
- Fully restricted: Healthcare provisioning properties (think patient portals, app domains)
- Partially restricted: Healthcare marketing properties (corporate sites, lead forms)
The key impact? If you're in healthcare/healthtech, you likely won’t be able optimize for conversions anymore - at least not native in Meta Business Portal. No more tracking form fills. No more measuring patient acquisition costs. No more retargeting based on specific conditions or treatments.
Note: There are a ton of unknowns for everybody and folks are trying to get straight answers so all of this may be irrelevant in a couple of weeks.
As Chris Turitzin noted in last week’s Health Tech Nerds roundtable:
”If you're not able to send low funnel events, that changes everything in the way that you run meta campaigns... trying to run non-conversion optimized meta campaigns will understand that they just don't work from a profitability stance."
Why Now?
This isn't just Meta being cautious out of the blue. As Yulie Klerman, former LiveRamp healthcare lead explained during the roundtable: "We've seen changes in the last 4 years and specifically the last on the state privacy regulation in the states. When they explicitly call out healthcare information... they're getting closer to GDPR."
The writing has been on the wall. GoodRx's FTC settlement. The HHS guidance on tracking technologies. The proliferation of state privacy laws.
Inside the War Room: Notes from Yesterday's HTN Roundtable
Sometimes the best insights come from rooms full of people trying to solve the same problem. Last Tuesday’s Health Tech Nerds roundtable felt like a war room planning session - equal parts strategy meeting and group therapy. With so much still unknown, it was a bit similar to an OpSec briefing with panelists and folks trying to get a sense of the “known knowns” and the “known unknowns”.
Four patterns emerged that tell the story:
1. The Platform Pivot
”Shift to top of funnel video," Brian advised, sharing wins from brand lift studies. "We know it works."
But it's not that simple. Moving up the funnel isn't just a tactical shift - it's reimagining what "conversion" means in a world where we can't track it.
2. The CDP Question
Brett Gailey dropped what might be the most important insight: "We're a CAPI & event obfuscation only shop. Our Meta rep communicated to us as not being directly impacted."
A glimmer of hope? Maybe. But it requires serious technical infrastructure - pay attention to the CDP players like those specific to healthcare such as Freshpaint or a newcomer - Ours Privacy as well as cross-industry players like Segment.
3. The Compliance Paradox
Yulie Klerman, who built LiveRamp's healthcare vertical, reminded us of an uncomfortable truth: Even if you find technical workarounds, you're swimming in increasingly regulated waters.
”It's not just Meta's rules," she warned. "It's state privacy regulations, HIPAA, and public perception."
4. The Size Split
Large healthcare companies will play it safe. But as Chris Turitzin noted: "Small startups... I don't think they have that same risk."
Different companies, different risk tolerances, different approaches. Startups are going to play fast and loose with these rules cause they are under a different reality than layer players. This is known risk (this has always been true) but pay attention to when these startups grow. Do they keep the same bad habits?
The Health & Wellness Gray Zone
Here's a fun riddle: When is a health company not a health company? According to Meta... it's complicated.
The definition of "health and wellness" feels like one of those Supreme Court obscenity cases - they know it when they see it. But for those of us building products and measuring campaigns, we need something more concrete.
From the roundtable discussion, here's what we know right now:
Meta defines health & wellness as properties "associated with medical conditions, specific health statuses, or provider/patient relationships." Think patient portals, wellness trackers for specific conditions, or anything tracking health outcomes.
But here's where it gets messy:
- A fitness app? Probably fine.
- A depression tracking app? Restricted.
- A vitamin company? Depends on the claims.
- A healthcare scheduling platform? Welcome to the gray zone.
As one Meta rep told a roundtable participant: "Most health supplement brands will not be affected, unless it is a prescription or for a specific disease." But another participant's supplement brand got flagged. Classic.
The secret seems to lie in condition specificity. The more condition-specific your product or marketing, the more likely you'll face restrictions. Likely more to come here but a lot of unanswered questions at the moment.
The CDP Plot Twist
Here's the fascinating thing about constraints/regulation in healthcare tech: they often create new winners.
When Apple killed mobile tracking, Mobile Measurement Partners (MMPs) became essential overnight. When GDPR hit, consent management platforms had their moment.
Now? It might be the CDP's (Customer Data Platform) time to really shine. Being a middleman and a way for advertisers to offload liability could be a goldrush for the best positioned players.
But not just any CDP. Healthcare needs something different than most other industries. As I learned at Revive tracking multi-touch attribution across health systems - you need infrastructure that understands both technical compliance and healthcare's unique dynamics.
What Makes Healthcare CDPs Different
Think about your typical CDP. It's built for e-commerce, B2B SaaS, maybe fintech. But healthcare? That's a different beast entirely:
Event Hygiene
- Regular CDP: "Track everything, figure it out later"
- Healthcare CDP: "Track precisely what matters, with clear governance"
Identity Resolution
- Regular CDP: "More data = better matching"
- Healthcare CDP: "Clean data = compliant matching"
Activation Workflows
- Regular CDP: "Push to all channels"
- Healthcare CDP: "Push with purpose and protection - likely with a confirmation step“
The New Technical Stack
Based on the roundtable discussion, here's what the winning stack might look like:
Foundation Layer
- HIPAA-compliant CDP (like Ours Privacy or Freshpaint)
- Event obfuscation engine
- URL redaction system
Processing Layer
- Custom conversion definitions
- Privacy-safe identity resolution
- Compliant activation rules
Activation Layer
- Meta CAPI integration
- Cross-channel orchestration
- Compliance monitoring
As Brett Gailey noted in the roundtable, teams using this kind of setup might be insulated from Meta's changes. But - and this is crucial - only if implemented thoughtfully. More importantly - no one really knows yet and its unclear if Meta is even sure.
The Data Product Manager's Dilemma
If you're a data product manager in healthtech, you're probably asking:
- "Do we build this in-house?"
- "Which CDP vendors truly understand healthcare?"
- "How do we maintain performance while increasing privacy?"
The answer? It depends on your scale. But here's what I learned measuring campaigns at Revive: sometimes the most elegant solution is the most boring one. It’s ok if its complex (that’s reality) but don’t settle for complicated.
Start simple:
- Map your conversion events
- Document your privacy requirements
- Build clean activation workflows
- Test and iterate with compliance in mind
The Path Forward for Data and Product Leaders
If you're leading data, analytics, or product at a healthcare company, here's your playbook:
Rethink Measurement
- Build proxy metrics that don't rely on direct conversion tracking
- Get creative with engagement signals
- Focus on top-of-funnel indicators that correlate with intent
The reality is you never truly had ROAS down - don’t kid yourself.
As John Wanamaker famously said:
Half the money I spend on advertising is wasted; the trouble is I don't know which half
Every function (even accounting + finance) deals in assumptions and abfuscations - marketing and product simply have more unknowns. Accept it and figure out how to move forward.
Strengthen First-Party Data
- Double down on owned channels
- Build better internal attribution models
- Create measurement frameworks that don't depend on platform data
Use this as an impetus to shift from the buy side over to the build side. Get a better handle on your own data and tooling while investing in owned channels. Don’t over-rotate but don’t be completely dependent on a company like Meta - they don’t care about you or your patients.
Explore Alternative Channels
- Test channels where healthcare isn't as restricted (but be careful!)
- Build cross-channel attribution models
- Focus on content engagement metrics
When I helped instrument campaigns at Revive, we discovered something counterintuitive: restrictions often revealed better channels we'd ignored. Some thoughts:
- Reddit: Shockingly good for healthcare discussions. Their ad platform is like Meta circa 2015 - less sophisticated but more permissive. Just watch the compliance as it’s easy to get in trouble here.
- Programmatic Healthcare Networks: Yes, they're expensive. Yes, they're old school. But they understand healthcare compliance better than any social platform.
- TikTok: Before you roll your eyes - their healthcare policies are still evolving. This is both an opportunity and a risk.
- Point-of-Care Networks: Remember these? They're having a renaissance moment.
- LinkedIn: Especially for B2B healthcare. They're the tortoise in this race - slow, steady, and surprisingly stable on privacy.
The secret? Build your measurement framework first, then pick your channels. Not the other way around.
The Bigger Picture
This feels like a tipping point. But maybe that's good.
Healthcare data has always lived in a world of constraints. HIPAA wasn't the end of healthcare marketing. Neither was the HITECH Act. Or state privacy laws.
Each time, we adapted. We got better and hopefully did better by our patients. We built smarter systems and maybe this pushes folks to go back to the basics - build a product or service that produces value for patients and a business that supports it sustainably.
What Happens Next
For data and product leaders, the next few months are crucial. The situation is going to change and hopefully, Meta will give folks more clarity ( to say nothing of the uncertainty on what brands
Ask yourself:
- How can we measure success without relying on platform data?
- What does "good" attribution look like in a privacy-first world?
- How do we balance growth with increasing privacy demands?
The answers might surprise you. They usually do.
Because sometimes the best innovations come from constraints.
And healthcare data products? We've been innovating around constraints since day one.
10 Uncommonly Useful Observations on Product-Market Fit for Data Products
Forget what you know about product-market fit for traditional SaaS—data products play by a different rulebook. In this post, I share ten uncommonly useful observations from my years in the healthcare data trenches, challenging conventional wisdom and providing a roadmap for success in the complex wo
As a veteran in the healthcare data product space, I've seen my fair share of successes and failures when it comes to achieving product-market fit. While many principles from traditional SaaS products apply, data products have their own unique challenges and opportunities. Here are ten uncommonly useful observations that can help you navigate the complex landscape of product-market fit for data products.
1. The "Aha!" moment is often delayed
Standard SaaS expectation: Users should have an immediate "Aha!" moment upon first use.
Data product reality: The true value of a data product often emerges over time as patterns and insights accumulate. Your onboarding process needs to set the right expectations and provide early wins while building towards the bigger picture.
2. Your product is only as good as your data sources
Standard SaaS expectation: Product quality is primarily determined by features and user experience.
Data product reality: The quality, freshness, and relevance of your data sources can make or break your product. Invest heavily in data acquisition, cleansing, and integration. Remember, garbage in, garbage out.
3. Customization is not just a feature, it's a necessity
Standard SaaS expectation: One-size-fits-all solutions with minor customization options.
Data product reality: Every organization's data landscape is unique. Your product needs to be flexible enough to accommodate diverse data structures, integration points, and use cases without becoming overly complex.
4. The sales cycle involves education and change management
Standard SaaS expectation: Demonstrate value quickly and close the deal.
Data product reality: Selling a data product often requires educating prospects on data literacy, changing existing processes, and aligning multiple stakeholders. Your sales process should include elements of consultative selling and change management.
5. Success metrics are often indirect
Standard SaaS expectation: Direct metrics like user engagement and feature adoption indicate success.
Data product reality: The true impact of your data product might be several steps removed from direct usage. Success could manifest as better decision-making, cost savings, or revenue growth for your clients. Develop ways to track and attribute these indirect benefits.
6. The "network effect" is data-driven
Standard SaaS expectation: More users lead to more value through increased interactions.
Data product reality: More data often leads to better insights and predictions. Consider how you can create virtuous cycles where using your product generates more valuable data, which in turn makes the product more valuable for all users.
7. Regulatory compliance is a feature, not a bug
Standard SaaS expectation: Compliance is a necessary evil.
Data product reality: In regulated industries like healthcare, robust compliance features can be a major selling point. Embrace compliance as a core feature and competitive advantage, not just a checkbox.
8. The product evolves with the data science field
Standard SaaS expectation: Periodic feature updates based on user feedback and market trends.
Data product reality: Advances in data science and machine learning can fundamentally change what's possible with your product. Stay on the cutting edge and be prepared to make significant pivots as new techniques emerge.
9. User personas include both humans and algorithms
Standard SaaS expectation: Focus primarily on human end-users.
Data product reality: Your product might need to serve both human analysts and automated systems or AI models. Design your APIs and data outputs with both in mind.
10. The MVP is more complex but potentially more powerful
Standard SaaS expectation: Build a simple MVP to test core assumptions quickly.
Data product reality: Your MVP needs to include not just basic features, but also data pipelines, quality checks, and initial models or analyses. While this makes the MVP more complex, it also means you're testing a more complete value proposition from the start.
Conclusion
Achieving product-market fit for data products requires a nuanced understanding of the unique challenges and opportunities in this space. By keeping these observations in mind, you can avoid common pitfalls and focus on the elements that truly drive value for your users.
Remember, in the world of data products, your goal isn't just to fit the market — it's to evolve with it, shape it, and ultimately, to help your users make better decisions through the power of data.
In this era of frothy "generative AI" talk and valuations, data has become the lifeblood of organizations, powering innovation and fueling competitive advantage. The much-hyped AI models and products are so fascinating because they were trained on vast amounts of curated, labeled, and sourced data - both clean and messy - collected over the past few decades.
Yet, amidst the rush to invest in sophisticated data infrastructures like warehouses and lakes, a critical disconnect has emerged. Executives often find themselves in the dark when it comes to harnessing the true value of their data assets. It's like they're sitting on a treasure trove but haven't quite figured out how to unlock it. As a result, data teams are undervalued, their challenges unaddressed, and their potential constrained by inadequate resources.
We have powerful hammers in our hands, trying to find those nails. If the aim (clean data and understanding) is only slightly off, self-inflicted damage is highly likely.
Enter the Data Product Manager (DPM) – the unsung hero who's about to shake things up and revolutionize the way we leverage data in the age of AI. A continuation of the BI trend and analytics in organizations.
The ideal DPM is a rare breed, combining technical expertise with business acumen and a passion for solving real-world problems with data. They are the translators, bridging the gap between complex data capabilities and strategic business objectives.
Imagine a skilled data analyst like Anna, who's been knee-deep in customer data for years. One day, she has a lightbulb moment and realizes her true calling is to bridge the gap between the tech world and the business realm. She transforms into a DPM, becoming the translator everyone's been waiting for - with a data background, customer and stakeholder empathy, first principles thinking, and ideally, a growth focus.
Now, being a DPM is no walk in the park. It's a juggling act with seven critical responsibilities:
- Setting crystal-clear goals for the data team, keeping them laser-focused.
- Connecting the dots between data initiatives and overarching business strategies.
- Crafting a roadmap for data products that make a difference.
- Ensuring seamless collaboration and alignment across teams.
- Upholding data quality standards, guaranteeing insights you can bank on.
- Quantifying the impact of data products, keeping the purse strings loose by finding ROI.
- Advocating for the resources the data team needs to knock it out of the park.
By fulfilling these responsibilities, DPMs align data initiatives with business goals, architecting requirements for projects that personalize customer interactions, optimize inventory levels, or reduce churn. They are the guardians of data quality, the advocates for resources, and the storytellers who quantify the transformative potential of data-driven decision-making.
In the age of generative AI, the DPM's role takes on even greater significance. As AI models become increasingly sophisticated, their performance hinges on the quality and relevance of the data they are trained on. DPMs must apply first principles thinking, breaking down problems to their fundamentals and questioning every requirement to ensure that data pipelines are reliable and focused on the intersection of customer and business value.
However, it's crucial to recognize that the typical dynamics between startups and incumbents do not apply in AI as they did in previous technology revolutions like mobile and the Internet. As Jason Cohen astutely points out, ignoring this difference can be perilous for AI startups.
Incumbents are not risk-averse when it comes to AI; they're embracing new technology and uncertain markets, spending historic amounts of money and time. They already have the innovation and the data, while startups struggle to find distribution in over-saturated markets. Top AI and software engineering talent are happy working at incumbents, with above-market rates, exciting projects, healthy budgets, and the ability to impact huge numbers of customers quickly.
Furthermore, there's no such thing as "the AI market" unless you're competing directly with OpenAI. The market for chatbots and SEO tools is the same as before, now with stiffer competition. The typical startup strategies relying on the advantages of David against Goliath are largely untrue in AI.
As we navigate the complexities of the digital age, the rise of the DPM signals a broader shift toward recognizing data as a strategic asset. Much like how product managers revolutionized software development, DPMs are poised to transform data teams from cost centers into revenue-generating powerhouses. By fostering communication, collaboration, and visibility, DPMs will elevate the strategic importance of data teams and unlock the full potential of data-driven innovation.
The future is data-driven, and the DPM is the catalyst that will propel organizations forward. As data's importance continues to grow, so too will the demand for skilled DPMs who can navigate the intersection of technology and business strategy. By embracing the power of generative AI, applying first principles thinking, and developing strategies tailored to the unique dynamics of the AI landscape, DPMs will shape the future of business, turning raw data into actionable insights and transforming the way we work, live, and innovate.
In this era of unprecedented opportunity, the rise of the DPM represents a shift in how organizations approach data. It is a call to recognize the strategic value of data and invest in the talent and infrastructure necessary to harness its full potential. The journey from data to AI is not merely about technology (another hammer); it is about vision (why), strategy (how), and the human touch (who) that connects the dots.
Some great resources to learn more:
- The Value of Data - David Jayatillake
- AI startups require new strategies: this time it's actually different - Jason Cohen
Stay strategic,
Kevin
A New Approach for Complex Environments:
As a young business analyst, I started my first contract in a warehouse and operations plant. A hundreds of years old manufacturer that had no ERP (enterprise reporting platform) or inventory tracking yet was wildly profitable for decades (their products were sold in cans but not those you are thinking).
Me and a small team were tasked with onboarding an inventory tracking system in this old-school environment. After weeks of prep and training, we were on-site for dozens of shifts as we handed out barcodes and scanners to employees.
We noticed something off on the third day.
Inventory levels kept ticking down. Throughput was constrained and manual adjustments increased. We thought the sync was delayed for the first day, the barcodes were placed incorrectly, or the scanners were failing.
Then I kept walking the floor. In the packing room, I noticed scanners were sitting on benches and their chargers - not good.
I approached Lenny (floor manager) and pointed this out to him.
,
“Out of sight, out of mind son” he replied.
I took a step back that evening and wondered about this problem.
Then, we bought holsters for each floor employee and let them customize their scanners.
Inventory levels went back to expected in a week. Problem solved for a couple hundred dollars.
In the ever-evolving fields of data and product development, especially in healthcare, we need strategies that break free from conventional boundaries. Not everything works when everything is meant to be a system in itself.
A first principle is a “basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.”. This philosophical approach encourages us to strip problems to their fundamental truths, which is crucial for teams dealing with complex data and product challenges.
4 core aspects of data product management and first principles:
- Breakdown the problem into core components - question every requirement
- Create a data product strategy that accomplishes the mission - the intersection of customer and business value
- Build a reliable data pipeline - product thinking to process
- Win through others - be a coach
First Principles for Data Product Teams
1. Breakdown the Problem into Core Components - Question Every Requirement
First principles thinking in data product management starts with deconstructing complex problems into their fundamental elements.
Understanding the analytical (really the business) question - the so what or why - is critical.
Complexity is not the goal in and of itself. No one gets points for difficulty in business. Question every requirement. Break down every component into its parts.
Encouraging yourself and others to question the assumptions you have is critical. Think of an EHR. EHRs, at their core, are financial and billing tools and those with poor usability have been connected with more medical errors. On top of that, the average ER doc has to make 4,000 clicks in a single shift.
Does this have to be true? Why are all of these needed? Start with each factor of how something came to be and you are on the right track.
2. Create a Data Product Strategy that Accomplishes the Mission - The Intersection of Customer and Business Value
A successful data product strategy aligns with both customer needs and business goals. All employees should be focused on fulfilling the company's mission to profit or purpose, maybe both.
Most team members are working directly toward the business goal by a product or service to customers: building (engineers, data, and designers), go-to-market (marketing and sales), optimizing the business (analysts and resourcing), or helping customs (support).
Product management doesn't directly build or operate. The goal is to inform the operations to optimize the intersection of business and customer value. How does that get done? By defining a strategy - specifically a data product one at that.
This includes four components:
- Goal and outcomes
If you don't know where you are going, you are already on your way
Go back to that first principle and a good data product manager will incessantly ask the hard questions in a quest of defining the mission they follow. What does the world look like for that goal or vision to be real?
Data Product Managers (DPMs) also need to know what other teams aim for. DPMs are intertwined deeply with other teams as your product is either an input or output of another. See it as insurance to make sure you are not colliding with others.
- Customers
“The customer is always right” and “customers don’t know what they want” are both accepted business wisdom. The line between “inspiringly bold” and “foolishly reckless” can be a millimeter thick and only visible with hindsight.” - Morgan Housel
That goal may be lofty and well-intentioned, but if no one pays for it or those that do are too few and far between, then what is the point? Customer input is the quantitative and qualitative data you develop and a sense you must cultivate.
What are customers signaling? Not directly, but what are they hiring to get a job done, and how are you, as a data product, helping your customers make progress in the jobs they need to get done?
That signal is worth listening to and what you hear from customers and what they do is the ultimate validation of your goal and efforts.
- Environment
Nothing is built in a vacuum. If you see an opportunity, others likely have as well.
When looking externally, think of PESTLE (Political, Economic, Social, Technological, Legal, and Environmental) - what changes affect your company, input data, and customers' interest?
While much focus is on the external factors in the environment (competitors and market forces), you should never discount the company environment and dynamics. Most importantly with this, understand the cyclical nature of teams and focus - everything is always in a state of change, whether you choose to see it or not.
Calm plants the seeds of chaos.
- Constraints
Lastly, any product team needs to understand the limits of the team that is doing the building. Just as a captain must understand the crew, time, and fuel to make a journey successful, DPMs will also.
People are the biggest constraint for product teams but the second most important constraint for data product teams.
Data, as mentioned, and its myriad components are the largest constraint on a data product once the goals, customers, and environment are better understood.
- Is the quality appropriate?
- Is there governance, documentation, and observability?
- What are the biases and limitations?
- How stable and extensible is the data?
Money is a critical factor in determining the scope and scale of a data product. The budget allocated dictates the quality and quantity of resources that can be employed, including technology, tools, and personnel. These constraints require a balancing act between desired features and cost implications.
Acquiring new data sources, spending on third-party tools, investing in data engineering, or freeing up resources for GTM (go-to-market) is critical to determining a trajectory.
Just like any other product, you can't consider only the initial development but also the maintenance and updates. Scaling, enhancements, quality systems, ETL updates, and product adaptation to changing needs.
Time constraints impact the speed at which a data product can be brought to market. A limited timeline might necessitate compromises in product features or depth of data analysis.
In fast-evolving industries, especially in this age of generative AI, where everything seems to change by the minute, time is crucial to ensure the data product remains relevant and competitive. Delays in development can result in missed opportunities or outdated solutions by the time of launch.
Thanks for joining - see you next time!
Part 2 - Next time principles 3 + 4
- Build a Reliable Data Pipeline
- Win Through Others
Where to learn more
Recommend books, articles, and other resources for readers to deepen their understanding of First Principles Thinking.
- “The Great Mental Models” by Shane Parrish for versatile thinking frameworks.
- "Inspired" by Marty Cagan for his influential text in developing product thinking.
- "Same as Ever" by Morgan Housel for a broad psychological look at the things through history that never change.