Scaling product and design teams is not just about hiring

When working in early growth stage companies, being able to scale your teams quickly enough is a key element in keeping the human workforce aligned with advancement levers.

Hiring might be the first thing to come to mind, right? But hiring is only part of the solution. Having your team expand by 3-5x in a month brings numerous issues to be tackled simultaneously.

In this post, we’ll discuss other factors imperative in scaling product teams.

What problem(s) were we trying to solve?

On one side, you are going to have a product team with a variety of backgrounds and expertise, many of whom are new to the company. Ways of work and collaboration methods are not universal, and everybody has been molded based on personal opinions and past experiences.

On the other hand, standards and expectations aren’t generic worldwide either. Most of the time, assumptions are made individually if there is no guide to follow. You could be thinking that you are a competent and strong performer as a senior product manager, and your manager thinking completely the contrary. Also, this is true from one company to the next. As a UX senior designer in Company A might be considered a UX lead in Company B.

And finally, your company’s growth stage, principles, or values may well be defined very poorly at the company-wide level. You haven’t had the need to explore your values and principles as an employee but as a more senior product employee, you may be expected to set these expectations.

If you are just a few people in the product team, this kind of alignment happens in daily conversations with your peers, and it just feels enough for the time being. But it could change overnight, principally triggered by an investment round. And when that day arrives, you should be ready to break with the existing team status quo and scale as quickly as possible.

We experienced this exact situation in the company that we work for. At first, we had an overwhelming quantity of questions and very few answers. How are we going to work and collaborate together? How are we going to define the same standards and expectations within our teams and across teams? How are we going to make sure that everyone’s view aligns with ours? How are we going to promote the same principles and values across all the lineup?

Plus, you have a brand new team, including product leadership, possibly with strong opinions of what is the right thing to do. How are we going to decide and attain alignment?

What did we do?

Ultimately, we accomplished our scalability intentions, and these are few key initiatives that made it happen:

1. Use market references from Product Leaders or recognised organisations (like Mind the Product) to bring initial alignment on the product leadership. There are plenty of case studies, established protocols or certified(ish) ways to work where everybody is more likely to welcome, as they are validated to certain levels.
2. Breakdown the team in cross-functional squads to enable constant collaboration. Instead of spending work on mapping dependencies, just eradicate them removing any friction in the progress, creating autonomous squads. Note that it is kind of the famous Spotify structure, and in our case it worked until a certain point. At least, we reduced friction considerably (let’s call them ‘semi-autonomous teams’).
3. Unify your agile process, same ceremonies, same timings. Before, every expertise-division used to have their own delivery process, and it required continual realignment as the key element was to communicate (aka provide updates) rather than collaborate. We changed the game, having cross-disciplinary goals, same meetings and same process. Also, if you are yet to have a Scrum Master role, it would be the ideal timing.
4. Define your product standards using a Product Playbook. It felt like defining your own micro product world within the company, but it set the same expectations crosswise for all product people, leaving little room for interpretation or mis-aligment. It included product stages definition on the product processes and cycles, objectives, and tools and techniques at disposal on every phase.

1. Build your internal career paths, as it clarifies skills required and expectations for every seniority level, as well as expected performing levels. Here we used the Product Assessment by Mind the Product, a great allusion to begin with (and it is a free resource, check it out here).
2. Fabricate your product values and principles, and use the company culture as a hint. It has to be a complementary association with the company as product shouldn’t be a separate entity. Having product values helps to be more tangible and proximate to the team, so it gets more involved in building them. Also help to detect individual growth areas, determinate professional growth and align promotions or performance improvements plans within the team with very little gaps. They act as a guide rather than dictating how certain tasks must be completed.
3. Keep it collaborative, iterative, open to changes, using a test and  learn approach. Settling the inception is hard, but clarify that is just that, the beginning. Nothing is written in stone or above discussion. So continuous learning and experimentation are a must. Generally, product practitioners are curious about improving themselves and their practice. Allowing ideas to be implemented as experiments introduces new ways of working. If it doesn’t work you try something else, if it does, great you’ve got a new way to achieve your goals.

The best thing about it is everyone is designing their team’s ways of working, which often leads to high engagement levels. Defining a solid foundation and moving on to the team experiencing it rapidly. We’ve found it facilitates strong relationships in and out of the division, by showing results and involving everybody in the journey.

What’s next?

This was just the beginning. We have modified and expanded our mechanisms, like developing and documenting our methodologies repository, adding templates for key documents, creating a design system or building another playbook integrations-specific. We also broadened our product values and operations, as well as adjusted our tracking structures. We even went beyond collaboration, learning code, analytics, design and product manager basic notions to understand our peers better.

And at the end of the day, no matter what kind of initiatives you are applying, if these have the critical elements of collaboration and standardisation as keys of success. Defining measurement systems and objective measurable goals is vital to make sure that everybody is on the same page.

Integrating some or all of these initiatives will help orient your team towards the important areas to cover when scaling your team rapidly!

Have you been in a similar situation? Let us know the initiatives you’ve implemented!

Discover more content on scaling product teams. For even more content on a range of product management topics, see our Content A-Z.