In this instructional video, Kedeisha Bryan explains why a single portfolio project helped a student secure a $100K data analyst role, and outlines a repeatable framework for building high‑impact showcase projects. She contrasts learning‑oriented tutorials with showcase‑oriented projects, emphasizing that hiring managers evaluate real decision‑making, not tool checklists. Bryan presents three core rules for a six‑figure portfolio project: (1) start with a high‑value business problem rather than a pre‑packaged dataset, using AI to assemble authentic public data; (2) embed ambiguity and messy data to force genuine analytical judgments that can be discussed in an interview; and (3) conclude with a clear, actionable recommendation and package the whole narrative around that outcome. She also warns against chasing trending project topics and encourages leveraging one’s own domain experience to define problems that hiring managers find compelling. The video stresses that such projects reduce hiring risk, demonstrate competence, and differentiate career‑changers from the crowd.
Chapters
One of my students showed this portfolio project in his interview and landed a $100K data analyst job offer. Meanwhile, other aspiring analysts are spending weeks or months building projects that may look decent, but do absolutely nothing to prove they can actually do the job. This project was different. So today I'm going to break down exactly why it made it so convincing so you can build your own projects that lead to high earning roles in data analytics. Now here's what makes this story even more interesting. The student already had a master's degree from one of the top schools here in the country. So if a degree was sitting right there on his resume, why the heck did a portfolio project end up doing the heavy lifting in the interview? Because the degree told the VP of analytics what he studied, but the project let the VP watch him work. He pulled it up and walked through it the same way an analyst would present to a stakeholder. Here's a problem, here's the data, and here's what I found, and here's how I got there. And the moment he did that, the whole dynamic shifted in the interview. It stopped being the generic Q&A and became a working session because now the VP could push back in real time. Why did you use that metric? Why did you approach your analysis that way? And what would you do next? Think about how much stronger that position is sitting across the table of a hiring manager saying, I know SQL, I know Excel, and I know Tableau. When you just list tools, then the hiring manager has to take your word for it. But when you walk them through your real work, they can actually evaluate you while you're sitting there. And that's exactly what they want. Because hiring you is a risk. You just made the risk smaller. And this is exactly where many career changers get stuck in the job application process. When the interviews aren't coming, the instinct is to add one more thing to the resume, another certificate, another course, another credential, or worse, even another degree. When the real problem is that nothing on the resume turns what you learned into evidence. That is what my student's project did for him, and that is what your projects need to do for you. But that only works if the project gives the hiring manager something meaningful to evaluate. And that's where most portfolios fall apart. Now, there's 2 types of projects. Projects for learning and projects for showcasing. Your projects for showcasing is what goes on your portfolio. But most people are trying to make one do the other's job. So let's clear the difference. Say you're learning Tableau, you find a tutorial, you download the same dataset as the instructor, and you follow along. They tell you which calculation to create, which charts to build, where the filters go. You finish and hopefully you understand Tableau better than you did before. That's genuinely useful and the project did what it was supposed to do. The problem starts when you take that exact same project and expect it to prove that you're already ready to work as an analyst. Because the hiring manager can see the dashboard, but they can't see which decisions were actually yours. Because someone else chose the problem, someone else chose what to investigate, and someone else already knew what the finished answer was supposed to look like, eliminating all the uncertainty for you. But real analyst work is built around uncertainty and ambiguity. Someone says revenue is down. Can you figure out what's going on? They don't hand you a tutorial. They don't tell you which chart to make. You have to decide where to start, what questions to ask, and who to ask. Maybe order volume dropped. Maybe people are still buying but spending less per order. Maybe the whole decline is coming from one region or product line, but you don't know yet. And having to find out is exactly what makes a project valuable because that investigation is what you can talk about in the interview. Now compare that to the project description that I constantly see on people's portfolios every week. Use joins, CTEs, window functions, and subqueries. Okay, but use them for what? Your manager is never going to walk over to you and say, can you get me 3 CTEs by Friday? They're going to hand you an ambiguous business problem and SQL is just going to help you get to the answer. So yes, tutorials have their place and learning projects have their place. You just have to know when the purpose changes. A project for learning practices a tool and a showcase project proves skill competency. So forget about asking how many projects do you need. There's only 3 rules that separate a 6-figure portfolio project from everything else. And once you know them, you can build yours around any problem that you want. Rule number 1, reverse engineer a high-value problem from your own domain or target domain. The project starts with a business problem, never a dataset. Most people work backwards though. They download the same clean Kaggle dataset as everyone else, poke around, make some charts, and then reverse engineer a story to justify them. Employers can smell that from across the room. You need to work from the other direction. Think about what actually costs money or keeps a manager up at night in the world that you already know. Overtime keeps climbing, customers who quietly leave in a month or 2, shipments that keep missing their windows, and state in one sentence a manager would say out loud. Overtime is up 18%, but output barely moved. Why? If you can't state your problem in one sentence before you open a single tool, you don't have a real project yet. You just have an exercise. But here's where things get modern. Once you have a problem, don't go and download fake practice data like everyone else. Use AI agents to search the internet and build the dataset for you with actual real data. Real industry benchmarks, real public records, real reported figures assembled around your target problem. Now your project is grounded in reality while the rest of the applicant pool is presenting the same recycled practice files. And when the interviewer asks you where you got your data from, you can have an answer that makes you sound like an analyst instead of a student. Now, rule number 2, the project has to force real decisions because your decisions are the thing that gets evaluated. If the data comes clean and the answer falls out of the first chart, there's nothing for an employer to judge. And that is a beautiful thing about building from real data. The mess comes built in. Inconsistent labels, duplicate records, a value that can't be possibly right. Because the moment you have to decide whether a weird record is a mistake or something real, you've created an interview story. Not, I just dropped nulls. A judgment call with reasoning behind it. And the same rule applies to the analysis itself. The first answer is almost never the real one, so the project should show you digging past it, bringing the number down by shift, by hour, by segment, until the vague observation becomes a specific fixable problem. Remember my student in his interview? The VP wasn't grading his charts. He was grading his decisions. Now, rule number 3, end with a recommendation and package everything around the result. Your project doesn't finish with a dashboard. It finishes when you tell the stakeholder what to do next with judgment attached. Based on what I found, I'd investigate staffing coverage of the first 2 hours of the night shift before changing anything else. Then the packaging carries that same result forward. You title the project after the problem, diagnosing an 18% overtime increase in warehouse operations. And notice that was an action title, a highly valued storytelling technique that you should definitely be learning. But that's it. Business problem first, decision that your employer can evaluate, and a recommendation packaged around the result. Whether you did the work in SQL, Excel, Tableau, Python, That's secondary. The tools are how you execute, but the rules are why the project convinces. Now, where should this high-value business problem come from? This is where I'm going to push against what most people are doing in the space right now. Every week I watch aspiring analysts chase whatever project is trending. Another streaming dashboard, another churn analysis on the same dataset that 10,000 other people have used, or another AI project they can't explain past the first question. And they all end up invisible for the same exact reason. They're following the crowd. And the crowd all looks identical to a hiring manager. Leaders don't build what's trending. They build from ground that they own. So if you've spent years in operations, teaching, healthcare, or on the road driving, you understand business problems the tutorial crowd has never seen. So build your projects there with AI pulling real data from the internet to construct it. Never your company's actual numbers. You may be new to the title data analyst, but you're not new to business problems. And the person who walks into the interview with a project rooted in a domain that they can actually defend doesn't read off as a career changer asking for a chance. They come off as an expert. Remember, if you understand the distinction between projects for learning and the 3 rules that encompass a 6-figure portfolio project, you will never lose in this job market. Now, I know some of you are sitting here thinking you'll start that project once the market calms down, or once the AI headlines stop, once it feels safe to commit. That is one thing I would push back on the hardest, because the people who hesitate through this next stretch are going to look up in 2 years and realize the door was the widest open The exact moment they felt it was scariest. I made the full case for that in this video right here, why this is the best opportunity to go all in data analytics and AI instead of waiting it out, and what's actually happening in the market underneath all the noise. I'll see you in the next one.
