March April untitle notes: 03/04-26 AI Team Organisation vs Problem Principles
- Iria Carreira
- Apr 29
- 3 min read
Apologies for not updating Untitled Notes in March. I decided to combine March and April.
Most of what I consumed in these two months, unsurprisingly, was about AI and how it will impact product teams. More specifically, I have been thinking about how it will impact product teams working in the built environment: architecture, engineering, construction, and operations technology.
What I find most fascinating is not only what is being said, all the theories about how tech and the world will change with AI, but what I could not stop pondering over the last two or three weeks, it's the urgency to find a new team structure, new ways of working or to try to solve it all in a matter of weeks.
Maybe this comes from my holiday vibes in Bangkok and Chiang Mai, where life feels fast and slow at the same time, maybe it's my historical background, but without perspective and context, it's difficult to foresee the future. I know there are visionaries, but not every LinkedIn post, Substack, or podcast is a visionary. It made me think about how, in tech, we are always in a rush. We try to figure things out quickly, move fast, and fail fast. If you mixed this together with the kind of society we live in, what I call the "noise society," where everyone can share opinions constantly on social media, it creates even more pressure and noise.
So in the last weeks I have been thinking about one question: why are we in such a rush to find solutions? Why this rush? and how big non-linear changes historically have affected societies and companies.
I really believe good decisions often need time, context and perspective. This is very difficult to apply in tech.
Right now, I see many people rushing to figure out a new team structure: how to organise product teams? Who can be removed to streamline delivery? Do you still need PM + UX + engineering? Whether one PM can support ten engineers, or what the "right ratio" is, is one PM and one engineer.
But in the last two months, most podcasts and articles I read focused on distribution and quantities. In reality, this is not a difficult thing to figure out in my view. No matter how you structure the team, the principle does not change: your team still needs to solve the real customer problem. And now, more than ever, you can solve more complex problems that are not obvious with new technology. And also, maybe your customer has decided they will fix their own problems.
Of course, thinking transversally, speed gives you iteration, I am not denying that, and iteration allows for solving the problems better. But too many iterations can also erode customer trust. So even if you can iterate faster, you still cannot afford to drift away from the real problem.
So, all this to say, I am surprised that there are not more people in the product development realms talking about what has changed regarding customer delivery and problem-solving with AI instead of the distribution/organisation of teams.