Article
September 23, 2026
4 min read
What Would It Take to Build Together?
A small team can explore a product idea in working code when its members have shared time and room to change existing commitments.
By Cristiano Pierry
Imagine giving a small team one product question and enough time to explore it together in working code. The group includes a designer, a client engineer, a product manager, and someone who understands the system behind the experience. They have access to an AI coding tool and a part of the product where they can experiment.
Separate plans and handoffs can be a reasonable response to competing demands. A designer may support several teams. An engineer may be responsible for keeping an existing service reliable. Making room for an uncertain idea means changing commitments that other people depend on. A proposal to build together has to account for that work.
An organization can give every function an AI tool and still send the work through exactly the same handoffs. When could the people involved work through the question together, inside the product?
Consider a hypothetical online store exploring a different search experience. A shopper who knows what they want can type a query and see results immediately. Someone who needs help choosing can move into a conversation. The team wants to find out whether that option makes shopping easier.
Take a shopper looking for a backpack that fits under an airline seat. They have a list of results and then ask for something that can also hold a laptop. Should the conversation sit beside the results? Should it update the existing list? What happens if the shopper goes back and changes the original query?
The interface has to reflect what the search system remembers about the request. Trying the transition in the application could reveal where a shopper loses track of which requirements still apply. It might also show that refining the results directly is easier than having a conversation. The team would need to try the interaction and eventually watch people use it.
An AI coding tool could help build alternatives the group could inspect and try in the same session. The designer could stay involved as the behavior changed, and the engineer could help shape the interaction while it was still open. The group would have a chance to revise an assumption before it became the basis for someone else's work.
For this search experiment, I would start with three to five people, with the relevant specialties represented. They would need shared working time as well as time apart to investigate or concentrate. The point of gathering them would be to stay with a product decision through several attempts at making it work.
The group could use a sketch to choose an approach, then continue designing in the running interface. A short record of why they rejected an option could help someone joining the next session understand the decision. I would judge those artifacts by whether they helped the work move forward or preserved something the team needed to remember.
There is a risk of adding this arrangement on top of everything people already do. If each participant still has a full schedule of separate deliverables, shared working time will compete with commitments that are already understood and visible. Returning to those commitments is a reasonable choice. A builder-team experiment needs someone to decide which other work can wait. That is a prioritization decision with consequences outside the group.
The team would also need an agreed scope for its changes and a route to customer research. In the shopping example, that might mean working on the transition between results and conversation while leaving the rest of the purchase flow alone. Engineering review would remain part of the work. A working version could then go into usability testing, followed by an A/B test if the idea showed enough promise. The outcome might be a decision to keep the simpler search experience.
I would want to understand how the collaboration affected the work, too. Did trying the interaction together resolve a disagreement that would otherwise have moved between teams? Where did the group still need expertise it did not have? Those questions would help determine whether to try the arrangement again.
This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.