What does a builder team look like?

How we can reinvent the way software products get developed.

Imagine a small team exploring a new capability in a product. Its members bring depth in product, design, engineering, and algorithms. They have access to AI tools and a part of the application where they can experiment. Anyone in the group can work with the AI to make a change, try an alternative, or investigate why something behaves the way it does. As they discuss an approach, they can build enough of it to try and change it together.

The work might involve bringing an existing feature to another platform. It could also involve an idea the product has never supported. In either case, I want the people involved to be able to explore the question in working software while they are still deciding what the experience should be.

I would start with three to five people around a focused product problem, with enough shared time to make progress together. Their roles describe where they have the most depth. Everyone should be able to contribute across strategy, user experience, research, algorithms, backend data, and frontend implementation. The person who sees something worth trying should have a way to explore it without first putting it into someone else's queue.

How much faster could we learn by making the idea real?

Consider a hypothetical product that helps someone choose among a set of options. The team wants to make those choices more useful to the person making them. It needs to work through what the backend knows about each option, how the algorithm selects and orders them, and what the interface lets the person understand or change.

Suppose an option looks promising on the screen but fails a requirement the person has given us. The team needs to trace the problem. Was the relevant attribute missing from the underlying data? Did the algorithm give it too little weight, or should it have treated the requirement as a firm constraint? Did the interface make a preference look like a guarantee? Each explanation would lead to a different change.

I want backend data and algorithm iteration inside that exploration from the beginning. The group could inspect the records behind a disappointing result, test a different selection rule, and see how it changes what appears in the application. If a useful attribute is absent, the next experiment may depend on improving the data or changing what a service returns. Another version of the screen will not answer that question.

A designer could work with the AI to change the running interaction and try it immediately. A product manager could explore how a different ranking rule changes the options people see, then examine the result with someone who understands the algorithm. The experiment gives them something concrete to challenge together. They can follow the question into the part of the system where it leads, with specialist judgment available as the work develops.

That means keeping versions of the data and algorithm changes connected to the experience the group is evaluating. A change that helps one example may make another worse. The team needs cases it can revisit, a record of what changed, and a way to compare the behavior. Research can add cases the builders had not thought to test. Those findings should feed the next iteration of the data, the algorithm, and the interface.

I want to shorten the wait between having a question, trying an answer, and learning enough to change it. If every adjustment requires a new document, a handoff, and a place in another team's schedule, a faster implementation tool can only take us so far. The people who can resolve the question need time to work on it together.

People would still need time apart to investigate or concentrate. Shared context makes it possible to bring that work back into the product while the choices are open. Someone exploring a backend change should understand the user problem behind it; someone changing the frontend should be able to inspect the behavior it depends on. A brief record of a decision can help the next person continue without reconstructing the whole discussion.

Porting an existing feature gives this way of working a useful starting point: there is behavior to inspect and compare. A new capability leaves more of the question open. The team may need to discard its first approach or discover that the proposed feature is unnecessary. Working code gives us something to challenge; user research is still needed to understand whether the idea helps anyone.

As the product leader, I want to participate in that work and take responsibility for connecting it to the problem we are trying to solve. A result from research might change our priorities. An algorithm experiment might reveal that our original promise depends on data we do not yet have. I want those discoveries to inform the strategy while we still have room to change what we are building.

A team like this depends on systems and expertise that already exist. Its members need access to the people who built and maintain those systems. Three to five is a starting point for a focused piece of work, not a staffing formula for a software company. The scope has to fit the people, and the group needs a way to bring in expertise it does not have.

For this hypothetical product, I would give the team responsibility for finding out whether people could make a useful choice with less effort. That leaves room to change the proposed solution. We would agree with the relevant owners on the code and data available for experimentation and the review required before a change could reach users.

The commitment would have to include time for review, user research, and whatever we learned needed fixing. A team funded only through the demo leaves the next group to discover how much work remains. The people making the early choices should stay involved in those consequences.

Making room for that work requires a real prioritization decision. Each person brings existing commitments. I would need to work with their leaders to decide what could wait, and make sure the people reviewing the work had capacity too. Giving the group a new name does very little if everyone still has to fit the experiment around a full schedule.

The specialties still carry weight when we evaluate the work. An algorithm change needs scrutiny from someone qualified to judge its effects. Engineering needs to validate the implementation and its impact on the services it uses. The team should expect some prototype work to need substantial revision. User research and a controlled experiment could then help determine whether a promising version improves on the existing experience.

I would also want to understand where the team's own work still had to wait. Could someone test an idea with the AI and bring the result back to the group, or did every change require another handoff? Did we discover a data limitation early enough to change direction? Those answers would help us improve the arrangement before extending it to more work.

This is the kind of team I want to build and lead. I want us to develop ideas through the experience of making them work, following a question from the interface into the data or algorithm when that is where the answer lies. Everyone should be able to help move the work forward and carry what we learn into the next attempt.

---

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.