What is an AI
Product Engineer?

Product x Engineering x AI

AI Product Engineer (noun): Someone who ships delightful, correct solutions to real problems fast.

The crude distinction has always been: Product decides the what, Engineering decides the how.

Traditionally, companies have separated the functions. Product people talk to customers, actively use the product, and tell the engineers what to build. The engineers build systems that are scalable and correct.

Some companies — famously Posthog — hire Product Engineers: people who can do both. This leads to big efficiency gains as you remove the communication overhead, and often a lot of conflict and personality clashes at the same time.

This hasn't changed. People who understand both what would be valuable to a customer and how to create it are valuable but hard to find.

AI lets Product people and Engineers go faster:

• Product people with AI can build demos fast, but they have bugs and don't scale
• Engineers with AI can build correct systems fast, but they don't solve customer problems or create Shareholder Value™

But Product people without engineering skills are still limited. The "80% done" demo falls apart and needs to be rebuilt from scratch.

And Engineers without product skills are building better software forges to let AI build AI-building tools faster and faster, but others don't value or understand the solutions and they have rough edges.

Combine all three and you get someone who can produce customer value fast and correctly.

Build your own AI Product Engineer

What to look for in an AI Product Engineer (or how to become one)

Some of the best AI Product Engineers I know are, or were, 'indiehackers'. They don't always have management skills, or sometimes they just prefer to work alone. But because they can build things that people value, they often find far higher returns by selling their own products rather than becoming employees to help someone else.

These people are hard to categorise because they tend to be the mavericks and misfits of the world, coming from varied backgrounds and skill-sets. But there are some things they tend to have in common.

Great at communication

Usually they've written millions of words in blog posts, explaining what they're learning and what they're selling to anyone who will listen.

Disciplined

They've honed their craft for hours every day for years or decades. There are many wannabes who look similar on the surface but never stick with any project for more than a few weeks or months at a time, and often only work on it sporadically. They iterate and refine on what they build, not just building it once and then losing interest.

They actually ship

Discipline is about doing the reps, but putting real things in public for others to use is a different muscle. Product Engineers haven't just built the side projects, they've published them and gotten some traction from real users.

They care

It bothers them if something they built is broken or has an issue. They've carefully used and refined the UX of their own products so they make sense to others too. If you email them with a sensible suggestion for improvement or to point out an issue, you'll often see a fix published within hours or days.

Systems thinking

Product Engineers can see how a new tool fits into a broader ecosystem, what problems it solves for individual products but also what means, where it moves constraints and bottlenecks, and what downstream effects it will have.

Open-minded

They're always happy to listen for a few minutes longer than average if you say something they disagree with. They love experimenting with new tools, technology, and ideas. They don't jump to the most obvious solution, rather considering different options before settling on a path forwards.

Generalists

They know a bit of marketing, sales, product, engineering, customer support. Not married to a specific tech stack.

Enjoy helping others

They actually like it when customers come to them with problems — unlike the stereotypical hardcore engineer who hates being distracted from building.

Building Product skills from Engineering ones

You can become a better AI Product Engineer by trying out new tools and seeing how they can help you. You can have — or at least pretend to have — more respect for non-engineers and ask them about their problems without assuming you can instantly solve them. Be less defensive if someone tells you something you built doesn't work or doesn't work well. Learn more about what makes good UX and how to delight users. Learn more about metrics and how to present them.

Understand the customer

You need to deeply grok what a customer actually needs. This might be different from what they say they need. What are they actually trying to achieve and why can't they do it with existing offerings? What do they value? What are they willing to pay for? What makes them delighted?

Understand what's possible

You need to understand what's feasible. If you think you can promise the earth with no tradeoffs and then throw it over the fence to an engineering team to figure out how to build, you're in sales, not product. That doesn't mean knowing every detail of how something will be built, but understanding what's technically challenging and what isn't — and what's impossible — is important for product too.

Understand different languages

You have to be able to speak a bit of engineering, a bit of sales, a bit of marketing, a bit of exec, a lot of whatever language your customer talks. These often sound the same but are actually quite different, so you can cause confusion and have things 'lost in translation' if you don't know the terminology of each profile.

Be good at UX

Usually this means actually play-acting as the user: clicking through interfaces, reading documentation, understanding and eliminating every friction point, creating delight.

Understand the business

You have budgets in terms of people, time, money. Don't spend $100 to create $5.

Building Engineering skills from Product ones

You can become a better AI Product Engineer by understanding fundamentals. Learn how to use a terminal. Ask Claude Code to help you bootstrap it. Learn about constraints like memory. Learn about data models. Learn some basic SQL. Learn some basic networking. Learn how to debug — how to form a hypothesis about what's wrong and test it.

Efficiency

In civil engineering, it's not difficult to build a bridge that stays up. It's difficult to build a bridge that only just stays up — without wasting resources. In software engineering this is not as widely understood. You shouldn't be firing up $1000/month K8s clusters to serve 1000 users.

Effectiveness

The opposite of efficiency in some ways. You should know when to waste one resource in order to preserve a more valuable one — waste money to save time, or waste time to save money. You get things done without getting bogged down in details, hyperfocusing on one metric above all others, or letting the fact that you don't have all the information about a goal stop you from moving towards it.

Data modelling

Getting the schema right is foundational and expensive to undo. Before writing a line of code, an engineer should be able to sketch the entities, their relationships, and where the boundaries are. Correcting a broken data model six months into a product is a rewrite, not a refactor.

Knowing when to abstract

Over-engineering is as dangerous as under-engineering. The skill is recognising the seam where a good abstraction will pay for itself many times over — and ignoring the temptation to create one everywhere else. Three instances of similar code is usually fine. A premature abstraction that doesn't quite fit is a tax on every future change.

Observability

Systems fail in ways you didn't anticipate. The engineers who recover fast are the ones who instrumented their systems before things broke, not after. Logs, traces, and metrics aren't overhead — they're how you know what's actually happening versus what you think is happening.

Understanding tradeoffs

There is no free lunch. Consistency vs. availability. Speed vs. correctness. Flexibility vs. simplicity. A good engineer doesn't pretend these tensions don't exist — they make them explicit, decide consciously, and document why.

Building AI Skills

Whether you're more Product or more Engineering, you can always up your AI game. It's new. Nobody knows how to hold it yet, and it's changing every day. Choose your own adventure but this is what I'd recommend.

Try Claude Code in yolo mode

You're right to be concerned but you don't know the true power of AI until you've let Claude Code rip with --dangerously-skip-permissions. With good prompting it's safer than you think, and as long as it doesn't have access to anything critically production, it's worth finding a few footguns the hard way in order to learn how to use it effectively.

Try things you don't think it can do

Regularly ask the AI to do something that you think it has a 90% chance of failing at or doing badly. You might be surprised.

Ask it how it did things

Once it's done something well, it's tempting to move on. But especially in cases where it surprised you, ask it how it managed.

Read a lot of output

Agents produce a lot of output and it's very tempting to just skip over it. But reading it can help understand how it works — what kind of searches is it doing, how is it exploring your file system or codebase.

Write longer prompts

Often you give an agent a 5 word prompt and it somehow knows exactly what you meant. The next time it doesn't, and you assume they're limiting the resources over at Anthropic or giving you a dumber model to save costs. In reality, it'll do what it thinks you want and sometimes it gets that wrong if you weren't clear enough. Try writing a 1000 word prompt. Try writing a prompt into a file. It feels like 'writing' is a waste of time and you're tempted to just ask the agent to write its own prompts, but if there's information only in your head that the agent needs, then typing it out — or dictating if you're a slow typer — is still the most efficient way to get that information to the agent.