Super Pod Team Structure, Setting Quarterly Goals, & Prioritization Decisions (with Alisa Sheyn and Matt Poepsel, Predictive Index, Pluralsight Flow)

Hi all, we are excited to share the second episode of The Product Management Leaders Podcast with you!

Our aim with this podcast is to connect you with some of the top PM leaders and share their real-world strategies and tactics for building world-class products with you.

In today's episode, Grant Duncan speaks with Alisa Sheyn and Matt Poepsel, who work together. Alisa is the SVP of Product at The Predictive Index and previously was the VP of Product and Interim EVP and GM of Pluralsight Flow. Matt is the VP of Partner Growth at The Predictive Index and formerly led product at the Predictive Index.

It’s fun to see how they build on each other’s thoughts, so go ahead and listen to the episode!

Leave us your thoughts about the episode and subscribe to be notified of the upcoming ones!

Transcript

Grant Duncan  0:05  

This is the Product Management Leaders Podcast in which you hear from some of the top PM leaders about their real world strategies and tactics for building world class products. It's sponsored by Voximplant, the leading serverless communications platform and no code drag and drop contact center solution. Voximplant enables product leaders and developers to integrate communications into their products, such as embedding voice, video, SMS, in app chat and natural language processing. Join over 30,000 businesses trusting Voximplant. Now let's jump into the show.

Grant Duncan  0:40  

Hey, it’s Grant Duncan, your host. Today, I’m speaking with two guests - Alisa Sheyn and Matt Poepsel who work together. Alisa is the SVP of Product at The Predictive Index and previously was the VP of Product and Interim EVP and GM of Pluralsight Flow. Matt is the VP of Partner Growth at The Predictive Index and formerly led product at the Predictive Index. It’s going to be fun to see how they build on each other’s thoughts, so let’s get started.

Grant Duncan  1:11  

Hi, all it's great to be joining you on the Product Management Leaders Podcast. Today we have Matt Poepsel and Alisa Sheyn joining us from Predictive Index. So to start, can you both share a little bit about your role and what the company does, and a brief history of your past?

Matt Poepsel  1:32  

Sure, happy to do! Because you use the term history, well, I'll go ahead and start, because I've been at PI just a little bit longer. After working about 15 years in different software product roles just outside of Boston, I took on with Predictive Index in 2013. So at the time I joined, I was the only Product Leader and we had no Engineering team. Even though we produce a piece of software, it was all done through an outsource to a web design agency. So trying to be a Product Leader with no Engineers is no easy feat. But we kind of struggled through that a little bit. And then we had two new business owners who purchased the company at the end of 2014, and put everything on hyperdrive - we became a proper software company. At that point, we started hiring engineers, I built out my Product team, and really had a great go of things. The type of product that we produce is a platform that's all about, what we call, talent optimization. It's all about how do we help people at work be at their best? How do we design winning teams and hire top talent and inspire all employees to greatness. So it's a combination of organizational science and software and tools that help managers and leaders at every level really succeed with that. And so after many years of taking on that role, we decided to also enter this new realm of product-led growth. And at that point, I decided I'm going to shift over and work with our distributors, what we call certified partners, around the world. We knew we needed somebody who had an ability to scale a product organization much larger and start to take us to the next level. And so we embarked on many months long search, until, toward the end, we were very pleased and were able to meet Alisa Sheyn, and I'll let her take it from here.

Alisa Sheyn  3:06  

Yeah, thanks, Matt. So my name is Alisa Shane, I am the Head of Product Design and Science over at the Predictive Index. I have come from a background of performance management tools, specifically in engineering. Came over recently joined in April, actually March I'm sorry, March of this year. And have had a great time so far, getting to know the team and really diving into what talent optimization is all about.

Grant Duncan  3:35  

Very cool! We're excited to be hearing from you all. Matt, I just wanted to ask a follow-up question there. What was it like having an outsourced engineering team in the early days, I imagine that must have been pretty tough,

Matt Poepsel  3:52  

Very tough. It's frustrating, because you didn't have any real rigorous processes and no ways to sort of turn our requirements and user stories into working product, there was nobody in the building. At that time. You know, it was very challenging to take user requirements and have a product vision and have any predictability or stability in terms of what we were building. So we fought really hard to get almost any features out. And there was one product before I got there, that was 13 years in development. I've never heard of such a thing, 13 years and never shipped. And this was the same agency that had worked on it, it was more of an internal like a CRM type tool. But so I came into a situation that had a reputation for not shipping. And then when I got there, I was also frustrated to not be able to ship the way I had been used to in earlier organizations. 

Grant Duncan  4:36  

Interesting. So how do you both think about using outside resources or consulting to scale your product or engineering teams, because that's a unique case. But in many cases, companies at some point realize, hey, maybe I can't recruit fast enough or we want to get this one product or feature built - let me scale out in some capacity here, so that I can scale back if I want to at some point. How do you both think about making those decisions?

Alisa Sheyn  5:10  

