How many projects do you need in a data portfolio?
The direct answer: three finished, documented projects, and they beat ten unfinished ones every time. Here is the recruiter attention math behind that number, what finished actually means, and the sign it is time to add a fourth.
How many projects do you need in a data portfolio? Three. Three finished, documented projects beat ten unfinished ones, every time, for every data role. If your three cover the core workflow of the job you want and each one ends in a finding you can defend, your portfolio is not "small", it is done. The rest of this article is the reasoning, because understanding why three wins changes how you build them.
The recruiter attention math
The number is not a style preference. It falls straight out of how much attention a portfolio actually receives.
Put those together and the strategy writes itself. Nobody ever sees most of a big portfolio, everyone sees the quality of whichever piece they open, and three well-chosen pieces already prove the whole job. A tenth project adds nothing to the minute that decides whether you get a callback, but the time it consumed was taken directly from the projects that do get opened. That trade is the whole game, and it is why a portfolio is worth it precisely when it is small and deep.
What "finished" actually means
The word carrying all the weight in "three finished projects" is finished, and most portfolio projects are not. Code that runs is not a finished project; it is raw material.
- A business question stated up front
- Cleaning and judgement calls documented
- A finding with a recommendation attached
- A write-up a stranger understands alone
- A public link that opens in one click
- A notebook with outputs but no narrative
- Charts with no decision attached
- A repo whose README is the default template
- Code only you can explain
- A private link or a broken one
The test is simple: could a hiring manager open the project with you not in the room, and within two minutes tell someone else what you asked, what you did, and what you found? If yes, it is finished. If no, finishing it, not starting another, is the highest-value work available to you. The step-by-step of getting a project to that state, from the cleaning decisions worth documenting to the final write-up, is covered in how to build a data analyst portfolio.
The quality bar, per project
Three projects only beat ten if each clears a real bar. Here is the bar, per slot.
The SQL project
A real business question answered in queries: revenue drivers, retention by cohort, the cause of a drop. Clean, commented SQL and a write-up that leads with the finding, not the schema.
The analysis project
A messy dataset cleaned and analysed end to end, decisions documented. This is the project interviewers probe hardest, because judgement with imperfect data is the daily job.
The communication project
A dashboard or report a non-analyst could act on: one decision, honest visuals, defined metrics. Charts that mislead sink this project instantly, so know the misleading charts patterns before you publish.
If you need concrete dataset-and-question pairings for each slot, the portfolio project ideas list maps directly onto these three.
A portfolio is not a warehouse of everything you built. It is the three pieces you would bet an interview on.
Does the answer change by role?
The number holds across data roles; what shifts is what the three projects are. A data scientist's trio swaps the dashboard for a modelling project: statistics and exploration, a supervised learning model with honest evaluation, and a forecast or deep-learning piece. A data engineer's swaps analysis for systems: a data model, an orchestrated pipeline, and a batch or streaming job, with a fourth project more defensible here than anywhere because infrastructure work has more distinct surfaces to prove. A business analyst's trio leans toward stakeholder deliverables: SQL reporting, a KPI dashboard, and a business case.
The logic underneath never changes, though. Every version is three finished pieces that together cover the workflow of the target job, each deep enough to survive an interviewer's twenty minutes of questions. If you can defend each project for twenty minutes, you have enough portfolio. If you cannot, adding a fourth will not save the first three.
When a fourth project earns its place
Three is the target to get hired, not a lifetime cap. A fourth project makes sense in exactly three situations. First, targeting: you want a niche, say marketing analytics or finance, and a domain-specific project signals it better than a cover letter can. Second, differentiation: a personal project on data you genuinely care about, which shows initiative no guided work can. Third, a specific employer: they run a tool or stack your three do not show. What a fourth project should never be is a substitute for finishing the first three, and past five or six the pruning rule applies again.
Where you publish also shapes how the count reads. On a hosted portfolio page, three validated projects with titles, descriptions, and skills look intentional and complete; scattered across an uncurated GitHub profile, the same work can read as thin (the fix is the three-pinned-repos setup from the GitHub portfolio guide).
The takeaway
Three finished, documented projects that cover the workflow of your target role. That is the number, and everything about how portfolios are actually read supports it. It also has a liberating corollary: you are closer than the size of other people's portfolios makes you feel. You do not need six months of output before applying, you need three pieces of genuinely finished work, and for most learners that is six to eight focused weeks. The moment the third project clears the bar, stop building and start applying, because from that point interviews teach you more about what your portfolio needs than another month of speculative projects ever will. The hard part was never the count, it is getting each project to genuinely finished, which is where most self-taught portfolios stall. That is the part D8A structures for you: each path is a sequence of guided projects on real, messy data, each one automatically validated when complete and published to a public portfolio page. The definition of done is built in, so your three projects reach the bar instead of hovering just below it.