Stream Teams Don't Need to Communicate their Research

At first glance, Stream Teams might look similar to traditional project teams. Both include the full range of skills needed to deliver value to customers - analysts, designers, developers, and more. However, the way these teams operate is fundamentally different.

Traditional project management uses stage gates, where work is handed over from one function to another within a team (for example, from research to design, or from design to development) with detailed documentation required at each handover point. Stream Teams eliminate these internal handoffs. Instead of working in sequence, team members collaborate continuously throughout the product development process.

This closer collaboration enables faster decision-making and delivery. Team members work together on small product increments, which leads to more fluid traditional role boundaries. Designers don't just design - they participate in research sessions. Developers don't just code - they help identify opportunities. Researchers don't just conduct interviews - they contribute to solution discussions. When everyone is actively involved in research, synthesis, and decision-making, there's no need for formal research reports or handover documentation. A quick context refresh at the start of prioritisation sessions is usually sufficient.

While Stream Teams may not need internal research communication, their insights can still be valuable to other teams across the organisation. Let's explore how these other teams can access and utilise research insights through a "pull" rather than "push" approach.

Product Teams

Product Teams are accountable for business outcomes, but they empower Stream Teams to make day-to-day product decisions. This empowerment works because Stream Teams have direct customer contact and can quickly iterate on solutions. However, this delegation of authority requires significant trust.

To maintain this trust, Stream Teams must provide transparency into their research findings and opportunity prioritisation process. This doesn't mean formal presentations or detailed reports - rather, it means making their work visible and accessible to Product Teams through research repositories and clear decision records.

This transparency can be achieved in two primary ways:

• Direct Participation: Product Managers should attend customer interviews and prioritisation sessions to stay directly connected to insights and ongoing priorities.

• Research Repositories and Opportunity Trees: By making all research available through an internally accessible research repository, Stream Teams enable anyone on the Product Team to dive deep into the details without requiring additional communication efforts.

Other Stream Teams

Customer conversations rarely stay neatly within product boundaries. A Stream Team focused on checkout might uncover valuable insights about the search experience. However, expecting Stream Teams to keep track of every other team’s priorities and coordinate accordingly is inefficient and impractical.

Instead, the Product Manager should take on this responsibility. They have the higher level view of what each Stream Team is working on and they should be getting involved in as many customer interviews as possible. This means that they are well-suited to ensure that valuable information reaches the right people when necessary.

Additionally, Enabling Teams can facilitate higher-level knowledge sharing through a Community of Practice, where research findings are informally shared across teams. This informal structure, coupled with open access to research repositories, enables anyone in the organisation to review relevant research if needed, fostering a transparent and connected environment.

Internal Product Teams

Internal teams, such as technical platform or design system teams, face a unique challenge: they serve Stream Teams directly while indirectly impacting end users. This creates a B2B2C dynamic, where they need to understand both the needs of Stream Teams (their direct customers) and end users (their indirect customers).

However, these internal teams shouldn't rely on Stream Teams to communicate end-user needs to them. Just as Stream Teams conduct research with their customers, internal teams should treat Stream Teams as their customers and conduct their own research. This means regularly interviewing Stream Teams, observing how they work, and understanding their challenges.

By taking responsibility for their own research, internal teams achieve two things: they gather more accurate insights into Stream Team needs, and they remove the burden of research communication from Stream Teams.

Conclusion

Stream Teams shouldn't be expected to actively broadcast their research findings across the organisation. Their responsibility should end at making their work accessible and transparent through well-organised documentation of research and decisions. It's the difference between maintaining a library and running a publishing house - one preserves and organises knowledge, while the other actively produces and distributes content.

Research insights should instead flow through natural organisational channels. Product Managers, with their broad view across teams, can identify and share relevant insights where needed. Communities of Practice provide spaces for organic knowledge sharing. This shift from “pushing” information out to making it available for other teams to “pull” creates a more sustainable and scalable approach to sharing research across the organisation.