You Can Just Build Things

Welcome. Today is not a workshop where you sit and watch me. Today you build. By the time you leave, you'll have made something real that solves a problem you actually care about. Let's get you excited about what's possible.

I’m Jethro Jones.

Award-winning principal · Author · Podcaster · Doctorate in exactly this

Thirty seconds on why you might listen to me. I'm a national-award-winning former school leader — I've led at every K-12 level, including a prison school. I host Transformative Principal, the longest-running and most-downloaded podcast for school leaders, and I founded the BE Podcast Network. I've written two books on this work — How to be a Transformative Principal and SchoolX — and I just finished my doctorate on exactly the question we're living today: how real people use design thinking and AI to solve problems that matter.

I run Optimization Doc.

I help teams turn flashy AI demos into workflows they can actually trust.

size: contain

This is what I do for a living now. I take the repeated, time-eating work a team does every week and turn it into documented, AI-assisted workflows their people trust — moving them from "cool demo" to reliable, reusable capability. It's human-first: I'm scaling what people can do, not replacing them. So when I tell you that you can build something real in an afternoon, that's not hype. I watch regular people and organizations do it. Today it's your turn.

Are you This Experienced with AI?

About you: Choose 1

What’s one thing you’ve built or created that nobody cares about?
What side project refuses to leave your brain?

What’s one thing you’re intentionally not using AI for?

What are you hoping to get from this event?

You don’t have to wait for someone else to build it anymore.

That used to be the rule. If the software you needed didn't exist, you were stuck — you did it manually, you paid a fortune, or you gave up. That rule is dead. That's what today is about.

Two things are true about AI

I only get a little time before we turn you loose, so let me give you the two things that matter most.

It’s a prediction engine.

At its core, AI predicts the next most likely thing. That's it. That's why it's fast, and that's why it sometimes makes things up.

It can do almost anything — but it’s hard to get it to do something very specific.

Can AI build the thing you want? Yes. Will it do exactly what you pictured on the first try? No. The whole skill today is learning to describe what you actually want clearly enough that it can help you build it.

/Goal

1. Identify a problem.

2. Find a solution.

3. Build that solution — today.

Three moves. That's the whole day.

Notice the order. We don't start with "what should I build?" We start with a real problem. The build is the easy part now. Finding the right problem is the work.

Most of your time is for building.

I'll talk for a bit. We'll find your problem together. And then I get out of your way. The biggest block of today is hands-on-keyboard, making the thing.

First: where do good problems come from?

Before you touch a single tool, you need a problem worth solving. Let's find yours.

What do you care about?

List three to five things you're curious about, excited by, or frustrated by. Don't filter. Education, your commute, your team's paperwork, a hobby, something that annoyed you this morning. Frustration is a gift here — it points at real problems.

“I wish because .”

This is the whole game. Pick one thing you care about and finish this sentence out loud.

“I wish researchers spent less time on paperwork, because it slows down real progress.”

That's a problem statement. It names who, what, and why it matters. Yours doesn't have to be big. It has to be real. This one sentence is your north star for the rest of the day.

I wish my customers could know exactly when I will complete their work

But which problem? Not every problem is the right one to grab today.

Some problems are too small to matter. Some are so big you'll burn out before lunch. There's a sweet spot in between — and I learned this the hard way in my doctoral work.

The Sweet Spot

Walk them through it slowly. As a problem gets more complex, the solution gets harder — but the real variable on the bottom is your willingness to persevere. The sweet spot is where a problem is complex enough to be worth solving, and a solution is achievable if you're willing to push. Pick a problem that lands in that circle. Not trivial. Not impossible. Worth persevering for.

Pick something small enough to build today, big enough to be proud of.

If you only had a few hours — and you do — what's the smallest useful version you could make? One screen. One tool. One workflow. Start there.

Let me show you someone who did exactly this — last week.

This isn't theory. A guy named Alex runs a land-clearing business. Watch how fast this went from a complaint to a working product.

The problem showed up as an annoyed customer.

