Ask Women in Product: How do you find your wins as a PM when you’re not producing working code?
The more senior you are, the greater is the likelihood that your work involves more than delivering working code. In this post, Lisa Wagner explains how she measures and celebrates the intangible wins.
This week’s question: As a PM without working code as a deliverable, where do you find pride in what you do? When what you’re producing is less tangible, where do you find your wins and feel like you’re succeeding?
Answer from Lisa Mo Wagner
Lisa Mo Wagner is a Product Manager at Zattoo. You can find her on Twitter at @lisamowagner.
The work of a product manager is more than just delivering working code. In fact, the more senior your role is, the more likely it is that you won’t have any code-related deliverables at all.
Even when you do have working code as a deliverable, it shouldn’t be the only thing that you, your team, and your success are measured by. So how should we think about and celebrate our wins when we don’t contribute directly to shipping a working product?
Focus on outcomes, not output
Start by not focusing solely on shipping features. John Cutler refers to this condition as being a Feature Factory, “a storypoint machine where the company only cares about how much is being shipped.”
What does this look like in practice? Consider the list below. While it’s not an exhaustive list, there’s enough there that you’ll get the gist of it.
- You’ll hear lines like these as reasons to build a feature: “The CEO wants it.” “My stakeholder asked for this.” Or “a more senior PM had this idea.”
- Your team believes that you’re “done-done” when the feature has been shipped.
- You have a timeline roadmap that looks like a Gantt chart (Tip: Janna Bastow explains why you should ditch them).
- You never deprecate any features.
Rather than focusing on output, focus on outcomes instead. While outputs are immediate-term results, outcomes describe how things ultimately turn out, the consequences of our work.
Outputs are familiar to all of us; they are specific results, like features. Let’s say we shipped a new feature on time. Is that enough for us to declare it a win in and of itself? Sadly, we can’t. While we can see that a feature has been shipped, we don’t know exactly how it affected our users.
In contrast, an example of a desirable outcome would be: “We want 95 percent of our customers to be happy customers.” There are different ways to achieve the desired outcome. To know if you are actually working on the right thing, you’ll need to define measures of success. In this example, you could measure your customers’ happiness this way: “Less than 5 percent of users cancel their subscription in the first three months.”
I have worked in several companies that relied heavily on project management rather than product management as their primary approach to getting work done. In that kind of environment, the features are decided on in advance, and there’s a constant struggle to do a good enough job of discovery to design features that are customer-centric. In this case, the output is what’s driving the work, not the desired outcome.
If your goal is not to ship working code, what is your goal?
I currently have a more senior role with a focus on strategy and planning. I do not work as part of a cross-functional team; instead, I work with several squads and I do not have any “code deliverables.”
So then, what are my outcomes?
Below you’ll find a list of things that are not features that I have been or are responsible for delivering as a product manager. Your list may vary depending on the company you work for and your level of seniority, but it should include the six areas I describe below.
1. Nurturing team health
Whether you work with a newly-formed team (as I did) or with a mature product organization, there will always be moments when things feel a little chaotic and hectic and the team is under pressure to deliver on time. These moments are stressful and can have bad long-term effects if left unchecked.
My main goal for my first three months with my team was to improve the team’s health, specifically by taking steps to make the team happy. I knew this effort had to be focused on the team as a whole and not just individual team members. I also had a few ideas on how to improve the situation. What I didn’t have at first, however, were any measures of success.
To help me get a better understanding of how well we were doing, we held regular Happiness Radars during our retrospectives. This practice allowed me to see what team members thought about the current situation on a simple scale of 😊- 😐- 😞. It also helps me gauge whether or not our process and team improvements were having the desired impact.
2. Translating strategy, giving direction, communicating the purpose
Let me say right away that this area is especially hard to measure.
One of the companies I worked for included the company’s mission and values as the first two slides in every presentation. It was a little annoying at times; in fact, you could measure the number of eye rolls. Having said that, repetition is an essential part of communication and if we want teams to understand their purpose, have a clear sense of direction, and execute on strategy, then we need to repeat that message. Repetition is even more essential in fast-growing organizations because what’s old to you will be completely new to someone who just joined your team. In the case of my previous company, this practice sparked more conversation and thinking about how we can better relate our initiatives to the company’s mission and values.
What constitutes a win in this area? You could set a goal like “ensure that everyone in the company is aware of this year’s main goal” with key results stated as “x% of presentations shows the yearly objective” or “x% of initiatives can be clearly related back to our main goal.” In a perfect world, x would be 100%, but let’s be realistic as well.
3. Discovery, running workshops, and experimentation
Product discovery, as defined by MixPanel, “is a method of deeply understanding your customers to develop products that perfectly suit their needs.”
As a product manager, you want to understand your customers as well as your stakeholders before you even get into solution mode. Once you have this understanding, you can think of solutions that can be worked out in workshops, prototyped, and user-tested. You could also run an experiment, a simple A/B test, for example.
There are multiple ways to set goals around discovery. If you’re just starting out, set a goal to do more discovery and then set a ratio of features built and discoveries run as your initial metric. You’ll always want to work towards doing some form of discovery work before you actually deliver a feature.
If you are already doing “some form of discovery,” you can set other goals like “learn new tools” or “experiment regularly”, with key results such as: “Use 1 new tool each quarter and evaluate how it worked for you.” The metrics are a little more tricky here because you don’t want to run experiments for the sake of it, but rather to gain useful insights.
4. Creating and refining structure/processes
Never create processes for the sake of it. You’ll want to create structure through processes only if you have a specific goal in mind.
For example, I have implemented processes to highlight dependencies early on, to support a team to self-organize, or to better collaborate with stakeholders. Find the metrics you want to positively impact and use the Happiness Radar results to see what areas would benefit from more structure.
You can assess the impact of structural or process changes through subsequent Happiness Radar results, through feedback from stakeholders, and by seeing if your subsequent product development iterations proceed more smoothly or encounter fewer blockers or delays.
5. Education, coaching, and professional growth
I set goals in this area for myself and sometimes together with my manager.
For example, I recently started another university degree in Forensic Engineering. My goal is to learn more about what excites me. An easy metric, in this case, is to pass all five exams this semester. A less obvious measure is to use your feelings as a key result. In my case, I want to still feel excited about the degree after the first semester is done.
Is there an area where you’d like to broaden or sharpen your skills? Ask yourself why you want to learn this and be honest! Your answer can be your next growth goal.
6. Removing dependencies or other impediments
As a product manager, you also deliver value by keeping the team on track. While the goal is fairly straightforward (e.g., “empower a team to do their best work”), measuring this can take a bit of effort.
You can, for example, track how often a team gets stuck and set out to lower that number by x%. You could log each issue that the team encounters and see how much time passes before an issue is resolved. You could see if any of the blockers could have been preempted had someone taken the time to map out dependencies. And you can see how successful you are at learning from these experiences and eliminating impediments on your next sprints.
Define what success looks like for you
For each of the areas above, you’ll want to start simple, define what success looks like, then find out if you’re on the right track by quantifying it. You can do this by asking yourself a few questions:
- Where am I (or where is my team) now?
- Where do I/we want to be?
- How do I/we know there’s progress on this goal?
- How do I/we know I/we got there?
A great tool for answering these questions is the Objectives and Key Results (OKRs) framework. You might have heard of this framework that’s been made popular by companies like Google, LinkedIn, Netflix, and Slack.
Objective = A broad ambitious goal. Key Result = A measurable finish line.
— Suzanne Abate on the Global Product Management Talk Podcast
Remember to use outcomes for your objectives. Avoid the common trap of setting an objective like “Ship feature XYZ” with a key result like “Deliver by date X” when you also have “working code” among your deliverables. If you need more guidance, consider reading Christina Wodtke’s book, “Radical Focus,” for a wonderful story and a detailed description of the framework. For a shorter introduction to the topic, I recommend Tim Herbig’s webinar on OKR and Agile Product Management Training: Enable Autonomy and Focus
Aside from your OKRs, you’ll want to define milestones. Don’t focus only on the big wins; celebrate the small wins along the way. Acknowledge the effort and work that goes into each milestone — it’s essential for morale.
Conclusion
Whether or not your deliverables as a product manager includes working code, such tangible outputs shouldn’t be the only things that you, your team, and your success are measured by. Consider which of the six areas outlined above you’d like to focus on next, identify outcomes that you want to achieve, then decide how you will gauge your progress against those outcomes. If you regularly invest the time to work through this exercise, you’ll have no trouble finding your wins.
In my last team, we wrote a team manifesto. I’d like to leave you with my team’s very smart mantra: “We want to never not celebrate!”
Thank you to @mdy for editing this piece.
