Choose a data science project from a business decision

A project becomes useful when its output changes a decision. “Build an image classifier” names a technique. “Rank refund cases for a daily team of five reviewers” names a user, action and constraint. The second brief makes data, evaluation and failure costs discussable before anyone chooses a model.

Score the brief, not its novelty

The career evidence lab compares two invented candidates.

from career_cases import project_decision_case

result = project_decision_case()
assert result["selected"] == "refund-review prioritization"
assert result["candidates"][1]["decision_fields"] == 4
print(result["selection_reason"])

The generic classifier has a downloadable label and a majority-class baseline, but no defined decision or action. The refund project identifies which cases enter limited manual review, expects 100 ranked cases each day, uses resolved review outcomes as labels and compares against oldest-case-first ordering.

That does not make the refund project automatically feasible. It makes its unanswered questions visible.

Write six fields before touching the data

1. 1Decision: What choice will be made differently?
2. 2User and action: Who receives the output, when, and what can they do?
3. 3Population: Which entities are eligible at each decision time?
4. 4Outcome: What observable event becomes the label, and when does it mature?
5. 5Constraint: What capacity, latency, fairness, privacy or error-cost limit applies?
6. 6Baseline: What rule or workflow operates without the proposed model?

Then inspect whether the necessary timestamps and labels exist. For the refund example, a random row split could mix later decisions into training. A useful evaluation keeps time order, measures ranking within the daily review budget and reports performance after labels mature.

Prefer a small complete project

A defensible portfolio project can use synthetic or public data if its provenance is clear. It should include a data contract, split manifest, simple baseline, candidate comparison, decision-facing metric, failure slices, reproduction command and limitations. A large notebook with ten algorithms is weaker if the reviewer cannot tell what action any score supports.

The project also needs a rejection rule. Examples include failing to beat the current queue, unstable performance across time, unacceptable false-positive cost or unavailable features at prediction time. Stating the rule before evaluation protects the project from becoming a search for any favourable result.

The Data Science course connects this decision brief to modelling, deployment and capstone defence. Course fit should be judged from the artifacts learners must produce, not an algorithm count.

Exercise

Draft three project ideas from one domain. Complete the six fields for each, list one unavailable-data risk and define a baseline plus rejection rule. Select the brief with the strongest feasible decision chain and preserve why the others were rejected.

Continue learning

This article is part of the Data science careers and portfolio decisions sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Continue with Turn a tutorial notebook into a defensible portfolio project.
• Then apply it in Explain model validation in a data science interview.

Reference: Google’s Rules of ML.