S1 Ep 9: How Do You Set Product Team Goals?

Ep. 9: “How Do You Set Product Team Goals?”

You can watch the episode on YouTube or listen to the podcast:

HOW DO YOU SET PRODUCT TEAM GOALS? Are you a product leader struggling with how to set meaningful, measurable goals for your product teams? In this episode, 5 experienced product leaders share their best tips and techniques on how they set goals, how frequently and who is part of the process.

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS

- - -

Hope Gurion: Are you a new product leader that is trying to implement OKRs, or shift from output measurement to outcome-based measurement? The reality is that most of the product leaders that I coach are at companies that are still early in the adoption of these philosophies. And that’s why in this episode of Fearless Product Leadership, I’m asking my experienced product leaders, “How do you set product team goals?”

Setting goals for my product teams was one of the most important and arduous responsibilities that I faced as a product leader.  It was so critical to get a clear, meaningful, measurable way to gauge success that resonated with company leadership and was grounded in what was important to customers and users.  In this episode of Fearless Product Leadership, we are going to hear from five experienced product leaders at startups, mid-size and large enterprises talk about how they set goals for their product teams. You'll learn practical tips on how to tie goals to company strategy, as well as who sets the goals and how often.

Fearlessly tackling the topic of goal setting in this episode are: 

  • Preston Smalley, VP of Product Management at Comcast

  • Ezinne Udueze, VP of Product at Bazaarvoice

  • Rosie Ruley Atkins, VP of Product, Homebase

  • Margaret Jastrebski, former SVP of Product at ShopRunner

  • Al Ming, VP of Product and Design at CNBC

Hope Gurion: First up, Preston Smalley of Comcast explains why goal setting should start with the product team and should be part of a setting, acting and evaluating lifecycle.

Preston Smalley:  So setting goals as part of the product team is one of the most important things that I think we do as leaders, and I think it's something that has always been a part of how, at least, I operate and I think many people operate, but exactly how you do it. There are so many different ways to do it and I think it's something that I really continue to try new approaches and see how we can get better over time.

So in terms of setting goals, there’s something actually that's top of mind for me right now, and one that when I go back to, because maybe six months ago I was reading John Doerr’s book, “Measure what matters”, and it really was resonating with me in terms of how to solve some of the problems that I think our teams face; that a lot of times they might be setting some goal of themselves, so bottom-up the product team has some objective, but then trying to reconcile that with other top-down management goals that might come from your CEO or other leaders, and then trying to reconcile that with other teams that you're working with. So, you've got dependencies, you've got stakeholders, and so nobody was really solving those types of problems.  

So I think what I was excited about is I think the promise of how to use OKRs in terms of trying to set an objective, and that objective being something that is inspirational and something that you ideally put a line, either up or sideways in the organization, but then being very crisp about your key result, I'm saying “This is how we're going to measure it”, I thought really a great way of breaking it down. In particular, I think part of where you get hung up in setting goals, is by focusing too much on output over outcomes, if we had a question on roadmaps we could start talking about roadmaps and how you get hung up too often as product leaders on features and output, and I think what this forces us to do is really think about what are you trying to drive. So, I think that question can be asked at a variety of level, but it can start with the product team and I think it should start with the product team, in terms of “Look what are you trying to change?”

So, building consumer products, we're trying to drive engagement, so maybe one of my teams is trying to take some number of customers that really use our product on a monthly basis, and they want to move that up over time. So that's really what you're trying to drive, and then you can start to really think about “Well what are the ways that might change the trajectory of that outcome”, and so then you can use that as a measure of, “Well maybe we could add Feature A, or we could improve Feature B”, but you're doing it through the lens of what outcome you're trying to drive, which I think helps in terms of focusing at list as to what are you working on, because if it's not driving an outcome then “Shoot! Why are you doing it?”, but also it helps you evaluate the success of those things, so as you build and launch those you can then look back and say, “Are you actually achieving it?” So having those conversations with the team to understand, “What do you say you are going to do, how did you move it?”, I think that’s all the healthy parts of that lifecycle; so you've got setting, you've got acting, then you're evaluating on the backend which should then move into the next cycle.  

I think that's what's great about OKRs; ideally, you're doing that on a quarterly basis and then you're working throughout the company. So it's something that we're now rolling out more broadly in our organization, I'm pretty excited about what it is going to allow us to do, because it puts everybody at the table, it puts your various stakeholders and different function, it puts your engineering team at the table because they've got to come to terms “Whether it is feasible in this quarter”, and then it really keeps that accountability around; “Did you achieve what you said you were going to  achieve?” 