Yeah, I'll jump in here. So I, in my past roles I have walked into a situation where there was a distinct outsourcing center that's focused across all products. And I've also worked in companies where we leveraged outsourcing for very specific, maybe a feature release or very time constraint situation where we had to get additional hands on deck. And I say, what I've learned is that the relationship with the outsourcer provider and the resource footprint will evolve. And so there is a focus on really being deliberate about what you're looking to get out of it. And understanding the risks rather than really leveraging the outsourcing provider or external development resources for just human power bandwidth. I think that's where a lot of leaders tend to make a mistake is that they don't realize the trade off - what specifically they're giving up. And so to give an example of that, maybe if all of your products are either supported or developed by a third party, you may not realize that there's intellectual property risk, or there's instability to the platform, so that if that relationship terminates, then the product is not really the in an ideal position to be picked up by an internal resource. There's also a cultural component to the two, of how do you really treat a development provider as a true partner, without creating silos and without sending the message that they are simply human power and adding to resultant force, but they're truly a partner. So I think really being deliberate with the goals and thinking of that partnership long-term helps create or better relationships.

Matt Poepsel  6:52  

Yeah, I pick up on the same thing, and it really comes down... When I've not done it well, I've tried to conform to their process, trying to think I'd get those efficiencies, and it never works out, at least in my experience. And the other is that, just like Alisa said, you know, trying to use them as an extension of the team. So in my example, all of our product professionals, we give them a behavioral assessment so we can understand their personality and how they prefer to work. And when a vendor comes in, and as providers, we do the same thing. And so we insist that they go through the same sort of processes that our employees do, and I coach them and develop them the same way, and I've had providers from a vendor say, I'm not getting this type of coaching and development from my own company, will you keep doing this for us? Absolutely. Because I need you to succeed so that I can succeed. So I think the more you can make them an integral part of your existing processes and approach, it works out a lot better, even if it requires them to stretch a little. It doesn't really work in reverse as well, in my experience.

Grant Duncan  7:51  

Yeah, that makes a lot of sense. So let's talk about PI a little bit more here. What does the product team look like and how is it structured?

Alisa Sheyn  8:02  

Yeah, so today, we have really three distinct super pods, we have one super pod, which is the growth team. So that encompasses all four of our product lines. So we have a product called Design, which really focuses on team performance and team dynamics, team objectives, and so on. We have another product that's all about hiring. So it's the PII or hire hero product that really helps recruiters connect the candidate with the job profile and make sure that there is really an ideal fit with the person and the job they're looking to do, as well as in Aspire products, all about personal relationships, and coaching and growth of an individual level. And finally, the last product at this time is the Diagnose product, which is an employee engagement survey tool. So the first super pod are those four products. There's an engineering director, a product director and sign director that oversee and lead that team. And there's a team of designers, engineers, and product managers that report to each one of those directors. The second super pod is all about platform capabilities. So when we think about things like global experience, search, monetization, volumetric loss, all sorts of capabilities that span across product and global experiences. There was a similar organizational setup there. And that is the platform team. And finally, we are now building up our product data science team. So AI, machine learning, data aggregation, predictive analytics, all things that support a product and offer predictability and insights to guide the process within those four products. It's the third super pod. So the setup there is a little bit different, because it's a data science team, rather than a product team, but we're moving towards that same structure that I described.

Matt Poepsel  9:52  

I think one of the best things at PI is that we take product-like approaches in just about everything that we do. So even when I shifted over to what we call a "partner world", where I work more closely with our distributors all over the planet. A big part of our function is to build technologies and tools and learning assets and things that allow us to scale. And so we take product-like approaches that began in our product lab. And we try to replicate those as best we can, even for non-software based on not traditional software based products. So as an example, you know, we'll maintain backlog in the same sort of way, we'll do our estimation and pointing the same way. We take lean approaches, we do all kinds of A/B testing, we actually map out flows and experience and we even borrow from Alisa's product labs, some of the product designers to come help us think through experiences and map them out in a very visual way using tools like Figma, and other sorts of things that are best practice. It has really taken all of the sales and marketing innovations that we have for our distributors to the next level, by borrowing and having grown up, if you will, with these product like approaches and another part of the building, it's really helped us really accelerate that scalability and user satisfaction and analysis in a very different audience.

Alisa Sheyn  11:01  

Yes, a great point Matt, I think that emphasis on experience, user experience doesn't just start and stop within the product. So being able to have consistency across all these different experiences, whether they be billing, partner interactions, anything outside of the product, I think it's important to have a similar approach there. And I love that you brought that up.

Grant Duncan  11:21  

Yeah, it's really interesting to hear that, especially because you talked about PLG (product lead growth) becoming a really key thing for Predictive Index. And to see that mindset even being taken into other teams is a great example of how PLG can be not just for the product, but for the company as a whole. 

Matt Poepsel  11:47  

It's very much about giving people the tools that they want, a way to have a very easy frictionless type of experience, you know, get their problem solved, and then decide if they want to expand the usage of the product, the adoption, they hit the paywall, whatever it might be. Even when you're talking about not product like approaches, we have to do the same things when we provide business intelligence, or on demand self paced learning, these are all where PLG-like approaches can really be helpful. If we just act like it's monolithic, top-down, you'll do this because we say so - nobody's gonna put up with that anymore. So I feel like we've taken sort of the best of what PLG is teaching us, I'll say that, because we're fairly new to it. But what it's teaching us, we're trying to incorporate those principles into all aspects of what we do, all over the shop.

Alisa Sheyn  12:32  

