Jeff Lash

Rahul Abhyankar [00:04] Jeff, welcome to Product Leader's Journey.

Jeff Lash [00:06] Thank you very much for having me. It's great to be here.

Rahul Abhyankar [00:09] Jeff, we both worked at MasterCard in St Louis at different times in our careers.

Jeff Lash [00:15] It's true. I will say there's a bit of a running joke in St Louis that if you've been here long enough and you work in technology, there's probably one of three or four companies you've worked in at some point. So MasterCard being one of them. Not a surprise, but still it's a small world.

Rahul Abhyankar [00:30] What's interesting about your experience at MasterCard is you maintained and ran a usability lab. I'm interested to hear about that. What did that entail?

Jeff Lash [00:43] Before I was in product management, I spent a number of years in the UX, usability space. One of them was at MasterCard. They had built out a formal usability lab with one-way mirrors and everything, which at the time was a pretty big feat.

We did a lot of different types of customer research, but specifically being able to do formal studies and have stakeholders literally walk down from their office and just sit there and see that. It was a great way of promoting the idea of user experience within the organization. This was the early 2000s, and the idea of usability and user experience was still relatively new. A lot of people thought, oh, you want to build a website or a technology product, you just have a cute looking design and have some people who know how to code it and that's all. So it was a great way to sell the concept, the importance of user experience and designing products around people.

That was really a big part of what got me eventually into product management, because at the time I saw, and I still do see, a lot of similarities between user experience and product. They are certainly very different roles with different skill sets. A lot of what helped me hit the ground running when I took my first product management job was my background in user experience and a lot of the same mentalities, the same ethos, the same idea of we need to design things that are easy to use and provide value to people. It's really the same fundamental concepts that work well in product management.

Rahul Abhyankar [02:11] And now, increasingly, there is an expectation on product managers to understand, have the sensibility of design. Talk about how have you seen the relationship between product and UX evolve over time and how can those two functions work best with each other?

Jeff Lash [02:29] I did a presentation back in maybe 2007, 2008. I think it was called "Product Management and User Experience: Two Peas in the Same Pod." I used the analogy that when I went from user experience over to product management, some people treated it as if I'm going over to the dark side, and my view is no, it's just two sides of the same coin. They go together.

The industry at large really saw these as very different, opposing forces, where user experience is about understanding users and making things that are solving needs and helping people and making lives easier, and product management is about coming up with ideas and making money. To some extent that was not good product management, and it was maybe user experience that was also not understanding that user experience lives in the context of a business environment.

Over the years they have come much closer together, and that was the argument I made then and I still stand by. Yes, they are certainly different roles, but there's a lot of overlap and a lot of collaboration. When I made the move from user experience to product management, I was the first person in my company that had ever done that, and a lot of people were like, wow, this is strange. This is not how you become a product manager. You come from technology or you come from sales or something, because those were the paths that were recognized. But to me it made a lot of sense because a lot of the same ideas were there, and I had studied business and marketing, so I had that intrinsic sense about me. It was a great blending of my user experience experience and my business mentality.

Now the expectations are a lot different and a lot closer together, which I think is great. Product managers are expected to understand a lot more about user experience, and UX people—designers, researchers, all in that encompassing—are expected to understand business aspects. The good people in both camps always have. Sometimes I see it going a little bit too far, where you have product managers that are doing detailed design and interface design, which I don't think is appropriate. I also know a lot of people in the two decades since I've made my switch that have migrated and actually migrated back. Some people who were in the UX field went to product, went back. There's a lot of people that have found that a lot of the skills are transferable.

Rahul Abhyankar [05:01] As many people in a company have product thinking, that makes the product manager's job easier. In your experience, how have you had an opportunity to build that product thinking in other functions?

Jeff Lash [05:15] Thinking back to your example from MasterCard, I was in a usability group but we had a lab and we brought people down and they would come downstairs and sit and watch. We would create summaries of customer research and distribute it.

