How to Scale Yourself as a PM
I first signed up for ClassPass in the summer of 2014 on its infamous unlimited plan. For the first time, I felt like I could take advantage of everything the NYC fitness scene had to offer. Watching the company closer from the perspective of a PM, I’ve been so impressed with the scale the company’s achieved and how powerful product can be to inspire customer loyalty and decision making. In the sixth session of the First Round Product Program, we were led by Justin Chang, the Head of Product at Classpass, who spoke to us about how we can scale ourselves as PMs as fast as our companies are scaling.
When headcount, revenue, and/or customers start to scale fast, you will inevitably start to notice cracks in your company’s foundation. Maybe you find yourself with more decision makers on a project. Or maybe, features that only used to take a week to build now take a month. As a PM, how do you scale with your organization in order to continue to be effective and drive impact?
Decision Making at Scale
When I was at Hired, once we hit around 100 employees and had expanded to multiple cities, all of the processes that once worked for us seemed to stop working at the same time. One decision maker turned into two or more decision makers who didn’t always align on what they wanted our team to do. When this started happening at Classpass, they implemented the DACI framework, to ensure that every project had only one decision maker. This not only streamlined their projects, but improved engineering morale and reduced context switching.
- Driver: The one person responsible for the project. Drives the process, aligns stakeholders, and presents options and recommendations to the approver. Typically the PM.
- Approver: The one person who makes the decision. Even more senior people in the company hierarchy cannot overrule this person’s approval after authority is granted.
- Contributors: Individuals on the working/project team that provide input, attend meetings, and produce work for the project.
- Informed: People informed of the project and its results, but are not included in meetings and are not required to do work.
If you want to try implementing this at your own company, you need to get buy-in from senior leadership. Start by documenting any occasions where multiple decision makers have slowed down a project. Once you’ve done that, start experimenting with one area at a time, learn, iterate, and then you’ll be able to show how this framework has increased your team’s velocity.
As the team grows and tech debt accumulates, you’ll notice that work velocity starts to slow. Other than it being incredibly frustrating, this slowdown increases the cost of the project. So what do you do? Justin suggests building durable teams around durable problems. For example, Classpass formed teams around Acquisition, Studio Experience, and Machine Learning. It changes from business to business, and it takes time to get this right, but when it’s working, each team can move faster across the whole stack.
Once you have durable teams, the velocity of your team is heavily influenced by your product development process. During this session, we went around the room and spoke about product development at each of our companies. There were many differences, but the first step was always the same: Define the problem you’re solving and the goal of the project. This may seem simple or obvious, but the fact of the matter is that things that slow a project down like scope creep and design changes could be prevented if everyone understood and aligned on the goals upfront.
Product Development Process @Classpass
- Goal definition: With DACI in the room, debate and align on your goal.
- Product Definition: Align on scope of the project. What is required to solve the problem and what is not and could be out of scope?
- Design Review: Be explicit on the type of feedback you want and don’t want.
- Tech Review: Align on the right technical approach.
- Go/No-go: Ensure you are operationally ready (e.g. make sure Customer Experience is ready to handle questions, FAQ’s are updated)
I joined Hired when we were around 40 people. At that time, it was very easy for everyone to know everything that was going on. As we grew, it became very difficult to keep everyone in the loop without filling up the entire calendar with meetings. People then started to voice that they didn’t know what product was building and what our roadmap was. There are three main things that helped the Product team at Classpass solve this problem:
- Make sure your Product Roadmap and Product Docs are accessible to the entire company. In particular, within the Product Roadmap, ensure each item is focused on the outcome.
- Hold Gate Meetings with DACI. These are meetings that require a certain decision to be made to proceed in a project. Ahead of the meeting put together your product doc (the Amazon 6-pager is a great format for this) and include all context at the top. Start the meeting with a 15-minute reading period for everyone to read through the context section, so that everyone is on the same page.
- Finally, send emails to communicate the DACI decision at every stage of the product development process.
Have you ever felt like you’re just taking orders from managers or executives? Or that everything is too “top-down”? When this happens, you may start to feel demoralized and wonder if your input even matters. Over time, people may stop committing to decisions, and instead start blaming or punishing others when things fails.
Something that really resonated with me from the session about empowering your team is that you need to improve psychological safety to allow your team to innovate. Psychological safety is the belief that you won’t be punished if you make a mistake. Once your team has this, they will be more willing to contribute to the conversation, take risks, and be creative. One strategy for doing this is presenting people with options instead of handing them a decision. Another strategy that I’ve found effective is starting every kickoff or major milestone meeting with a background share. During the background share, we go around the room and everyone briefly shares what they know about this project, what they wish they knew, and what they are excited about.
No matter what scale your company is at right now and what cracks you’re noticing, the most important thing is to not ignore the eventuality of the issues scale brings. Approach that scale problem as you would approach any product problem for your users. What are you solving? Who are you solving it for? What hypotheses do you have on how to solve it? Test, learn, and iterate!