The Product Engineering Team

Slides of the talk: The Product Engineering Team – Codemotion Milano 2026 (PDF)

This article is based on the talk I gave at Codemotion Milano 2026. The subtitle sums it up: own the problem, collab on specs, let agents code. It’s not only about us as engineers, but about our teams.

In the last two years I have been trying to bring a new way of working into our engineering teams at TeamSystem, and I led the initiative that brought AI tools into our software development lifecycle right from the start. Today I work on both product and engineering, and of course on AI in particular. What follows is what we have learned so far.

The code changed. The process didn’t.

A year ago, we would have been asking how AI changes the role of the software engineer. Today, many of us already see it changed. It’s not a finish line: we are right in the middle of this transformation.

But has the way your team works changed? Think about your sprint, your SDLC. How many teams still work with Scrum or Kanban more or less like before, just with new tools?

The Faros AI AI Productivity Paradox Report 2025, based on more than 10,000 developers and 1,255 teams, shows it clearly: +98% pull requests, +91% review time, and the same delivered value.

For more than a year now, we have realized that making coding faster doesn’t necessarily mean delivering more value to the customer. Very often, the effort simply moved somewhere else.

The point is: coding was never the real bottleneck. In every team working on complex projects, development is only a fraction of the time. The rest goes into communication, coordination, analysis and review. We are living in a time of huge hype around optimizing one single task, a task that is only one part of an engineer’s job, which in turn is only one part of building a product.

Direction beats speed

There is another principle that I always find very underrated: direction beats speed. Going fast, writing tons of code, but in the wrong direction just means moving away faster from what customers need.

And yet most teams are built with a mix that leans heavily towards execution. In many teams we have one product manager and five or ten developers. Isn’t that, by design, a bottleneck and a single point of failure for every team?

Code is no longer, or at least soon won’t be, the bottleneck in building products. So, if code is no longer the bottleneck, for a new way of building products we must redesign the software engineering team, so that it can work in a balanced way on the other steps of the process too.

Cutting development effort means getting back precious time. But what makes the difference is how we decide to use it. What are you investing that time in right now?

01 · Own the problem

A problem in many teams I have worked with is that engineers didn’t really know the problem they were solving. They knew the task, but not the problem. In that situation, keeping direction and alignment is incredibly hard. Every small detail needs communication. Iterations go up, and quality goes down.

The engineer of the future can’t be that engineer. My thesis is that the engineer of the future will be a product engineer: an engineer who owns the problem.

There is a really nice definition from the folks at PostHog, which I summarized like this. A product engineer is a software engineer who:

1. is customer obsessed: their thinking always starts from the customer. They ask themselves what the thing they are building is for, and what value it has for the customer;
2. starts from the user’s problem, not the ticket: their goal is to solve problems, not to work blindly on a ticket;
3. takes extreme ownership of ideas and ships them end to end: their definition of done is the customer’s problem solved;
4. genuinely loves building: and this is the one I like most. They don’t love a programming language, an architecture or a library. They love building, using all of these things.

Some time ago I built a small product as a side project, fully spec-driven and AI-assisted. Not the best product ever, to be clear. I did it to understand where AI for coding really is today, and I had a lot of fun. Being able to give shape to my own ideas has always given me a unique kind of satisfaction (I wrote about it in The Joy of Building).

Being a product engineer is hard, though. You need to be cross-functional, with skills that range from customer and business knowledge, to UX and design fundamentals, and of course technical depth. And today, all of this comes with a big dose of AI on top.

Do you know who often makes a great product engineer? Founders of tech products. Because, at least early in their careers, they had exactly this cross-functional experience. But it is something you can train and grow anyway.

Our team: TouchX @ TeamSystem

So, does it work? At TeamSystem we are experimenting with it, because it’s the only way to really understand things.

We are trying it in a team called TouchX, which builds the customer journey for TeamSystem customers, so, simply put, onboarding and offboarding. It is made of a product & engineering manager with a deep tech background and a few product engineers. Supporting them, there are two specialists: a software architect and a design researcher. A small team, but a kick-ass one, with a very strong sense of ownership of the problems.

How do we work in practice?

First of all, we start from a prototype. It is our tool to understand the requirements and design the solution, and also to align the stakeholders. It may sound obvious, but using prototypes in the first phase of analysis is a powerful change. Prototypes let you have the discussions earlier, cut down iterations, validate ideas and be more confident about the direction. Always the direction.

Then, once we are aligned on the prototype, the first activity is building a solid context.

Nothing over-engineered:

1. A team LLM wiki: meetings, decisions and documents go in as sources, and an agent keeps the knowledge base current. We have an automation that feeds the project wiki from our discussions on Teams.
2. A solid harness: agent instructions, shared skills, MCP tools, hooks, subagents and automated checks.
3. Spec-driven development: specs, plans and tasks written first and versioned with the code, as one source of truth for people and agents.

All of this lets us build context, both short-lived and long-lasting, that improves the work of the agents as much as the work of the team members. A catch-up on the project status? Onboarding a new developer? These are all things an agent pointed at the project context can easily help with.

We have all understood that AI needs good-quality context to work well. Garbage in, garbage out. So the team’s first deliverable has to be exactly that: the context.