In my product roles I used to do a thing where—in this case it was we were working on products for physicians—I would have a physician come in once a month to the office and we would have lunch and I would invite some folks from our production team, some folks from development, some folks from project management. We would literally sit around and talk with this person. Most people had certainly met a doctor before, but not in a work context. The more opportunity you give people to participate in discovery, to listen in, if nothing else at least to see the results or see summaries, that's great.

There's a big responsibility for product managers to share the context. So not just this is the project we're working on and this is the feature I need built, but what is the problem we're trying to solve? What does the competitive landscape look like? What are the challenges our people are having? Today, at Forrester, whenever we work on a new enhancement area, we always start with a brief that talks about what's the context, what's the market situation, what are the problems that our people are having.

I was talking a couple weeks ago with some folks on our technology team and I was saying, hey, I need you to review this document I've been working on, and the thing you would probably care about is on page eight, so you can just scroll down to that. And they said, no, actually we're going to read the whole thing. We want to know what the context is, but we also want to know how this is impacting our pricing strategy. We want to know how this is impacting revenue recognition. We want to know how this is impacting all these other things. They're hungry for it.

Most people don't get up in the morning and say I'm excited about just writing some code or building a spreadsheet or working in Figma. They wake up in the morning saying I want to help make people more successful, make people's lives better, solve problems. Probably 90% of the people that I've worked with over my career in design and engineering and marketing and legal—they want to understand why is it that we're doing what we're doing. There's 10% that are just like just tell me what to do and I'll do it. But the vast majority are really hungry for that, and I found that if they've been in environments where they have not had that before, when you give it to them, their eyes just light up and that's when they start really engaging. When we talk about this idea of a high-performing product team—not the product management team, but the broader team—it all starts with that shared customer understanding.

Rahul Abhyankar [07:53] The word that you use there—context—that is such an important element, because all of a sudden, when you establish that context around customer success, around business success, people can see how their work is part of that bigger context.

Jeff Lash [08:11] I distinctly remember working on a product that had been around for a long time, maybe like a decade or so, and there were some people that had worked on it from almost the beginning. We were working on a new enhancement or some changes. I said, hey, we're going to do some usability testing or concept testing and I'd like for you to join. And they said, I've never actually seen someone use our product. I've been working on this product for almost 10 years and I've never actually seen some real user or real customer use the product.

There's a lot of situations where people have never had the opportunity to do that, to see someone actually using the product. It's a great opportunity to bring people on because it doesn't cost me anything. If I'm doing a customer interview, there's no cost to have a developer listen in. If we're doing a usability test, there's no reason why I can't say to someone from marketing, hey, come on and join.

Rahul Abhyankar [09:03] In B2B, which is where you spent most of your career, and as have I as well, that context is really important, because in B2C, in some form or another we are consumers and we understand the products that we use. But we're not going to go buy an Oracle database system or a Cisco router, even though we might be working on it.

Jeff Lash [09:28] There was a great example that you reminded me of. I worked for a while managing a product that was used for recruiters—third party recruiters who were working with companies to fill jobs. I was out doing some observational research, going to recruiters' offices and watching them for a couple hours. There was this one part of the application where they were entering a new job opening or job posting. There were like 10 fields that we made them enter.

We had heard complaints from people about, oh, there's too many fields that are required. I just want to save the record and add to it later. And there was some internal discussion: well, we need all these fields, we need to know the job title, we need to know the location.

I was watching this recruiter enter information, and they got a phone call from a candidate who they had reached out to earlier that day about an opening. So they had called Joe Smith and said, Joe, we think you're the right person for this job. While they're working on another job, Joe Smith calls and the recruiter's on the phone. This is back in the old day where they cradle the phone, and they were in the middle of entering this job posting and they were trying to pull up the job posting for Joe Smith and they had to close it and delete all their data.

