What no agent should answer

There is a question we always come back to at Framna: not what we can build, but what we should build and why. For us, this is at the core of every good product team. Let’s be fair: in hindsight, the different members of the product team have had their roles in the product decision process, but involvement has been capped. Designers usually worked one or two sprints ahead of what the developers will build; design had a natural position together with product management in the conversation of the direction of the product. While devs and QA have been focusing mainly on the task at hand, the development of the current sprint, the PM's role has been to organize to get everyone aligned with the product vision and strategy, to surface decisions, and to collaborate with stakeholders. The biggest shift we see with AI is now the entire team needs to have its gaze collectively on the horizon, to have a closer collaboration on the product vision, and making product decisions more as a collective.

This shift has been driven by the increased speed of development thanks to the release of very capable coding models. Teams are pushing the scope of sprints and building more, which is exactly why product decisions have to stay tighter. Suddenly, design cannot work one or two sprints ahead. The collaboration needs to happen closer, and decisions need to be made more upfront than before. This is a shift; even if the team has always been involved in product decisions, we need more alignment, a better common understanding of the product vision, and how we in the best way support the goals that we are trying to achieve.

David Marshall, Principal Designer at Framna, argues that the speed is less a new capability than a stress test: it reveals how strong a team's product practice was all along. That, more than any tool, is what separates teams with real AI fluency from teams that are simply using AI to ship more features.

One practice that has been adopted is what the teams call mob prompting. When the team has a direction of the goal where we want to go, we use AI to get them all aligned on the how and what to build. This requires the team to share an understanding of the strategy, our user insights, and the architectural trade-offs. The main benefit is that the product reasoning happens on the actual artifact while it takes shape, not on a description of it, and in this time each competency learns from each other's understanding. By doing this, we are quicker at answering the question of what we are trying to solve and how we are doing it fast, but at the same time we build the collective understanding of why we are making the choices that we are; this is the crucial bit for AI-native teams.

Making decisions faster means doubling down on research. Since the shift has moved from making decisions for a few sprints ahead into making product decisions in the current sprint, this means that we need more alignment on user needs and better user understanding. A growing trend within Framna is that we invite more of the product team to tag along; Design does not own the research phase, they support it. Oscar Sellhed, business designer at Framna who supports our partners in ways of working, frames it:

Faster building does not become better products by default. It raises the cost of aiming the speed at the wrong thing. The teams that pull ahead share one habit: they can decide together, and quickly, what is worth building at all.

Alignment doesn’t happen on its own. It is hard and deliberate work, this is the capability we are trying to build. A team that holds its strategic judgment in common, so that when the tools let us move faster, we move faster toward the right thing. AI can write the code and fill the screen. It should not tell you what you are trying to solve, or why it matters to the person on the other side. That answer still needs to come from the team. The only real change is that now the whole team has to be there when it is found.