When I first started trying to build a data portfolio, I got a bit stuck on the idea that I didn’t really have anything “good enough” to show. Most of what I saw online was Kaggle competitions, polished GitHub projects, or people who already had internships producing very clean end-to-end case studies.

At that point, I didn’t really have any of that. And I think that’s probably more common than it seems when you’re just starting out in data.

Over the past year working in a SaaS environment at DataSync, my view on this has changed a bit. Not completely, but enough that I’d probably approach it very differently if I was starting again today.

Rethinking what a “data portfolio” actually is

The assumption I had at the beginning was that a data portfolio had to be made up of public projects using external datasets. Something structured, impressive, and clearly “finished.”

But working closer to real product and growth work has made me realise that most data work in practice doesn’t really look like that. It’s usually a lot messier. Questions aren’t always clearly defined, data isn’t always clean, and you’re often working backwards from a decision someone needs to make.

So I’ve started to think of a portfolio less as a collection of finished projects, and more as evidence of how you think through problems.

For example, whether you can:

• take a vague question and turn it into something structured
• work through messy or incomplete data
• explain your assumptions clearly
• connect analysis back to a decision someone would actually make

Once you start thinking about it like that, you realise you probably already have more material than you think.

What I've noticed so far

One thing I realised quite early on is that I was treating “lack of public projects” as a bigger issue than it actually was. I kept thinking I needed access to better datasets or more “real” projects before I could start building anything meaningful.

But that mindset actually slowed me down more than anything else.

What seems to matter more — at least from what I’ve seen in interviews and working around data teams — isn’t where the data comes from, but how you approach it. People are usually trying to understand how you think, not whether your dataset came from a competition or your own experiment.

That shift made things feel a bit simpler. It meant I could start building from what I already had instead of waiting for the “right” project to appear.

Where to actually get portfolio ideas if you’re starting from zero

If I was starting again, I probably wouldn’t wait for external datasets or formal projects. I’d start with things that are already around me.

One of the simplest approaches is using your own behaviour as a dataset. Things like music listening habits, spending patterns, or app usage can actually become quite interesting if you frame them around a question. The key isn’t the dataset itself, but the decision or insight you’re trying to explore.

Another useful exercise is recreating dashboards or metrics you see in SaaS tools or online screenshots. Not necessarily perfectly, but enough to understand what each metric is trying to show and why it might matter. That helps you start thinking in terms of product decisions rather than just analysis.

A third approach is writing out “fake” stakeholder questions and answering them. Things like “why did sign-ups drop last week?” or “which users are most likely to churn early?” Even if the dataset is simple, the value is in how you structure the problem and what assumptions you make along the way.

What makes a portfolio actually useful

The longer I’ve worked around data teams, the more I’ve realised that strong junior portfolios don’t necessarily stand out because they are visually impressive or technically complex. They stand out because they make it easy to understand how someone thinks.

When I look back at what tends to matter in interviews or discussions, it usually comes down to a few things:

• whether you can define a problem clearly
• whether you can handle ambiguity without overcomplicating it
• whether you can explain your assumptions
• whether your analysis connects back to a decision someone would actually make

Technical skills obviously matter, but at an early stage they’re rarely what differentiates candidates.

A simpler way to structure your portfolio

If I had to simplify it, I think it’s better to aim for a small number of projects that each show a slightly different angle of thinking.

For example:

• one project focused on user behaviour or engagement
• one project where you simulate a business decision or trade-off
• one project where the data is messy and you show how you clean and interpret it

Each project doesn’t need to be large. What matters more is that each one shows a different way of working with data and thinking through problems.

A final reflection

Something I didn’t fully appreciate at the beginning is that over-polished portfolios can sometimes make it harder to understand how someone actually thinks. If everything looks too clean, it can be difficult to see how they deal with uncertainty or ambiguity.

In real data work, things are rarely neat or fully defined. So showing a bit of that thinking process — even if it feels imperfect — can actually make your work more realistic and easier to trust.‍

Why this is something DataSync is focused on

From what I’ve seen so far working at DataSync, a lot of early-stage analysts struggle less with tools and more with interpretation. It’s relatively easy to learn SQL or Python syntax, but harder to understand what the output actually means in a business context.

A lot of what we’re building is aimed at helping bridge that gap — moving from raw data to something that actually informs decisions, rather than just producing analysis for its own sake.

And I think that’s also what makes a portfolio stronger in the long run. It’s less about showing that you can run analysis, and more about showing that you can think in a way that connects to real decisions.