We could have lots of internal meetings and debates about why are these fields required, but seeing the context, the workflow that someone goes through, was huge. There are hundreds of decisions that developers make, that designers make on a daily basis, that influence the usability and the context and the experience of using the product. Understanding that context—had we known that, we would have created a different solution. Without that, you just assume, of course, someone's going to fill out all 10 of these fields.

Rahul Abhyankar [11:16] Is there anything that you've learned from your experience, that you've seen, that the way we are codifying that context could be done a lot better?

Jeff Lash [11:25] The biggest influence in that is not the tool, it's the people and the processes. That context is up here a lot of times. So the most important thing is getting it out of your head and onto some artifact. There are tools that certainly can help, but what I've always advocated for is a good tool can't fix a bad process.

A good tool can't make up for not doing discovery. A good tool cannot make up for not understanding your customers. A good tool cannot make up for not having a good relationship with the other people on the product team. The right tool can help facilitate, can streamline it, but it's not going to fix those more fundamental problems.

When I was an advisor for eight or so years advising product leaders, sure, I'd help them with recommendations on tools, but it was always, let's make sure we've got your fundamentals right. Let's make sure we've got the people, processes, roles and responsibilities clear, good working relationships. You have people with the right skills. All those things matter so much more than the tool. If you have all those in place and a tool, you are awesome, and a tool can certainly help accelerate some of those things, but they're not going to resolve fundamental gaps.

Rahul Abhyankar [12:33] That's not the high order bit. Tell me about SiriusDecisions and what was your role there.

Jeff Lash [12:39] I joined SiriusDecisions in 2012. At the time, it was a company that was focused on providing B2B marketing and sales leaders with research and advisory about best practices. There was a practice that focused on product marketing. Clients were saying, hey, you're helping us improve our product marketing function. This is great. We could also use help with product management. So Sirius made the decision they wanted to branch out into the product management space.

That was when I came on board, along with some other folks, and we built out a product management advisory service. My job there was to really look at best practices in the B2B product management space specifically—not just what are the things that people are doing, but what are the things that people are doing well. There are common practices and there are best practices, and sometimes those do not overlap. We would write research based on the practices we saw, and then we would work with clients to help them implement those.

It was a great way to get a lot of visibility into a lot of different companies. Most people who've been product managers have worked for one, two, three, maybe five different companies. We had relationships with clients where I worked with some of the same clients for two, three, four plus years, so I got to see them evolve and grow, and their product management challenges certainly changed over the years as well. It was a great experience of being able to take what I had done myself as a practitioner and then marry that with the research we were doing and the best practices we were seeing, and trying to synthesize that and assimilate it and guide our clients on how to follow it.

Rahul Abhyankar [14:16] Forrester acquired SiriusDecisions. I want to come to that, but I want to stay with this work that you did at SiriusDecisions. Let's take a client where they don't have any product management and they don't know they need product management. Were they part of your target segment or not at all?

Jeff Lash [14:38] They were typically not a client of my service, but we had other services. I had colleagues that were advisory chief marketing officers, for example, and they would come to me and say, hey, Jeff, I've got this client. They don't have product management, but they need it. I'm working with the CMO. We want you to come in and help make the case for it.

It wasn't me coming in and selling and saying here's why you need product management. It might be, tell me about your last couple of product launches. How did they go? Who is responsible for understanding customer needs? Do you have a roadmap? Who handles pricing? A lot of questions that usually would unearth a lot of issues and challenges, and we would say, based on the challenges you're hearing, here's what we see other companies doing and here's an approach you might want to take and here's the benefits of that. Sometimes they would, six months later, come back and say, hey, we hired someone or we're going to hire someone, and we'd like your help in building that function up.

Rahul Abhyankar [15:33] Now let's come to another scenario, where the client has product management as a function. Do you then get the question, hey, we don't know how good we are in this function, so help us assess our product management competency? How do you engage with that client, and how do you take them along the path of understanding or benchmarking their product management?