Yeah, if you think about it, PLG is really about frictionless user experience. And that doesn't have to be on the product side. I mean, you don't think of Costco as a PLG company, but they were one of the earlier companies pre-pandemic, that would offer samples. So you try a bite-sized sample, very frictionless, no obligation, of whatever food you're looking to buy, and you walk out with that product. So PLG doesn't necessarily apply to product, it applies to overall what the user experience can be. 

Grant Duncan  13:02  

That's a great example. Okay, so I'm kind of curious, Alisa, you talked about super pods. Can you go into a little bit more detail, because I don't think everyone structures their teams in super pods. 

Matt Poepsel  13:15  

But they should!

Alisa Sheyn  13:15  

The thing about super pods is the vision, the mission and the intent for that collection of teams. So there might be a lot of similarities between a product team and another product team. So they belong in that super pod, the way that we measure their performance, they are a profit center, right? They bring users, they generate subscriptions, and we can really track them as a true product growth. Hence why there's logic to aggregating them. The platform team is supporting the growth products and enabling with a variety of capabilities. It's hard to measure, it's harder to measure, specifically how, based on, let's use global experience, for example, does a good experience really increase your subscription rates? Or is that a product attribute, a product measurement. So the way that we measure these products and the way that the function, the vision that they have helps aggregate that... They're very distinct characteristics. Each super pod, in terms of how they work with other organizations, how they interact with the user, and how they're measured on their success, I think creates those super pods.

Matt Poepsel  14:23  

That's been helpful for us to see that too. Because with Alisa's leadership and talking about how to structure teams of people doing meaningful work, on my side of the building, where we don't work with software engineers the same way, but we work with business intelligence engineers, and we work with learning experience designers and other folks that work on marketing websites, etc. And we try to emulate the practices that she's brought over to the product lab. And we're like, Well, how do we make this work better? Well, we don't have to reinvent the wheel, we can just take the best of what we can, replicate it over there. Even though it's a little bit of a different arrangement. We don't quite live and work together the same way that software engineers and software product leaders and  product designers work, but a staggering amount of that stuff can be replicated to a certain extent. And it just makes it easy for the organization to say, Oh, I understand how we're going to, you know, make a transparent user experience, we don't have to reinvent that, we can just borrow from the product lab and bring that over. So it's been great for us to see sort of product lab tickets, lumps and figure out how to get something humming. And then just try to replicate that as best we can in other parts of the building.

Grant Duncan  15:25  

Yeah, that's very cool. And how many people are currently in each of the super pods?

Alisa Sheyn  15:33  

So there are four products. So there are four teams. That means four product managers, four designers, from an organizational design perspective, and a team of engineers, between five and seven, depending on the history of the team's complexities. And they're the types of roles and types of skills that we're looking for. For instance, a mobile team or science team might have different types of engineers rather than a traditional product team, or there's just full stack engineers. The platform side is  a little bit less straightforward. At this time, there are three teams, that is the PLG capabilities team, which focuses on all things around user provisioning, account management, permissions. There is a global features team, which also focuses on some of the global aspects of the experience. And then the partner platform or the partner Business Center, which is where our partner network or resellers go to conduct the business with PI. So there's a platform team that focuses specifically on that, ensuring that the partner experience is just as frictionless as we want the user experience to be. Essentially, our user population is split, we have our direct clients, and we have our partners that are also working with us on a daily basis.

Grant Duncan  16:53  

Very cool. You can answer this for PI or maybe for past experiences. How do you determine your quarterly goals?

Alisa Sheyn  17:04  

Yeah, that's an interesting one. So I'm a big fan of the OPR framework. I love the ability, I think there's a balance between thoughtful planning or multi-year planning as well as an agile software development approach. So typically, there is a multi-year roadmap that is either created or is a continuing and revised and refined over time. Having a multi-year product roadmap, where appropriate, really helps define where the company is going long-term. So that's sort of the what? And then if you think about how do you measure that success - once you know where you're going as a product, and an example of that could be we're looking to become a platform, we're looking to break up the monolith, it could be a number of different things, then the measurements, or the what, become the part of the annual planning process. So if you then attribute product performance to the product roadmap, you can start to build out themes and measurements and metrics that are important. Once that's available, that's probably more of an annual planning process, then that really breaks down into quarterly refresh of what's the chunk of work that we're picking up this quarter. And that can be not just product work, that also is operational work, team growth. I mean, it could be something as simple as planning out what our product competencies are, what are our product manager career pathways. So it's not just work that the product lab takes on, but it's all around how the product lab works as well. So every quarter, we'll pick up a chunk of work and and break it down to specific features and deliverables that really match that annual company objective.

Matt Poepsel  18:47  

I think that really speaks to the challenge that any Product Leader has, which is you've got these near term or something's on fire, something's, you know, frustrating a user, whatever it might be, and you really want to get that stuff fixed. But at the same time everyone has finite resources, I don't care who you are. So then when you start thinking about what are my goals for a quarter? How do I actually compete and handle all these different demands that we have for our limited resources? So when you start thinking about it, the one thing I would press upon any up and coming product leaders is to really understand the business thoroughly. The long term, where's it headed? How are you going to get there? What's the status and the mechanism of competitive differentiation? Because you might find that you have to make an investment in something that's not can produce a near term result, but it's required in order to unlock a bigger win down the road. You're gonna have to make room for that. And sometimes the hardest thing for a very empathetic product person like myself, was always saying no. I hated saying no to people. I never got good at it, but I certainly did it a lot. You have to be able to set quarterly goals with an understanding of where's it all going. Having to create that challenge in the short-term is just inevitable when you're starting to work towards that longer-term outcome.

