How Common Ways of Working Trap or Untrap Teams
This chapter is from the book
This chapter is from the book
This chapter is from the book
Expectations and reality tend to diverge in the realm of digital product management. Let us imagine a few scenarios to compare expectations with reality.
Suppose you become a product manager and are excited to create products customers love and help your business thrive. With such a motivation, nothing can stop you. But suddenly, you bump into the corporate firewall. When you face prescriptive roadmaps, extensive timelines, and output commitment, you get sucked into backlog management, quickly getting demoted to a backlog manager.
This kind of disappointment isn’t exclusive to product managers. Imagine you’re a software engineer. You’re passionate about crafting clean code and building scalable solutions. You want to bring your best to the team, but then you realize that shipping features at the speed of light matters most. Pressured, you cut quality to meet deadlines. Now, you’re no longer a software engineer. Without realizing it, you’ve become a coder. Your code stinks and your solutions aren’t scalable. Despite initially delivering on time and budget, you’re surprised because nobody uses the shiny features you gave your heart and soul to create.
What would happen if you were a product designer? You’d also get a gold pass to the club of frustrated people. You aim to create intuitive designs and outstanding user experiences, but your motivation lasts only until reality hits you. Astounded, you realize that success means creating pixel-perfect prototypes that business stakeholders love and approve, even though they don’t represent your customers.
Do any of these situations ring a bell to you? If not, we may live in different worlds, because I’ve been part of them from South America to Europe, from start-ups to well-established corporations. The question is, what do you do when you face such situations?
When people lack skills, some may complain and do nothing about it. This attitude is what I call becoming the victim of the circumstances.1 In contrast, with the proper skill set, you can challenge the status quo and transform your situation by engaging in a step-by-step journey.
Simple actions can help you overcome the common traps described earlier. To equip you with the skills to make that possible, I invite you to join me in a conversation about how teams typically work, because that reality has a tremendous impact on what they can achieve.
Let’s explore the dynamics frequently present in feature factory companies.
How Feature Factory Companies Work
Not every company is the same. Every organization has its particularities and dynamics, though they all share some common traits. Understanding your company’s unique dynamics enables you to identify opportunities to simplify how its product teams work.
First, let’s look at companies’ typical structure. Companies have multiple departments—for example, management, marketing, operations, customer service, product, and so on. Sometimes, these departments are called teams or areas. What separates departments from one another are their responsibilities and way of working. Departments often work inside their bubble and coordinate tasks with other departments when necessary.
In larger companies, the complexity increases with divisions and units under different leaderships. The relationship between such divisions may be quite distant, and collaboration becomes daunting. For our analysis, we’ll stick with a small company. Figure 1.1 depicts some typical departments.
What all departments have in common are ideas, and each department often perceives its ideas as important and urgent. Some ideas relate to their work, others to the company’s core product or service.
The more unclear the company’s vision and strategy are, the harder it becomes to decide what to do with endless ideas.
)
Figure 1.1 Example of company departments
This situation is overwhelming because ideas have different objectives and, in most cases, have no connection with each other. In turn, the excess of ideas and pressure for delivery challenge product teams. Meeting expectations requires interactions with all departments, understanding their wishes, and doing something about them.
Collaboration between Product Teams and Business Stakeholders
Creating a backlog is a common way of dealing with the ideas suggested by the business stakeholders (i.e., the business members interested in your product or service). This method represents a dangerous trap for product teams. Collecting ideas and adding them mindlessly to a backlog is easy—but having a gigantic list of unrelated ideas creates unbearable expectations.
The depth of ideas varies significantly. Sometimes, they are on a milestone level, such as “Expand our product to a new audience.” At other times, ideas are related to specific wishes, such as “Allow customers to export their orders of last 90 days.” This diversity complicates prioritization. Yet, the typical approach is to put everything in the same bucket and have long discussions until everyone agrees on what comes first.
With extensive backlogs, more business stakeholders than you can handle will knock on your door, asking when you plan to deliver on their ideas. That forces you to coordinate tasks with everyone, complicating collaboration as you juggle multiple topics.
Figure 1.2 illustrates the complex dynamics between product teams, departments, and the backlog. The bigger the company, the more complex this situation becomes.
)
Figure 1.2 Product teams’ interactions with business stakeholders and the backlog
When you look at Figure 1.2, what’s wrong with it? Take a minute to reflect on it.
Products exist to serve customers, not business stakeholders. When the people creating the product don’t interact with customers, creating useless products is the potential result.
It shocks me how often companies develop solutions for their customers without interacting with them. It’s easy for us to fall in love with ideas, become blind to reality, or, even worse, forget about it. The results are often undesired.
Releasing New Features Nobody Cares About
How’s your experience releasing new features? Maybe it’s a hit or miss. Let’s continue our conversation about the sad reality of feature factory teams.
After months of hard work and exhaustive coordination, the product team got a new feature out of the backlog. Everyone from the team and business loves it. The new shiny feature is ready for customers, but something unexpected happens. Customers who interact with the new feature don’t understand its purpose and cannot benefit from it. Confused, customers reject the new shiny feature beloved by business stakeholders, and inevitably everyone becomes frustrated (Figure 1.3).
)
Figure 1.3 Building features customers don’t need
Creating solutions companies love, but customers couldn’t care less about, isn’t why product teams exist. Yet, that happens more often than it should. I call it a bug, not a feature. As with all critical bugs, it requires a hotfix.
If the feature factory is a bug, what would fix that? You cannot expect a simple fix, but fostering empowered teams with collaborative flows will transform the situation. Marty Cagan, SVPG Partner, wrote a blog post defining empowered teams2:
Great teams are comprised of ordinary people that are empowered and inspired. They are empowered to solve hard problems in ways their customers love, yet work for their business. They are inspired with ideas and techniques for quickly evaluating those ideas to discover solutions that work: they are valuable, usable, feasible and viable.
Empowered teams have significantly higher chances than feature factory teams to create value. Yet, enabling empowered teams isn’t trivial. We will discuss what it takes to get there in Chapter 10. For now, let’s focus on the collaboration challenges.
Over the years, I’ve noticed two standard product development flows spread across companies regardless of their framework:
Coordinative → Team members spend significant time coordinating activities among themselves, stakeholders, and other teams. Most of their energy goes into organizing how to get the work done. This approach aims to avoid mistakes and failures, which forces teams to be rigid with their development flow. It becomes a “strict” contract because someone gets the blame when something goes wrong. Plans become the ultimate goals because nobody knows what they are fighting for.
Collaborative → Team members focus on collaborating to use their current knowledge to uncover promising opportunities. The ultimate goal is to create value for customers and the business. The team is flexible with how they get the job done while focusing on driving value. Trust is the basis for the collaborative approach. When something derails, the team takes responsibility and jointly finds a solution. Teams start with simplified plans, progress toward the unknown, and adapt the following steps based on the evidence. An overarching goal guides their decisions, ultimately creating value for everyone involved.
The product development flow dramatically contributes to teams becoming empowered or trapped in feature factories. Let’s explore each of these two possible flows in detail.