People ask me what coding languages I know. Python? JavaScript? React? The answer is none. I've never written a line of code myself. I wouldn't know where to start. I couldn't tell you the difference between a function and a method, or explain what an API does in any meaningful technical detail. If you sat me in front of a blank code editor and told me to build something, I would stare at the cursor until one of us gave up.
And yet I've built fourteen live products. Real things, with real users, running on real servers. A cultural news aggregator. A wearable tech feed. A tube exit guide for the London Underground. An AI art gallery of modern brands reimagined as 1970s retail stores. A personal taste engine. Each one designed, built, and shipped by me - a forty-something Strategy Director from Nottingham whose entire technical background consists of being reasonably good at PowerPoint.
The tool that made all of this possible is Claude Code. And the skill that makes it work isn't technical at all. It's the ability to articulate clearly what you want. If that sounds familiar, it should. It's the same skill that makes a good creative brief.
Prompting is briefing
Here's the thing nobody tells you about working with AI coding tools: the skill that matters most isn't technical. It is communicative. You need to be able to describe what you want with precision. You need to articulate the outcome, the feel, the constraints, the audience, the tone. You need to paint a picture of the finished thing clearly enough that someone - or something - else can build it.
That's a creative brief. That's literally what a creative brief is. And if you've spent any time in advertising, you've been training for this your entire career.
Think about what a good brief does. It defines the objective without prescribing the solution. It describes the audience with enough specificity to be useful but enough space to be creative. It sets constraints that focus the work rather than limiting it. It communicates a feeling, a tone, a direction. It says "this is what success looks like" without saying "this is exactly how to get there."
That's exactly how I work with Claude Code. I don't write code. I describe what I want the product to do, how it should look, how it should feel, who it is for. I give it context, constraints, references. I tell it what I like about a particular design and what I don't. I iterate, refine, push back, redirect. It's a conversation, not a command. And the quality of the output is directly proportional to the quality of the input - which is exactly how briefs work too.
Strategists, creative directors, copywriters, producers - anyone who has spent years learning to communicate ideas clearly to people who will execute them - these people are already trained for this. They just don't know it yet.
What actually matters
When I look at the skills that have made the biggest difference in building my products, none of them are technical. Not one. Here's what actually matters:
Knowing what to build. This is taste. It's the ability to look at a space and see what is missing. To feel a frustration and recognise it as an opportunity. To have an instinct for what should exist that doesn't yet. No coding tutorial teaches this. No bootcamp covers it. It comes from paying attention to the world for a long time.
Knowing who it is for. This is audience intuition. It's understanding, at a gut level, what a specific person needs and how they want to receive it. Fifteen years of writing strategies for brands taught me this. Every product I build has a person in mind - not a persona, not a demographic segment, but a real human with real needs. That clarity shapes every decision.
Knowing when it is done. This is editorial judgment. It's the ability to look at something and know whether it needs more work or whether adding more will make it worse. Knowing when to stop is underrated. Most products would be better if someone had the confidence to ship them one iteration earlier.
Knowing when something feels off. This is craft instinct. It's the itch you get when the spacing is wrong, when the colour palette clashes, when the copy tone shifts between sections. You can't always explain why something feels off, but you can feel it. And that feeling is worth more than any technical debugging skill, because it catches the problems that users feel but can't articulate.
The debugging mindset
When something breaks - and things break constantly - you don't need to read code to fix it. You need to describe the problem clearly. "The navigation disappears when I scroll past the hero section." "The cards are stacking vertically on mobile but they should be in a grid." "The hover state on the share button is turning blue but it should match the accent colour."
These aren't coding skills. These are observation skills. You're looking at something, noticing what's wrong, and describing it with enough precision that the AI can find and fix the issue. If you've ever given feedback on a design - "the headline feels too heavy" or "there's too much space between these sections" - you already know how to debug.
The secret is specificity. "It doesn't look right" isn't useful. "The font size of the subheading is too close to the body text, which makes the hierarchy unclear" is extremely useful. The more precisely you can describe what you see and what you expected to see, the faster problems get solved. Again, this is a communication skill, not a technical one.
Design decisions, not code decisions
Most of my time building products isn't spent on functionality. The functionality is usually the easy part - tell the AI what the thing should do and it builds it. The hard part, the part where I spend hours, is design.
What typeface communicates the right tone? How much padding does this card need to feel spacious without feeling empty? Should this animation be 200 milliseconds or 300? Is this shade of purple too saturated for a background element? Does the mobile layout need a completely different structure or can the desktop version adapt?
These are creative decisions. They're the same decisions a designer or art director makes every day. The difference is that instead of opening Figma and implementing them directly, I describe them to Claude Code and iterate until they feel right. The process is different. The judgment is identical.
When I built First Out - the tube exit guide - I spent more time choosing the right shade of each Underground line colour than I did on the actual positioning logic. When I built Modern Retro, I spent hours refining the gallery layout, the card hover animations, the typography hierarchy. When I built CultureTerminal, the design system took longer than the content pipeline. That isn't a bug in my process. That is the point. The design IS the product. The code is just the means of delivery.
Start now
If you're reading this and thinking "I could do that" - you probably can. Here's how to start.
Pick a real problem. Not a hypothetical one. Not something you think other people might want. Something that genuinely frustrates you. Something where you've thought "why does this not exist?" or "why is every option for this so bad?" That frustration is your brief.
Start small. Your first project shouldn't be a social network. It should be a single page that does one thing well. A guide. A directory. A tool that solves one specific problem. Scope it tight. You can always expand later.
Describe it clearly. Before you open any tool, write down what you want. Not a spec document - just a clear description. Who's it for? What does it do? How should it feel? What's the one thing that makes it better than existing alternatives? This is your brief. Make it good.
Iterate relentlessly. The first version won't be right. The fifth version might be close. The tenth version will start to feel like something. This is normal. Building is iterating. Every round of feedback makes it better. Every "that isn't quite right, can you make the heading larger and the background warmer" gets you closer to what you see in your head.
Ship it. Put it live. Show it to people. It doesn't need to be perfect. It needs to be real. A live product that's 80% right teaches you more than a perfect mockup that never ships. The feedback from real people using a real thing is worth a hundred rounds of internal review.
Don't try to learn code. Don't enrol in a bootcamp. Don't spend three months on tutorials before building anything. The tools exist now - today - to turn your ideas into products using nothing more than clear thinking and the ability to articulate what you want. The skills you already have - taste, judgment, clarity, audience understanding - are the skills that matter. They were always the skills that mattered. The only thing that has changed is that now, for the first time, those skills are sufficient. You don't need a technical co-founder. You don't need a development budget. You don't need permission from anyone.
Stop waiting. Start building. The results will surprise you. They certainly surprised me.