Alisa Sheyn  19:58  

I think, Matt, what's important to realize, is that when you don't have these longer-term goals, when you fail to see some of the really core dependencies across products or across your platform, that then prevent you from maybe accomplishing some of the shorter-term goal goals. The second part of that might be around making decisions and understanding complexities, and being driven by complexities rather than considering the complexities and moving forward. So if you're a data-driven leader, you might have a prioritization call between two products or two features. And so it's easy to look at all sorts of complexities. And it could be technical complexities, change management, it could be something as quantitative as your market, your total market or your financial model. So what I've seen in the past, is being driven to the decision by those complexities, and not thinking of strategically "This is where I'm going in several years", these are the complexities that I consider, but I'm going to consider them, acknowledge them and move forward with the right path in a company. I think it's easy to get lost sort of in the trees and not see the forest without that longer-term vision.

Grant Duncan  21:07  

What's one of the toughest product decisions you've had to make at some point? 

Matt Poepsel  21:14  

Early on for us, it was the choice what to do about mobile. You know, in our example, we have two sides of our of our offering, for example, we assess more than three and a half million people every year, who take different types of personality and job related assessments to try to make sure they make good choices when it comes to where to work. But at the same time, we also have administrators who have to interpret all that data. The first camp loves mobile, the second camp, it doesn't fit quite as well. And it's always one of those tough prioritization decisions. And when you watch this explosion of use of mobile, that you have to make decisions with limited resources of how much are we going to invest in that experience? That was one of the things we deliberately talked about and said, we're going to kind of fly in the face a little bit of consumer demand in order to provide even more value through a more traditional means. So that was tough.

Alisa Sheyn  22:06  

I think for me, it's really distinguishing between good and good enough. And then when you're tasking teams with execution, they have that longer term vision in mind, it's easy to move towards good, and it's helping to move towards good. But at some point, there's a call, right? This is good enough. And this fulfills that capability and meets the need. And let's move forward to what's the next strategic objective for the company or for that team and really carving out a clean cut to that scope. And then being able to take on another chunk of work. I think it's very easy, very natural, and in some ways predictable to fall into the path towards good and not stopping at good enough. And being able to innovate.

Matt Poepsel  22:48  

Might help if you ship more than once every 13 years, for example. That would be nice.

Grant Duncan  22:53  

Haha, yeah, yeah, I can imagine so. So when you think about like, let's say, on a weekly or monthly basis, what are the metrics that you're tracking and reporting on?

Alisa Sheyn  23:07  

So from a financial perspective, your land and expand metrics, your subscriptions, your conversions, so purely kind of the market, the pipeline, and being able to see the financial performance done on the product side, looking at user flows, activity, feed maps for activity, are there certain drop off points that are common. So really understanding the user experience and the user behavior as well, is key. I think another area that many product leaders don't consider a primary metric of success, but it is a primary metric of success for me, is experimentation. So how many experiments are we running? Are we learning where are the splits and where are their concurrent tests running? And if so what are the learnings? Whether the feedback mechanisms in place? Really evolving as the product itself and not just the financial metrics that are behind it.

Grant Duncan  24:02  

And when you talk about the user flows there, like what's an example for PI where you think, you know, we want to make sure they get from this stage to this stage to this stage? What's an example of the specifics, or the conversions you're tracking?

Alisa Sheyn  24:20  

Sure, sure. So for instance, if somebody goes in and has the intent to enter our design product, so I'm landing on the dashboard, going into the design product, adding team members, taking behavior assessments, then generating a team type and seeing what their team's strengths or weaknesses are, going through that, inviting other team members to share, and finishing the flow with kind of understanding what their team objectives are 13 type and how those two fit together. That is an example user flow. There might be a drop-off point where they are taking the behavior assessment, but then they got distracted, their phone rang and they didn't complete the assessment. Or they've completed the behavior assessment, but they haven't quite generated the team type, they haven't been added other team members. So thinking through those experiences step by step and understanding where the likely drop-off points will be, and being able to generate the flow, kind of the metrics and the full performance across all the users. 

Grant Duncan  25:18  

Yeah, makes sense. Matt, would you add anything on the metrics idea?

Matt Poepsel  25:23  

One thing over in the other side of the business where we're working in developing, I would say sales and marketing innovations, we have a little bit of visibility to outcome measures that isn't always as easy on a consumer facing side of the products like when Alisa is talking about where we can actually see the impact of moving the needle in terms of either prospecting activity or sales. And that's been really refreshing. For you know, for many years, I was building products and putting them into people's hands, and you would only hear how much they were affecting in certain cases, and changing and transforming companies, but you couldn't necessarily see it in your own data. And so now, with more of a sales and marketing innovation engine, now, you kind of see directly, like, did sales velocity improve, did sales probability improve, did average contract values move the way that we would have expected. A little bit of a higher bar too, because now you have to hold yourself accountable to those things, because you can directly see them. But it's just a little bit different, we do still have other parts where we can't see it quite as directly, that we have to sort of use those other measures as well. But it's been a nice sort of compare and contrast to be able to see different types of product led approaches to showing up and understanding, are they producing the results that we intended, you know, in two very different ways?

Grant Duncan  26:35  

