- ZeroBlockers
- Posts
- Balancing Quick Decentralised Research with Deeper Market Research
Balancing Quick Decentralised Research with Deeper Market Research
Research isn't a one-size-fits-all activity. Teams building products need to understand customer needs and address immediate pain points while also keeping an eye on larger market trends and shifts. To tackle this dual challenge, companies need to deliver on both research levels.
In our article about making research easy, we focused on quick, lightweight methods that stream teams can use to keep regularly connected to user needs. But we also recognised the need for deeper, more detailed research as well. To tackle this dual challenge, we need to define a clear separation of responsibility for each type of research.
Different team types
The ZeroBlockers framework highlights five different team types that organisations can adopt to scale empowered product teams. Here’s a quick recap of the five teams:
Product Teams. Responsible for product outcomes but do not build the product. They set the vision and strategy and design the stream team to deliver on the strategy.
Stream Teams. These are the teams that build the product. Each team owns a separate value stream or part of the product.
Internal Product Teams. These teams provide services to the Stream Teams.
Enabling Teams. These teams are responsible for streamlining how the Stream Teams operate through knowledge sharing, training, and tooling.
Ecosystem Teams. These teams provide the business goals, strategy and funding for Product, Internal Product and Enabling Teams.
The five team types of the ZeroBlockers framework
Given that Stream Teams need the insights from the deeper, more detailed market research, but they do not have the capacity to deliver on it, this is a perfect use case for an Internal Product Team. The Internal Team can provide the detailed research as a service to the Stream Teams.
Why is it called an Internal Product Team and not a Center of Excellence / Centralised Team?
The “Product Team” part of the name is intentional. Most teams providing services to Stream Teams would not consider themselves products. Think of teams like finance, legal or research. But productisation enables scalability and standardised quality.
It can be very hard for people to figure out how to turn their service offerings into products, but it is possible. Two simple examples include:
Standardised offerings. Rather than relying on very detailed briefs about what is needed, the research team could do some discovery to figure out what the Stream Teams really need and provide a set list of research activities, including turnaround times, to deliver on those needs.
Subscription model. Going one step further, the team could proactively conduct the research that they know teams need and allow them to subscribe to receive periodic updates from the latest research. Teams will get frequently updated research without the wait period from commissioning to delivery.
A side effect of this type of productisation is that research that internal teams find valuable could also be valuable to external teams as well. What was traditionally a cost center could become a profit center by selling research externally.
Why don’t Internal Product Teams do the low level research?
The Center of Excellence model has been shown to be an anti-pattern in the research by the DevOps Research and Assessment group. There are a few core challenges:
Internal Product Teams lack a feedback loop
The Stream Teams are the ones turning the research into real products and learning from customers’ real behaviour. This is a reinforcing loop where the teams develop deeper and deeper insights into customer needs and pain points.It takes time to request, wait and get a response
Stream Teams need to be able to turn ideas into working products as quickly as possible. Having a blocking dependency on another team would slow this down too much, and it would reduce the Stream Teams’ accountability for success: “I just build what the research team told me to build”.If the team is busy then the delays grow even more.
Having dedicated, highly specialised and skilled researchers will result in higher quality research. But this success will become a failure point as more teams will request research leading to longer wait times for the requesting parties. Ultimately teams will start to skip research as they need to move faster.
Conclusion
The dual layers of product research—low-level research led by Stream Teams and high-level research driven by Internal Product Teams—are vital to achieving a balanced, effective product strategy. By dividing responsibilities between these teams, organisations can ensure that they’re addressing both immediate user needs and long-term market opportunities.
Ultimately, the key to success lies in creating a symbiotic relationship between these two research layers. When Stream Teams and Internal Product Teams collaborate effectively, they not only improve the product itself but also contribute to the company’s strategic growth and adaptability.