Jeff Lash [15:56] That's probably a pretty typical engagement that I would be involved in, and usually it was not "we don't know how well." It would be like "we know we're not doing great." Usually there's some sort of inkling that some things were not going right. Either a new product leader came in and said, hey, something seems off, or the CEO would come in, or again the chief marketing officer would be like this is not right. For whatever reason, they would usually have some inkling of a need.

With many clients, we would do that assessment. There's a couple of different things we could assess. One of the things we always looked at is what is the process? I like to use the example of, if I was a new product manager and you hired me tomorrow, you would give me a physical binder or a virtual binder that described a whole bunch of stuff. What are my job responsibilities? Do you have that documented? How do you describe product management? If my responsibility was to bring a new product to market, would that binder detail all the steps that I go through? Is that consistent for every product manager or does it depend? Sometimes we would just ask those sort of questions. Job responsibilities would be one thing. Process was a big one, because process starts to get at: are there breakdowns and activities not being done or skills that didn't exist?

Then we also look at competencies. We had some models looking at what are the competencies that we expect a product manager to have across the whole product lifecycle and what are some of the different levels of competency. Maybe an entry-level product manager we don't expect to be an expert on portfolio management, but your VPs we certainly do. We would marry that with also not just taking their word for it. A lot of these were self-assessments, but we would also ask questions. If someone says, oh, our product managers are best in class at user personas, I would say great, can you show me the example? If they can't show me an example, then it probably means they're not best in class. Or they show me the example and I say, oh, that is not good. From what I've seen, I would not consider that best in class.

It was a lot of self-assessment, but certainly we'd check on that. Although interestingly, I do find a lot of people are pretty honest. We'd also ask other people around in the ecosystem. It was always interesting if we said, hey, how good is product management at roadmapping? And they would say, oh, we're awesome at roadmapping. And I'd go ask portfolio marketing or sales or development, how good is product management at roadmapping? And they'll say, oh, I've never seen a roadmap. Okay, so that either means they're not doing it or they're doing it and not sharing it with you. Either one of those, depending on the answer, is an interesting thing to learn.

We would do a lot of projects where we'd do some or all of those assessments. That provided us with really good visibility into the state of the organization. It also sometimes was helpful to put some third-party objective data behind what a lot of people felt in their gut. Sometimes a new product leader would come in and say, yeah, this team is good in some areas but not performing well in others. But I want to validate that it's not just me. Also, if I'm trying to make change, I need some support and evidence to make that change.

Rahul Abhyankar [19:22] Would you get questions from clients along the lines of, what does best in class or good look like, and how would you answer that question?

Jeff Lash [19:33] There's definitely differences in companies. What good looks like for a 50-person startup is different than what good looks like for a 100-person hardware technology company versus a service company. There's certainly some differences, but there are some fundamental things we looked at. That's usually what we tried to focus on—the core.

For example, in our competency assessment, it wasn't just rate your competency as a one to five, but there would be specific examples. At a level four, we expect to see this. At a level three, we expect to see this. So there was some context. People say, I thought we were actually really good at doing customer research, but now that I see what a level five is, I realize we're actually not. We're more at a three than a five.

Part of what we do—a lot of our research is based on the aggregation of all the different companies we've seen. I think that's one thing that people appreciated. Even people who've been, like yourself, in product management for 10, 20, 30 years, they have a lot of experience, but they are by their very nature limited mainly to the companies they've worked at. We had this unique view of a couple analysts on the team and all the companies we've worked at plus all the companies we're working with. I also talked to a lot of non-clients. Even helping out on sales calls or being involved in other research projects where we do research with non-clients, we got a chance to see a lot of variety.

I got to the point where usually there were about three or four questions I could ask that would tell me where they were. People would say, wow, how'd you know that? Based on their answer to their question, I'd say, I'm guessing you have a lot of former engineers that you made product managers. And they're like, yeah, wow, how did you know that? It wasn't 100% foolproof, but 90% of the time we get pretty good at diagnosing those sort of things pretty quickly because we saw a lot of the same patterns.