Can you share about how PI eats its own dog food or drinks its own champagne?

Alisa Sheyn  26:44  

Oh, yeah, I'd love to. So right here on my screen, I actually have a printout of most of my colleagues have behavior profile behavior patterns. So typically, when somebody asked this question, I take my camera, and I turn it around at the wall behind me and there's just pages and pages of different profiles. So we structure our conversations to what somebody's behavior profile may be. So for instance, I have a meeting this week with a number of engineering directors, and a lot of them have similarities in their behavior profiles, in that they require more precision and more structure, more formality in the communication, something that we call the D factor. And knowing that helps us structure the conversation in a way that's both absorbable or digestible by them. So being able to provide guardrails, being able to find intent and agendas and structures for that meeting, the very kind of simplistic or basic way with respect to communication. That's certainly an example, or knowing if somebody is more sociable or more reserved, mayhelp adjust sort of the questions that you'll ask them. You might say, I hope you're doing well to somebody that's more reserved, rather than Hey, how was your weekend? What did you do? How was that, was your wife there? You might have a number of different conversations. And I've experienced that myself, where somebody that's lower on the social goal to reserve the V factor. I shared something personal with them. And their answer was, Oh, well, it sounds like you had some personal challenges, sorry to hear. And then we moved on. So they're not a very sociable person. So that doesn't mean they don't care. It's just not how they express themselves. While a higher v might go in and ask more detail about that. So knowing that and looking at that, that behavior profile really helps structure and build a higher engagement with the team. We also use our hiring a higher product for all hiring that we do internally. So we generate job assessments and create job targets, and rank candidates and look for ideal candidate profiles that fit in that job target. We conduct all of our employee engagement surveys in-house using our product, and most of the discovery or design product to generate text on our teams work together.

Matt Poepsel  29:02  

And just like Alisa was talking about the Team Discovery, it's one of our newer products. We also like to use our employees, sometimes, at least on my team as test subjects. And I'll give an example. We're starting to hear right now that clients are struggling because they're starting to return to work and reintegrate the workforce and get ready for this nature of hybrid work where it lets us rough numbers and say a third just can't wait to go back to the office. Another Third are saying, I'm never going back to the office. And another third are like Well, I'm I'm a little tentative, I'm probably gonna go back. But I don't want to go back same way as before, I want to float a little bit. And so we're starting to see that. So within my team, what we do is we take the team discovery tool, and we start to create visualizations about who's planning to come back full time, who's going to float who's going to be part time or fully remote? And how do we use those visualizations, to create interpretation about how do we help people be at their best? And how do we start to understand where people might be struggling a little bit and so trying to use and drink our own champagne as you're talking about in order to come up with new interpretation, new guidance, new tips that we can then provide to the client base, it all kind of begins, you know, with our own use of our own products tied to specific business trends that we're seeing. So we're looking at that now, we're looking also, you might have heard of RACI charts - responsible, accountable, consulted and informed. Again, another great lens to look at a team. So we're really starting to press the envelope, a little bit of the tools we've already built, to try to make them even more precise and even more consultative and helpful for clients. So we consume them ourselves first, because if it doesn't work, we'd rather blow up and skin our own knees, then we would subject you know, 1000s of clients to to something that wasn't going to work. 

Grant Duncan  30:43  

And how do you think about balancing customer requests with new innovations when they aren't aligned? The the trade off prioritization topic we briefly mentioned.

Alisa Sheyn  30:56  

Yeah, that's really interesting. So the quote that comes to mind is, I think it was Henry Ford That said, if, if I built what the customers were asking for, I would build a faster horse. Right? So there's a balance there. And in my mind, the way to really get most of customer feedback, so that you are moving towards innovation is proactive systems put in place to collect feedback, rather than reactivity to feedback that you might get. And it's tricky, because you'll find yourself in a, say you're working on a feature, and then you get feedback from a customer that they want a different feature, that that's not what they're looking for. If you don't have systems in place to collect feedback, validate your research and have both qualitative and quantitative research on the user experience, then it's very easy to fall subject to that reactivity, without really understanding the bigger picture. So I think, to put simply, if you're reacting to user feedback, without having a system in place for that proactive back collection, you've already failed, right, because then you're not able to really have the right context and make the right call. So there's a balance in productivity and reactivity.

Matt Poepsel  32:10  

In my experience, when I was a younger product leader, the worst things I could build are things that I thought was a great idea. Because I could see it, I was a domain expert, this is great. Isn't this great? Let's go build this, man. No, that's not great. Let's actually build things and solve problems maybe in ways that people hadn't expected. And let's start small. We totally embraced this lean approach and minimum viable approaches to be able to say, Are you right, or are you not? We can spend a little if you've got a hunch, we're not gonna spend Bigley, if you have a hunch. And so ultimately, I think that was something I learned. And you may have the best idea of all, but you're not gonna write checks for your own product. So you need to go talk to people who will, and make sure it's gonna work for them. And then all of a sudden, you can be innovative with some small or maybe not small, but some percentage of your roadmap you can put to those things that are truly innovative, that nobody's asking for, but you still have the burden of proof to make sure it's going to work. More of the time, you need to be listening to what people are actively complaining about. If it's preventing them from achieving their product goals - you got to get that stuff cleaned up. I don't care how innovative you are. If you can't meet their basic expectations, you're not going to get very far.

