"I don't know what I'd build."
I hear this constantly from teachers who want to create something of their own. They've read about side income. They've seen colleagues leave teaching and build businesses. They're curious, maybe even excited.
But they're stuck on the first step. They don't have The Idea.
Here's what I want you to understand: neither did I.
Moodle wasn't my idea. I found it. Guest Loop wasn't a stroke of genius. It was frustration with Airbnb that I finally decided to do something about.
The best products don't come from big ideas. They come from small frustrations that someone decides to fix.
The Myth of the Big Idea
We've been sold a story about entrepreneurship.
Genius founders have breakthrough insights. They see the future before anyone else. They build revolutionary products that change the world. The idea comes first, fully formed, and everything else follows.
This story is mostly nonsense.
Most successful businesses started with someone noticing a problem in their own life and thinking: I could probably solve this better than what currently exists.
Airbnb started because the founders couldn't afford their rent and had air mattresses. Slack started as an internal tool for a gaming company. Instagram started as a check-in app before pivoting to photos.
The idea wasn't the hard part. Finding the problem was. The idea emerged from living with frustration long enough to do something about it.
You don't need a big idea. You need to pay attention to small problems.
The Friction Audit
Here's an exercise I give everyone who says they don't have an idea.
Make a list of 20 problems you personally experience. Not problems you've heard about. Not problems you think exist in the market. Problems you feel, in your own life, on a regular basis.
Don't filter. Don't judge whether they're "big enough" to be businesses. Just list them.
For each problem, answer five questions:
How often does this problem occur?
Daily? Weekly? Once a term? Problems that happen frequently are generally worth more than problems that happen rarely.
How painful is it when it happens?
Rate it 1-10. A 3 is a minor annoyance. A 9 is something that ruins your day. High-pain problems are worth solving.
How do you currently solve it?
What's the workaround? What tool do you use? What manual process have you cobbled together? This tells you what you're competing against.
What's wrong with the current solution?
Why isn't it good enough? What's frustrating about it? This is where your opportunity lives.
Would you pay money to make this problem go away?
Be honest. Not "would someone pay" but "would you, personally, right now, spend money on this?" If yes, you've found something interesting.
Do this exercise properly and you'll have 20 potential starting points. Some will be dead ends. Some will be too small. But hidden in that list is probably something worth building.
Where Teachers Find Problems
You have access to problems that most entrepreneurs don't even know exist.
You understand teachers. You know what they complain about in the staffroom. You know which tools they hate. You know which processes eat their time. You know the gap between what admin thinks happens and what actually happens.
You understand students. You know what they struggle with. You know what engages them and what loses them. You know the problems parents don't see.
You understand schools. You know how decisions get made. You know who has budget. You know what gets approved and what gets blocked. You know the politics, the priorities, the constraints.
This insider knowledge is valuable. Problems that seem obvious to you are invisible to people who've never worked in education.
Some examples to get you thinking:
A parent communication tool that's actually designed for how teachers communicate, not how software companies think they should communicate.
A resource organiser that works the way teachers actually save and find things, because we all know the shared drive is chaos.
An IEP goal tracker that makes compliance documentation less painful for special education teachers.
A behaviour log with quick entry, pattern detection, and easy reporting.
A relief teacher handover system that actually tells casual staff what they need to know.
None of these are revolutionary. All of them are real frustrations. All of them could become products.
Start With Yourself
The minimum viable first project should be something you'll actually use. Not something you think other people might want. Something for you.
This keeps it real. You understand the problem because you live it. You're motivated because you'll benefit directly. You get immediate feedback because you're using it every day.
Guest Loop started this way. My wife and I run Airbnbs. We were frustrated with not owning our guest relationships. I built a tool for us first. Only later did I realise others could benefit.
Moodle started this way too. I was frustrated with the passive LMS at Tokyo Keizai. I deployed Moodle for my own teaching first. Only when other teachers saw it did it spread.
First for you. Then for others. This is the pattern.
Validate Before You Build
Your problem might be unique to you. Before you invest months building something, make sure other people share the pain.
Search Reddit, LinkedIn, Facebook groups. Wherever your potential customers gather online, look for people complaining about the same thing. Look for posts asking for solutions. Look for frustration that matches your frustration.
Talk to people in your target market. Not surveys. Actual conversations. Ask about their challenges. Listen for the pain points. See if your problem shows up without you prompting it.
The key is to listen, not pitch. You're not trying to convince anyone of anything yet. You're trying to understand if the problem is real and widespread.
If you can't find others who share the friction, reconsider. Either you're unique, or you're looking in the wrong places. Either way, building a business gets much harder when you're the only one who wants what you're selling.
Scope Small
Once you've found a validated problem, the temptation is to build everything. To add features that might be useful. To create the comprehensive platform that does it all.
Resist this temptation with everything you have.
One problem. One solution. That's it.
Every feature you add is complexity you have to maintain. Code to debug. Interface to explain. Decisions for users to make.
The first version of Guest Loop was embarrassingly simple. Digital guidebook. Email capture. That's it. No CRM. No blog generator. No analytics dashboard. Just the core thing that solved the core problem.
It was ugly. The backend was horrible. Clunky. Confusing. Buttons in the wrong places. Workflows that made sense to me but baffled everyone else.
I shipped it anyway.
The product got better because we shipped it ugly first. If I'd waited until it was perfect, I'd still be waiting. The perfect version doesn't exist. There's only the current version and the next version.
The Pattern
Here's the pattern I've seen work, distilled to its essence:
Step 1: Find friction you personally understand.
Not market research. Not trends. A problem you actually feel in your own life. Something that annoys you enough to fix.
Step 2: Validate that others feel it too.
Search online. Have conversations. Look for signal that this isn't just your problem.
Step 3: Scope the smallest possible solution.
What's the minimum you could build that would address the core pain? Not the dream version. The ugly first version.
Step 4: Build it.
Use AI tools if you're not technical. Partner with someone who can build if you can't. But get something working.
Step 5: Use it yourself.
Dogfood it. Feel every friction point. Know where it breaks.
Step 6: Get your first real user.
Someone who's not your friend. Someone who'll tell you what's wrong.
Step 7: Iterate based on feedback.
Fix the biggest problems. Cut features that confuse people. Add features they actually need.
Step 8: Get someone to pay.
Even $50 proves that someone values this enough to exchange money for it. That's validation nothing else can provide.
This is the path from "I don't have an idea" to "I have a product people pay for." It's not glamorous. It's not fast. But it works.
What's Actually Stopping You
Let me name some fears, because you're probably feeling them.
"What if my idea is stupid?"
It probably is, at first. So was everyone else's. Ideas get better through contact with reality. You can't refine something that doesn't exist.
"What if someone else is already doing this?"
Good. That means there's a market. Competition validates demand. And there's always room for a better version, especially one built by someone who actually understands the users.
"What if I build it and nobody wants it?"
Then you'll have learnt something valuable, faster than if you'd spent months researching and planning. Failure is information. It's only wasted time if you don't learn from it.
"What if I'm not technical enough?"
AI has changed everything. You can build working prototypes without writing code. The barrier isn't technical skill anymore. It's willingness to start.
"What if I don't have time?"
You don't have time to build a big thing. You have time to build a small thing. Start with 30 minutes a day. That's enough to make progress.
The Real Blocker
Here's what I've learnt about people who say they don't have an idea.
Most of them do have an idea. They have several. They just don't think those ideas count.
They're waiting for the idea that feels big enough, important enough, guaranteed enough to be worth pursuing. They're waiting for certainty that never comes.
The friction audit usually surfaces something interesting within the first ten minutes. The problem isn't lack of ideas. The problem is lack of permission to pursue the ideas they already have.
So here's your permission.
That small annoying thing you keep complaining about? That's an idea.
That tool you wish existed but doesn't? That's an idea.
That process you've hacked together with spreadsheets and workarounds? That's an idea.
You don't need a bigger idea. You need to take the ideas you already have seriously.
Your Homework
This week, do the friction audit.
List 20 problems you personally experience. Answer the five questions for each one. Rank them by frequency and pain.
Then pick one. Not the best one. Not the most marketable one. Just one that's interesting enough to explore.
Spend an hour searching online for other people who share this problem. See if it's real beyond your own experience.
That's it. That's the first step.
You don't need a big idea. You need a small problem and the willingness to solve it.
Start there.
This framework is from "Teach Yourself Out," which shows teachers how to translate classroom skills into products, income, and options. If you want the full path, the book goes deeper.
Where teachers find problems worth solving • Real support • Real builders
Written by
Jason La Greca
Founder of Teachnology. Building AI that empowers humans, not replaces them.
Connect on LinkedInReady to translate your teaching skills?
Join the Teach Yourself Out community. Learn how to leverage your classroom experience into product management, consulting, or building your own thing. Free to start.