Hope Gurion: Next, Ezinne Udueze of Bazaarvoice shares how they recently evolved their approach to setting goals and have found value in the act of crafting a strategic intent document.

Ezinne Udueze:  It's actually tied to the strategic intent document that I spoke about, so let me start off with what we used to do. We used to actually have the product managers build out what we called “Bazaarvoice Goals (BVG)”, almost like your tickets, but they would start with the bigger mission, what they want to get done and then build out tickets from that point out, and the metrics also.  But one thing was fundamentally missing and that was almost a narrative as to “Why this is the right goal”. So, as I mentioned, the product leadership team built out a strategic intent document with our executive team for a span of two, three years. Now, we have the product managers build out their own intent document; the product intent or feature intent document, and it actually is modeled after  a project poster within Jira, it's within confluence, and it just asks the questions of “What are you trying to do, why are you trying to do it?” Asking those questions, we talk about the problem space, then we talk about the customer, then validation, here is where you actually begin to tease out your risky assumption, and then I have a section called building the ready-to-make it, which is where you start ideating on how you solve the problem and you bring in engineers for this 4th section.  

The creation, and the writing, and being really intentional, and really building out a narrative of the “Why”, allows a product manager to collaborate with their peers on what they want to do and for whom, given a window of six to nine months, and what they think the work product and deliverables need to do that will drive the original objective, and when they build that out, it's then easy to write the BVG. It also is easy to create PowerPoint slides that express what your product or feature is supposed to be doing in the next three, six, nine months, and really bring your team along. Oftentimes in that process, they tease out what metric they intend to move,  some of them will be lagging, others may actually be leading, and their questions in there about “Are these measurable, what are the current benchmarks”, and that's actually how the goals are set, and then we can measure them afterward.

We've used OGSMs, OKRs, but regardless of what framework, the ‘why’, bringing your team alone on the “why”, and determining how you're going to measure, how the deliverable addresses the “why”, is what the foundation of this planning document is. So now we've got our goal.

Hope Gurion: Next, Rosie Atkins of Homebase describes how company goals are clear and measurable but that product teams need to have room for possibilities to be creative and successful.

Rosie Atkins: How do we set goals for the team here at Homebase? Again, it does go back to us interrogating the ideas and thinking about “How big and how long”, until we learn something significant about this. We know exactly how much revenue and how much customer growth we want to accomplish over the next quarter, and three-quarters trailing, frankly, after that, so all of the PM's have that overarching goal in mind. Now, not all of them are going to be taking a proportional share of that growth under their wing, so making sure that their contribution to it is significant enough is where we're sitting. I'm not in a position to say to Rachel on my team “Your job this month is to deliver 25,000 conversions into this paid plan”, saying to her “Your job this month is to find three ways that we can influence conversion behavior, and then let's put them out there and see which one is the most influential, then let's attach a metric to it”. 

Now, I know what the percent activity and the percent meaningful conversion is going to be and Rachel  does too, but it's not pinned on one activity, it's pinned on the things that we've discovered are going  to be meaningful, so she's not looking for that conversion growth in the dark, we're saying “What are some ideas that we can pursue, what's the biggest one, how are we going to figure out how to meaningfully implement this”, and then we  might have an idea; if we're seeing this many people and we can drive this conversion, here's your number.

It all does roll up to the company targets but we're a product team of five people right now, so it's really easy for us to have a universal notion of what the goals are, and just like we don't have a road map that looks out many months because we're iterating, we're also iterating on our goals and there's that explicit understanding. I think that one of the things that we only recently got good at, was celebrating when we hit those goals or when we get to a milestone. We hit a milestone yesterday in the number of schedules published in a single day, and that was the result of probably four months of  work on our scheduling product that cumulatively had this impact, and  yesterday was just an incredible day to be able to say “Look, we have this number!” And I think that if I had started somebody out, saying, “Get to this number”, that's a much more daunting task.

I think that when you attach goals to tactics, they become inherently less effective because then you're sort of a hammer and everything looks like a nail, and you get stuck in the hammer roll and you're constantly searching for nails. I think that when you set goals against bigger initiatives and bigger ideas, and you set them against possibilities, then you’re opening up any good product person's creativity; to explore, and to learn things from customers, and to learn things from data, to learn things from their engineering teams, to learn things from customer support, we have a great customer success team. If we were saying “Tell us how many people want this feature. Well this is the feature and we're just going to pour as much fuel on it as we can”, I think it becomes toxic very quickly and it becomes demoralizing. I've worked in a lot of organizations that use OKRs, and I'll tell you that very often leaders love OKRs because you think everybody is lined up, and most of the people who have OKRs consider them bullshit, and that to me is the worst thing. When I start really thinking about why, it's because you get too aligned around a tactic or a particular metric, rather than the objective part of OKR, which is a great idea.

