Fixing Breaks in Product with Scale

Problem

"The Build Trap" - Going from "we can't build enough" to "we build too much". Teams will default to keeping busy and building more software, instead of improving business metrics and verifying the results of what they just shipped.

Planning Will Break - With scale, planning horizons will shift from weeks, to months, to years. Suddenly teams have to understand how their "part" fits the "whole picture".

Communication Will Break - It's suddenly no longer enough to "stand on a chair and announce the change" or to "walk over and talk to the team to learn about their progress".

Organization Will Slow Down - Suddenly everything will default to needing an approval, consensus from another group, or worse, a backlog to be worked on later. What used to take days, will start taking weeks. If this is left unattended, your decision making slows to a crawl.

Big, Messy Data - Getting insight and running queries stops being the same thing. Running experiments to validate your product hypotheses is a key way you'll now move the product forward.

Actions taken

"The Build Trap" - Focus teams back on the customer problem by using Impact Maps, OKRs, and future press-releases. Go back after you shipped something and use data to iterate. Of course, enable all of this by structuring product teams so that they're small, cross functional, and organised around goals or metrics like engagement, growth, retention, or virality.

Planning Will Break - Keep roadmaps focused on themes, not features. Know the metrics and goals behind each piece of work. Repeat your product vision to the team at every opportunity. Use impact maps. Set OKRs with the team and explain how they cascade up to the wider business objectives.

Communication Will Break - Start using more written communication. Set just enough process, cadences, templates, automation, and tools to coordinate the work happening across teams.

Organization Will Slow Down - Let the teams closer to the work make the decisions or work with your development team so you can change elements on the screen without requiring code changes. Another option is to reduce shipping anxiety by using feature flags to launch features to a select group of customers. Lastly, you can test assumptions without writing software by using prototypes, concierge tests, etc... It is important to keep asking the questions of, "how can we learn what we have to learn in one day? What's the one week version of that?".

Big, Messy Data - Work with a specialist to set up data tools the teams can rely on. Set hypothesis, run experiments, and use data validate results, so that your teams can remove vias and make better decisions.

Lessons learned

• Discovery and validation become the bottleneck. That's how you get into the build trap.
• Coaching teams on how to set good roadmaps, goals, strategy and vision together, and on how to communicate those clearly to one another becomes a key skill.
• Setting up weekly show and tell meetings across the product teams to demo their work in progress will help keep communication strong.
• Clear, to the point, written communication is very important. Coach on this.
• Keep pushing for speed and finding ways to remove dependencies and decentralize decision making.
• Running experiments to validate your product hypotheses is a key way you'll now move the product forward. Without this, visionary thinking creeps in.

Source: What Changes as a Product Organisation Grows from 10 to 100 People