1. Principles of Effective Product Teams

Hello everyone! I’m back to discuss another crucial topic: principles of effective product teams. Let’s dive into a summary of the key principles that are essential when considering the structure and mindset of a product team.

1. Mission-Oriented Team

A strong product team should consist of missionaries, not mercenaries. This means people who are passionate about making things happen and truly believe in the product they are working on. It’s essential that everyone in the team feels empowered and genuinely responsible for the outcomes that the product achieves.

When a team has clear business objectives or goals, they should feel empowered to meet those goals. At the same time, they must take ownership if they fail to achieve them. The ideal structure is non-hierarchical, meaning no one is a boss within the product team. For instance, the Product Manager (PM) would report to the Head of Product, the Product Designer would report to the Head of Design, and the Developers would report to the Head of Engineering. This setup avoids internal hierarchies within the team.

2. Small, Cross-Functional Teams

The ideal team size follows the “two pizza rule”—in other words, the team should be small enough that two pizzas can feed them during an all-night deployment. The team should be cross-functional, meaning they have all the skills needed within the team to handle everything from discovery to delivery.

The team should be durable, with members ideally sitting together in the same space to promote collaboration. They should possess the knowledge and autonomy to solve problems, handle large projects, optimize performance, fix bugs, and deliver features independently. In doing so, they should dominate both the vision and objectives of the product.

3. Team Composition

A typical product team usually includes a Product Manager (PM), a User Experience (UX) Designer, and a group of Developers, with one ideally serving as a Tech Lead. In cases where the functionality is exclusively backend, like an API team, the UX role might not be necessary, but in most cases, the role of UX is crucial.

4. Autonomy and Responsibility

This model works because it fosters a durable squad with autonomy and a shared voice. They know the business objectives they are tackling, which creates a collaborative environment. If a team is not durable and constantly changing, it becomes difficult for them to develop the necessary maturity around the business problem they need to solve.

Allowing the team to understand business goals ensures that their output is valuable—not just a list of features, but solutions that align with business objectives. Delivering simply for the sake of delivering is not enough; the process is only complete when it is validated and has achieved the desired business outcomes.

5. Ownership and Motivation

Empowering the product team and giving them ownership over their work significantly boosts motivation. Team members become more invested in the product’s success, leading to better outcomes and a stronger sense of ownership.

Case Study: Creditas’ Journey to Change Product Culture

At Creditas, we initially faced a painful lack of delivery speed in both product and technology teams. We weren’t delivering at the pace the business needed. After investigating the root causes, we found several major issues:

• Waterfall disguised as agile: We were following a waterfall approach where ideas flowed from top-down management, followed by creating a business case and roadmap. This roadmap required decisions on solutions too early in the process, stifling innovation and creativity among the team members.
• Late-stage risk mitigation: All risks were left until the final stages—during design and development. By the time solutions were implemented, the business had often changed, rendering the solution obsolete or irrelevant.
• Big Bang releases: We suffered from a reliance on big bang releases, which involved months of work only to discover bugs and other issues during deployment. By the time we deployed, the business had often evolved, and the solution no longer met the needs.

Misalignment and Lack of Vision

There was significant misalignment between the business and the technology teams, often leading to the two groups working towards completely different goals. This lack of vision resulted in frustration, as neither side had a clear understanding of the direction.

We also encountered a lack of empathy between technology and other departments. Technology was simply viewed as the team that “fixed things” or resolved operational issues, but the solutions weren’t making a significant impact on business objectives. We were stuck in a cycle of deploying features that provided little to no value.

Culture of Fear and Dependence

There was a strong fear of failure, leading to a reluctance to take risks. This created an unhealthy cycle of aiming to avoid mistakes at all costs, which ironically resulted in more failures. Additionally, there was a high dependency between teams, with each team reliant on others to complete features, leading to further delays and frustrations.

Finally, the product teams felt a complete lack of autonomy, which led to extremely low motivation. The technology team was essentially in a state of depression, unsure of what they were coding or why it mattered.

Conclusion

To build an effective product team, the key principles include:

• Creating a mission-oriented and cross-functional team.
• Ensuring the team is small, durable, and empowered with autonomy and responsibility.
• Aligning the team around business objectives to ensure their work drives real results.

By addressing these principles, you can build a motivated, effective product team that delivers meaningful value to the business.