Hope Gurion: Now, Margaret Jastrebski shares her experiences at ShopRunner and some of the challenges they ran into when adopting OKRs across the product organization.

Margaret Jastrebski: Here's what I found that works well, maybe not so well when it comes to accountability and setting goals for product folks. Where I work most recently, ShopRunner, we set in place, system of OKRs, so that's out there now in the industry, a lot of people use it, like Google, and it was like you spent about a year working through the process, so of course you launched this idea and you're like “Oh great, it’s going to work”, first time. I think we said company OKRs are really really good, and those OKRs operated at an annual level, so those  were the ones that didn't change, and then what we did was take it one step lower and bought Team OKR on a quarterly basis, and each of those OKRs were supposed to build-up to the top-level OKR. So, we, quarter by quarter, really worked at it.

So of course, the first quarter you try something, you got to refine it and see how it works, but what we did the first quarter, we took each team and had each team set OKRs; so we had Sales Team OKR, Marketing Team OKR, etc. What we realized that quarter was that it's hard to actually break OKRs apart in that way, because sales goals, and marketing goals, and product goals, were so intertwined that we started to not work in sync; we were trying to work our individual OKRs and we actually weren't working across the teams as well.

Then the next quarter we took it down, we had the whole team, so we took all of the director level teams and the heads of the various adult team set together OKR. So then we had our top-level OKRs at the organization level, and then we had probably 50 OKRs across the organization, at a very detailed level, and that really was great because then the OKR was almost the team goal and got very specific on the team goal, and then what we did was group the teams to then review the OKRs together. What I did for my areas, we reviewed them on a bi-weekly basis, and then just making sure every couple weeks by checking in, “Are we making progress on the things we laid out”, and then it was for three months’ worth of time.

So that was really great because the teams themselves were very attached to their goals and it was very clear what the expectations were for them, but there was this other missing layer in between it; we've got these top-level business goals and then we have these day-to-day, week-to-week type goals that the teams were working through, “How do we make sure to stick those together”. So that was the next iteration of trying to figure out, “Okay, maybe too many down here and not enough up here. How do we start to close that gap?” So, the teams were working through it.

It's one of those things that I think that there's always room for improvement. I also think as the company changes, there are different needs of teams shifting the goals; you're going to find things that work for you, ways that work for you. I was also thinking when it comes to goals and accountability, I think that it also depends on what type of team you've got; the product team that I managed at ShopRunner, we were a mix of, products feature team, support teams, and architectural, foundational kind of back-end team. For me as a leader, it was very easy to define the products feature team’s goals; “For this quarter, we’ve got to get this product out, for this client, with this type of performance”, very easy, I say easy but it’s easy-ish, it was articulate, you could really encapsulate it, there is start to finish, “What are the SMART goals, where there is a time-bound”, and all of those things. When it came to the architecture team, it's one of those things where there are no real endpoints; it was like all we need is to make the architecture scalable. Well, what does scalable mean? How do you know when you've got there? How do you know when you've been successful with it? So that that took a lot more work and ultimately what we broke it down into is a little bit more like “Well here is a milestone, and it's a little bit more. Well, we know that there are a handful of milestones that we have to hit and we know that ultimately these milestones together are going to make progress towards our goal”, but it was much less measurable, the milestone was a little bit more binary but the outcome  was more difficult to get our arms around. So again, it's one of the things, “Yeah, its like features. Yeah, open to the market, you can see it”, architecture, slower-moving, more infrastructure, hard to encapsulate. Ultimately at the end of the day, you just do your best, you try, and then you try again, and then you try again, and just stay focused.

Hope Gurion: Finally, Al Ming shares the critical importance of connection and commitment when establishing the product team’s quarterly goals. 

Al Ming: The way I think about how goals are set for the product team, I'm trying to  think of a good example for that, there are a couple of different layers to that; I say this a lot, this relates a little bit to the John Doerr OKR models, where you're trying to create connectivity between a team and the organization, but the last thing I want is for a team's goals to feel disconnected from the organization's goals, and that happens a lot where you have the “Step 1, this, Step 2, question marks, Step 3,  profit”. So for my teams, what I want is for them to be able to make a clear connection between those and look at the goals of the organization, look at the strategy that we've set forward in terms of the major swings that we want to take, and figure out with me what the mandate of those teams are.

