Brought to you in partnership with
The AI platform to help teams aggregate, search, and synthesize customer feedback. CustomerIQ aligns teams with insights from channels like CRM notes, surveys, support tickets, and call transcripts, to help drive retention, product improvements, and revenue. Align every team with the needs of your customer and deliver an exceptional experience with one powerful AI platform
Learn more here
For years, Forrester has been a trusted source for business and technology leaders worldwide to drive growth and innovation.
The company's insights are derived from extensive annual surveys involving over 500,000 consumers and business leaders worldwide, underpinned by rigorous and objective methodologies.
Forrester generates around $500M/yr offering a range of services including research, consulting, and events, with headquarters in Cambridge, MA, and London, along with North American offices in McLean, VA, and New York, NY.
Today we’re sitting down with Jeff Lash, Forrester’s VP of Global Product Management, to learn more about how Forrester builds product.
Here’s what we covered:
- Structuring teams by customer need
- Using sales to test products in-market
- Tracking initiatives vs OKRs
- Coordinating with CSMs for customer feedback
- The unique relationship with sales in enterprise PM
- Appreciating the complexity in product marketing
- The importance of subject-expertise in niche markets
- Oreos and New Orleans’-style funerals (if that’s not a teaser we don’t know what is)
Please enjoy our conversation with Jeff Lash.
•
Walk us down memory lane, how did you get to today?
My journey began when I went to school for marketing – this was just before the first dot-com boom, so while I was in school studying “traditional” marketing, I was really intrigued by the Internet economy technology. Believe it or not, I began my career when HTML was a prized skill and those who set up the Apache server also handled graphic design. I worked in web design and development for a while, though I realized I was not a great graphic designer or programmer.
But, I realized I was good at understanding user needs and making websites easy to use, and it was then that I found my passion for user experience and information architecture, and that was my focus for the next six or seven years. Working alongside product managers, I started to see how they shared my focus on user needs and creating valuable products. I realized that if I wanted to make the products better, I would likely have more impact in a product role.
So, I took up a role in product management at the company I was with at the time. In a month or two, it just clicked. It was a combination of the marketing concepts I studied in school, the tech background I had from growing up around computers, and my UX skills. Since then, my focus has been on product management – as a product manager, and as a leader of product management teams.
In 2012, I joined SiriusDecisions to work as an analyst and advisor, helping B2B companies improve their product management practices. After SiriusDecisions was acquired by Forrester, I transitioned into a role where I'm running the products for Forrester, and now, I'm following the very advice I gave my clients. It's been quite a ride!
How big is the product org and how is it structured?
The product organization I manage is rather unique and exciting with about 30 individuals divided into various teams, with the structure being quite diverse. We have traditional product managers, but we also have people who are responsible for the operations and fulfillment of our products, and we also have people people in client-facing roles – for example supporting learners when they are taking part in our Certification, or working with clients of our Forrester Analyst Relations Council
In terms of those occupying product management-type roles, we're looking at roughly 10 individuals. And we're responsible for much more than just the Forrester digital platform; our services include access to analysts who are experts in their fields.
Let's say you're a chief information security officer, and you're a client. You get to use our digital platform to find research on security best practices and trends. You've got access to collected data from our numerous surveys about the happenings in the security and risk market. We also have webinars, peer discussions, and more, all accessible through our digital platform.
Furthermore, you can get direct advice and guidance by speaking with experts from our team. If you're attempting to implement something like 'Zero Trust' at your company, we connect you with our in-house experts to guide your journey. This approach is part of our ongoing relationship with clients.
So, essentially, while we offer a digital product and platform, there is also a significant human component, making us more than a traditional SaaS or information services product. Particularly, our human touch defines us - we firmly believe in being on your side and by your side.
How is the team structured?
A traditional approach to structuring a product management team would be to say, for example, I have four products, so one person will manage the first and a different person will manage the second, and so on. But that's not the way we operate, since most of what we're delivering is shared. For instance, we have a digital platform that is used by nearly all of our clients, and it supports over a dozen different products. It wouldn't make sense for each product to have a different product manager who is trying to add new features to the digital platform – users of all of our different products use a lot of the same digital product capabilities.
So instead, we decided to structure our team based on customer needs, which, from what I’ve seen, is a pretty unique approach but has proved highly effective. We outlined and identified specific needs that our clients have. For example, they approach us because they want access to our research or they want to connect with our experts. Additionally, we also take into account unique needs for certain market segments we cater to.
Then I aligned the product leaders who report to me around each of those needs. Each leader is accountable for a need, and each need in turn aligns to some specific products and services. Although there's some overlapping, this system also provides a clearer picture of who's responsible for what. It's been great because it clearly defines the roles based on the customer needs, not based on our product architecture or our technology stack.
So rather than having product management focused on owning a particular technology platform or SKU, they are focused on a customer need. This also allows team members the freedom to determine how well we're meeting those needs and what we can improve. Rather than being confined within the boundaries of a specific product, it encourages them to think about what new products, projects, or anything else that might be necessary to meet those needs.
What is the ratio of engineers to PMs?
It’s interesting, I don’t really think about that too much because so much of what we do is not just technology development, it’s people-powered services too – so other resources from other functions are key when we think about capacity or bandwidth. For engineers, we’re probably somewhere around 7-8 engineers per product person on average. And then, on top of that, we have what we call our 'digital experience' group, or DX. In this group, we have a mix of UX designers and user researchers. For every product manager, we probably have approximately have 0.5-0.75 of a DX member.
How far out do you plan?
Over the past couple of years, there have been times when we were planning major initiatives like a new product launch, and we were well over a year in advance. During that period, we knew exactly where we were going and weren't doing much else besides that. After the launch, our approach was a bit more flexible. We certainly had a plan, but we also wanted to leave space to adapt based on what we were hearing from the market.
But we're also trying not to plan too far out because you know, we want to remain flexible. For example at this time last year, there were a number of things that weren’t on the roadmap that we ended up delivering – a new capability leveraging GenAI, for example.
So, I think there's a balance. You don't want to be in a position where you have no idea what you're doing next week, but you also don't want a roadmap that's set in stone for the next 18 months. I think we've been doing a good jobof facilitating this balance and also conducting more in-market experiments.
This is something I've introduced where we pilot an idea quickly, let the sales team try selling it, and depending on the results, we either formalize it or learn from it and pivot. Sometimes it works great, and other times we say , 'Thank goodness we didn't invest too much time in that!' So, the planning timeframe is kind of a moving target, one we're always adjusting based on many factors.
What percentage of ideas come from top down and what percentage come bottom-up?
I would say that the majority of ideas are bottom-up. Take GenAI for example. It came about because of a directive from our CEO, but the bulk of the ideas about how to leverage GenAI came from the product manager and designers and engineers who were assigned to the project, as well as input from others across Forrester My team and I aren’t just tucked away in a back room hatching ideas out of nowhere. A lot of our process is driven by feedback we receive, sometimes from our Customer Success Managers or sales team, but more often from direct customer research or quantitative data we’re gathering. Basically, we're continuously weaving in what we hear from the market into our work. So, most of the innovative ideas are bubbling up based on what we're learning from customer experiences and trends in the market.
Do you use OKRs?
We're not currently using OKRs in the formal sense, though we use a similar approach.
At the start of each year, we set out initiatives that are based on the company's strategy. As a product team, we then break the initiatives down. Some initiatives, like HR or employee experience, are ones that we're a part of but do not lead. Other initiatives are ones we'll play a heavy role in.
From there, we determine the projects we want to undertake. In most cases, there are metrics around these initiatives, so we're not entirely devoid of the OKR structure- we've just modified it a bit. Each year we tweak based on what we learn works and what doesn't.
We follow a monthly routine of producing a set of key performance indicators (KPIs) that tie in with our big initiatives. For example, if our initiative is to improve retention, we put together various retention projects and track related metrics – not just how we’re doing on retention itself, but also leading indicators that can help us understand if retention is likely to increase in the future
For instance, in the case of any SaaS product, user logins and usage are key factors of retention. If no logging in or usage is happening now, it likely foreshadows a risk in renewals later. But beyond that, it’s not just if people are using it, it’s how they’re using it – there are certain types of activity and engagement that are better than others, and it’s important to understand potential correlations between what we call “activity metrics” and the higher level “impact metrics” like retention and revenue.
How do you track product usage?
Over the past two years, we have implemented a few commercial off-the-shelf tools specifically for product analytics. Earlier in my career, I felt like a lot of the products were designed more for e-commerce or public use rather than to help understand usage and analytics within a logged-in, paid-for product. In particular, we have a digital analytics platform that we use for most of our general usage tracking and analysis, and we also have a tool we use for product engagement and digital adoption.
Now, the unfortunate truth is, a lot of it does involve manual work In part that’s because as I’ve mentioned, a lot of the value of the client experience is not based on what happens through our digital platform, and we have different systems that track those interactions. But the redeeming factor here is that we do collect a lot of good records and can connect some of the dots. For instance, we can track that a certain client communicated with an analyst on a Monday, logged into our platform on Tuesday and downloaded some research and then registered for a webinar, which they then attended the following week. A lot of tracking, as it turns out, is down to good old elbow grease like spreadsheets and CRM reports. We supplement these manual efforts with some of our off-the-shelf tools to glean an understanding of product usage.
How do you manage customer feedback?
Like most companies this is definitely a challenge. When I started there was really no process at all, just emails and one-off comments. So we've implemented a formal idea collection process where salespeople, client success managers, and really anyone within Forrester can pass along customer feedback or a feature request. We also have the option for clients directly to provide feedback within our digital platform, and we do a lot of proactive outreach too – regular client surveys, or asking for feedback after a session with an analyst. That's where a lot of feedback comes through initially.
Like many companies, we still struggle with handling feedback from various places. But we've found that rather than trying to collect every piece of feedback, we focus more on themes we're hearing or areas we're looking into. A prime example would be when we were trying to migrate clients from our heritage products to our new product portfolio. We knew there were some cases where migration was easy and some where it was challenging.
We focused our feedback collection on understanding why these challenges were happening. So I wasn’t worrying, "How do I gather and track and respond to every piece of feedback from any client." Instead, my focus was on understanding what we were hearing in these challenging scenarios. This involved talking to those clients and account teams, and looking at relevant data.
Years ago I read something I still remember: one school of thought is to collect every piece of data and go through it, and the other is, "If it's important, we'll hear about it again." My team talks to customers all the time. We have another team doing 'voice of customer' research, and researchers in the DX team. So while we do have a lot of mechanisms to keep our ears to the ground and not miss anything, , we’re generally more focused on the things that are bubbling up the most and dealing with those.
Do you have a regular practice for synthesizing feedback from teams?
Yes, absolutely, we do have a regular practice for synthesizing feedback from customer-facing teams. For example, within my organization is a team responsible for our Certification product and team team is constantly interacting with people who are undergoing the certification process, as well as with sales and account teams managing client relationships. So, they’re really in touch with what's happening on the front lines and getting a lot of customer feedback that way, and there’s a pretty regular practice of synthesizing that feedback and acting on it.
We also have a dedicated voice-of-customer team within our marketing organization. This team carries out traditional voice of customer research and we work with them to also lead specific focused studies if needed.
Another unique aspect of our business is that we have analysts who are in constant conversations with clients, and they serve as an additional source of valuable feedback. While we still conduct our own interview and primary research, these conversations allow us to gauge what's happening in the market on a daily basis.
How do you manage feature/project rollouts with other departments??
We really leverage our close working relationships with our portfolio marketing team and our sales enablement team. Both these departments are set up based on Forrester research about what good product marketing and sales enablement look like.
Interestingly, for us in product management, the relationship is not just with the engineering and design team-- even though those connections are crucial-- but also significantly with marketing and sales. I would say my team probably works more closely with marketing and sales than with engineering. This is important because as much as we can come up with the best idea in the world, the fact is we rely heavily on a direct sales force-- given that we don't use an e-commerce model or don't necessarily have a product-led growth model.
Given the nature of our subscription-based product, many of our clients are in multi-year contracts. We’re not waiting for the contract renewal to show value, we’re really focused on adding value and raising awareness of enhancements and improvements to make sure people can immediately benefit from it.
We use a system called Launch Tiering – this is based on some of our own Forrester research. Every new product or change or enhancement is classified into one of five tiers, with Tier One being a significant announcement that might get discussed on our earnings call, all the way down to Tier Five only garnering a mention in a weekly sales newsletter. Each tier has pre-defined activities, deliverables, and recommended resources.
The importance of this system can't be overstated. It's almost like an air traffic control for our roadmap, making sure all the upcoming projects have the necessary mechanisms in place for a successful launch. This way, we avoid situations where we create an excellent new product or capability, and then it doesn’t meet goals we outlined for it because the launch was mishandled.
It's like if a tree falls in the forest: if we spend a lot of time and energy to launch something, but no one even notices, does it even happen?. Thankfully, with our present system, that happens a lot less than it used to.
What do you think is unique to B2B product management vs B2C?
In my perspective, B2B product management, particularly when sold to SMBs through e-commerce, can resemble B2C. However, when it comes to enterprise sales and larger dollar amounts, the process vastly differs from consumer-grade scenarios. The nature of sales plays a significant role. Even if product management creates an incredible product, if the sales team isn’t on board due to how they’re incentivized and compensated, there will be resistance.
I’ve seen this in previous roles - sales team members refusing to push a product because it was not as profitable to them as others were. Another notable difference I see is the speed of changes. As much as we try to speed up our operations, our customers cannot adapt to rapid changes. In one of my previous roles I had a customer base that couldn’t handle the idea of monthly product updates; that was just much too frequently for them to process and adapt to them, and even quarterly was quick for them.
However, things are changing slightly, and parallels can indeed be drawn between B2B and B2C environments. But the complexity and the ecosystem of involved parties often make B2B deployment a more complex process.
At Forrester, for example, when we onboard a new client, it’s not just onboarding them with access to our digital platform; we can’t – and don’t – just send an automated email with their login details. We have a kickoff meeting where we understand the client's objectives and initiatives for the year These initiatives and outcomes then get captured within our product, and we provide recommendations on the activities that we can work with them on to help them achieve their goals. There was certainly design and technology work that needed to be done to enable this, but the bigger lift was that there were people involved with this – our Client Success Managers, who coordinate the relationship with the client, and the analysts from our Research team, who are providing those recommendations.So here, the complexity here was not in the technology but rather in internal process changes This is why I think that while there’s a lot that’s similar between B2B and B2C, there’s a lot related to how we develop, launch, and operate products that will be different in more ways than people might think.
Tell me about the role sales plays in enterprise B2B product management?
There’s a few key elements in the role that sales plays in B2B product management, and a lot has been said by others already about this – sales asking for a feature they need to close one big customer, while product management is trying to create products for lots of customers. But one important aspect of working with sales in B2B products isn’t talked about as much, and that’s getting the mindshare of sales.
In my current position, the products my team andI manage are the main ones sold by our direct sales team. In previous roles, I’ve sometimes managed products that were just one of 10 or 20 different products that could be sold by our sales team, creating a real mindshare game.
I mean, I didn't want them to ignore the other products, but I had targets to hit too, right? Therefore, getting people excited about my product and facilitating its sale was a substantial part of my role. I used to think of it like this - if a salesperson had an extra hour, I wanted them to choose to focus on my product.
To do that , I had to make selling my product as straightforward and efficient as possible since any barriers or complexities could mean that the salesperson just decides to spend time trying to sell a different product. I spent a lot of time working not just to improve the product but also to help sales understand it, help make it easier to explain and sell.
It's a different game than simply releasing a product and waiting to see who signs up for a free trial.This is where sales become paramount in B2B product management. It becomes about how to make it easier for sales teams to sell the product effectively when they do secure that meeting with a potential client.
What’s something unique or central about your approach?
One thing I firmly believe now that I didn't 10 years ago is the depth of complexity involved in product management. In more straightforward environments, you might think it's as simple as doing some customer research, creating a product, launching it and expecting success. Yes, those are crucial components, but there's so much more that happens along the way.
I was an analyst at SiriusDecisions and then Forrester for about eight years, and I had the chance to collaborate with and learn from with some of the brightest minds in B2B marketing and sales. That experience gave me a vast education in things like working with ecosystem partners, best practices in demand generation, marketing operations, and sales enablement. So, I've developed a considerable appreciation for all these nuances – there’s a lot of focus in product management on working with engineering and design, which is important, but alignment with marketing and sales is just as important (if not more) and that doesn’t get nearly as much attention, but it’s something I’ve been really focused on.
Moreover, my approach to product leadership has also evolved. I’m continually reminded of the importance of focusing on the big picture and reminding my team of that – ununderstanding our client's needs, coming up with potential solutions to their problems, and focusing on the outcomes that we want to achieve
Also, even though we operate in a B2B environment, we are doing a lot of live, in-market experiments, which I think a lot of people think are only possible and applicable in B2C environments.For instance, we recently did an in-market test, where a version of our product was only available for sale by a specific group of salespeople, and we decided whether to roll that product out to the broader market based on the success from that pilot and comparing their results to others.
Experimentation is often talked about in terms of digital A/B testing of different page designs or call to action copy, but we’re genuinely testing real product differences in the market under complex circumstances. So instead of arguing about which idea is better, more often, we’re testing ideas with real clients and prospects. I'm proud that we've managed to incorporate these sorts of methodologies into our operation. The key is learning to question ideas and test them quickly, and accepting there's a risk of being wrong – but we’d much rather learn that before we get too far rather than invest a lot of time and money in an unproven idea.
What do you look for in product hires and what does your interview process look like?
When it comes to product hires, I would say our approach is somewhat unique. A lot of my team actually came from other parts of Forrester. While we have hired people with previous product management experience from other companies, that’s not the background of the majority of my team.
That's not to say we sought out blank slates - everyone we've hired is very experienced, just not not all of them came with deep backgrounds in product management. There of course has been a learning curve for some in terms of basic product management concepts, but it has the benefit of the team having expertise in the personas we serve and their needs, and also not having preconceived notions about what product management should be.
When we do hire, we look at how a candidate can complement the existing team. For example, when we were hiring for our Certification product, we realized we had a gap on the team in terms of depth of expertise around specific adult education and pedagogy . So rather than someone who had deep experience on product management across different industries or technologies, we hired someone who had some product management experience but more importantly understood adult learning and online learning platforms. So more than having tons of product experience, having the right current skill we need or the ability to learn specific new ones is key.
In terms of our interview process, we use this same philosophy. We leverage the research Forrester has created on product management - and lucky enough, a lot of that research includes things that I wrote! But we’re not limiting ourselves exclusively to people who are familiar with or used our product management frameworks. I'm always looking at how candidates can complement our existing team, whether it's through their unique experience or their ability to learn skills, and also their overall approach and philosophy regarding product management and working across roles.
When hiring for product roles, I'm looking for people who understand the collaborative nature of our processes. As I mentioned earlier, our structure isn’t one where where one product manager handles one product. It's more about managing major aspects within the whole portfolio, so people need to be comfortable with that.
I'm also considering the unique nature of our business. We're not a traditional SaaS business. We're kind of a blend of services and technology. So having someone with a good understanding of our business and our customers is huge. Actually, a number of people on my team have been at Forrester for a while – a few for over 15 years each. So they bring in a lot of understanding of our business and more importantly the personas we serve. Some of them even offer insights from the research side of things, having been analysts and done a lot of work collaboratively with clients over the years
But I'm not just looking for institutional knowledge. I also appreciate having team members who are new to the business. It's about striking a balance. Like, the nice thing is, they're not tied to the notion of, "we've always done it this way." Most of them have held different roles before they came to product management. So even though they know the company, this is often a new area for them. It's been nice being able to leverage their experiences in a way that doesn't feel stagnant, that allows us to break away from the "we've always done it this way" mentality.
What are fun or unique traditions or rituals on your product team?
One unique tradition in our team, especially being a remote team, is our weekly meeting where we have an opening question to break the ice. As a manager, my natural inclination is to be efficient and just get right to business, but I realized that it's also essential to build connections – especially when we’re distributed. Even though many of the people have worked together for years, when you’re not physically together it’s harder to learn more about each other.
These opening questions are usually random and fun; for example, it was National Oreo Day and I asked people about their favorite way to eat an Oreo. It sounds like a silly question, but there were very passionate opinions about the “right” way – twist off one cookie? Dunk it in milk? Eat it in one bite? This tradition that we developed rather spontaneously has uncovered a whole bunch of really interesting things about our team members and it's a great way to get to know people on a more personal level, beyond just business.
Another meeting tradition we have is what we call Bright Spots – this isn’t specific to my team, it’s done across a lot of areas at Forrester. iIt’s just a reminder to highlight some good things that happened – positive customer feedback, a big milestone on a project, good financial results, even bright spots from our personal lives. It’s a good reminder that even when we’re having challenges, there are always bright spots to make note of.
Huge thank you to Jeff Lash for sitting down with us and sharing his time and expertise. You can follow along with Jeff on his Linkedin here.
•
Again, we hope you enjoyed this article and got value from it. Please consider sharing this Product Collective email with your colleagues, or head directly to our blog to view this post on the web.