The 5 Ps of data science are Problem, People, Process, Platform and Portfolio: five conditions that must hold before analytical work changes a decision. Each P names a recognisable way teams fail, and the order matters. Platform is the only P you can buy, which is why teams so often buy tooling to fix a problem nobody has defined.
This piece is for analysts, data science leads and managers whose team is busy but not landing results. For each P you get the question it forces, the symptom when it is missing and the trade-off of fixing it, then three places where the framework stops helping. Used as a diagnostic, it earns its place; filled in as a checklist, it is wallpaper.
They help in one situation: a team is busy and nothing is landing. Somebody is always certain they know why — usually that they need better tooling, because tooling is the part you can buy. The five Ps are useful because they force you to check the cheap causes before the expensive ones.
| P | The question it forces | The symptom when it is missing |
|---|---|---|
| Problem | What decision changes because of this work? | Findings that are interesting and unused |
| People | Who owns this, and who is accountable for it being right? | Work restarted three times by three people |
| Process | How does a question become an answer someone trusts? | Results nobody can reproduce, including their author |
| Platform | Can people get the data and run the work? | Six weeks to first query, analysts building their own extracts |
| Portfolio | Which of these things should we not be doing? | Fourteen half-maintained models and no capacity to start anything |
Read the table in order. The first row without a concrete answer is where your problem is, and it is almost never the row the argument is about.
A problem is not a topic. "Customer churn" is a topic. "Which of these 4,000 accounts should the retention team call this month, and how much better than calling them at random does that need to be to be worth the analyst time?" is a problem.
The test is whether you can complete this sentence: if the answer comes back X, we will do A; if it comes back Y, we will do B. If both branches lead to the same action, the analysis is decoration however well you execute it.
This is where data science teams waste more effort than anywhere else, and it is cheap to fix — it costs a conversation before the work starts rather than a quarter afterwards. Google's Rules of Machine Learning starts in exactly this place: "Don't be afraid to launch a product without machine learning", followed immediately by "First, design and implement metrics." Decide what you are trying to move before deciding how. What makes a good AI project applies the same judgement at project level.
The trade-off: insisting on a named decision genuinely does suppress exploratory work, and some exploratory work pays. The resolution is to timebox exploration explicitly rather than to disguise it as a project with fictional business value.
The usual framing of this P is a list of roles — data scientist, data engineer, analytics engineer, ML engineer, domain expert. That list is worth having, but it is the less important half.
The important half is ownership. For any piece of work, three questions need a name attached:
Teams that cannot answer the third question produce a great deal of work that quietly stops functioning. Teams that cannot answer the second produce work nobody defends in a meeting.
Skill mix matters in one specific way: the gap between people who can produce an analysis and people who can make it run without them. That boundary decides how much of your team's capacity goes on keeping old things alive. The technical skills a data science manager actually needs sets out what it takes to hold this together.
The trade-off: hard role boundaries produce hand-off queues; no boundaries produce five people all doing the interesting part. Small teams should err towards generalists and accept the duplication.
Process here means the repeatable path from question to trusted answer — not a governance document.
The established description of that path is CRISP-DM, whose phases are business understanding, data understanding, data preparation, modelling, evaluation and deployment. IBM's CRISP-DM guide is the most accessible primary write-up, and its framing of the first phase — gain as much insight as possible into the business goals, and meet stakeholders to establish what the work addresses — is the same point as the Problem P, arrived at from the other direction. The two frameworks stack: CRISP-DM describes one project's phases, the five Ps describe the conditions around all of them.
What makes a process real rather than documented:
That is a short list, and it is the whole of it for most teams. The failure mode is not an absence of process documents; it is documents that describe a process nobody follows.
The trade-off: process has a fixed cost per project, which is why it feels punitive on small ones. Scale it — a two-day piece of analysis needs the assumptions written down and nothing else.
Platform covers storage, compute, orchestration, the catalogue, and everything that decides how long it takes an analyst to get from a question to a query. Its honest measure is one number: how many days from a new joiner's first day to their first query against production data.
It gets bought first because it is purchasable, and it is the P most likely to be over-specified. Teams acquire a lakehouse, a feature store and an orchestration layer before they have enough recurring work to justify any of them, then spend a year on migration instead of analysis. Modern data engineering in 2026 covers where the genuine decisions now sit: open table formats, catalogues as the new lock-in, and object-store economics.
The other half of Platform is the part nobody demonstrates in a vendor call: what happens after something is deployed. Hidden Technical Debt in Machine Learning Systems (Sculley et al., NIPS 2015) remains the standard account of how machine learning systems accumulate maintenance cost through entanglement, undeclared consumers and configuration sprawl — costs that fall on the surrounding system, not the model. The MLOps engineer career guide describes the discipline that absorbs them, and tools and techniques for data science covers the working toolset.
The trade-off: under-investment is also real. If analysts are maintaining private extracts because the platform cannot serve them, you are paying for infrastructure anyway, just in the most expensive currency available.
Portfolio is the P most often reduced to a slide about strategic alignment, and it is the one with the sharpest practical edge: a portfolio view exists so that things can be stopped.
Every model and dashboard a team ships becomes a standing liability. It needs monitoring, it breaks when something upstream changes, and somebody has to answer questions about it. Teams that never retire anything gradually convert their capacity into maintenance, and then cannot explain why they ship nothing.
A workable portfolio practice is small:
The trade-off: this is genuinely overhead below a certain size. One or two people do not need a portfolio review; they need to remember what they built. At five or six, nobody holds it all any more, and that is when the list starts paying for itself.
They cannot tell you whether an answer is right, what good looks like in your organisation, or whether a sixth condition matters more than one of the five. A framework that claims no limits is marketing.
It says nothing about whether an answer is right. Every P can be in place around a badly specified experiment or a leaking model. Correctness is a separate discipline, and the five Ps will not catch a failure in it.
It is a mnemonic, not a method. It tells you which conditions to check. It does not tell you what good looks like in your organisation, and any version that claims to is describing someone else's company.
Alliteration distorts it. Five words beginning with the same letter is a memory aid, not a finding about how work happens. Data quality, for instance, does not begin with P and matters more than at least two of these. If a sixth condition matters in your context, add it and let the mnemonic break.
Used within those limits, the five Ps do one useful job well: when a team is busy and nothing is landing, they tell you where to look first, and they stop you from buying a platform to solve a problem definition.
## Frequently asked questions ### What are the 5 Ps of data science? Problem, People, Process, Platform and Portfolio. The Problem is the decision the work should change, People are the skills and ownership around it, Process is how work moves from question to answer repeatably, Platform is the tooling and data infrastructure, and Portfolio is how competing projects are prioritised and retired. ### Is the 5 Ps framework a replacement for CRISP-DM? No, they answer different questions. CRISP-DM describes the phases of a single analysis, from business understanding through to deployment. The 5 Ps describe the conditions around the work — who does it, on what, and which projects get chosen at all. The two sit at different levels and combine cleanly. ### Which of the 5 Ps do teams get wrong most often? Problem and Portfolio. Problem fails when nobody can name the decision the analysis would change, so the result is interesting and unused. Portfolio fails when projects are started but never stopped, so a team of eight ends up maintaining fourteen half-alive models and starting nothing new. ### Does a small data team need all five Ps? A one- or two-person team needs Problem, Process and enough Platform to be repeatable. The People discussion about role boundaries and the Portfolio discussion about prioritisation start to matter at around five or six people, when nobody can hold the whole picture in their head any more. ### How do I use the 5 Ps in practice? Use it as a diagnostic rather than a plan. When a project is stuck or a team is busy without shipping, check each P in order and find the first one that does not have a concrete answer. That is almost always where the problem is, and it is rarely the one people are arguing about. --- _Source: 1stepGrow (https://www.1stepgrow.com/articles/5-ps-of-data-science/). Cite with the title, "1stepGrow" and a link._