Building on our exploration of the different types of teams (read more here), this installment dives deeper into what makes a product team  truly empowered. 

So imagine building an empowered team is like baking a delicious cake. Just as a cake requires the right ingredients, careful preparation, and a bit of creativity, so does an empowered team.

In this section, I will reveal some of the key ingredients for building empowered teams, as outlined by the Silicon Valley Product Group (SVPG). The reality is, there is no single way to create product. However, there are tried and tested principles that can help you transform toward a more product-led operating model with empowered teams at the very core. By the end of this part of the blog series, you should be able to answer the following crucial question: How can we effectively transition from delivery/feature teams (often seen as mercenaries) to empowered product teams (true missionaries)?

1. Strategic context
   1. Company Mission / Objectives / Scorecard
   2. Product Vision & Principles
   3. Team Topology
2. Objectives & Key Results
3. Discovery & Delivery
   1. Discovery
   2. Delivery
4. Closing Remarks

Strategic context

A key ingredient as per the SVPG is strategic context and this includes several layers, but we’ll start off by looking at the company mission/objectives/scorecard.

Company Mission / Objectives / Scorecard

Scaled Agile Inc. refers to these as strategic themes. Enterprise executives and portfolio stakeholders collaborate to analyze various inputs and establish a set of strategic themes. These themes are specific, differentiated business goals that convey strategic intent from the enterprise (higher-level) to the portfolio (lower-level).

If you’re wondering what a portfolio is, it’s described as ‘a collection of value streams that continuously deliver valuable solutions to customers.’ In any organization, you will typically find two types of value streams:

• Operational value streams: The sequence of activities needed to deliver a product or service to a customer, e.g., manufacturing a product (a manufacturing company) or providing a loan (a financial institution).
• Development value streams: The sequence of activities needed to convert a business hypothesis into a technology-enabled solution that delivers customer value, e.g., developing and deploying a CRM system or building an eCommerce website (an online retailer).

More information can be found here.

In my current organization, we have adopted the Simplify@Scale way of working (see below), with tribes consisting of areas (with specific portfolios) and areas consisting of various squads (agile teams). The tribe leadership team went through several iterations to define the tribe themes and goals that we have today. Once finalized, they shared them with the various areas and squads. This iterative process answered a fundamental question: What will have our focus in the upcoming 1-3 years?

Here are some examples of strategic themes from well-known companies:

• Tesla: Playing the long game by focusing on sustainable energy and innovation.
• Airbnb: Prioritizing unique, scalable experiences over traditional hospitality models.
• Toyota: Emphasizing humility and continuous improvement (Kaizen) in their business strategy.
• Apple: Launching products with tremendous restraint and focusing on user experience.
• PayPal: Challenging the status quo in the financial industry with innovative payment solutions.
• Spotify: Changing the rules of the music industry by offering a streaming service that prioritizes user accessibility and experience.

Product Vision & Principles

More often than not, these strategic themes serve as input for creating the product vision, which is the second vital layer of strategic context.

Simply put, the product vision answers the fundamental question of why you are creating a product and what you hope to accomplish with it in the future (next 3-5 years).

When finalized, the product vision should be able to answer several key questions e.g.:

• Is it clear how the lives of users and/or customers will be improved?
• Does it provide a clear direction for where the product is headed and what it aims to solve? A product vision should be the driving force behind the product roadmap.
• In a nutshell, it should clearly describe the future you are trying to create.

The vision should always be kept at the forefront during development. This means that every aspect of product development should be aligned with achieving this vision. For example, the product vision statement of Tesla (refer to image below) presents a clear picture of the future world they are trying to create.

It is also worth noting that the product vision can continuously evolve based on customer feedback and learnings gained over time. It is very much a living artifact that can be subject to changes, but ideally, it should be ambitious enough that you shouldn’t have to change it that often. Annual updates seem to work for most enterprises.

On a practical note, we utilized a product vision board template (readily available online) to prepare our vision. It includes the following sections and addresses several key questions:

• Vision
  • What is your purpose for creating the product?
  • Which positive change should it bring about?
• Target Group
  • Who are the target customers and users?
• Needs
  • What problems does the product solve?
  • Which benefit does it provide?
• Product
  • What is the product about and what makes it stand out?
• Business Goals
  • How is the product going to benefit the company?
  • What are the business goals?

Team Topology

Team topology is the third and final layer of strategic context and it’s all about how we should organize ourselves to optimize product delivery and performance. It involves defining team responsibilities, workflows, and communication channels to ensure efficient collaboration and minimize dependencies.

Although there are different types of team topologies, platform teams would best describe the teams within our tribe (Global Data & Analytics Platform) and area (Data Platform). These teams provide services and capabilities that other teams can leverage, focusing on creating reusable components and infrastructure. I’ve done my best to create an anonymized version of our organization chart below to give an idea of how this topology might look in practice:

To learn more about the intriguing topic of team topology and proven patterns for promoting flow and delivering value faster, I highly recommend the book “Team Topologies” by Matthew Skelton and Manuel Pais. Although I haven’t read it myself yet, it’s high on my list and has been recommended by several colleagues in the past.

With the right strategic context, your team will understand the “why” (i.e. the importance of the work they are doing) and be able to make informed decisions about the product and its future, as that future state will now be clear to all (thanks to the product vision). More often than not, this context (coupled with a good strategy) helps determine which problems to focus on. Once you have more clarity on the problems worth focusing on, the next question is likely how to solve them.

Any empowered product team should be able to answer this, provided that they have: 1) clear objectives they are working towards, and 2) a habit of continuous discovery and delivery. In the following section, we’ll explain this in more depth.

Objectives & Key Results

Objectives and key results (OKRs) represent a collaborative framework for establishing clear goals and measurable outcomes.

A recurring theme emphasized by the SVPG is to give a team a problem to solve, rather than a feature to build. Although driven by product leaders, aligning on the problems worth solving is a team effort and these discussions typically serve as input for defining your team-level objectives. When going through this exercise together, the team should ask themselves: Now that we know the higher-level company goals and ambitions (i.e. strategic themes), how can we, as a team, contribute to these goals? The team objectives are intended to cover the critical work in support of the higher-level company objectives (i.e. strategic themes) and they should always be aligned with the vision and strategy.

Key results, on the other hand, are the measurable success criteria used to track progress toward the objective. Instead of just tracking random results, ask yourself what is truly the most meaningful to measure, not necessarily the easiest. In other words, what can we measure that will help us determine if we are moving forward or not?

Before adopting the OKR technique, we measured our success primarily by comparing the number of features completed against the quarterly plans. However, this method focused very much on outputs (what was delivered) rather than outcomes (benefits or changes).

Discovery & Delivery

Once you have defined your team-level objectives and key results (OKRs), the next step is to identify initiatives that will help demonstrate ongoing progress. These initiatives can be any ideas that move the needle toward achieving our OKRs.

The practice of Continuous Discovery & Delivery (CDD) helps to identify the right initiatives to work on. CDD is described as “a process that enables product teams to continuously learn from their customers, validate their assumptions, and deliver valuable outcomes.“

Discovery

Discovery is characterized by active learning; specifically, we aim to learn as much as possible about our customers or end users. Techniques such as customer journey mapping (refer to image below) can be leveraged to gain a deeper understanding of how the user interacts with your product (user journey experience). Collecting user feedback is a vital part of this process, with the goal being to identify “pains” that can be converted into potential “gains.” Once you have identified some potential “gains,” you should begin exploring potential solutions and this is the essence of discovery work.

Marty Cagan explains how continuous discovery can help us quickly separate good ideas from bad ones. Discovery should always precede delivery, and reserving time for discovery can help mitigate the risk of surprises down the line (while on the road to production). As part of discovery work, we want to explore four critical questions: 

1. Value: Will the user buy this (or choose to use it)?
2. Usability: Can the user figure out how to use this?
3. Feasibility: Can our engineers build this?
4. Viability: Can our stakeholders support this?

These are essentially risks that we would like to address before commencing with actual delivery-related work. In fact, a fifth (and very relevant) risk was recently added to this list: ethical risk, i.e., should we build this?

If you can effectively answer all of the above questions as part of your discovery initiative, it will almost always lead to a validated product roadmap and backlog that delivers true value. On the other hand, if you fail to prioritize this exercise, you risk creating a backlog filled with work items that do not deliver any meaningful value.

Practically, discovery involves ‘running a series of very quick experiments’ prior to committing to the delivery of new features. To do these experiments quickly and inexpensively, the team should consider using prototypes. Prototypes can take on many different forms and shapes, but the purpose should always be to quickly come up with some form of evidence that proves that something is worth building (or not).

So the goal of discovery is really to accelerate the learning curve towards the decision fork of whether to pivot or persevere. And when you have finally proven a particular idea and are ready to transition from experimentation to implementation, it is time to deliver!

Delivery

The purpose of delivery is to build and deliver production-level code of high quality. Here, we want to focus on four things to truly demonstrate that the product works as expected:

• Scalability
• Reliability
• Performance
• Maintainability

Closing Remarks

I am confident that most of you have already encountered the contents of this blog in some way, shape, or form.

When reviewing the Agile Manifesto, we can clearly see that the empowered product team model supports various underlying principles, including, but not limited to, the following:

Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Marty Cagan himself once said something that truly resonated with me: “The issue with agile is not the manifesto, but the process people that took it over.” As per the Agile Manifesto, we should remind ourselves to always value:

• Individuals and interactions over processes and tools.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

I hope this post gave you some valuable insights! If you found it helpful or have any thoughts to share, please leave a comment below and let me know. Your feedback helps me create better content for you. Don’t forget to hit that like button if you enjoyed reading! 🚀