Part 5: Preparing for scale
This is part 5 of my five-part series on scaling your product management craft (Creating Conditions, Leading with Intent, Building Foundations, Recruiting World Class PMs, Preparing for Scale).
In part 3 I wrote about how product managers might find themselves in a balancing act doing the work of the prospective hire while still recruiting to fill the role. Once the new hire has on-boarded and ramped, many managers continue to hold on to the IC work. I certainly have been guilty of this; the product work is rewarding, and you compare the effort of teaching vs doing it yourself one more time. Managers with any intention of scaling must let go.
Why do product leaders find it so difficult to give up this control?
I’ve debated about this with many peers. It often is because of what comes next. In this summary of Julie Zhou’s book, she writes about how you can use delegation to provide the space and headroom to empower your product managers. In other words, you might suddenly find yourself in a position with less to do and wondering what value you add to a team. You might not know it yet, but this is the just the calm before the storm.
Do you recall the concept of shipyards in part 3? Now that you’ve become competent at building a shipyard, how can you create an environment that enables your product managers to become shipyard builders? How do you make sure you have consistent, scalable processes as a people manager and a team lead? If you’re not paying attention, you might find yourself in that storm, unprepared.
How do great leaders do it? Over the past two years, I’ve been collecting notes from several conversations and observations of my peers, mentors, managers, coaches and leaders I admire. Here are the traits exhibited by the leaders who rise out of the chaos to scale teams.
Great leaders create systems for communication
Learning from prospects
If your company is selling a SaaS product, no matter how great the website is, there is an extra level of clarity your prospects gain by trying your product, pushing its limits and asking questions.
Where could you find this information? It might be in user reviews, sales engineering call logs, support tickets, executive emails, slack channels, online forums, and so on. How can product builders (product managers, engineers, designers, etc.) get access to this information to excel at their work? You start by creating a process that drip-feeds exposure. Product builders can take turns shadowing sales engineering to hear about use cases, and pain points. To make it simpler to disseminate this information, you can use a tool like Gong to share snippets with your team.
Hearing your customers
There’s no better way to gather feedback from customers than asking them.
If your product gets a lot of traffic, you can get started with a customer relationship tool like Intercom.io, or orchestrate surveys/polls through an analytics tool like Hotjar or an NPS tool like Delighted. Perhaps you’re in B2B and have a smaller volume of organic site visits. Consider customer councils as an alternative. Selectively approach and recruit motivated customers. Try to eliminate bias by ensuring there is a diversity of vertical, industry, company size and use cases. This article touches on some best practices for running an active council. A successful council agenda may include topics like:
- Feedback from a beta or recently released feature, or recruitment of members to join one
- Discussion on pricing and evaluating willingness to pay or churn impact for critical feature requests
- Opportunities for partnership marketing and webinars to highlight success stories
Make the customer council integral to the prioritisation and roadmap process.
Empowering your team to speak up
Regular team meetings are the perfect opportunity for communication and calibration towards goals.
Leaders operate team meetings at several levels of granularity and frequency. Find the balance that works well for you to keep folks involved without adding a lot of overhead. Your cadence might look like this:
- Product all-hands: Quarterly, for sharing success stories, vision
- Product leadership: Monthly, for roadmap calibration
- Squad/business unit: Monthly, for process and team unity
- Directs: Weekly, for tactics and risk mitigation
- Scrum: Daily, for blocker elimination
Naturally, it might be hard for folks to share what’s on their mind and engage in a productive discussion. I got a great tip from a colleague of mine to kick off a meeting with a sharing session where each team member spends a minute talking about what’s on their mind, not related to work. I’ve seen many variations to this like favourite 90s video game or stretching exercise. It can be particularly useful before diving into a workshop.
Great leaders invest in processes for improvement
Improving team collaboration
Reward push-back from your team with meaningful action plans.
With an open line of communication, leaders gain access to valuable information that could make the organisation more productive. Ignore it, or not include the team in the solution, and you will lose faith in your colleagues to give you this feedback again.
Look back at the last retrospective you had with your team. There were probably a few nuggets that you filed away for next time, and it slowly became a backlog of “things we should do if we had time”. Convert these team issues into goals and rise to the occasion with product workshops. Some common topics well suited for product workshops:
- Standard templates for 1-pagers, rollout plans, specifications
- Product and software delivery life-cycle
- Go-to-market process
- Product prioritisation process
- Software testing process and environment availability
- Deployment process
- and other bottlenecks that impact time to develop and time to deploy
A common pitfall when running a workshop is to treat it as a lecture, sharing methods that worked well in the past. Instead dedicate time weekly to prepare for these workshops — generating pre-work material and assigning leaders for focus groups, as necessary.
The work product from these workshop becomes artefacts that the team owns, accepts and therefore more likely to consistently use. Great leaders use this technique to level up their teams and create new standards across the organisation.
Here’s an example of a product delivery life-cycle that fit the specific pain points for a highly collaborative team.
Designing career journies
The most frustrating experience for an employee is going through 51 weeks in a year and being blindsided by unexpected feedback in week 52.
To have fruitful compensation conversations with your directs, you need to start the process at the beginning of the year (or when the employee started).
Employees expect clarity from their managers as to what success is. Great leaders use three tools to create objective standards and calibrate the conversation. They are:
- Product Manager Characteristics
- Career Ladder
- Structured 1:1s
I’ve expanded more about it, here.
Great leaders have trustworthy relationships with their directs. When there is an opportunity to provide feedback, it comes with empathy, understanding and context. Great leaders also focus on the long-term, about the career journey which goes beyond the confines of function or company.
Great leaders celebrate others and evolve
Sharing success
There is no greater satisfaction than giving the credit where it is due.
Product leaders eager to make a significant impact send out the release notes to cap off that the team has shipped something awesome, and remember to praise every single participant who helped cross the milestone. And then they jump on to the next whizzbang feature. Most companies have regular happy hours and release celebrations to thank the team for their efforts. While a quarterly release celebration to stop and reflect on all the accomplishments in the past three months is a very positive thing, sharing success at a more frequent interval can transform the team experience.
Great leaders incorporate product demos as part of the weekly team huddle or retrospective meeting. The demo allows team members to share their work, get critique and celebrate the tiny wins. They bubble up the best demos to the company all-hands to create a conversation about the craft of product and design, and to give visibility for the creators to showcase their mastery.
Create space for others
The transformation from self-preservation to uplifting the team can have exceptional impacts on team morale and autonomy.
Great leaders are comfortable creating this space for their team. By putting in places these systems and processes, they trust their team to scale the operations to the next level, ultimately moving away from the day-to-day activities. It certainly is not easy to do, as it requires confidence and the professional maturity to think about the sum of what you do for your team rather than a list of responsibilities you had in your job description. You have to evolve and transition leadership roles to your team members. Perhaps they can lead a council, or present a strategic roadmap to a customer, or be on point for coordinating team meetings. Start small and progress at the pace that works for you.
Note: You still can roll up your sleeves and contribute when the team asks for it! It will give you empathy to relate to what your team members are experiencing and find further opportunities to improve.
Being a thoughtful change agent
If you’ve made it this far, please DM me. You must be quite interested in this topic, and I’d love to interview you.
So, great! You’ve finally made the transition from individual contributor to manager, and created processes for your directs to do the same. Your team is ready to scale!
Product leaders take this opportunity to focus on finding new problems to solve, but also to be thoughtful change agents. As organisations scale, they go through a lot of unavoidable change. Change can be painful, especially when it is misguided and unnecessary. Great leaders consider these levers when unlocking the next level of growth.
- Tying company strategy, to team strategy, headcount and budget
- Team stage in the Tuckman’s model for development
- The ratio of product managers to developers
- Feature ship time when cross-team dependencies exist
- Company-wide bottlenecks
- …