Alisa Sheyn  33:16  

Yeah, I think that's where the experimentation of starting small really comes in. In that what data validates that prioritization call? What experiments have you run, you know, and you can pay a small price for running an experiment and seeing if there's interest or appetite in certain feature, when you can even put a painted door or a fake door where there's no feature, right, we're just testing the interest or the appetite for that direction. That's a small price to pay for a very compelling learning. So being able to experiment and start small, I think is huge.

Grant Duncan  33:49  

When you're working as a PM leader, obviously collaborating with your engineering teams is critical. Do you have any tips or strategies for others that they can implement to create better working relationships?

Matt Poepsel  34:06  

I know when I was coming up, I tried to take an active interest in the engineering reality of what it meant and try to be versant in their approaches and what they were trying to do. They wouldn't let me write any code, of course, because they had the good sense not to let that happen. But I think that also stopped short of actually pretending like you knew what the heck you were doing. So it's like, it's one thing to take an active interest in somebody's world and how it works and some of the basic principles so that you can sort of help, but don't overstep and get to the point where you pretend like you know, you're giving them advice. You're not you're not an engineer, but you have a healthy respect and understanding of their work. That served me well, when I was coming up.

Alisa Sheyn  34:41  

That's interesting that. Coming from, I think I mentioned earlier, that I headed up with support Pluralsight flow product, which is all around engineering, productivity, engineering, metric, management engineer performance. That gave me a really unique insight into how engineering work is split up, and I think a lot of mistakes that product people and product leaders make is this feature myopic view into the roadmap is it's all about shipping features. And then you lose sight of things like tech debt, saleability, stability, performance, load time, all of those, you might get all your feature work and null and void, the page is not about loading, right. Or if it's a 15 second load time, no matter how great your report is, you've just lost your user, right? Like they're maxing out, and then they're walking away. So being able to acknowledge that product performance is not just feature work, it is product performance overall, I think helps build a partnership between engineering and product. There's always inherent and deliberate friction between product and engineering, around shipping features and product performance and solutions. And so being able to acknowledge that it's actually one performance, one team, one experience, that's comprised of both features and stability in architecture and infrastructure, and everything that supports that. And it helps make some of those prioritization calls a lot less painful and a lot less friction in them.

Grant Duncan  36:07  

Do you both think that you need to have an engineering background to be a PM? Or do you think you can be successful PM leader without having that background?

Alisa Sheyn  36:17  

I think there are a lot of different PMs out in the world. Some camps do have engineering backgrounds. So that helps them maybe excel on more technical products, or being able to have more intelligent conversations with respect to trade offs or technical decisions. Again, I second mass point heroes don't confuse yourself with an engineer versus a kind of an engineering savvy product person. Those are two very different things. Also, other PMs, right, there are business focused teams, there are  experience focused here. So a product manager might come from an experience background, or they might be a customer, some of the best product managers I've seen, were customers and users before, so they really understand the customer pain point. So I think there to answer your question, though, you don't have to have a technical background. But depending on where you are, as a product, where the state of the product and where you are, as an organization, might help types of skill sets that you prioritize and value within your product management organization.

Matt Poepsel  37:18  

I had the same approach where I would try to have product professionals who were reasonably well rounded and had a little bit of exposure to all the different things, I mean, between the metrics and the business intelligence to, you know, some basic financials to understand how engineering works and the reality of those things, but without having to go exceptionally deep in all of them, because you just you couldn't. So sometimes I've seen in product design, they refer to T shaped people that are kind of at least a little bit of all aspects of design, but really deep in one thing like user research or visual, I like the same approach for product people. I think that it's become very specialized over the years. And so I feel like having a basic level of proficiency across engineering and the business and product specific capabilities is important. And then after that, you know, going really deep in something that makes you have exceptional value into the product that you're building.

Grant Duncan  38:08  

Yeah, great points. That's probably reassuring to many of the up and coming PMs who might not have an engineering background that there's there's hope for them. How do you think about customer engagement and communications in your products.

Matt Poepsel  38:26  

So from a communication perspective with customers, we introduced a tool called Pendo, which we use for product messaging, and that was a real game changer for us to be able to segment campaigns and messages, if you will, to specific users based on had they not used a given feature, or maybe they were coming up for some sort of message that they needed. And using the software as an actual vehicle not just to collect information, but also to provide in-product messaging was was really, really powerful. We also use things like email, and we reach a different part of the user base and audience that way. It's something we've thought a lot about, and there's a lot more avenues open today than there used to be. I think the question, or at least the concern that I see a lot of times, in my own experience working with other people's products is they seem to be a lot more interested in talking to me than I am talking to them. And they don't really necessarily understand that you're kind of in my way here. So I get that you're an eager product person who's trying to get my NPS score, but not right now. So I feel like there's as a field, generally speaking, and to overgeneralize I think that we've kind of fallen in love with the tools and the and the mechanisms to be able to have this conversation. We're like, so hungry for it. But at the same time, I think a little discretion might be important as well.

Alisa Sheyn  39:40  

I think another point to consider here is the messaging and the communication with the customer happens not just in the product. So they might be bumpers or messages coming from the product itself. They might be hearing about your conference that you're hosting coming up. They might also be getting a marketing campaign. They might be hearing about some promotion that you're running or brand emails. So there might be a lot of different communications. So really being able to streamline what that, I think I mentioned earlier, the user experience is not just within the product. So being able to understand when are they getting communicated to? Is it aligned? Is it consistent? Is the overall communication experience a positive one, or is it overloaded. So being able to be holistic and the communication plan, I think it's also helpful,

