- ZeroBlockers
- Posts
- When Things Go Wrong: The Real Benefit of Empowered Teams
When Things Go Wrong: The Real Benefit of Empowered Teams
In product development, encountering unexpected results isn't just common – it's inevitable. The true measure of a team's effectiveness lies not in avoiding failures, but in how they respond when faced with disappointing data or failing features.
You've just launched the first version of a feature, and the data is falling short of expectations. Meanwhile, development of version two is already underway. What should you do?
I’ve been faced in this situation many times, but one experience in a Waterfall project stands out. After a customer demo, we received major change requests and fixing them was going to take time and money. As the project team, we lacked the authority to make decisions affecting the budget. We submitted a change request and continued working on the original design, fully aware that every line of code written might need to be redone. We couldn't risk working on the new design without approval, as missing the schedule would be seen as failure. Our goal of producing the output was more important than it’s effectiveness.
Empowered Teams are Accountable for Outcomes
When teams are accountable for outcomes instead of just outputs, their response to disappointing data changes dramatically. Rather than waiting for permission, the team can make quick, informed decisions.
When data suggests a feature isn’t working, the first crucial step is to pause development immediately. This isn’t about stopping for the sake of stopping. It’s about preventing further investment in a flawed direction and creating space for analysis. It also helps avoid technical debt that could make future changes more expensive.
Continuous Research
With development paused, teams can focus on investigating root causes of the issue. Data tells what is happening but not why. By conducting user interviews, analysing usage patterns, and examining feedback, teams uncover the underlying issues.
Continuous Design
Once the causes are identified, teams brainstorm potential solutions. These solutions are broken down into core assumptions that can be quickly validated or invalidated before further investment.
Continuous Development
With validated solutions in hand, development resumes in a new direction. If tests confirm the new approach, priorities are updated. If not, teams must be willing to kill the feature and reallocate resources.
Essentially, the team operates as usual, but with a temporary reset. It’s like emptying a Kanban board. Since work is pulled rather than pushed, teams naturally refill their workflows with validated, high-value initiatives.
Success in Action: The Airbnb Photography Pivot
In 2009, Airbnb faced a critical problem: listings in New York City weren't booking. By using their own product as customers, they immediately identified the issue: poor quality, amateur listing photos that failed to attract renters. They didn’t want to rent any of the places they looked at.
Pause: The team paused their technical development plans to fix this issue
Investigate: They identified poor photography as a potential root cause
Ideate: Y Combinator's Paul Graham suggested a non-scalable solution: professional photography
Test: The team flew to New York, rented cameras, and upgraded the photos themselves
Decisive Action: When weekly revenue doubled to $400, they scaled the solution offering free professional photography to selected hosts.
This rapid response and validation led to a major pivot in their approach, eventually leading to a professional photography program that became a key differentiator for the platform.
When to Kill: Airbnb Plus
In 2018, Airbnb launched Airbnb Plus, a premium tier for verified, high-quality homes. Properties were physically vetted annually, and Airbnb planned to heavily promote Plus listings. However, the program struggled with both customers and hosts.
Pause: In 2023, Airbnb paused to evaluate the program's effectiveness
Investigate: Hosts didn’t like the program because Airbnb wanted exclusivity. The increase in earnings didn’t compensate for the loss due to exclusivity. From a customer perspective, the Plus properties were great, but so were lots of other properties. People wanted to see all of the matching properties.
Ideate: The team couldn’t think of a way to satisfy the competing needs of the business, hosts and customers.
Decisive Action: The program was paused and the team were disbanded to work on higher priority initiatives.
Challenges
Having autonomy to decide what to work on is not all plain silaing. There are challenges that teams need to be aware of.
Sunk Cost Fallacy
One of the biggest hurdles is emotional attachment to past work. Teams that have invested months into a feature making it psychologically difficult to kill their "baby" despite clear negative data. Organisations can counter this by celebrating teams that make tough kill decisions and tracking the cost of delayed decisions.
Constant Pivoting
On the flip side, pivoting too frequently can lead to “pivot whiplash.” Teams that chase every new data point without allowing time for meaningful patterns can abandon promising ideas too soon. To prevent this, teams should define explicit success criteria before launching features. Success metrics and evaluation timelines should be set in advance, ensuring decisions are based on data, not impulse.
Decision Paralysis
Even with abundant data, teams may struggle to make timely decisions. Success requires consistent application of the research-design-development cycle, with clear ownership of decisions and predefined evidence thresholds for major changes.
Team Morale
Perhaps the most subtle challenge is maintaining team morale and psychological safety when features are frequently killed or pivoted. When ideas are regularly stopped before completion, it can lead to risk aversion, with teams gravitating toward "safe" features over innovative ones. Build resilience by celebrating learning over success, conducting blame-free retrospectives, and including "features killed" as a positive metric in team assessments.
Conclusion
The real benefit of empowered teams lies not in their ability to build features, but in their capacity to respond quickly and effectively when things go wrong. This adaptability becomes a crucial competitive advantage, enabling organisations to learn and evolve rapidly rather than persisting with proven ineffective approaches.