Building Effective Product Squads

I'd like to explain how the squad model fundamentally transforms product discovery and development, particularly in contrast to traditional approaches.

Think of traditional product development like a relay race—the baton (product idea) gets passed from product management to design to engineering, with each group working somewhat in isolation. This can lead to knowledge gaps and misunderstandings, especially where the features are complex, and the technology is more involved. The product manager may not have all the information or experience to define the product requirements.

The squad model, in contrast, uses the unique skills of each product team member to achieve a shared goal of making the product process more fully defined and the end product satisfying the customer's needs.

In traditional teams, a product manager might spend weeks researching and documenting requirements before bringing in designers, who then create designs before engineers ever see the concept. This sequential approach often leads to solutions that look good on paper but face technical challenges or miss important implementation details.

The squad approach transforms this by having everyone—product managers, designers, engineers, and quality assurance—involved from day one of discovery. When a new customer need is identified, the entire squad can immediately start exploring solutions together. Engineers can quickly point out technical constraints or opportunities, designers can sketch solutions in real time, and product managers can validate assumptions immediately.

This concurrent involvement creates what we call "shared context"—everyone understands not just what they're building but why they're building it and how it fits into the larger picture. It's like the difference between reading about how to cook a dish and watching a master chef prepare it—you pick up countless subtle details that would be impossible to document.

One of the squad model's most powerful aspects is its impact on learning and innovation. Because squad members work together consistently over long periods (unlike project-based teams that form and dissolve), they develop deep expertise not just in their own areas but in adjacent disciplines. A developer might start understanding user experience principles, while a designer gains insight into technical constraints. This cross-pollination of knowledge leads to better solutions and faster innovation.

However, it's essential to understand that this model requires certain conditions to thrive. The organization must also be willing to truly empower these teams, resisting the temptation to micromanage or impose excessive processes. The transition to a squad model isn't just a structural change—it's a cultural transformation. It requires trust from leadership, maturity from team members, and a willingness to learn and adapt. But when these elements come together, the results can be remarkable: faster innovation, higher-quality products, and more engaged teams.

This model particularly shines during product discovery because it enables rapid experimentation and learning. When a squad identifies an opportunity, they can quickly move from idea to prototype to validation, with all perspectives represented throughout the process. It's like having a complete workshop of tools and expertise readily available rather than having to schedule time with different specialists.

How Squads Operate in Practice

Think of a product squad as a specialized emergency room team. Just as an ER team has different specialists (doctors, nurses, technicians) working together seamlessly to treat patients, a product squad combines different expertise to solve product challenges. Here's how this works in practice:

Daily Operations

The squad starts each day with a quick synchronization, similar to a surgical team reviewing their cases for the day. They discuss what they learned yesterday and what they aim to discover today. Unlike traditional standups that focus on tasks, these discussions center on learning objectives and customer problems to solve.

During discovery, the entire squad participates in customer interviews together. When speaking with a customer about a pain point, the developer might spot a technical opportunity that the product manager hadn't considered. At the same time, the designer might immediately sketch a potential solution that takes advantage of that technical insight. This real-time collaboration leads to richer insights than if each specialist worked separately.

Decision Making

Squads make decisions through what we might call "informed consensus." When evaluating a potential solution, each squad member contributes their perspective: the engineer speaks to feasibility, the designer to usability, and the product manager to market fit. Instead of hierarchical decision-making, the team reaches decisions through a shared understanding of the problem and constraints.

Learning and Documentation

Knowledge sharing happens naturally through daily interaction, but squads also maintain what some call a "discovery journal" - a shared record of their learnings, failed experiments, and successful approaches. Having a central repository like Confluence for this daily interaction is critical as the product evolves and new challenges emerge. You have a record of what worked and what didn’t for those of the extended teams you are interacting with.

Conditions Required for Success

Now, let's examine what needs to be in place for this model to thrive.

Organizational Culture

The company must truly embrace autonomy, not just talk about it. This means leadership needs to be comfortable with squads making significant decisions without seeking approval for every move. It's like giving a chef control over their kitchen - you hire skilled people and trust them to create fantastic dishes, not micromanage their cooking process.