Rahul Abhyankar [21:31] How long would an engagement with a client be where you've done their assessment, you've understood and helped them understand where they are, benchmarked vis-à-vis best in class and your methodology, and then helping them along the way? What would that engagement look like post that assessment?

Jeff Lash [21:56] A lot of it really depends on how big the organization was. If it's a product team of five people, they can make change a lot quicker than a product team of 100 people. How quickly the organization was willing to move, and also how many other things they had going on. If this was the number one project, they could devote a lot of time. But if it was, oh, we're trying to do this and these five other things and we acquired a company and we're moving from on-premise to cloud, it just depends.

There were some clients where we worked with them for multiple years, and it wasn't working on the same problems. I can think of one client where they had five different business units. We started working with one business unit doing this sort of work, doing an assessment, doing some workshops with them, then on a regular basis interacting with them, making some change. Another business unit saw what they were doing and said, hey, that's going pretty well, can you help us? So we started working with them. About a year later they said, hey, we need to tackle this globally, for all of our business units rather than just one at a time. That lasted over the course of a couple of years. Now, it wasn't every day eight hours a day, but we were working alongside a lot of their leaders.

A lot of times it was tied to a business initiative that's already undergoing. Sometimes it is, we need to do an assessment. Sometimes it's, hey, we have a new product that we're trying to launch and in the context of that, we need help with a best-in-class approach to pricing. Or it's, we just acquired a company and we need to rationalize our portfolio. Along the way we'll learn a good portfolio rationalization process. There were a lot of projects where I worked on these big assessments, but a lot of it was much more around: we've got this business priority and we need help. Teach us how to fish and also help us catch some fish along the way. Usually they might start with one specific problem and then expand from there.

Rahul Abhyankar [23:58] Forrester acquired SiriusDecisions. What is the product at Forrester, or products that your team is managing?

Jeff Lash [24:07] When SiriusDecisions got acquired, I stayed in my current role for a little while and then I made the switch from being a research director to running our product. All that advice that I was giving to other people and telling them what they should do, now I'm trying to follow that advice myself. We like to say we try to drink our own champagne, and I use a lot of the research that I wrote on a regular basis as a product leader.

We have subscription services. We have a lot of different products. A core part of our offering is services that are designed for technology, consumer and digital, and B2B marketing, sales, product leaders to help them improve their performance. We also have services that are designed to give people insights into the market. If you're a security software company and you're trying to understand the security software market, your competition, the needs of your customers, we can provide you with that insight on what those buyers, consumers, competitors in that market space are doing.

A lot of what we do is subscription services. It's an interesting mix because it is a combination of really three basic things. There is the intellectual property, the research that we are creating. There is the digital platform that that research is delivered through, as well as a whole bunch of other value-added features. We just released a Gen AI tool as part of that. We also have peer discussions and webinars and certification and a whole bunch of other things that are available through the digital platform. Then there's also the human component, which is unique—clients not only have the ability to read the research and access it through our digital platform, but they have the ability to talk with a human being. It's partly a SaaS product, partly information services, but partly a services product. Those are the products we're managing. We have a number of other products as well. It's an interesting mix of both technology product management as well as service management, service delivery.

Rahul Abhyankar [26:07] Overall you are anchored around a set of problems that you need to address for your customers, and then the solution or the offering is a combination of this digital platform, services, advisory, or events like webinars.

Jeff Lash [26:23] When I came into my role, we had a lot of people that had been doing product things scattered across the organization. We pulled them together in a product organization and I was trying to figure out what's the best way to organize the team. In a traditional environment, you have, oh, we've got a product for educators, we've got a product for students, we've got a product for administrators, so we're just going to have different product managers like that.

In our case, we do have products designed for different personas. But really the difference is the research you get access to. Are you a security and risk leader or are you a demand marketing leader? What you get as part of those services is the same as just intellectual property, the content, the area that the analysts are talking to. So it didn't make sense to structure our team on that, because so much of what we do is shared.

