🟢 Why I Built a Fake Adventure Travel Company (and Why It Works Better Than "Employees” Tables)


Hey Reader,

Over the past few weeks, I’ve shown you The Mister Rogers Blueprint in action using Summit Adventures, the fictional adventure travel company I built for teaching.

You’ve seen real queries.

Real business insights. Real data quality issues. Today I want to tell you why I built it this way. Because the reason matters more than you might think.

The endless tutorial hamster wheel of death

You know the pattern.

You watch a Udemy course. It makes sense. The instructor shows you SELECT, WHERE, GROUP BY using an “Employees” table with 8 rows.

"Cool."

You feel good, complete the course, and update your LinkedIn profile.

Then you sit down at your actual desk with your actual database with 147 tables and millions of rows, messy data everywhere and you realize that you actually have no idea where to start.

So you take another course. Maybe a Coursera specialization this time. Or a $3,000 bootcamp that promises “job-ready SQL skills.”

Same result. You understand the syntax. You can recite what a LEFT JOIN does. But when your boss asks “Why aren’t our high-value customers rebooking?”

Panic mode. Because nobody taught you how to translate business questions into queries. This was me in at the end of 2019. My SQL skills had gotten super rusty because I wasn't practicing regularly on real database systems. I thought that just keeping up with tutorials and bootcamp courses were good enough.

I call this tutorial hell. You keep learning syntax but never learn how to actually solve problems.

I’ve been there. Early in my career, I spent months bouncing between SQL tutorials. The truth is that SQL isn't really that hard. The problem is how everyone teaches it. Most courses teach syntax. Nobody teaches how to actually have business impact with SQL skills.

In real life, nobody writes SELECT * FROM EMPLOYEES style queries for fun. You’re answering questions for people who don’t think in database terms. Your CMO doesn’t walk up and say: “Can you write a LEFT JOIN between customers and orders with a CASE statement?”

She says: “Why aren’t our high-value customers rebooking?”

You need to:

  1. Translate that business question into the right tables and columns
  2. Write the query that answers it
  3. Translate the results back into language she can act on

Most SQL tutorials skip steps 1 and 3 entirely. They just teach you step 2.

That's like teaching someone how to ride a bike, focusing ONLY on the ride down the street and ignoring how to balance on the bike and how to get off safely.

So I built Summit Adventures from scratch.

Seven interconnected tables:

  • 1,000 customers with realistic names, emails, and cities
  • 100 expeditions like Kilimanjaro treks and Iceland photography
  • 45 guides with specialties and experience levels
  • 1,600 bookings with cancellations and promo codes
  • $1.85M in revenue with payments, refunds, and partials
  • 500 expedition instances showing when trips actually run
  • 600+ guide assignments tracking who leads what

Big enough to feel real. Small enough to understand.

But here’s what really makes it work: the people.

I created four executives who run Summit Adventures. Every lesson starts with one of them walking up to your desk with a real question:

  • Lindsey Glennt (CEO): "I need to understand our revenue by expedition category. Board meeting is Thursday."
  • Marcus Gallardo (VP Operations): "Which guides are underutilized? I’m planning next quarter's schedules."
  • Gabby Traversia (Marketing Director): "Show me our customer acquisition trends by month. Something feels off."
  • Dev Cunningham (IT Director): "Find all the records with data quality issues. We need to clean this up."

(btw, I have dealt with every single one of these in my 15+ year career in data analytics. I now lead a team of 30+ data professionals and nothing has changed! Same business problems.)

Notice the difference?

You're not being asked practice GROUP BY statements until your eyes bleed. You're solving business problems with SQL. You learn SQL in the context where you’ll actually use it.

The intentional mess (this is important)

Here’s the part most tutorial creators won’t do. I deliberately added realistic data problems.

About 15% of records have issues:

  • Email addresses like “evan.clarke743@noemail” (clearly not real)
  • Phone numbers that are just “555-0100” (placeholder data)
  • Ages that don’t make sense (a 102-year-old adventure traveler?)

Not because I’m sloppy. Because real databases have these exact problems and you have to work around them in the real world. You need to learn how to spot them. Filter them. Work around them. Explain them to executives who don’t understand why “the data is dirty.”

That’s the actual job.

Why this approach works

Remember two weeks ago when I showed you how to find that expert customer gap?

-- Customer distribution
SELECT 
    experience_level, 
    COUNT(*) AS customer_count
FROM customers
GROUP BY experience_level;
-- Results:
-- 268 expert customers (26.8%)
-- Product distribution
SELECT 
    difficulty_level, 
    COUNT(*) AS expedition_count
FROM expeditions
GROUP BY difficulty_level;
-- Results:
-- Only 19 expert expeditions (19%)

268 expert customers but only 19 expert expeditions.

30 seconds to find that business opportunity, once you know what to look for.

That wasn’t a special cherry-picked example. That’s how the entire teaching approach works. Every query you write answers a real question from a real executive.

You’re building muscle memory for:

  • Translating business questions into the right tables and joins
  • Connecting multiple data sources to get complete insights
  • Spotting and handling messy data (it’s everywhere)
  • Presenting results in language non-technical people understand

This is why students like Jenn say: “I paid $2,500 for an Ivy League course. Brian’s approach crushes it. You feel like you’re learning side by side vs. an abyss of a giant infinite online classroom.”

It’s not that my SQL teaching is different. It’s that the context makes everything stick.

What I’m building toward

This week, I’m putting the finishing touches on the complete SQL for Business Impact course.

Eight modules. All built around Summit Adventures. Every lesson starts with an executive asking you a business question. You then work step-by-step to solve each problem. From learning to doing.

  • Module 1: Your first day (customer analysis)
  • Module 2: Product catalog (sorting and filtering)
  • Module 3: Booking patterns (time-based analysis)
  • Module 4: Connecting the dots (JOINs)
  • Module 5: Finding who’s missing (LEFT JOINs and NULLs)
  • Module 6: Following the money (revenue analysis)
  • Module 7: Ranking what matters (window functions)
  • Module 8: Executive-level analysis (putting it all together)

Most importantly! I don't include any abstract theory. No super boring, over simplified “employee/department” tables. Just practical analytics skills in business context -- based on the fake Adventure Travel company I built over the past couple of months :)

Plus: You’ll get access to Summit Adventures SQL Lab, a custom-built query editor I created specifically for students. Pre-loaded database. No installation. Dark mode. Query history. Example queries. Image and CSV export. Works on any device.

One question for you:

What’s holding you back from being confident with SQL right now?

  • Feeling distracted?
  • Skills have gotten rusty?
  • AI is stealing all of the data jobs?
  • Tried learning SQL in the past and it hasn't worked?

Hit reply and let me know. I read and reply to every response, and I’m genuinely curious what obstacles people are facing. Or fill out this quick survey. I have big plans for teaching more "Full Stack Business Analyst" skills in 2026 and beyond.

Next week, I’ll share more about what the course includes and when it opens. For now, I just wanted you to understand why I built it this way.

Talk soon,

Brian

P.S. “Is Summit Adventures too simple compared to my real database?” I've thought about this question a lot. No. The patterns you learn with 7 tables scale directly to enterprise systems with 200 tables. The thinking process is identical. That’s the whole point!

Whenever you’re ready, here’s how I can help you:

  1. Get more data analytics tips in my previous newsletter articles
  2. Fill out the subscriber survey and let me know what's going on in your life this week (and how I can help!!)

You are receiving this because you signed up for Analytics In Action, purchased one of my data analytics products, or enrolled in one of my data analytics courses. Unsubscribe any time using the link below.

600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246
Unsubscribe · Preferences

Starting With Data

Learn to build analytics projects with SQL, Tableau, Excel, and Python. For data analysts looking to level up their career and complete beginners looking to get started. No fluff. No theory. Just step-by-step tutorials anyone can follow.

Read more from Starting With Data

Hey Reader, Last week I showed you The Mister Rogers Blueprint, the step-by-step guide to approaching unfamiliar dataset and delivering actionable insights. You might be thinking: “Okay, cool framework. But does this actually work?” Fair question. Let me show you what happens when people learn SQL this way. First, let’s talk about what doesn’t work. Jenn (a student and data coaching client of mine) paid $2,500 for an SQL course from an Ivy League university. She thought it would be robust,...

Hey Reader, Remember Mister Rogers? "Won't you be my neighbor?" That show taught me back in the day (and my now-grown kids more recently) along with millions of others young and old how to approach new situations with curiosity instead of fear. Turns out, that's exactly the mindset you need when someone drops an unfamiliar database on your desk. Here's the situation every analyst will face: You start a new job or project. Your manager says "Pull the customer data for Monday's meeting." You...

Business leaders are dumb. That's what a lot of business analysts think because they create something "awesome" with a dataset and then it gets ignored. Unfortunately, these types of business analysts don't realize that leaders aren't dumb. They are just busy. They are responsible for making decisions and making them quickly. And leaders need answers (based on data) more than anything. Think about it: if they need answers and you have the skills to provide those answers... You become their...