Understanding CRISP-DM for Product Managers
Leveraging the classic framework from a product perspective
This is the second post in an 8-part series exploring frameworks for effective AI product management. In my previous post, I examined how AI has evolved from simple analytics to complex generative capabilities and why traditional product frameworks struggle with these new challenges. Today, I'll dive into CRISP-DM from a product management perspective and explore how this classic framework can be effectively applied to AI initiatives.
It’s structured. It’s familiar. And with the right lens, it can be surprisingly effective for AI product managers, especially those looking to bring clarity and alignment to complex, cross-functional work.
However, CRISP-DM wasn’t designed with product managers in mind. It doesn’t account for real-world pressures, such as stakeholder alignment, ethical risks, or iterative delivery. That’s where we come in.
This post breaks down each phase of the CRISP-DM framework from a product management perspective, focusing on what you need to watch, what you’re responsible for, and how to adapt it to the reality of modern AI product delivery.
1. Business Understanding
Start with clarity or spend the project untangling confusion.
This phase defines the "why" behind your AI effort. It’s where product managers do the heavy lifting of turning executive intent into a feasible, shared understanding of the problem to solve.
What to focus on:
Stakeholder alignment: Uncover differing expectations early, especially around what the AI solution will and won’t do. Avoid assumptions about capabilities or outcomes.
Success metrics: Tie technical KPIs to business outcomes (e.g., increased conversion rate, reduced manual review time), not just accuracy or F1 score.
AI fit: Clarify whether AI is the right solution. What’s the baseline, and what improvement justifies the complexity?
Constraints: Identify real-world constraints across legal, regulatory, ethical, or organizational lines. These will shape feasibility and scope.
MVP definition: Scope down to a version that delivers value, reduces risk, and gives you a viable learning loop.
What you're responsible for:
A problem definition that’s both technically grounded and business-aligned
A success metric framework that includes leading and lagging indicators
A stakeholder map outlining influence, expectations, and communication rhythms
A risk register capturing AI-specific risks, like data gaps or fairness concerns
If done well, this phase reduces downstream churn and gives your project a stable foundation on which you can revisit when tradeoffs inevitably arise.
2. Data Understanding
This is where timelines often shift and your roadmap gets real.
The best modeling strategy in the world won't matter if the data isn’t there, is of low quality, or doesn’t reflect the use case. This phase is where the gap between intention and execution becomes visible.
What to focus on:
Data access: Ensure the team can legally and operationally access the necessary data sources. This often involves working across IT, compliance, or even procurement.
Reality check on data quality: Clarify what exists vs. what was assumed. Validate sample size, coverage, recency, and labeling.
Business implications: Help stakeholders understand how gaps in the data will impact the product. Will specific segments be underserved? Will the model need human oversight?
Timeline recalibration: Revisit delivery expectations based on actual data readiness.
Data reuse and governance: Ensure your approach supports longer-term product needs and aligns with broader org data strategy.
What you're responsible for:
A data availability summary that maps sources to use cases
A data quality impact statement that explains what tradeoffs are being made
An updated delivery timeline that reflects any delays or accelerations
A cross-functional comms update that translates technical data findings for business stakeholders
This is where you protect the team from overpromising and help the business understand that great AI starts with grounded data, not just great models.
3. Data Preparation
Unseen by users but critical to performance.
This is where your team invests the bulk of their time, quietly building the foundation on which the model depends. As a PM, your job is to support that effort while keeping the broader team aligned on progress.
What to focus on:
Team support: Ensure data engineers and scientists have the necessary time, tools, and clarity. This phase is long, and we need to acknowledge and normalize that.
Progress visibility: Translate slow-moving work into visible milestones. Stakeholders need to see momentum, even if there’s no UI or model.
Scope control: Define what’s “good enough” to move forward. Avoid endless iterations on data pipelines or feature sets.
Cross-team coordination: Align with privacy, legal, and IT teams when data flows across systems or jurisdictions.
Technical debt awareness: Track shortcuts and quick fixes that require refactoring after launch.
What you're responsible for:
A data prep milestone tracker that communicates progress in plain language
Feature and transformation documentation for future iterations or audits
A resource plan that includes any ops or tooling needs
A compliance sign-off path if regulated data is involved
This is the invisible work that determines model quality. Great PMs know how to make it visible and valued.
4. Modeling
Product constraints still shape the technical center of the project.
Modeling is where your technical team builds the predictive engine, but as a PM, your influence remains critical. You translate product needs into modeling decisions and balance technical depth with delivery discipline.
What to focus on:
Evaluation criteria: Define what success looks like before the team starts building, especially in GenAI or high-risk domains where subjective quality is important.
Exploration time vs. timeline: Support experimentation while maintaining momentum. Know when to converge.
Tradeoffs: Frame business implications of model decisions: accuracy vs. explainability, latency vs. compute cost, personalization vs. privacy.
Early feedback: Share initial model outputs, even raw ones, with stakeholders to validate direction and prevent surprises.
IP and reuse: Address licensing, reuse rights, and integration complexity if using pre-trained or third-party models.
What you're responsible for:
A model evaluation rubric that includes business and technical metrics
A decision log showing the rationale behind model selection
Early output demos for stakeholders to provide feedback
A communications plan to translate model behavior for non-technical audiences
You’re not optimizing the model, but you are owning its framing, its evaluation, and its connection to real-world value.
5. Evaluation
Where technical success meets business validation.
By now, the model performs, but that’s not the same as product success. This phase validates whether the model meets business needs, integrates with workflows, and holds up under real-world use.
What to focus on:
Business metric validation: Test whether the model moves the KPIs you defined in Phase 1.
Edge case testing: Surface the scenarios where things break - bias, performance dips, strange outputs.
User feedback: Run UAT with real users in real environments. Capture usability, trust, and clarity.
Deployment readiness: Make a structured go/no-go recommendation. Be honest about gaps.
Iteration planning: Use what you learn to start shaping v2.
What you're responsible for:
A business impact report that includes metrics and qualitative insights
A UAT plan and results summary
An edge case catalog with mitigation options
A launch decision doc with a clear rationale
A v2 feature backlog informed by evaluation learnings
This is where product management ensures the model doesn’t just work - it works where it counts.
6. Deployment
It’s not done until it’s used.
AI solutions often stumble at the finish line, not because the model failed but because the rollout did. As PM, this is your moment to drive actual adoption and impact.
What to focus on:
Rollout strategy: Choose the right approach, pilot, phased rollout, or full launch, balancing risk and speed.
Change management: Help teams understand and adopt the new system. Identify who’s affected, how, and what they need to succeed.
Monitoring and retraining: Ensure logging, alerting, and retraining workflows are in place.
Ownership and support: Define who’s responsible for post-launch operations, support, and model maintenance.
Integration and reliability: Test how the model behaves within full systems, not just offline evaluation.
What you're responsible for:
A deployment playbook with rollout, training, and support plans
A monitoring and alerting framework that maps to business risks
A change management strategy with internal comms, enablement, and training
A handoff plan that defines who owns what post-launch
This is the phase where technical success either has a business impact or stalls due to organizational friction. PMs make the difference.
CRISP-DM gives structure to ambiguity. But it doesn’t account for model drift, iterative delivery, user experience, or ethical risk.
That’s why newer frameworks like CRISP-ML and CRISP-GEN AI exist to extend the foundation and reflect the realities of machine learning (ML) and generative AI.
In my next post, I’ll examine CRISP-ML, which builds on CRISP-DM by incorporating monitoring, retraining, and feedback loops that today’s AI products require.
The shift for PMs: You’re not just managing models, you’re managing living systems that learn, change, and interact with users over time.
That requires new frameworks. And it starts with adapting the ones we already know.