We actually have the team organized around needs. For example, one of the needs is around clients wanting to get access to our research. Another is, I want to enable my team, I want to enable my organization. Another is, I want to get an in-depth view of my market. Our digital platform serves all different personas, all different types of clients and needs, and there's shared functionality. I have the folks on my team organized around those customer needs rather than the different products, because otherwise we would just be bumping into each other all the time, because a lot of the features that would benefit a technology leader are the same features that will benefit a marketing leader.

It was an interesting change, but it's worked well, and it's also centered the team around—and the rest of the organization around—this idea of, yes, we're managing products, but we're really focused on customer needs and addressing those needs.

Rahul Abhyankar [27:59] In most companies, product managers are assigned products and then they can look at continuing evolution of that product, the roadmap. There is simplicity in that approach. But now what you're saying is you've organized the team around customer needs. On the back end that may translate into two or three products that come together to address that need.

Jeff Lash [28:22] Absolutely. There certainly are situations where there's this need and this product just addresses this need. There's a one-to-one alignment. But there are certain situations where one person on my team is responsible for the customer need of access to research. We have 15 different services that provide access to research, so that's a need that cuts across all of them.

To be honest, it was maybe a bit of an adjustment for some of the folks on my team because that was new, but they, to their credit, went into it with open eyes and open arms, and I think it's worked really well. There's still areas where there's overlap and there's a lot of things where it's like, whose area does this sit in? But to your point, it is not where I'm saying, hey, you're managing this feature, build this feature. It's you're responsible for this need, which really gives people that context of, your job is to solve this problem. We have some existing products that solve this problem, but do we need new products, or maybe changes to products? Or maybe we have too many products right now to try to solve this problem, so we need fewer products. It's giving people a little bit more open space rather than just "make this product better."

When I've been in environments where that's been the case, sometimes you end up getting a lot of infighting because, in a B2B situation as we are and a lot of listeners are, there's a sales organization that you sell through. That is the channel, and there's a limited mind share and bandwidth. What you don't want happening is product managers fighting other product managers for that sales bandwidth, because if I'm responsible for product A and you're responsible for product B, I want my product to sell, you want your product to sell, so we're going to fight over who gets sales attention. That's not a good situation to be in, because maybe the most important product for the company to sell is product C.

This has also helped. I'm not going to say that we've completely fixed that problem, but it's helpful because we have this context of what is really the best thing based on our company strategy, what is best based on the customer needs. We try to make sure that we have appropriate understanding of where all the products and needs fit in.

Rahul Abhyankar [30:19] That's very interesting. Do you see any areas of confusion here? Let's say I'm a salesperson hearing some feedback from clients about a specific product, but I don't know who owns that product, because now product managers own customer needs. But I need someone who owns this specific product because that's where that product needs to get better. As a salesperson, who am I going to?

Jeff Lash [30:41] To some extent, I don't want you as a salesperson worrying about that. I don't want you spending time trying to find the right product manager. I want you focused on selling. But that's what happens.

Rahul Abhyankar [30:51] Those are conversations that happen in companies.

Jeff Lash [30:54] We years ago set up a pretty good system for collecting ideas and collecting feedback. If they happen to know the right person, they can go to them, but if not, we have an intake way of collecting that, evaluating it, routing it to the right person. There are certainly some products we have that are only sold by certain teams or in certain regions or situations. So there's definitely that alignment, that affinity there.

One thing I learned years ago is in B2B we're not creating products for one specific customer, we're creating products for many customers. If one sales rep hears something from one customer, that's mildly interesting. But if a sales manager says, hey, the five people on my team have heard this from a bunch of different customers, I'm much more likely to pay attention. Not that I don't care about customer feedback, but we just don't have the bandwidth to respond to every single piece of feedback from every single customer. We want to be focusing on the problems that are widespread, that apply to a lot of customers in our target market.

