What I Learned at Slack
Part 4: The Six Forces of Product Development
I was the first product manager at Slack. I couldn’t be more grateful for all that I learned helping grow the product and the team, so it’s high time I shared a few of those lessons.
Fast-growing companies like Slack are always changing. They must constantly strive to make sure their organization and processes are addressing the new challenges that emerge each day. With each new project, with each new hire, with each new stretch goal, successfully delivering on the promise of the company grows more complex.
One useful way to think about this problem is as a set of interlocking forces that balance one another. The classic example of this is the project management triangle: the tradeoff between scope, time, cost, and quality. Change one and the others must change too.
This model is useful, but it has two problems. One, it is limited in its scope: it doesn’t cover all the tradeoffs in today’s typical product team of designer, developer, product manager. Two, it doesn’t help you take action. Are those three roles the right ones for your team? How should roles and responsibilities change as you grow?
I think about structuring product teams using the model below. Six fundamental forces driving product development, with clear decision-making at their center as a tie-breaker.
Each is an inescapable part of building tech products, yet it’s challenging for any individual to advocate for more than one force at once. If you’re in charge of the schedule, it seems easy enough to adjust the other forces enough to hit any deadline. Yet if you control resources too, suddenly your choice is between hitting your deadline, overworking your team, or giving other projects short shrift. The complexity of an individual’s decisions increases exponentially with every force for which they’re responsible.
So what’s the best structure for product teams? You can assign each force its own advocate, but that comes at a cost: larger teams and their communication overhead. You can assign each team member two or three forces, but the likelihood they’ll neglect one of the forces increases alongside. The point is not to prescribe a certain “ideal” team structure, but to recognize reality: we mostly need to find the right balance of responsibilities with the people we have today.
Structure your product teams by balancing these six forces. They need not be equally balanced — each force’s importance varies with the stage and situation of each company — but they all need advocates. Consciously assigning those advocates when you design your organization allows you to prioritize and reprioritize the forces as the company changes over time. Explicitly communicating those assignments helps clarify roles so teams can work together harmoniously.
Example: Founding Team
Let’s say we have a founding team of two: one designer, one engineer. They’re trying to find product/market fit with very limited resources. They agree to divide the forces this way:
Customer Value: Designer
Decisions: Whoever’s CEO
The advantage of this small team is that they can discuss and resolve issues quickly.
Both founders face a classic tradeoff between strategy and tactics. By having to advocate for both high-level customer value and the details of design and quality, the designer will likely have to cut corners in service of quick iteration. With limited runway and no one else to help, the engineer’s code will necessarily be quick and dirty.
Want to get more done? Hire more engineers to handle Architecture, and let the founding engineer focus on Resources and Schedule (i.e. more hiring). Want to make sure what you’re shipping matches design? Put the founding designer in charge of Schedule, and let them wrestle with finding the right balance of scope and time. Seeing more potential in the technology than the original product idea? Maybe it’s time for the engineer to take over driving Customer Value.
There are plenty of options for how to hire and assign roles. Using the six forces to make those decisions (and communicate why) helps draw a clear line between the company’s goals and the corresponding organizational changes.
Example: Slack, 2014–2015
As Slack grew post-launch, we iterated through a number of different arrangements as the organization grew and matured. The point was never to find a perfect structure, but to adapt to the constraints of the moment as new hires arrived and roles shifted over time. We strived to build the best product we could with the time and resources we had. Here’s how things looked post-launch:
Customer Value: CEO
Architecture: Engineering Lead
Resources: Engineering Lead
Quality: Customer Support/QA Lead
At this point we simply needed more people to do the work. As we hired more individual contributors (including me!), the founders and early employees were able to shift to more managerial roles. Here’s how it looked a year later (changes in bold):
Customer Value: Product Manager
Architecture: Engineering Lead
Resources: Engineering Manager
Schedule: Product Manager
Quality: Product Manager
As the company grew and feature teams multiplied over the course of the year, engineering managers began to handle resources as there were more engineers to distribute across various projects. We hired quite a few product managers, one for each feature team, so they were able to handle some project management and QA alongside their core role advocating for the customer. Dividing the PMs between three forces meant development slowed while we invested in process to improve forecasting and quality, but our velocity improved over time as we had more resources and emphasis on scheduling.
These roles will continue to shift and change as the company grows, but this snapshot shows how useful the six forces model can be in considering the tradeoffs of real world planning. Sure, we’d love to always have the perfect team in place at every moment, but in practice growing companies are in constant transition — both the team and the business they’re building. As you navigate those transitions, let the six forces model be your guide.