“Scaling” is one of those buzzy words thrown around in the startup community. It’s used to mean a host of things like scaling technical infrastructure, hiring people (and hiring processes), being more cost-effective with customer acquisition, etc.
It’s so buzzy, that one of Sarah Cooper’s 10 Tricks to Appear Smart in Meetings is to simply ask: “Will this scale?”
For product teams, scaling can mean: (1) increasing usage/customers, (2) expanding product area/offerings, (3) speeding up the pace of development, or a combination of these. From both personal experience and the collective wisdom of the product community, here are three challenges a scaling product team is likely to face when trying to achieve any of these variations of scale:
- Scaling collaboration (this post)
- Scaling people (next post)
- Scaling principles (the third post!)
Part 1: Scaling collaboration
I was a PM at Intercom when we grew from ~200–500 employees. During that time, the go-to-market functions (multiple teams across sales, marketing and customer success) grew extremely quickly in headcount. There were more people, new functions, and every team’s process was being built as we flew the proverbial plane.
In spite of trying to speed up and adding more people to do the “job”, things slow down.
The irony is that in spite of trying to speed up and adding more people to do the “job” (building, launching, selling), companies can go through periods where things slow down and teams feel bottlenecked.
Tips for managing these challenges
1. Collaborate intentionally
- Get to know your partners
- Define owners
- Agree on cut-off dates
Like developing user empathy, a good first step is to spend time with partner teams like PMM, Customer Success, Customer Education and Sales Ops — especially if any of these are new functions that have never existed in your company. Through 1–1’s, or even a series of lunch & learns, understanding what each team actually works on, and how they work, can go a long way in building team resilience.
For example, I’ve learned that changing the UI of a feature hours ahead of launch used to be annoying, but manageable, because I’d be the person left with extra work. But in a larger company, the launch process includes sales enablement and CS updating visuals for for customer and education materials. Last minute changes not only create a rush of work, but undoes hours (or days) of prior work which is incredibly demoralizing.
Deciding up-front on who owns making these changes is a great first step that provides clarity and humanizes the impact of the change. To created shared expectations, Jasmine, a product marketing manager at Intercom, also suggests setting cutoff dates, so each team has confidence on when final decisions and changes will be made.
2. Use best practices for remote & distributed teams
- Zoom by default
- Document immediately
- Make your ask comprehensively
Even if your company is largely co-located, working cross-functionally means at least some interactions are remote. Companies like Uber have an implicit “Zoom by default” policy, says AJ, a former product manager at Uber. On a project or team, it was common to have someone dial in from home, or from a different part of the office. Having that dial-in by default saves everyone the 5 minutes of slacking: “where’s the Zoom id?”
Paige, a product lead at Asana, pays particular attention to the conversations that continue even after a meeting formally ends. Those hallway discussions can result in implicit decisions that get lost. So, she makes sure to write them down (and share them) immediately…before the next meeting takes her attention away! This goes a long ways in keeping the whole team on the same page.
Yet others like Lacey, a product lead at Proteus Health, know that documentation has its own challenges: Slacking out a decision gets high visibility, but is easily lost. Documenting in a doc is much better, but there’s just enough friction that it’s not always done. Even then, it’s often double- or triple-entry.
Finally, send any requests and updates with as much context as possible. Slacking a “hey, got a sec?” really doesn’t work when your counterpart is a few timezones ahead, or simply has a different cadence of meetings. Instead, leave full asks with the “what”, “why”, context and reference docs, and most importantly “by when.” While these are generally good communication tips, they really become necessary when working cross-functionally because the cycles are so much longer.
3. Embrace your new role as your project’s internal CMO
- Give it a name
- Make it fun / memorable
Finally, larger projects will have a number of people & teams who are loosely affiliated (vs fully dedicated). Creating a sense of mission, a shared understanding of impact, and a healthy dose of fun is a critical part to binding team members together. Chris, a product lead at Segment, shared that memes are often created to give projects an internal identity. This gives people a sense of belonging to something fun, exclusive, and certainly memorable.
At Segment, memes are often created to give projects an internal identity.
At AskSpoke, one of the earlier sets of product changes I led was grouped under a tongue-in-cheek name of “No request left behind”. We were working on UI, search, and notification changes that would ensure AskSpoke users could effectively triage and respond to each employee request easily and quickly. When we launched, shouting “yeeeah!! No requests left behind!” was a lot more fun than “more notifications!” (which no one would ever shout).
Of course, as the rest of the company grows, so does the product team. And in Part 2, we’ll look at how the best product teams in Silicon Valley have learned to hire high caliber PMs and balance culture with skills along the way.
We’re helping product teams scale with Bento
Bento is building tools for cross-functional alignment. Project tracking tools give teams visibility into a set of tasks and their deadlines. Bento gives teams the content (docs, designs, conversations) so there is shared context and knowledge for collaboration.
Growing companies means there are more teams and newer tools. Bento makes it easier for the overall team to know what’s been created (and where) and what’s changed since you last engaged. Bento’s Change Log allows teams to capture decisions shared in Slack, email, or in meetings and share it in one place when onboarding new members or stakeholders.
Please drop me a note at email@example.com if you’d like to learn more!