That's where trying to look at what are those things that are coming up over and over, and that's where we rely on individual salespeople and CSMs, but also we rely on the leaders of those teams to sometimes say, hey, here's what we're hearing broader. So back to your point, I was half joking that I don't want salespeople to know, but they do know. They do know the things that come to me versus come to someone else. We still kind of encourage them—yes, we want all feedback, but I don't want you worrying about who owns it. I want you providing the feedback and we'll worry about who it goes to.

Rahul Abhyankar [32:20] I'm very intrigued about this model that you have implemented, which is assigning customer needs to product managers. I think that opens up the horizons for a product manager, because now they are responsible for the need now and into the future. For leaders who are listening to the conversation, how do they make the switch to say, I'm going to anchor my product management team on customer needs rather than assigning somebody a product to manage and own?

Jeff Lash [32:44] The first thing I would say is, this idea was based on some research that I wrote when I had my prior role. We have a research report on different ways to organize product management teams—organizing by product, organizing by technology, organizing by customer segment, organizing by persona. There's different ways to do it, and in that research we talk about when each is appropriate. I'm not by any means saying this is the model that everyone should follow. In our situation we evaluated the different options and this we thought would work best, and so far it's worked well, but it's not going to be appropriate for everyone.

In many cases you may find people are kind of already doing this. You might have product managers responsible for certain products, but those products roll up to a group PM or a director or someone, and you might say, well, that person's responsible for the teacher products versus the administrator products. Well, is it really teacher problems or what problems are those products solving? There might be, as a first step for some people listening, are we actually already kind of organized this way already, but we're just talking about it differently? Maybe by saying, hey, instead of you're responsible for the embedded reporting product, actually you're responsible for the citizen development report generation need, or something like that.

There might be ways to, rather than make a complete 180, just say, how can we take what we have today and structure it? It also might be something where you can say, look, in some areas we want to structure this way, in some places we don't. You might say, hey, we still need a person managing this product because this is an important product and it makes sense, but in the other part of the organization it makes sense to structure it differently. In fairness, that is—I mean, we kind of do have a little bit of that. There are some people that very much focus on a specific product, but even then we're talking about it in the context of these needs.

Rahul Abhyankar [34:21] How do you then measure success? For a product manager who owns a product, product revenue, performance of the product—those are well-understood metrics of how you can define and measure success. But when you have a product manager who's responsible for a customer need, how would you and the product manager both look at how are we going to define whether I'm successful in addressing this need or not?

Jeff Lash [34:47] It is more challenging. It's not as straightforward, but I think it's a good thing. We do have some shared goals, so that everyone on the team—my leadership team—has certain goals that we're all looking at meeting. There are revenue bookings numbers for the portfolio overall, there are retention numbers, and things like that.

We talk about metrics in different levels. There's impact metrics like market share and profitability and revenue, but there's also output metrics—one level down. Outputs lead to impact. We can look at—we use a thing called CX Index or Net Promoter Score, things like that, on aspects of the product. Not just how often did they use search, but how happy were they with finding information in your product. Or looking at usage as a proxy. Then there's lower level, which is activity, which is how many times did people do certain things.

When we look at metrics we always make sure they ladder up, because if we're just looking at revenue, that might be a lagging indicator in an organization that has a six-month sales cycle. But I don't want to just focus on the activities, because then they might be doing their activities but I don't know if it's providing that impact. It's a little more complicated. To your point, you can't just say, here's your number. But when I've been in situations where people have that number, they sometimes laser focus on that at the expense of other things. Yes, you hit your number, but you did it by bullying other people, or you overachieved your number, but we actually ended up losing revenue because you cannibalized from another product. The standard model of product revenue isn't perfect necessarily either.

Rahul Abhyankar [36:21] That's interesting to think about, certainly. For your product management team, what sort of rituals do you follow? End of quarter, beginning of a new quarter, give us a sense of that.

