The Team Got Faster With AI. 5 Changes That Help Product Decisions Keep Up
AI has accelerated developers’ work. Can your company decide just as quickly what they should build?
When requirements preparation and customer research fail to keep pace with implementation, the team starts waiting. The acceleration you gained exposes the next bottleneck. How can you change the way Product Owners, developers, and business stakeholders work together so that product decisions keep pace with the team’s delivery capacity?
1. Prepare upcoming tasks in advance
When do you define the goal of the next sprint? If you only do it at the end of the current one, there is little time left to talk to customers, resolve uncertainties, and refine requirements. Faster implementation makes these delays more noticeable.
The team developing Pragmatic Meet, Pragmatic Coders’ free event management platform, faced exactly this problem. After rewriting the application, changing its architecture, and introducing specification-driven development with AI, the four-person team was working around four to five times faster. Preparing the next tasks, however, could no longer keep up with the team’s capacity.
During one sprint retrospective, someone suggested extending the one-week iterations. The discussion revealed that the goal of the next sprint was only being defined during the previous sprint’s review or shortly before it. The team needed to start refinement earlier, while the current sprint was still in progress.
In practice: During the current sprint, review with the team the tasks that are most likely to come next. Identify what you do not yet know, who can provide the answers, and when those answers will be needed. Pay particular attention to decisions that require input from customers or other people outside the team.
2. Share responsibility for requirements with developers
The person responsible for the product needs time to understand customers and choose the direction of product development. At the same time, a faster team encounters requirement-related questions more frequently. When every question has to go through the Product Owner, these responsibilities begin competing for the same limited time.
In Pragmatic Meet, Bartek Czarnecki, who leads the team, realized that he had become a bottleneck himself. The team needed to rethink who gathered requirements and how they were processed. One part of their approach was to give developers direct access to customers. When an engineer needs information, they can ask the customer directly instead of routing the question through Bartek.
This way of working requires preparation. Developers need to understand the product goal, the business context, and the purpose of the conversation. Helping them develop these skills becomes an important part of the Product Owner’s role. As a result, more people can participate in clarifying requirements.
In practice: Agree on which questions developers can clarify directly with customers, which decisions they can make independently, and when they need the Product Owner’s involvement. At first, you can run selected customer conversations together so that the team learns how to ask questions and evaluate the answers.
3. Check for shared understanding before implementation begins
Before the team starts building a feature, it is worth checking whether the person responsible for the product and the developer have the same outcome in mind. A mockup or a user flow makes it easier to discuss specific system behavior and uncover misunderstandings early.
In Pragmatic Meet, a user story is added to Jira together with links to the knowledge base. With the help of AI, the developer prepares a specification and mockups, then presents the proposed solution during refinement. They explain in their own words what they intend to build and show how it is expected to work. The person responsible for the product can then confirm the direction or point out changes that are needed.
The role of this conversation is particularly important. AI-generated materials provide a shared point of reference. Having the developer explain the solution also helps verify whether they understand the requirements and are ready to take responsibility for the outcome. In the Pragmatic Meet team, this is one of the reasons why shared discussions have become increasingly important.
In practice: For the next feature, ask the person responsible for implementation to present the solution using a mockup or a specific usage scenario. Review together which user problem you are solving, how the feature should work, and which questions are still open. Finish the discussion with a clear agreement on what is ready for implementation.
4. Plan customer contact together with feature development
When preparing a task, decide upfront whose feedback you will need and when you will need it to make the next decision. Waiting for an answer can take longer than the implementation itself.
This became particularly visible when Pragmatic Meet moved from rewriting the existing system to developing new areas of the product. During the rewrite, developers already knew the requirements and had the working platform as a reference point. New features required a deeper understanding of user needs. The team began experiencing more difficulty gathering this information and preparing the decisions needed for further development.
In this situation, moving faster also requires more frequent conversations with customers. Mockups can help because they allow the team to present an idea early and discuss a concrete solution. The ability to prepare these materials quickly became an important part of product work on Pragmatic Meet.
In practice: For each planned feature, define what you need to learn from users before implementation and what you will validate after release. Schedule customer contact early enough to avoid blocking the team. Also consider whether some questions can be answered using a mockup instead of waiting for a working feature.
5. Make product knowledge accessible to the whole team
Greater developer autonomy requires access to the information they need to make informed decisions. It is therefore worth looking at where customer insights and product decisions are stored and who is responsible for keeping them up to date.
In Pragmatic Meet, product knowledge is collected in a knowledge graph maintained by the team. It includes information about the existing system, planned changes, and conversations with users. Initially, one person was responsible for maintaining it. As the knowledge base grew, keeping it updated became too much work for a single person, so responsibility gradually shifted to the entire team.
This complements direct conversations between developers and customers. An answer obtained during one conversation should also help other people working on the product. Otherwise, some of the knowledge remains available only to the people who took part in that particular discussion.
In practice: Agree on a single place for storing product requirements and decisions. Decide who updates it after a customer conversation and how you mark decisions that have changed. Then test it on a real task: can a developer find all the context they need without asking someone else?
What is slowing down product decisions in your team today?
Take a look together at whether upcoming tasks are prepared in advance, whether developers participate in validating proposed solutions, and whether customer conversations actually influence what you build.
You will find these questions in our Product Health Checklist. Complete it together, discuss any differences in your answers, and choose one area to improve in your next sprint.
Check the health of your product with the Product Health Checklist.
