"I can't build software. I'm not a developer."
I hear this constantly. From executives, from educators, from smart people who've convinced themselves that building is someone else's job.
It's the biggest lie holding organisations back.
Building isn't coding. It never was. Coding is just one implementation detail, and increasingly, it's the part AI handles for you.
Building is thinking in systems. It's understanding how things connect, what causes what, where the leverage points are. That's a skill anyone can develop. And it's the skill that actually matters.
What "Thinking in Systems" Means
When I built Guest Loop, I didn't start by writing code. I started by thinking through the system:
What's the goal?
Guests arrive at my property, get the information they need, feel looked after, and I capture their email for future contact.
What are the components?
- • A way for guests to access information (QR code → landing page)
- • Content they need (property details, local recommendations, emergency contacts)
- • A way to capture their details (email signup)
- • A way for me to manage and update content (admin interface)
- • A way to reach them later (email integration)
How do they connect?
Guest scans code → sees property page → browses content → optionally leaves email → I follow up later. Each step flows to the next.
Where are the failure points?
QR code doesn't scan. Page loads slowly. Content is outdated. Email doesn't send. Each needs handling.
What's the minimum viable version?
Start with one property, basic content, simple email capture. Add complexity later.
That's systems thinking. Notice there's no code in any of that. Just clear thinking about components, connections, and flows.
The code came later, and by the time I got there, I knew exactly what I was building. The hard thinking was done.
The Myth of the Technical Founder
There's a persistent myth that building requires deep technical skill. That you need to understand algorithms, data structures, and programming languages before you can create anything.
This was never entirely true. But it's especially false now.
The most important skill in building has always been understanding the problem. Technical implementation is secondary. I've watched brilliant developers build useless products because they started with technology instead of problems. I've watched non-technical people build valuable tools because they understood exactly what was needed.
AI has widened this gap. Now you can describe what you want in plain English and get working code back. The implementation barrier has collapsed. What remains is the thinking barrier, and that was always the real challenge.
The founders who succeed aren't the ones who write the best code. They're the ones who understand systems: how users behave, how components interact, how value flows through a product. Technical skill helps, but it's not the bottleneck.
The bottleneck is clarity of thought. And that's domain-independent.
The Components of Systems Thinking
Let me break down what systems thinking actually involves:
1. Identifying the Goal
What are you actually trying to accomplish? Not the feature you want to build, the outcome you want to achieve. This sounds obvious but most projects fail here. They start with a solution ("we need an app") instead of a problem ("guests can't find information easily").
2. Mapping the Actors
Who's involved in the system? What do they want? In Guest Loop: guests want information quickly, I want their contact details and fewer repetitive questions. Both actors have goals. The system needs to serve both.
3. Understanding the Flow
How does value move through the system? What triggers what? What's the sequence of events? Draw it out. Guest arrives → scans code → views content → provides email → receives follow-up. Each arrow is a connection that needs to work.
4. Identifying Dependencies
What relies on what? If the QR code doesn't work, nothing else matters. If the content is wrong, email capture is pointless. Understanding dependencies tells you what to build first and what to test most carefully.
5. Finding Leverage Points
Where does a small change create a big impact? In Guest Loop, the leverage point is the QR code placement. If guests don't scan it, nothing else happens. That's where to focus optimisation.
6. Anticipating Failure Modes
What can go wrong? How will you know? What will you do about it? Every connection is a potential failure point. Systems thinkers plan for failure; they don't assume success.
7. Defining Boundaries
What's in scope and what isn't? What's the minimum version that delivers value? Scope creep kills projects. Clear boundaries save them.
None of this requires coding. It requires thinking clearly about how things work.
What AI Changed
Here's what's different now:
Before AI
You could think in systems all you wanted, but at some point you needed someone to translate that thinking into code. That translation was expensive, slow, and often lossy. Developers didn't always understand what you meant.
After AI
You can describe a system in plain language and get working implementation. The translation layer has collapsed. Your systems thinking becomes the product much more directly.
This changes who can build.
Previously, you needed either coding skills or money to hire coders. Now you need systems thinking and the ability to communicate clearly with AI tools. The first is a skill anyone can develop. The second is just clear writing and iterative refinement.
The new builder archetype isn't a programmer. It's someone who:
- Understands a problem domain deeply
- Can think clearly about systems and flows
- Communicates precisely
- Iterates based on feedback
Notice that none of these are technical skills in the traditional sense. They're thinking skills. They're communication skills. They're the skills of a good product manager, a clear writer, a rigorous thinker.
The Product Manager Mindset
The closest existing role to "systems thinker who builds" is product manager. Good PMs don't write code, they define what should be built and why.
Here's what PMs do that translates directly to building:
This is systems thinking applied to products. And it's exactly what you need to build with AI assistance.
If you can think like a product manager, you can build. The AI handles the implementation. You handle the thinking.
A Practical Example
Let me walk through how this works in practice.
Problem:
My team wastes hours every week manually copying data between two systems that don't integrate.
Systems Thinking:
Goal:
Eliminate manual data copying, save team time, reduce errors.
Actors:
Team members (want less tedious work), the two systems (have APIs? export functions?), me (want efficiency and accuracy).
Current Flow:
Person exports from System A → opens spreadsheet → reformats data → imports to System B → manually checks for errors. Takes 3 hours weekly.
Desired Flow:
Automated process extracts from A → transforms data → loads to B → notifies team of any issues. Takes zero hours weekly.
Components Needed:
- • Connection to System A (API or export)
- • Data transformation logic (what fields map to what?)
- • Connection to System B (API or import)
- • Error handling and notification
- • Scheduling (when does this run?)
Dependencies:
Need API access to both systems. If either doesn't have an API, need a workaround (file export/import?).
Minimum Viable Version:
Script that runs manually, does the transfer, flags any issues. Automation and scheduling can come later.
Failure Modes:
API credentials expire. Data format changes. One system is down. Transfer partially completes. Each needs handling.
Now I can describe this to an AI assistant and get working code. Not because I know how to write API integrations, but because I know exactly what I need the integration to do.
The Skills to Develop
If you want to build, here's what to practice:
Problem Definition
Get specific about problems. Not "our process is inefficient" but "we spend 12 hours per week on X task because Y doesn't connect to Z." Precision matters.
Flow Mapping
Draw how things work. Boxes and arrows. Don't worry about formal notation, just capture: what are the steps, what connects to what, where are the decision points. If you can't draw it, you don't understand it well enough.
Decomposition
Break big things into small things. Any complex system is just a collection of simple components connected together. Identify the components. Understand them individually before worrying about connections.
Constraint Identification
What are the limits? What can't change? What must be true? Constraints shape solutions. Know them early.
Iteration Mindset
Accept that the first version will be wrong. Plan to learn and improve. Don't try to design the perfect system upfront, design a system that can evolve.
Clear Communication
Practice explaining systems to others. If you can explain it to a person, you can explain it to an AI. If you can't explain it clearly, your thinking isn't clear enough yet.
What This Means for You
If you've been telling yourself "I can't build," stop.
You can think. You can analyse problems. You can understand how things connect. You can communicate clearly.
That's building. The rest is just implementation, and implementation is increasingly something AI can help with.
Start small. Pick a problem you understand well. Think through the system. Describe what you need. Use AI to help create it. Iterate until it works.
You'll learn that the hard part was never coding. The hard part is thinking clearly about what to build. And that's a skill you can develop with practice, no computer science degree required.
The Real Barrier
The reason most people don't build isn't lack of technical skill. It's lack of permission.
They've been told building is for developers. They've been told they need certain credentials, certain training, certain job titles. They've absorbed the message that creating technology is someone else's job.
That message was always somewhat false. Now it's completely false.
The tools exist. The barriers have fallen. The only thing stopping you is the belief that you can't.
Building isn't coding. It's thinking in systems. And you already know how to think.
Written by
Jason La Greca
He's spent 20 years as a product manager and technologist, and he's watched too many smart people convince themselves they can't build. They're wrong.
Connect on LinkedInReady to develop building capability in your organisation?
Take the AI Readiness Assessment to see where you stand.
Start AssessmentWant strategic guidance on building capability?
Explore Teachnology Advisory for hands-on support.
Explore Advisory