Stefan
Latest posts by Stefan (see all)
At the beginning of the year Google laid off 12% of its workforce. A shock to the system. A lot was talked about in the weeks to follow, and a lot of folks opined what is wrong with google. Many now former colleagues expressed their thoughts and feelings publicly, with a lot of learning shared across the tech sector. 💣
For myself the situation meant a lot of firsts. I had someone on my team laid off, which was a first for me. How to deal with this? Can I even reach them? A lot of open questions followed. Then, the uncertainty in my region. Germany is still processing the layoff decision (as of August 2023) and has yet to share the outcomes. Many people envy Germany for its strict labor laws and works council structures. Personally, I feel more at home in a place where I know quickly what is going on as opposed to a long drawn out process. But I can see how having the government secure your job no matter what is attractive to some.
As a Product Lead, I see this moment as a distinct start of a new phase of my personal and professional development.
Today I’d like to share some of those learning that really affect how I look at the role of a PM overall. I’ll also share some practical tips on how the product team addressed the challenges which arose in the aftermath.
Directly after the layoff, and I mean one to two days after, a very strong signal emerged. I’d call it a version of ‘fight or flight’ behavior. Some folks truly signaled they want to ‘fight’ this. They want to engage. They want to solve. Many of them, understandably so, were creative problem solvers or engineers. Individuals used to roll up their sleeves and take initiative. I found myself drawn to this cohort, probably due to my background as an engineer and my identity as a ‘builder’.
Another group disengaged. From where I was sitting, those folks were ready to just take their hands off the keyboard and wait to learn more. They took time to process and digest. Many of them were more directly affected, had a team laid off, or their project impacted deeply. Understandably, they were confused about the signals and how to read them.
As a leader, I had to find ways to accommodate both flavors, and truly show empathy for the whole spectrum of emotions people were going through.
In a place like Google, where things are magical most of the time, with unprecedented perks, focus on employee well-being, and jobs which have the highest salaries, but also the highest impact on users, this was truly a new situation for me.
We held listening sessions, and tried to share what data we had while also containing speculation on areas where we simply didn’t know anything. This was tough, and a lot can be said about the mechanics of how these layoffs were enacted.
We also tried to ensure teams had the opportunity to get into ‘fight mode’ in a productive way. This was a balancing act. I rushed to Berlin and spent time with the team brainstorming. There was a big momentum with a small but significant group within our teams to go ‘first principles’ on how we generate value. A great thing, albeit difficult under those circumstances.
Another aspect which became clear during this time was that there is a – maybe natural – gravity toward ‘continuing on our product trajectory’. Every group, with past successes, will reinforce the paths to success in some way. Shocks to the system can play a big role in helping the system to reorganize, and on the way challenge legacy assumptions.
A part of the team did that. We understood that the group, irrespective of the layoffs, was also mandated to move into a new product space: supporting learning inside the Google Tech workforce, using software as a main lever (as opposed to manpower). This was always a space of interest, but not one too actively explored. With the new found energy from the part of the team in ‘fight’ mode, we agreed to place a larger bet on this space.
We worked like crazy to expedite the tools of the newly formed x-functional product teams, especially around product discovery.
Product discovery is a useful concept, but needs to be heavily calibrated toward the context of the problem domain, as well as the state of the team. In our case, we had to do the full program: the theory, the practice, and everything in-between. We also had to land this with a workforce who had just gone through a traumatizing experience. We had our work cut out for us.
One of the things we started with is to create a ‘charter doc’, outlining the Why first.
We provide context to what we are trying to achieve, and why it is important for our users, our company, and our group. We then added ‘principles’, which served as filters for ideas folks had. Many people in fight mode really cranked out a large number of ideas. Many of them fell short of the type of long-term impact & value for our users that we felt is needed beyond the immediate craziness of the disruption past layoffs. To avoid saying No as leads over and over we needed to expose our rationale in a way that handed folks the rod, not the fish. Principles helped us accomplish that.
Principles mainly help clarify business constraints.
Examples are to work on solutions for tech roles, leverage automated approaches, and focus on learning journeys. They were:
1) Focus on Google engineers. We could choose a lot of segments of users, and going too broad would blow the solution space wide open. To ensure we limit our fragmentation, we focus on 1P developers.
2) Support learning journeys. Many user journeys exist for engineers. Ours are learning journeys. That was a clear boundary.
3) Main focus on surfaces where users are already on. To avoid building our own surfaces outside of users flows, incurring a lot of distribution cost.
4) Prioritize automated approaches. Avoid one off approaches and truly try and find paths to automated approaches using software.
5) Focus on effects correlated with efficiency and productivity. To ensure we would anchor on what is valuable to the overall PA.
Most principles worked well. The one that I had to address after the fact was (5). We really should have split our goals into input goals (such as engagement, time spent on learning content) and output goals (like productivity). This would have helped the team to better connect products to goals we can control, and don’t worry too much to show (complex) lagging behavior. But hey, you live and learn.
We also exposed our working model, and selected something known as ‘safe to fail experiments’.
This is a model where a couple of aspects help ensure what we do has a high probability of success, while also allowing us to pivot on the idea entirely. One aspect of these experiments was to start working on a problem ‘away from the knot’, which means to avoid a compound set of challenges, and instead find something where we only have one problem to address.
One idea, for example, chose to focus on how to help engineers during code reviews with learning resources. Instead of focusing on all parts of this journey, we isolated a very specific journey (code reviews for engineers going through a form of certification) to limit us to a moment where learning is known user need. We also left the existing UX unchanged, and only added marginal content within the bounds of the existing UX. This way we weren’t adding a big UX change to the mix. The hypotheses became super narrow and focused: Engineers benefit from additional learning opportunities during a code review for certification. That’s it.
Another aspect was to provide the phases ideas had to graduate through over time.
We came up with a 4 phase setup, bringing ideas from articulation, over staffing, all the way to execution and finally ‘graduate’ them into real core product priorities. Clearly there was an expected drop off along the way, and that was expected. Gamifying the flow helped encourage teams to self direct and build a sense of accomplishment along the way. This became crucial, since folks needed the wins to stay engaged, and seeing others around them unlock another level sparked healthy competition.
Our phases were:
1) 💡 Ideation: Sit down, do desk research, talk to users and colleagues. Whatever you have to do, do it, and build hypotheses. Rub them against the principles to self guide how well they meet the space we want to win in.
2) 📝 Articulation: Write things up and articulate your ideas. In a world.of hyper-fragmented teams (regional, time zone), we need to share ideas asynchronously. The best way is doing a structured, brief, write up. This forced another level of making sure we weren’t ideating outside of the constraints of the business.
3) ⚙️ Allocation: Select the most promising ideas and allocate resources (eng, PM, design, user research). It helped to make that point explicit, so teams could start to execute on pilots with air over from leadership. While operating lean, we were still part of a global corporate environment, with all the processes such as performance management and quarterly planning.
4) 🎓 Graduation: Create a moment to select a pilot outcome into a long-term priority. This was a challenge, since we didn’t quite know what exactly we were looking for (natural for product delivery). We ended up graduating pilots, and it was truly a happy moment. At this point the regular planning processes and more linear processes (OKRs, PRDs, reviews) would kick in.
Another ingredient for our efforts which we provided more systematically was consistent access to UX research resources.
The team did a stellar job helping the individual teams across a variety of problems. They provided consistent research brief guidelines and prototype evaluation across our users. It allowed us to express a sense of user value as well as a relative ranking.
We are a small team in a massive organization, and we knew we couldn’t have the impact we are looking for without striking strategic partnerships. We specifically prioritized partners owning surfaces we knew our users are already on. Our users – Googlers in tech roles – experience moments of learning needs on those surfaces. But those surfaces often don’t have the mandate to prioritize the learning journey per se. They serve other, more critical use cases, such as writing code or finding information across all of Google.
For example, Google’s IDE is hyper optimized for code creation and maintenance. We know users have learning needs as they code, but the team working on the IDE is hard pressed to rank those highly given the overall goals they pursue. However, we could provide a significant value by partnering with those surfaces and provide the resources (eng, PM, UX) to support those use cases for learning. A true win-win.
To kick-start this process we had a series of ‘expert talks’.
A brief 30 min session by individuals across the various partner teams and surfaces, with a focus on learning. It was truly inspiring to see how we learned from across the company. Teams learned about what those other teams were doing, learned who the individuals behind them were, and became more empowered to explore on their own how our team could support our mutual users.
Showing our work, and how we connect the dots across the org wasn’t just inspiring for us. It turns out a lot of folks had thought about learning, but were unable to truly sink their teeth in. The economies of scale really kicked in and helped motivate the team.
To ensure we executed well we always asked for feedback and input.
To ensure we weren’t working away from our teams, we ensured a constant open discussion and asked for opinions and input often. A key way to build trust & safety within the teams. We used various mechanisms spanning from meetings to listening sessions to surveys. While they presented a bit of an overhead, they were all necessary. We also leveraged our leadership to signal support for the effort often, so the teams felt this work wasn’t just done in isolation but really connected to the success of the overall org.
Summary
The operating model presented really enabled our team to deliver innovative ideas in a narrow space in a short period of time.
We avoided super complex ideas by creating narrow principles, as well as ensured safety in execution by leveraging ‘safe to fail’ experiments.
Our process was embedded in the whole organization by talking to a lot of adjacent spaces upfront through expert talks, and sharing those out broadly. Leadership signaled support consistently, and we asked the team for input to adjust the process as needed.
In the end, we ended up with a couple of extremely powerful results, including:
- A repeatable process and a set of reusable templates for product discovery.
- Individuals who started to own the process. This happened across functions, i.e. product, eng, UX.
- A set of powerful ideas, some of which graduated to become fully prioritized ‘core products’.
Success looks different for every different teams and organization. In our case, we really exceeded expectations.
Take Action 🎬
📅 Book a private coaching session with me to grow your PM career. I will share my 15+ years of experience as a Product Manager, all my learning and pitfalls, with actionable tips and concrete lessons to model after.
📚 To learn the foundations of Product Management, I recommend reading INSPIRED by Marty Cagan. Marty has been leading the Silicon Valley Product Group for over two decades. His work is foundational for Tech Product Managers – a must read.
📚 To learn how to start with Why, I recommend Start with Why, by Simon Sinek. Simon is a genius when it comes to articulating the factors which will forever transform how your team thinks about purpose. If you struggle converting your group to a team of doers, instill more motivation, and truly transform the way you work together, this is the book for you.
📚 For iterative product discovery, check out Continuous Discovery Habits, by Teresa Torres. It presents a structured & scalable approach to continuous product discovery which will enable you and your team to act.
📚 To learn about OKRs and goal setting, I recommend Measure What Matters, by John Doerr. It really builds the foundation for understanding OKRs as a central planning tool, how it is implemented within and organization, and how it sits alongside other planning processes such ass performance management.