Matt Poepsel  40:28  

It does bring up another thing that I remember from early days, a product leader is a powerful entity inside of an organization when they speak with the authority of the customer. So the more you use your communication vehicles to understand what's really needed, and what's really going on, even though like when I was coming up, I didn't have a lot of direct authority, meaning a large organization, I spoke with the authority of the customer, and that would carry the day. My call out to product leaders who are coming up, is to say make sure that you use the communication vehicles at your disposal, to really get fully steeped in what your customer is up against, and not even just their functional needs - their emotional mindset, their social aspects of what they're trying to do, their frustration, what keeps them up at night, what are they trying to accomplish in their lives. And that's going to give you real insight and authority, when it comes time to, you know, fight for those precious resources or advocate for your position on something. That's the perspective that you want to be able to represent.

Alisa Sheyn  41:32  

I think a lot of times, just being able to be connected to the voice of the customer is so key. You'd be surprised how many product leaders, engineering leaders, design leaders or product designers, engineers, that don't communicate to the customer on a regular basis. And it could be something as simple as listening to a recording of the last customer call, looking at activity live. I've had structures in place in the past, that required each director or manager to actually have a number of customer sponsorships or customer calls a month, where they just really have to be continued to be plugged into that experience, rather than relying on application or metrics or research. There's something to be said about really diving into and speaking with the customer, and being accountable on the product experience and really being in front of them and explaining that, rather than maybe collecting data from behind the scenes.

Matt Poepsel  42:23  

And I think also being able to bring that back to the rest of the organization. So at PI, as an example, every month, we have an all company meeting. And we have a segment that we always start with, called "Heroes welcome". And we consider the users of our products to be heroes, because they're changing and transforming their organizations to be better at the people part. So we will have a showcase of "Here's somebody who had this specific problem, here's how they used our product to solve that problem". And you just look around the room, or around the Zoom, and you see people's eyes light up! Because they're like, "I never get to talk to customers, I don't get to meet them. I'm just here in accounting, or I'm over here doing security or whatever". And you're like - "We're making a difference". And so the product professionals are a vehicle to bring in all of that purpose driven impact. I would definitely recommend for product professionals out there to bring that to the organization if nobody else is doing it yet. because it's a very powerful thing to do. And people just love it. They just love it.

Grant Duncan  43:18  

Yeah, yeah, I'm sure that is really impactful for people to hear. Those are great points you guys have mentioned. Even me at Voximplant - worth thinking about similar things. How do we think about the whole touchpoints that they get from, you know, first sign up all the way through first week or even beyond that. And I really liked the idea of highlighting those heroes, as you call some of those customers, to the whole company. That's a great, great insight. What sources or communities do you use to continue learning? So like, you know, if you're on Twitter, or you're on LinkedIn, or you're reading a book or website, what are some of those?

Alisa Sheyn  44:03  

Yeah, I've recently got engaged with West pushes product lead organization, so they have a product lead course. But on top of the course, they've been really great about connecting me with other product leaders, really diving into some of the same issues. So I'm really all into the product lead community, there's an open view, growth pros community as well that focuses on sort of the growth stage and how do you enable the PLG framework to support that. So I've been spending a lot of time in those communities lately.

Matt Poepsel  44:33  

And I want to see my product leaders being well rounded too. I think there's just no substitute for a great subscription to Harvard Business Review, stay abreast of leadership and business trends and themes and thinking, really important. If you're looking at podcasts. I love "How I built this" love "Masters of scale" with Reed Hoffman, just things that are kind of outside of your direct kind of hands on keyboard domain, because you just don't want to lose sight of the fact that you operate within these forces of bridging business intent and actual what manifests through your product, so I think it's important to be well rounded. So I like a variety of different sources for that reason.

Grant Duncan  45:11  

Yeah, those are great ones, we can put those in the show notes for people to find them easily. So if you were given a magic wand, and you could change or solve any one product management problem, what would that be?

Alisa Sheyn  45:26  

I think it goes back to that good versus good enough challenge. And if there is a way to continue, focus on one area is really perfected. In some cases, there is a way but that's not always the ideal situation. So really being able to allocate resources towards focusing and perfecting one domain area and bringing a lot of satisfaction to that team, while also having the recruiting capacity, the onboarding capacity and the management capacity for standing up other areas that either cross off technical dependencies, or really pull you towards that long term vision, I think that sort of would be my... And it's never a clean trade off, right? You're always making prioritization calls. So having I guess, indefinite resources, spun up, ready, recruited, trained, and then on board and ready to go, to have an infinite number of focus areas, I think, would be the best one answer.

Matt Poepsel  46:20  

And for me, my magic wand, I'd turn to the professionals themselves, the product leaders and give them ultimate confidence and clarity in the vision they're trying to manifest through their product. I think a lot of times there are forces inside of an organization that can pull a product leader off of their course a little bit, or they can get shouted down by something that's unrelated. And I think when you again, you have that clarity that in your mind's eye of what the customer and the user really needs. And to just let that guide you, I feel like, I'd love to see more product professionals really embrace that and have success and in advocating for their point. Because a lot of times I've seen more product leaders who are right, but who can't articulate or make their case, than those who are just kind of totally off the sniff - that doesn't happen in my experience as often. 