Read it out loud. "I took off for the 13th. I'm losing money taking days off." This isn't a data problem. Alex was already sending texts, emails, voicemails. It's an expectation problem — the customer thought a scheduled date was a promise.

Source (Alex B, @bprintco): https://x.com/bprintco/status/2077032883529580747

The real friction, in his own words.

Weather and equipment move his job dates constantly. He communicates like crazy. And still, his number one complaint is people taking off work and getting upset when the job slips. Sound familiar? Every business has a weird problem like this that no off-the-shelf software solves.

Source (the original thread): https://x.com/bprintco/status/2077032883529580747

So he stopped sending reminders — and changed what the customer sees.

The insight: don't show a fragile promise. Show the real operating model. A queue. An arrival window, not a hard date. How many jobs are ahead. When the next update comes.

Source (the queue idea): https://x.com/bprintco/status/2077038638592844088

He built this. In an afternoon.

This is a private job dashboard for one customer. Arrival window: a range, not a date. Queue position: seven jobs out. Weather watch. A clear "call me if you have a hard deadline" button. It doesn't eliminate uncertainty — it productizes it, so the customer finally understands it.

Source (the mockups he shared): https://x.com/bprintco/status/2077083961340067909

“Fixed this issue in a few hours. AI is amazing.”

A few hours. He wired it to his existing scheduling system through its API — internal dates stay exact, the customer sees windows, and a big change automatically triggers a text and email. AI didn't replace his business. It wrapped a better experience around it.

Sources — "fixed it in a few hours": https://x.com/bprintco/status/2077083961340067909 · how it's automated through the Jobber API: https://x.com/bprintco/status/2077085566080807208 · the AI build process (GPT + Codex + design skills): https://x.com/bprintco/status/2077087686599356550

He started with a real problem.

Here's my favorite part. When someone asked if he'd planned all this, he said: "No lol. Making a post about it made me start thinking. You witnessed a brain dump." Explaining the problem clearly was the spec. That's what you're going to do today.

Source (the "brain dump" reply): https://x.com/bprintco/status/2077122004138831987

The repeatable pattern

This is the recipe. It works for a business, a classroom, a nonprofit, a household.

Find the friction.

Name it plainly.

Describe the outcome you want.

Let AI help you build it.

The quality of what you build depends almost entirely on how clearly you can describe the real-world result you want. Not "build me an app." But "when a customer opens this, they should see a window and feel calm instead of anxious."

OptimizationDoc.com/events

ChatGPT — think the problem through, out loud.

A custom GPT — a design-thinking coach in your pocket.

Discovery Canvas

Codex — turn the idea into a working prototype.

You don't need to know how to code. Pick the one that fits how you like to work.

Start by talking to the AI like a smart colleague who needs context. Describe your "I wish" statement. Ask it what the smallest useful version looks like. Then build.

Be honest about where AI helped — and where you decided.

That's not cheating; hiding it is. The best builders today can point at their work and say "AI did this part, and I made this call." Own both.

Here’s the whole day — 10 to 4.

We've got this room until 4:00, and most of it belongs to you. Here's the shape of the day so you always know where we're headed. (Doors and coffee opened at 9:30 — glad you're here.)

10:00 — Welcome & why you can build now

10:30 — Find your problem

11:30 — Build (solo or with a team)

12:00 — Working lunch: how to demo what you make

3:00 — Showcase your prototype

4:00 — Wrap

Point at the clock. From 11:30 on, I'm out of your way and just walking the room. The deadline is your friend — 3:00 is what turns a nice idea into a real demo. Don't wait for permission; start building the moment you've got a problem worth solving.

Your first build push:

— Define your problem (“I wish _ because _”)

— Sketch the smallest useful version

— Build and test it with AI

— Get something you can show

This is how you spend that first stretch after we break. Tight loops. Don't polish — get to something that works, then make it better.

All that matters is that it is real.

A rough thing that solves a real problem beats a polished thing nobody needs. You already have the problem. You have the tools. You have the time.

Go build something.

That's it from me. Find your problem, find your sweet spot, and make the thing. I can't wait to see what you come up with.

You Can Just Build Things

I’m Jethro Jones.