Most career-change advice starts with the expensive decision. Quit or stay. Bootcamp or degree. Twelve thousand pounds or nine months of evenings. That is a strange place to start, because you are being asked to commit serious money and time to a field you have never actually done. You have read about it. You have watched people talk about it on LinkedIn. That is not the same thing.
A side project fixes this, but only if you treat it as an experiment rather than a hobby. The difference is not effort. It is whether the thing can tell you no.
Start with a belief you are trying to kill
A portfolio piece asks: what can I show people? An experiment asks: what do I currently believe about this field, and is it true?
Write the belief down as a sentence. Not "I think I would like data analysis." That is unfalsifiable. Something closer to: "I believe I would enjoy spending most of my working hours cleaning messy data and answering other people's questions about it, and that I am good enough at it that someone would pay me."
That sentence has testable parts. Do you enjoy the cleaning, which is the bulk of the job? Do you like being the person who answers questions rather than the person who asks them? Can you produce something a stranger finds useful?
Take Marta, an operations coordinator at a logistics firm, seven years in, convinced she wants to move into data analysis. Her actual belief, once she wrote it out honestly, was: "The interesting part of my current job is the part where I build spreadsheets to explain why deliveries are late. I want a job that is only that part." Good. That is specific enough to test.
Second example, carried through the article: Tomas, a secondary school teacher, drawn to instructional design. His belief: "I like designing learning, I just do not like classroom management. In instructional design I would still be building learning experiences, but for adults, without the discipline problem."
Both beliefs are plausible. Both could be wrong in ways that cost tens of thousands to discover the expensive way.
Test the daily reality, not the exciting five percent
This is where nearly every side project fails. People test the part of the new field they already know they will enjoy, because that part is why they got interested. Then they conclude, correctly and uselessly, that they enjoy it.
The trap looks like this. Someone curious about data analysis builds a chart from a clean public dataset in an afternoon and feels a rush. But charts are maybe five percent of the job. The rest is chasing down what a column actually means, discovering that two systems disagree about the same number, and explaining to a manager why the answer is not the one they wanted. Someone curious about design makes a beautiful mockup nobody asked for. Real design work is the fourth revision after a stakeholder changed the requirement.
So ask: what does a bad Tuesday look like in this field? Then build a project that contains at least one bad Tuesday.
Marta's project, redesigned around this: rather than a portfolio dashboard from a Kaggle dataset, she offers to help a friend who runs a small bakery chain figure out which of their four locations is actually profitable per hour of staff time. The data is a mess of till exports and rota spreadsheets in three different formats. Nobody has defined what "staffed hour" means. That is the job.
Tomas's project: instead of making a slick e-learning module on a topic he loves, he offers to rebuild the onboarding material for a local charity that trains volunteer befrienders. He has to interview two people who do not have time for him, work within a subject he does not care about personally, and accept that the charity will want it in a tool he finds ugly.
Neither is glamorous. Both are honest.
Scope it so it can actually finish
An unfinished side project teaches you almost nothing, because the most informative part of any work is the last twenty percent. Finishing is where you find out whether you can hold quality under fatigue.
Fix three things before you start.
- A time budget. Not "I will work on this when I can." Something like: twelve evenings over six weeks, two hours each. Roughly twenty-four hours total. That is enough for a real deliverable and small enough that you can see the end from the start.
- A defined deliverable. Something a specific person receives. Marta's is a two-page written answer with three charts, delivered to the bakery owner, that says which locations to keep and why. Tomas's is a rebuilt onboarding pack plus a thirty-minute facilitator guide, handed to the charity's volunteer coordinator.
- A stop date, agreed in advance. Put it in the calendar. When it arrives, you stop, finished or not, and you assess. This is the single most useful constraint, because it converts an open-ended drift into a bounded test.
If the scope will not fit the budget, cut the scope, not the budget. A small finished thing beats a large abandoned one every single time, and not by a little.
Decide now what "no" looks like
Here is the uncomfortable part. Most people build projects that cannot fail. Any outcome gets read as encouragement. It went well, so the field is for me. It went badly, but that was because I was tired and the data was bad, which would not happen in a real job with real support.
Before you start, write down two or three results that would mean stop. Real ones. For Marta: "If I find that I resent the data cleaning and only enjoy the final chart, that is a no. If the bakery owner cannot use my answer because I could not explain it clearly, and I find that conversation draining rather than interesting, that is a no." For Tomas: "If I discover the part I actually miss is standing in front of people, that is a no, and it points at training or facilitation instead."
Then hold to it. The discipline is not in writing the criteria. It is in accepting them six weeks later when you have already told your friends what you are doing.
A no is not a failed experiment. A no that costs you twenty-four hours instead of a year's salary and a course fee is an extremely good outcome. It also usually contains the next hypothesis inside it.
Build for a real person, not for your own folder
Private projects flatter you. There is no one to tell you the output is confusing, arrives late, or answers the wrong question. Feedback is the entire mechanism by which the experiment produces information.
You do not need a paying client. You need someone with a genuine problem who will look at your work and react honestly. A small charity, a friend's business, a community group, a team in another department at your current employer, an open source project with real users. The test is whether they would notice if you disappeared. If they would not, you are still working in private.
Ask them for one thing at the end: was this useful, and what would you have needed to make it more useful? That answer is worth more than the deliverable.
The honest version of doing this alongside a job
You will be tired. Not romantically tired, actually tired, in a way that leaks into your day job and your relationships. Two hours on a weeknight after a full day is not two good hours, it is maybe one good hour and one hour of staring.
Some things that help.
- Put the sessions in the calendar as fixed appointments rather than intentions.
- Front-load the hard thinking into weekend blocks and use weeknights for grinding work that survives low energy.
- Decide in advance what you are giving up for those six weeks. Something has to go. Usually it is exercise or social time, and choosing consciously beats losing it by accident.
- Tell one person your stop date so it exists outside your own head.
- Do not start a second project before finishing the first. This is the most common way the whole method collapses.
Check your employment contract first
Before you build anything, read your contract, specifically the sections on intellectual property, outside work and non-compete or non-solicitation. Many contracts assign your employer ownership of work created during employment, and some are written broadly enough to cover things made on your own time and equipment.
The practical rules are simple. Do not use your employer's laptop, accounts or data. Do not build something adjacent to your employer's business. Do not use client relationships you have through work. If your contract requires disclosure or written permission for paid outside work, get it in writing before you accept money. If you are testing paid work, keep the invoicing clean and declare it properly.
None of this is exciting, and skipping it is how a promising experiment turns into a legal problem that follows you into the next role.
Then use the result, either way
If the answer is yes, a finished project is disproportionately useful. It is a CV line, an interview story, and a reason to contact people in the field who now have something concrete to react to.
Written up, it looks like this:
- Rebuilt profitability reporting for a four-site bakery chain, consolidating till and rota data into a single weekly view that identified one loss-making location.
- Delivered a two-page recommendation to the owner, who closed the underperforming site in the following quarter.
- Redesigned volunteer onboarding for a local befriending charity, cutting the induction session from three hours to ninety minutes while improving the post-training confidence score.
- Interviewed five experienced volunteers and rebuilt the materials around the four questions new starters actually asked.
Notice what those lines do. They name a real recipient, a real constraint and a real outcome. No line says "personal project to learn analytics." The interview story writes itself from there, and the best question you will be asked is "what went wrong," which you can now answer with something specific.
If the answer is no, walk away cleanly. Finish the deliverable anyway, because you promised it and because the last twenty percent is the informative part. Then close it. Write two paragraphs on what you learned and what you now believe instead. Do not leave it half-open as a source of guilt for the next two years.
And then, if you still want to move, run the next experiment. The belief has changed. Marta might now believe the thing she wants is not analysis but operations improvement with better numbers behind it, which is a different and much cheaper move from where she already sits. Tomas might now believe he wants to train trainers. Both are better placed than they were, and neither has spent a penny on tuition to get there.
That is the point. The side project is not the beginning of the new career. It is the cheapest available way of finding out whether the new career is worth beginning.