The Skill Gap Nobody Talks About in Data Science

I want to start with something uncomfortable.

Most data science portfolios look the same. A Titanic survival classifier. An MNIST digit recognizer. A house price prediction model with an R² of 0.87. Clean notebooks. Tidy visualizations. Accurate models.

And almost none of them answer a question anyone was actually asking.

I don't say this to be dismissive. I say it because I spent a long time building exactly that kind of work — technically correct, professionally irrelevant. It took building real projects with real stakes to understand what was missing.

The missing piece is not a new algorithm. It is not a bigger dataset or a more sophisticated pipeline. It is the ability to connect analytical work to a decision someone needs to make.

What the gap actually looks like

Here is how it manifests in practice.

A data scientist builds a churn prediction model. It achieves 89% accuracy. They present it. The business takes no action. The data scientist is frustrated — the model was good. The business is unmoved — they don't know what to do with 89% accuracy.

The problem is not the model. The problem is that nobody answered the question that comes after: given this prediction, what should we do differently tomorrow?

A model that predicts which customers will churn is useful. A model that predicts which customers will churn, ranks them by revenue impact, and identifies the intervention most likely to retain each segment is actionable. The technical work is similar. The business value is completely different.

That translation — from analytical output to decision support — is the skill that separates data scientists who get hired and retained from those who don't.

What building real projects taught me

I am a final-year data science student at JKUAT. In the last few months I have shipped three projects that I consider genuinely different from most student work — not because the models are more sophisticated, but because each one started with a question someone with actual responsibility was trying to answer.

The Kenya Boda Boda E-Mobility Viability Engine started with a single operational problem: battery swap companies in Nairobi cannot optimize their network because they do not know where rider demand concentrates relative to existing infrastructure. The analytical question was: given public data, can we identify coverage gaps and predict where new stations would reduce both operational friction and PAYG loan default rates simultaneously?

The finding — that distance to the nearest swap station is a stronger predictor of PAYG default than income level — was not a finding I planned to discover. It emerged from asking the right question first and letting the data answer it. That finding is what made the project land with operators. Not the K-Means clustering. Not the Weibull battery degradation curves. The connection between infrastructure placement and credit risk that nobody in the sector had quantified publicly.

FinLens AI started with a different kind of gap. Western financial AI tools are trained on S&P 500 data. When applied to Kenyan companies — banks funded by deposits rather than debt, insurers holding policyholder reserves rather than commercial liabilities — they produce systematically wrong risk assessments. The question was not "can I build a credit analysis engine." It was "can I build one that actually understands what a Kenyan balance sheet looks like?"

VoltReturn started from a conversation. After the emobility project attracted attention from an operator, I realized the analysis was right but the format was wrong. The people who decide where infrastructure capital goes do not interact with Streamlit dashboards. They need IRR projections, NPV distributions, sensitivity analysis, and board-ready investment memos. The question shifted from "where should the next station go" to "if we build it, is the investment worth making." Same domain, completely different product.

In every case the technical work was real. The models, the pipelines, the deployment — none of it was trivial. But none of it was the point. The point was the question each project was built to answer.

Why this matters more than it used to

The barrier to building technically competent data science work has collapsed. Large language models can write serviceable Python. AutoML tools can tune models. Kaggle notebooks demonstrate every standard technique in exhaustive detail.

What cannot be automated is understanding what question is worth asking in the first place.

The data scientists who will be most valuable in the next five years are not the ones who can build the most sophisticated models. They are the ones who can walk into a room where someone has a problem, understand what decision they are actually trying to make, and return with something that helps them make it better.

That skill is not taught in courses. It is not demonstrated by accuracy scores. It is built by working on problems that have real consequences — where the output has to be useful, not just correct.

What real projects are actually like

The other thing courses do not prepare you for is the texture of real work.

The data is incomplete. The methodology you planned hits a wall because the public dataset you needed does not exist in the format you assumed. The stakeholder who commissioned the work changes their mind about what they want halfway through. The model that performed beautifully on the training set behaves strangely on the first real documents you upload.

You improvise. You document the gaps honestly. You build a fallback that handles the edge cases your original design missed. You ship anyway and note the limitations clearly.

In my FinLens AI project, the anomaly detection baseline is trained on SEC EDGAR data — American companies. It flags Kenyan bank balance sheets as statistical outliers because they are outliers relative to US baselines. I documented this as a gap, built a RAG layer that contextualizes the anomaly against African market benchmarks, and was honest in the README about what the model is and is not doing. That honesty is part of the work.

Real projects are messy in ways that make you better faster than clean tutorial projects ever could. The mess is not a problem to solve before you start. It is what makes the work meaningful.

The practical implication

If you are building a portfolio, the question to ask about every project is not "does this demonstrate my technical skills?" It is "does this answer a question someone was actually asking?"

The Titanic dataset demonstrates that you can run a classification model. It does not demonstrate that you understand what to do with a classification model when the business context is ambiguous, the data is incomplete, and the stakeholder needs to make a decision next week.

Find a real question. It does not need to be commissioned work. Public data is everywhere. Industry reports describe the problems operators are actively trying to solve. Regulatory filings contain financial data that nobody has analyzed from an African market perspective. Census data contains population distributions that nobody has mapped against infrastructure networks.

Build something that answers the question. Be honest about the limitations. Ship it publicly.

That is the portfolio that stands out. Not because the models are better. Because the judgment is visible.

John Apollos Olal is a Data Scientist and Software Engineer based in Nairobi, Kenya, and the founder of Apollos Digital Solutions. He is currently finishing his BSc in Data Science and Analytics at JKUAT.

GitHub: github.com/JohnApollos Portfolio: https://johnapollos.netlify.app