Meet your AI team: PM, Director, Designer & Engineers

Give one idea for an AI application to a team of five people and you'll get five different opinions on what to do with it.

The product manager asks what problem we're actually solving. The designer questions the flow. An engineer brings up a headache waiting a few sprints down the road, and the director wonders out loud whether the feature is worth having at all.

This is all a good thing.

Developing an application isn't a matter of sitting down, opening a laptop, and generating code. Once a product begins, certain problems arise at specific stages, and someone has to make decisions, think about the experience, and build around it.

This is where an AI product team comes in. Shipd's team is five specialists, and we think of them as Maya, Theo, Ren, Devin, and Sam.

MMaya, the AI Product Manager

While it sounds basic, Maya is usually the person asking the dreaded question: why are we doing this?

An AI product manager has the job of connecting what users want with what the company needs to accomplish and what the engineering team is able to build. A feature might sound cool in a meeting, but that doesn't mean it's worth two weeks of building.

Maya turns those conversations into requirements. She decides what gets prioritised and what can wait, and what the next iteration of the product should look like. She's also the person who makes sure product and engineering aren't speaking on entirely separate levels.

Think about it: engineers can build nearly anything if you give them the right requirements. The hard part is figuring out what those requirements are.

That's the job of product management in an AI product team.

TTheo, the Director

While Maya looks at things from the product side, Theo is thinking about the whole.

A director's responsibility isn't to make sure everyone looks busy. It's to make sure the work is worth doing. That might mean an impossible call between two important tasks, a decision about where the product moves next, or spotting how a technical choice made today will shape the product's health a year from now.

This matters more than it sounds. A team can be incredibly productive, but if it's moving in the wrong direction, it isn't being productive at all. Plenty of features get implemented without ever tying back to the reason the product exists.

Theo holds the big picture. He thinks across disciplines, sets the direction, and gives the team enough of it to make decisions on their own, without getting stuck in an endless cycle of asking for permission.

Good leadership shines through in quiet ways. It's most noticeable when it's missing.

RRen, the AI UX Designer

Now we meet Ren. She's the person who asks: how is anyone actually going to use this?

An AI product designer isn't just thinking about colours and buttons. In an AI application, a user might be reading a generated response, waiting while an AI takes an action, reviewing a recommendation, or correcting a mistake. Each of those moments is a design problem.

Ren develops the flows, interfaces, and interactions of a product. She takes Maya's requirements and turns them into something that makes sense to people, something that doesn't need a comprehensive side note to be understood correctly.

There's real collaboration involved. A design can look easy on a screen and turn confusing the moment it's wired to a live API. A user notices an action that didn't behave the way it looked like it would. Designs change.

AI UX design isn't about making applications look cool. It's about making complex technology feel understandable.

DDevin, the AI Backend Engineer

Most people who use an application every day have never once thought about the backend. Which is exactly as it should be.

When a user logs in, saves information, uploads a document, or asks an AI to take an action, a lot happens behind the scenes. Devin is the person who makes that possible.

As an AI backend engineer, he builds the APIs, databases, authentication, business logic, and integrations, everything that ties an application together. Clicking a button labelled Generate isn't interesting. What happens after the click is what makes an application work: the request is received, information gets saved, a model gets called, the response comes back, and errors get handled when the whole chain somehow doesn't.

That's backend development. Devin builds the part that lets an application handle being more than a demo.

SSam, the AI Frontend Engineer

Sam is the person who makes the product appear.

The design can be finished and the backend can be running, but none of it means much to a user until someone ties the two together. As an AI frontend engineer, Sam turns design files and API contracts into interfaces people can actually see and touch: the pages, components, interactions, and responsive layouts.

He also has to stay in constant conversation with Devin. A button needs to send data. A response needs to render. Loaders need to feel intentional. Errors need to be handled gracefully.

And everything changes, repeatedly. Ren adjusts a flow, Devin reshapes an endpoint, Maya reorders the priorities. Sam fine-tunes, someone tests, and another problem surfaces. That's software development. The frontend and backend aren't separate worlds; they have to work as one for an AI application to hold together.

So how does an AI team in Shipd actually work?

It's tempting to draw the process as a straight line: problem, product, design, engineering, launch. Real life doesn't play by those rules.

Maya discovers a user problem that changes what was planned. Ren sees that the proposed experience won't be intuitive. Devin finds a technical limitation, and Sam realises a particular interaction would be very hard to build.

The team goes back. Then forward again. Then back again.

Maya asks what should be built and why. Theo watches the big picture. Ren decides how the product will be experienced, Devin does the hard work of making it real, and Sam turns all of it into what a user sees and interacts with.

When these five work together, the product moves faster, not slower.

maya  · pm        the problem named, scope cut        ✓
theo  · director  direction set, worth building       ✓
ren   · designer  flows · screens · design system     ✓
devin · backend   data model · REST API · postgres    ✓
sam   · frontend  wired to /api, live in your preview ✓
─────────────────────────────────────────
while you were away, maya drafted
the next iteration →  [send the team to work]

The part people don't talk about enough

Getting your application to work for the first time feels exciting. It should. It's the completion of a process. But it's not the end of one.

Once you've launched, there are changes to make, bugs to fix, integrations to update, workflows that stop making sense, and features that once seemed essential and no longer are. That part of software development doesn't fit neatly into a product demo.

You don't just need to build an application. You have to keep working on it.

This is where the difference between generating an application and shipping something becomes obvious. A generated starting point gets things off the ground. Products are developed by people, or teams, who return to the code, understand what has been built, make changes, test them, and keep building.

Shipd is designed to work this way. Rather than treating a finished generation as the point to stop, the team keeps going: improving features, fixing problems, and moving the product closer to something people can actually use.

It's not really about the titles

Maya, Theo, Ren, Devin, and Sam each have different duties. The more interesting thing is how they collaborate.

A product decision impacts the design, which impacts the frontend, which has to work with the backend. A single user problem can send the whole team back to the drawing board. That's what a good product team looks like: five specialists working on one problem.

Making something exist is one part of the equation. Making it work is the other.

Meet the team in your office →