Alisa Sheyn  47:08  

That's so true. Matt, it's so true and such an excellent point, in that so much of the organization is looking at and relying on that product leader. And it's just as important in how you get to the answer, and also what the answer is. And that answer could be a product direction, prioritization call, whatever. But the organization is listening, not just to what you're saying, but how you're saying how you got there. So that confidence really goes a long way there.

Grant Duncan  47:35  

Great points. So how do you explain to your family or maybe non-technical people, you know, not in software industry, what you do for a living?

Matt Poepsel  47:47  

I think my mother in law nailed it. When I asked her what I do, then she says, oh, he works with computers. She has narrowed it down perfectly. I think

Alisa Sheyn  47:57  

That's when you get the age old cliche when somebody's asking you to fix their printer, haha! I think it's easier to describe what the product does, rather than what you do for that product. So if people ask me what I do, I tend to talk about talent optimization, I tend to talk about behavior analytics and behavioral science. So I start there, I think, in this case, it's easier... people relate to the product better, rather than kind of your function with the product, if you're not bringing in the organizational complexities or roles and responsibilities. You're really just talking about what the product does. And I think for a product leader, if you're connected to what the product does, then that's 75% of what you do, right? So identify with the product rather than the role. That's  helped me for some of the more straightforward products. I definitely struggled with that when I worked in an engineering metric management platform, then it was like, Alright, here's a computer. And here's somebody that works on computers. And we're gonna build a tool that looks at the tools that they use. Had a whole lot of complexity in explaining that.

Grant Duncan  49:07  

Yeah, I'm sure that's like, abstraction upon abstraction for them.

Alisa Sheyn  49:12  

Oh, yeah. 

Matt Poepsel  49:13  

It's not 100% helpful. But if you think about, I identify and eliminate problems, in an elegant of a way as possible. And it all comes down to that the products that we use, and that we refer and tell our friends and our families about are ones that solved a problem for us. So I think the more clear you are about articulating and telling stories in the form of what problem do we have? And then how does you know your contributions and how you, you take this abstract mess of inoperable sort of ideas. And eventually you make something manifest that actually solve someone's problem. The best day you ever experience as a product leader is when you ship something, and you get that feedback, whether it's through watching clicks, or somebody tells you anecdotally, somehow, that you made a difference in their life and in some way that's important. And it doesn't have to be, you know, world peace. It can be something small, how many apps do we use that that save us time or bring us joy or whatever might be? All those productivity experiences that make life better? And that's where the payoff is, so be a small part of that.

Grant Duncan  50:14  

Yeah, yeah, I think that definitely even helps just the personal motivation side of it as well. Well, thanks so much, Matt and Alisa for coming on today, I think you've provided some great insights that others will be able to think about and implement. Before we wrap up here, who is one other person that you think we should have on this podcast? Or because there's two of you, you could each name one person, either way.

Alisa Sheyn  50:40  

Is this like a realistic person or sort of a who would you invite over for dinner type of question?

Grant Duncan  50:46  

I think like, who would be a great guest for this.

Alisa Sheyn  50:50  

So my personal heroe, Sheryl Sandberg. So I don't know how accessible she is these days. But I would certainly say from the all the books I've read and all the podcasts, I've listened to her with her. That would be an excellent person to bring on.

Matt Poepsel  51:05  

I'd go find out who designed that Apple, the little air locator thing that have now, it's like you put a little key chain on your stuff. The reason I say that is because my bride went out and she bought one of the tile little things. Apple announced that product release the next day, she said, this tile thing is crap, get rid of it. I want this new Apple one. I'm like, holy cow. That was fast. So whoever designed that thing, man, that's where it's at. So you can make that type of response. And you should have them on the show for sure.

Grant Duncan  51:34  

Very cool. Any last closing thoughts for other PM leaders here?

Matt Poepsel  51:39  

I'll just say a quick thanks, Grant, for having us on. This is hugely important. When I was coming up, we didn't have podcasts and these things. I had a trunk full of audio books and the fact that there's so much great content that you're putting out and getting to people who are coming up and trying to learn the ranks or maybe even if you have experience, you're brushing up on the basics, this is great. So thanks for what you do.

Alisa Sheyn  51:58  

Yeah, saying thank you, Grant. And I guess my one word of advice is never stop learning. So if you hear something, if you see something... we now live in such an information rich age that everything's at your fingertips. So being able to tap into that and continuously improve and get better. It doesn't have to be product. It could be your leadership skills. It could be your understanding of design. It could be all of these other areas and products such a cross functional discipline that they all help make your into a better product person, a better product leader, some never stop learning.

Grant Duncan  52:29  

Yeah, pretty points wrap on. Thanks all, have a good day. 

Alisa Sheyn  52:33  

Thank you!

Matt Poepsel  52:33  

Thank you so much.

Grant Duncan  52:38  

Thanks for listening to today's podcast, and thanks to our sponsor Voximplant, as well. If you're looking into how to improve your communication and customer engagement, check them out. Lastly, if you enjoyed this episode, please leave us a review and tell your friends so that others can find it more easily. Have a great day and feel free to reach out to me, Grant Duncan, if you have any questions you want asked in our next episode.