Jeff Lash [36:32] Certainly a recap of what happened last quarter. What were the outcomes? Those impact metrics that we're looking at. Did we achieve the things we had said to do? Looking at our roadmap—but we're constantly doing that, so we're not looking at it just once a quarter. We're looking at what did we plan. We get a lot of feedback throughout the year just in terms of how sales is doing, how retention is doing, what we call our CX Index, which is a customer satisfaction measurement.

We at Forrester have corporate objectives. Every year there's the three or four company initiatives. How well are we doing on those company initiatives? Which ones do we as a team need to maybe double down on the next quarter or the next half of the year? Not that we would ever really take our attention off of them, but hey, we're doing really well on number one, but number three we're a little bit behind, so we should focus there.

I did put a thing out on LinkedIn, probably on July 1st: look at that document you put together in January that said this stuff would happen in Q2. Did it actually happen? Look what your roadmap says is on the calendar for Q3. Is it still there? Just kind of regular introspection and review is good.

Rahul Abhyankar [37:39] I'm looking at the wall behind you there, Jeff, and you have a banner that says "measure twice, cut once." Tell me about that.

Jeff Lash [37:50] I was in Nashville a couple of weeks ago and I was at a print shop and I got it. I really like it. This usually rotates. There's probably some product management metaphor I could draw, but I will say that's not why I bought it. I just thought it was funny and looked cool.

Rahul Abhyankar [38:02] This aspect of taking product management everywhere with you—what other areas of life do you see your product thinking permeate outside of work at Forrester?

Jeff Lash [38:15] The biggest thing over the past couple years is I've gotten really big into pickleball, which I think a lot of people have gotten big into pickleball, both playing it and actually I started coaching pickleball. I got certified as a coach two years ago. I do some coaching on the side. Part of that was because I've always loved teaching other people. As an analyst I got to teach and guide and coach and help. I enjoy doing that. I also feel like I learn a lot when I teach. It helps me reinforce things in my own life.

To put on my product management cap for a while, it's a large and growing market. I thought, from a total addressable market situation, I can only see it growing. Even in the year and a half since I've been teaching, it's been growing like crazy. I thought this is a good time to get into it. I don't know what the future holds for it with me, but in a good week I'll play once or twice a week and I'll coach once or twice a week. I spend all day, most days, inside in front of a computer, so it's nice to be involved in some sort of hobby where my phone is down, I'm not looking at gadgets, I'm outside usually, and getting some exercise as well.

Rahul Abhyankar [39:24] That is very cool. A couple of product management principles that you've applied there. It's a big market, growing market, within reach, so you have access to that market, and you have uniquely differentiated skills in terms of your certification to be able to serve that market. That's awesome.

Jeff Lash [39:52] Yeah, and it's interesting. I've met a lot of people through pickleball that are also in product, or I've met through work. The pickleball business itself is booming—the number of companies that have started up, on the coaching side, facility management, equipment. I'll keep my work life and my pickleball separate, but at some point, like I said, I can only see it growing. I felt like it was a good thing to try to do, and some good connections I've made on the pickleball court.

I actually read an article last week—they're saying for a while it was the golf course that was where all the business deals were happening. Then surfing was the big thing, surf meetings rather than that, which being in a landlocked state, you can't really take advantage of. Now apparently it's pickleball. I'm sure in a couple of years it'll be something else, but for now it's a nice thing to do on the side.

Rahul Abhyankar [40:33] Fascinating. Great. Well, Jeff, thank you so much for taking time to be on Product Leader's Journey. Really enjoyed this conversation, and you've shared some really intriguing aspects of product management that are worth reflecting on and understanding more. Thank you so much.

Jeff Lash [40:48] Thank you very much for having me. I really enjoyed it. I appreciated it, and thanks for the opportunity.

Rahul Abhyankar [40:53] Hi there, this is Rahul Abhyankar. Hope you enjoyed listening to this episode. You will find the notes at productleadersjourney.com. Subscribe to the podcast, and if you like it, share it with your friends and colleagues. See you soon.