So, at the time that we define that strategy, or we redefine that strategy; what is the Charter of this team? What piece of this puzzle, that we're trying to solve together, is this team responsible for? What KPIs does this team believe that they can move, that we agree will move the main KPIs?” If you are a newsletter team for example, and what you can measure and impact are opens and click-throughs, how does that relate to our goals around revenue? How does that relate to our goals around building unique visitors? What ancillary or secondary metrics can you connect back to the primary metrics that we feel good about and what part of those tactics are our mission?

So what I tend to do with my teams, like our apps teams, or our web teams, or our newsletter teams working on growth or engagement or revenue is, “What part are you? What are you trying to accomplish?” And then when we look at quarterly goals، when we look at their backlogs of both, opportunities and stories, keep that in mind, that is your goal, that is what you are trying to accomplish, and connect it to the real metrics, connect it to the work that you've done and have a little pressure on yourself, “This is the number that I am taking ownership of, I am taking responsibility for this and the work I'm doing is aimed at this”. It's very easy for product teams to get locked up in all the noise, all the signals coming from outside, all of the things people want, the backlog of bugs, and the stuff that just piles up.  One of the things I ask of them is, especially during quarterly planning, to say “I want to commit to a big effort, I want to commit to something that I think is getting..”, and big doesn’t necessarily mean it's a huge piece of work, it's a big impact, effort, something they're going to do that is going to move that needle, that’s going to be worth the time that they put into it, that's going to change things. That way, when they're thinking  about their backlogs, when they're  thinking about product discovery, when  they're thinking about what they want to  do, they are focused on that goal, they  are focused on the lever they can  accomplish, the piece of the puzzle that  they're getting after, the clients that  they're able to satisfy. And  part of that is about it being both  top-down and bottom-up, that we  agree on what the metrics are; if I give  you a metric and you don't know how to  solve, that's not going to work you're just going to assume do crazy things with that, that if we agree on the metrics, the organization  agrees on the metrics, understands, again, back to that transparency about how the  work you do connects back up to the  larger organizational goals, we  coordinate together during quarterly  planning and we say “Yes! That is awesome!  Let's go after that, that's going to be a  change to the way that we do things”, then  they know that the stories they work on,  the opportunities they pursue, the  experiments they conduct, are all driven  towards achieving that goal, and they  know that the work they're doing is  impactful, and everyone does, honestly. It all creates that loop of excitement, and passion, and engagement, and transparency. 

Hope Gurion: Setting goals for product teams is foundational for product leaders. So many companies are great about setting those higher-level company goals maybe for the quarter or for the year things around revenue like ARR or MRR or customer growth or retention goals or even NPS metrics for support teams but product leaders really need to find those leading indicator metrics that can be owned by and are inspiring for the product and Engineering teams. Instead revenue or net new customers, you might choose goals around the level of adoption or usage levels of newly acquired customers. If retention is what matters, you can identify what moment in the customer Journey really unlocks the value and has a high correlation to retention and drives lifetime value of those retained customers and measure the % of customers that reach that moment in their journey. When I’m working with product leaders who are setting measurable goals for the product team for the first time, I work with them to figure out 1) what is possible to measure 2) how does that Key Result relate to those bigger indisputable corporate objectives and then of course the question becomes have you actually instrumented the product with the analytics that need to make the Baseline and progress measurement easy for the product teams.  If you haven't done that then you're going to be faced with either making that investment in product analytics instrumentation or you're going to have to use some other either manual or qualitative calculation in the short-term. This is the type of advice that I provide to product leaders as part of the coaching work that I do.

If you are not fearlessly leading your product teams through the goal-setting that is a necessary part of outcome-focused product management, I would love to be of help to you so please reach out on LinkedIn or on Twitter.

- - -

You can find me, Hope Gurion, on Linkedin and Twitter or subscribe to “Fearless Product Leadership” on your favorite podcast platform to be notified of new episodes.  You will find transcripts, videos versions of each episode as well as more information on my Fearless Product coaching and consulting services by visiting my website, Fearless-Product.com.

Previous
Previous

S1 Ep. 10: How Do You Create Accountability for Product Teams?

Next
Next

S1 Ep. 8: How Do You Say No to the CEO?