02 · Collab on specs

A fair question at this point is: if an engineer is responsible end to end and does a bit of everything, what’s the team for? Is it just a group of product engineers working as isolated individuals?

Many of us have seen how AI tends to isolate us more and more, in a conversation with it instead of with the team.

Our idea is that the team remains a hugely valuable concept: it is the guarantee for a product that lasts.

The product manager becomes the guardian of the direction, a compass for the team. But they can delegate the detailed decisions, and that makes the whole development pipeline much more parallel. That is the key to really increasing velocity.

Specs are the new code

We are all seeing how specs are becoming the new code, and we will find simpler and simpler, but still rigorous, ways to define them.

Nothing new, someone might say: a developer always needed a spec to build a feature. And yet we all know it wasn’t always like that. I think the explosion of specs is one of the good things AI brought us. If they were also correct, even better.

At the team level, what we need to do is start collaborating on the spec, and not only during review. A shift left of collaboration: the whole team, together with the agents, works on the spec; the code is generated from the spec; and the review, where we used to collaborate, becomes the last step rather than the first moment of real discussion.

The spec is generated from a conversation between the team

What many teams lose today, because of missing tools or missing discipline, is the knowledge that comes from the discussions and the analysis happening inside the team and with the stakeholders. That knowledge is the requirements and the spec of a feature.

If we shorten the path from idea to development as much as possible, a conversation inside the team, with AI as a team member, can itself become a spec. Maybe with the AI asking questions proactively. It is no longer a one-to-one chat. It is a team conversation.

There are already tools that let you do this, and you don’t need to build anything in-house (even if building something handmade is fun). One example is Claude Tag, a Claude feature integrated into Slack. It lets you interact with Claude inside conversations: ask it to investigate a bug, start a development, and so on, with long-term memory and the ability to bring the conversation into the context. You can do the same with some of the more advanced coding assistants, like Devin by Cognition. During a recent trip to San Francisco, I saw how some teams use exactly this workflow to go from discussion to PR.

Another technique we are finding super useful in the TouchX team is the automation that fills the project wiki. A simple scheduled routine in Claude Code picks up the discussions in a Teams channel and updates the wiki, which becomes the source of truth for the team and for the agents. If you are good at balancing size and relevance, it becomes a really powerful tool. You can then build more layers on top of it, especially in complex organizations. But start simple, as always.

Know which session every line came from

An important aspect, and in some cases still underrated, is the link between the code and the spec. A diff shows what changed. The spec shows why. When we do reviews, we will need to look more and more at the intent, not only at the code.

How many times is the problem with a PR not really the technical implementation, but the fact that it doesn’t fully cover the requirement, or gets it wrong? In those cases, a link to the context helps us understand where the implementation comes from and what was missing in the spec the developer used, and it gives the next agent the context, not just the code, for the following iteration. Essential.

There are tools for this already today. One is Git AI, which tracks AI code all the way to production and, not by chance, is now part of OpenAI. Entire is a Git forge built entirely around agents. And Cursor has created its own open spec for AI code attribution, Agent Trace.

03 · Design for cognitive load

As our delivery capacity grows, the problem that shows up quickly is our ability to manage cognitive load.

End-to-end ownership, being cross-functional, knowing both the domain and the tech, and a high delivery speed: all of this means more load for the engineer. How do we handle it? The risk is ending up mediocre and sloppy at everything. Or even worse, running out of bandwidth and ending up in so-called information overload.

If you think about it, it is a problem similar to the one we already see with agents. Same problem: a limited context window. Agents have a limited context window, and as the context grows, they get worse at alignment and accuracy. Teams have a limited cognitive load. Product engineers and agents both need focus.

We find the answer in the evolution of one of the best-known theories about tech organizations. In their keynote at QCon London 2026, Matthew Skelton and Manuel Pais described Team Topologies as the “infrastructure for agency”: the boundaries that give human teams autonomy are the same ones that keep AI agents governable. In other words, we will need to design team boundaries the same way we design agent boundaries:

1. write down what each team and agent can decide alone;
2. keep scope small enough for one team and one agent’s window;
3. give every service one team that owns its context and outcomes;
4. give agents only the access their task needs.

We will need to reward clear boundaries, independence and autonomy, and reduce the size of the domain and of the team.

Split by domain, not by technology

The best way to do this is to favour a split by domain, not by technology. No frontend team that has to know the whole application domain, with one feature crossing three teams and many handoffs. Instead, teams that own a part of the problem, end to end: they start from the problem and own the outcome.

Invoicing, accounting, taxes… all separate domains that provide their own components, which can then be composed into one single user experience. This is what we do in our composable enterprise architecture. The result: less cognitive load and full ownership.

What to try on Monday morning

To sum up, here is what you can take home and start applying right away:

1. Own the problem. Grow cross-functional people who can take on customer problems, not micro-tasks.
2. Collab on specs. Specs are the new code, and we need to contribute to them as a team, with all the tools and automations that already exist.
3. Design for cognitive load. Build your teams with cognitive load in mind, and split them by domain, not by technology.

We are experimenting with all of this right now, and we keep learning every week. If this way of working resonates with you and you would like to try it in your own team, feel free to reach out: we can try it together.