Team Composition

Squad members need deep expertise in their primary area and a broad understanding of adjacent areas. A developer in a squad should be not just technically proficient but also able to think about user experience and business impact.

The squad also needs emotional maturity. Members must be comfortable with ambiguity, able to handle disagreement constructively, and willing to admit when they're wrong. These soft skills are as essential as technical expertise.

Leadership Approach

Leaders need to shift from directing to enabling. Their role becomes more about removing obstacles and ensuring alignment with company strategy than about telling squads what to do. They should ask, "What do you need to succeed?" rather than "Why didn't you do it this way?"

Real World Example

Let me explain how these squads work in the real world of medical device development, using examples that bring the concepts to life.

Imagine you're building a Vendor Neutral Archive (VNA) system that needs to handle mammography images across multiple hospitals while using Azure cloud services. It's like orchestrating a complex medical procedure, where the surgical team's expertise and the hospital's infrastructure must work perfectly together.

Let's walk through a day in the life of your squad:

The morning starts with what I call a "360-degree sync." Your team gathers, but unlike traditional standups, where people list their tasks, this is more like a medical team reviewing complex cases. Your cloud infrastructure engineer might mention, "Hey, I noticed our Azure storage costs spiked in the East US region yesterday when Memorial Hospital uploaded their mammography batch." This immediately triggers valuable cross-functional discussion - the DICOM specialist explains the image sizes while the security engineer considers data residency implications.

Think about when a new feature request comes in - let's say an extensive hospital network wants real-time collaboration on breast cancer screening cases. In a traditional setup, this might bounce between departments for weeks. But in your squad, something magical happens:

While the radiologist explains their needs, your Azure specialist is already thinking, "We could use Azure Health Data Services for this." Your security engineer chimes in about HIPAA compliance requirements, and your UX designer is sketching interfaces that would work in both emergency and routine scenarios. It's like having all the experts in an operating room, each contributing their expertise in real-time.

Here's where it gets exciting - regulatory compliance. Instead of being a bottleneck at the end, your QA specialist is part of every conversation from the start. When your cloud engineer suggests a new Azure service, the QA specialist immediately considers validation requirements. They might say, "If we use this new compression algorithm, we'll need to validate it across these specific use cases to meet FDA requirements."

The cloud integration adds fascinating complexity. For instance, when discussing image retrieval speeds, it's not just about the DICOM protocol anymore. Your squad needs to consider:

- Azure's geographical distribution (because radiologists in California can't wait for images stored in Virginia)

- Cost implications of different storage tiers (because not every image needs instant access)

- Security requirements across different jurisdictions (because healthcare data privacy isn't one-size-fits-all)

Let me share a real challenge many medical device squads face: disaster recovery. In a traditional setup, you might have separate teams handling this. But in your squad, it becomes a holistic conversation. Your cloud engineer might say, "We can use Azure's geo-redundant storage," but then your medical device specialist adds crucial context about time-critical access needs for emergency cases. The entire squad collaborates to design a solution that balances technical capabilities, medical requirements, and cost constraints.

Communication becomes particularly interesting in this model. Think of it like a well-oiled emergency room team - everyone has their specialty, but they all speak enough of each other's language to collaborate effectively. Your front-end developer learns about DICOM standards, your cloud engineer understands clinical workflows, and everyone gains a basic understanding of regulatory requirements.

What makes this really work is the shared context. When a radiologist mentions a workflow challenge, everyone in the squad understands it from their unique perspective. The UX designer sees the interface implications, the cloud engineer thinks about performance optimization, and the security specialist considers compliance aspects—all in real-time.

The beauty of this approach is that it turns what could be a complex, siloed process into a fluid, collaborative effort where everyone learns from each other while building something that genuinely serves healthcare providers' needs. It's not just about building software - it's about creating a medical tool that doctors can trust and rely on. This is the beauty of delivering customer value, and Omotenashi, while it's often translated simply as "hospitality," actually captures that magical feeling of anticipatory pleasure in doing something special for others.