Episode 186: Optimizing Enterprise Product Development Processes with Christopher Li
I recently had the pleasure of sitting down with Christopher Li, SVP of Product at Xactly to explore the evolving landscape of product management. Christopher, with his wealth of experience in product ownership and strategy, offered a fascinating perspective on the multifaceted role of a product manager and the dynamic nature of product development.
In our conversation on the Product Thinking podcast, Christopher shared his unique approach to balancing strategic vision with practical execution. We delved into the art of aligning product teams, navigating career flexibility within product management, and leveraging innovative strategies to drive successful product launches. His insights into the integration of various roles and the importance of cross-functional collaboration provided a refreshing take on managing complex product ecosystems.
Join me as I dive into Christopher's expert advice and uncover practical tips for enhancing your product management practices, embracing career versatility, and fostering a more cohesive product development process.
You’ll hear us talk about:
04:52 - Phasing in Agile and Scaled Agile Framework
Christopher discusses the approach he took to balance predictability and innovation at Xactly by phasing in an agile methodology alongside the Scaled Agile Framework (SAFe). Recognizing the limitations of an annual roadmap in maintaining both long-term vision and day-to-day execution, Chris and his team introduced a quarterly discipline through SAFe. This method allowed them to complement their existing roadmap with a more adaptable and dynamic approach. However, Chris also acknowledges the challenges that came with adopting SAFe, particularly in terms of change management and process fatigue. Despite widespread buy-in, the sheer number of moving parts within SAFe necessitated a gradual integration rather than a wholesale adoption, which ultimately allowed for more tailored and effective process improvements.
22:03 - Merging Product Owner and Product Manager Roles
Christopher discusses the transition from having distinct roles for Product Owners (POs) and Product Managers (PMs) to a more integrated approach. Historically, these roles were segregated, with POs focused internally on the R&D organization, while PMs were more market and customer-facing. However, Li's team found more long-term benefits in merging these roles into a hierarchical structure. As POs gain experience in implementing and shipping products, they naturally transition to PM roles, taking on market-facing responsibilities while delegating internal tasks to incoming POs. This shift not only enhances collaboration but also boosts morale by offering a clearer path for career progression, allowing individuals to explore various facets of product management based on their interests and strengths.
27:18 - The Importance of Cross-Functional Experience in Leadership
Li highlights the value of cross-functional experience in developing strong leadership within product management. He notes that many of the best leaders he has worked with have experience in various roles beyond product management, such as sales or engineering. This diverse experience gives them a well-rounded perspective on the business, enabling them to better understand how different teams and functions operate and how they can work together effectively. Li mentions that when he started his career, product management was not as well-defined, and people often found their way into the field through other roles. This organic approach helped build a broader business understanding, which is now more structured due to the growing allure of product management as a career path.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking podcast. Here's your host, Melissa Perri.
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking podcast. We're thrilled to welcome Chris Li, the Senior Vice President of Products at Xactly. Chris is a distinguished product leader renowned for his strategic approach to product management, particularly in leveraging AI to enhance revenue operations. We're going to talk about agile planning and strategic alignment and how he's implemented certain approaches to bridge the gap between execution and strategy. And yes, we're going to talk a little bit about SAFe. But before we jump in with Chris, it's time for Dear Melissa. That's the segment of the show where you can ask me all of your burning product management questions and I answer them here every week. Go to dearmelissa.com and let me know your questions. Here's this week's question.
Dear Melissa, should product managers do user research by themselves or should we hire a dedicated user researcher to do this task? Why am I asking this question? Well, because I find myself busy with a lot of tasks. When should I do user research? Even if I should do the research, how should I set expectations for stakeholders on timing to answer our questions?
So this is a nuanced question. Should product managers do user research? 100%, absolutely. Do you have to own all of the user research that is done in the company or for your products? It depends on the size of your company and it depends on what type of research it is. Dedicated user researchers are incredibly valuable and companies should not just look at product managers to do everything. They should also think about hiring user researchers. Now, you want to hire a user researcher as you scale and as you have more and more research tasks. They can go out and do generative research to try to figure out what are the new trends or what are the new problems that are coming up. They can also help train other product managers, UX designers, and other people in how to do good research and make sure that you have great standards for them. They can also go and conduct research for people who might be too busy. That's definitely an option as well. Well, but at the end of the day, you as a product manager should be doing some kind of research. It doesn't mean you have to do all the research, but you should be talking to customers. If you don't do that, you're going to lose track of what the customers actually want. There's a lot you can gain by sitting with them, watching them, seeing what they do with your product, observing, right? And you're going to lose that if somebody's just summarizing it and shipping it off to you. So where I love to use user researchers, things like strategy. If we're building a strategy from scratch, I just did this with one company. We went out, we talked to a bunch of our different users, and we're trying to figure out and narrow down what are common problems that a lot of different types of personas experience.
This is good generative research to go out, understand a hypothesis, try to norm and form, and then we're taking that and using it to inform our strategy. That's a great way to actually have user researchers dedicated, going out, doing really good, complicated research, longer research studies to come back and synthesize it for leaders. So that's a great place where you could use your user researcher. You as a product manager, though, should be making time to do user research. Now, you don't have to do it absolutely every day, but you need to be staying informed. So for example, if you are getting ready to do a new product, you might spike and do more research because you're discovering, you're trying to understand problems, you're trying to understand what is coming next, and you're painting a vision. This is going to take a lot more research than something like getting feedback on your latest release and seeing if it meets needs. In that place, you probably have something that is more directive. You have hypotheses about, did this actually work? You're going to go talk to a bunch of customers and see if it worked. It's more of a, did this work, did this not, and why or why not? But the other stuff, it's like, let me go search for problems. That's our generative research. Let me search for problems. Let me see what our opportunities are. Now, where a lot of product managers make this mistake is that they start with generative research with no backing of what we think our hypotheses might be. This is where you go and get data. So you dig into the data, you figure out what the trends are, you align those back to business metrics, and then you form some hypotheses and then you go out there and you do research.
This targets your research so that it's not so open-ended and you're just talking to 100 people and you're not sure exactly what's going to come up. Tthere's a time and place for that, but in a lot of the places where we do this for product management, we want to have informed hypotheses before we go out and start talking to customers, especially when we're starting something new. So what I would suggest is look at your data, figure out what your business goals are, try to understand where the business goals are not meeting expectations. So for example, do you have a retention problem? If you do have a retention problem, maybe go start looking through a bunch of churn feedback. Maybe your customer support team has feedback for you, maybe the sales team has feedback for you. Try to understand what's happening, who's churning, what types of personas are churning. This is going to narrow your scope of research from this to like a much smaller area where you know who to target, you know what questions to ask, why did you leave, why are you unhappy, and you start to get some clues on what you could actually ask to uncover the real reasons underneath it. So you needed to prepare for your research. You need to go out there and get a bunch of data and try to figure out what's going on before you set up research. Then you can go out, and try to figure out, do I need to talk to 10 people or 20 people or how many different personas or different situations? When you set expectations for stakeholders, you should have informed those hypotheses first, then made your research plan. Again, this is where a user researcher can help you make a research plan. And then understand how long it takes to line those up, when you might have some answers, and you keep them informed.
So for example, if you're going to talk to 10 people, it could take you a while depending on how responsive everybody is. If they respond to you really fast and they say, yeah, let's do some research, dive in. Maybe it'll take you two weeks. But if they're slower, that can actually take a long time to line up 10 people. So you have to understand who your customers are. But you set these expectations and you ask the stakeholders as well for help. If they are, let's say, stakeholders from sales, can your account managers work with me and give me a warm lead into these people I want to talk to? Or, hey, I need budget to be able to offer gift cards or something else that might make them want to do research with us. Those types of things can help it go faster. And that's how you leverage your stakeholders to help. So I hope that helps. At the end of the day, it's great to have dedicated user researchers. I think they're fantastic. But as a product manager, you should never be pushing all of your user research onto the user researchers. You should be doing some of that yourself and make sure you're talking to customers. If you have to tag team with a user researcher, great. Split up the work. Do it together. But do not go for long periods of time without talking to customers directly. Make sure you do that. I hope that helps. Again, if you have any questions for me, go to dearmelissa.com. Let me know what they are, and let's go talk to Chris.
Advertisement - 00:07:12: Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes.
Melissa - 00:07:49: Hey, Chris, welcome to the podcast.
Chris - 00:07:50: Thanks for having me, Melissa.
Melissa - 00:07:51: Can you share a little bit about your product management journey and what led you to your role at Xactly?
Chris - 00:07:56: Yeah, absolutely. So I've been in enterprise software for about 20 years. Ironically, I actually started my career in engineering, very quickly realized that wasn't the right role for me. And so I pivoted to professional services, spent some time in professional services, and then actually moved earlier in the customer lifecycle to pre-sales. And I found that I became fascinated with how can I be more influential delivering solutions to our customers? And I quickly realized that the avenue for me, given my skill set and the things that I was interested in, would be to move further upstream into product management. So I spent the best, going on 15 years in product management and have worked through the different functions of product management. I actually helped start a software company here in Toronto. So I'm based in Toronto, Canada, which we ultimately sold to Xactly. That's how I found my way to Xactly, where I was the chief product officer. And at Xactly, I've held a variety of different product roles. And ultimately, our original CPO got promoted into the CEO role as our founder decided to retire. And he then elevated me into my current role, which is the SVP of product. So I have global responsibility of the product organization. There's about 40 folks within the product function at Xactly, geographically dispersed across the world.
And it covers all of the traditional product functions. So product management, product design, product strategy, product marketing, product operations. And we also support the corporate development initiatives here at Xactly. And then just very quickly for folks, Xactly is an enterprise software provider. We provide sales performance management solutions. We've been in the industry for about 20 years at this point. And we help organizations optimize their go-to-market, right? So everything from the upfront planning that they do with how they should allocate their go-to-market resources. Through to modeling out the potential financial return on their investment in go-to-market. Through to actually operationalizing that model and executing upon the plan. And then of course, we are well known for incentive compensation management. Which is helping organizations manage the compensation plans and associated incentives for their go-to-market folks. And we also help them with forward-looking sales forecasting to identify areas to course, correct. So, a number of different solutions, platform first organization serving enterprise organizations.
Melissa - 00:10:34: I love a good story about a CPO getting promoted to a CEO too. I think that's very cool. So when you came into Xactly, what were your biggest challenges? What were you tasked with doing?
Chris - 00:10:44: The major sponsor of Xactly is Vista Equity Partners. And I would say that when I joined Xactly, shortly after we were actually brought private from Vista Equity Partners, because historically we were a public company. And I would say that we didn't have a lot of maturity in all things roadmap, all things product management, right? And that's actually one of the reasons why the former CPOs, now the CEO, came in was to bring rigor to the product management organization and the practices. And over the years, we found that we needed to institute ancillary processes in and around the traditional annual roadmap planning process. We found that by having operationalized an annual roadmap, it was great as far as having some level of direction and rigor with which we operated and collaborated with our cross-functional peers. But we found that at times, we were losing sight of the longer-term perspective that we should be focused on, as well as the, I'll call it the day-to-day rigor that guides us to ensure that we're delivering the new products or features within our products in a highly predictable way. So we knew that we needed to do some things differently.
Melissa - 00:11:57: So what did you concentrate on to kind of balance that predictability and bring in innovation as well?
Chris - 00:12:03: So we decided to actually phase out the way that we would solve that problem. And we thought that the most important thing for us to focus on was to complement the annual roadmapping process with something more agile. So we ended up adopting the scaled agile framework to institute a quarterly discipline that, again, complements the roadmap. And so we spent a bunch of time operationalizing that. And it brought a whole lot of predictability to the way that we operate. The one thing I'll say that we found, though, was that there are a lot of elements to the scaled agile framework. And from a change management standpoint, there were some challenges that we faced. And a lot of it was just fatigue from process optimization, right? I think all folks within R&D bought into the value of a scaled agile and how it brings the team together and unifies the perspective, but there are a lot of moving parts, right? And so we actually this year decided to slow down the amount of the core discipline that we absorb and kind of make the process exactly, right? Like historically, we had benefited from being organic with the evolution of our processes. And so we decided to do that. And I think it started to pay dividends. But to balance the agile approach and not lose sight of the long term, we also actually booked ended the scaled approach with the annual roadmap with what we refer to as an innovation framework. And that's actually a disciplined framework that allows us to effectively recast our three to five year product vision and strategy. And then when we decide we're going to make those big bets, it actually gives us a mechanism to be able to track earlier stage KPIs that will tell us whether or not that bet is ultimately going to pay off, right?
Because, sometimes with these longer term initiatives, you don't always have a specifically go to market feedback as to whether or not the thing that you're working on that's going to span multiple years is actually going to return the right type of outcome to the business. You need to think about different things, right? So a perfect example of how we applied that is when Xactly was acquired by Vista, we were effectively a single product company. And then shortly thereafter, when we became private, we acquired few rganizations and product sets, right? Like myself, I came through in acquisition. And so we very quickly became multi-product, which is a very challenging thing to be able to manage because typically there are multiple competing technologies. There aren't economies of scale of R&D that you realize. And so we knew that we needed to transform from a multi-product company to a true platform first company, right? Similar to the product strategy model that like a sales for, or a Microsoft employees, right? Where all of the products are unified on a singular platform, there are shared services, and then those shared services are leveraged by each of the solutions that you then bring to market. But you know, you're sitting on one core platform. And as I talk through that, hopefully that's not something that happens overnight, right? That is a multi-year bet that takes place, but you need to keep people disciplined and aligned to the vision. And so we knew that just focusing on an annual roadmap and kind of recasting it every year and then overlaying a quarterly process that of course helps with execution.
We were concerned if we didn't compliment that further with a multi-year innovation framework that allows us to track the efficacy of where we are in the journey that we might lose our way. And then over time, at some point, as with any transformation, there could be changes in leadership. There could be a number of reasons for why you say, hey, you know what? You're partway down the journey. But I haven't seen the financial return on this yet. Should we abandon? And so fortunately, we instituted this framework that allowed us to stay focused on what are the things that we need to get right for this first year of a multi-year journey to know that it still makes logical sense for us to continue down the path. And we've since then applied this innovation framework in combination with the scaled agile quarterly framework for a number of additional innovations. And they've really helped us stay focused on kind of this balance between the long term and then the short term via the scaled approach.
Melissa - 00:16:33: How do you put together your innovation frameworks? Who's involved in that? What does that look like? And what are the outputs, right, that you would communicate to other people?
Chris - 00:16:41: So we have a dedicated product strategy team. I would say that for a lot of these processes, the number one recommendation is ensuring that people have the space to do it, right? If you ask one team to manage all of these different processes in a highly integrated way, then they lose the time to be able to do any of them effective. And then they end up actually adding less value than just having not done them to begin with. And so we have a dedicated product strategy team that also collaborates with our research team and they're focused exclusively on figuring out what's next and operationalizing the innovation framework. And the way that we structure the innovation framework, there are like a series of gates that we go through across the multi-year journey that these innovations are subjected to. The actual nature of the gates and the KPIs are highly dependent on the nature of the actual innovation itself, right? So if there is a multi-year innovation that is something that's modernizing, let's say an existing capability product, feature or whatnot that would be disruptive to all of our customers, as an example, there's a certain level of rigor that's put into the innovation framework that focuses on the level of disruption, as an example. Or if there's something that's completely transformational, it's net new, then we might focus on kind of the expected go-to-market outcomes. So it's more of a, can I get early prototypes in the hands of prospective customers or whatnot, or even existing customers and do the collaborative co-innovation with them, versus managing the potential disruption of some sort of modernization exercise. But there's a series of different gates. It all starts, of course, with an ideation element, right?
So there's like a funnel to the framework, but the funnel obviously focuses us on making sure that we are kind of checking all the boxes as we iterate from stage to feel confident, both internally, we have to have conviction internally that we're focusing on the right things, as well as, of course, we need to report up to the board that these are the kind of the bigger bets that we're making, and here's the expected outcome, and here's the governance that we've applied to this process to make sure that we are stepping through the stages of this multi-year innovation. And then the other thing I'll say is, with all that said, it's not all just about longer term innovation, right? Like where product management becomes very interesting is this kind of balance, right? Between how do I kind of disrupt for the future, but stay current on today, and deliver and support go-to-market, and all of your customer experience teams with the things that they need to do to be successful today, whilst kind of constantly reinventing. And so I think that's where this combination of the multi-year innovation framework that then manifests in the roadmap, but then is executed and managed via the quarterly process, it allows us to just kind of balance the tension between truly forward-looking and let's focus on tomorrow, like the things that are very acute and immediate to our customers.
Melissa - 00:19:38: So with product strategy teams in the past, when I've seen them implemented, I found that there was friction between the product managers and the product strategies teams. And we had one actually at Athena Health for a while. And the complaint we got from product managers was that the product strategy people do all the fun, innovative stuff and do the forward-looking things. And they kind of throw it over the wall to us to just execute. So then they felt like they were just project managers of whatever was being executed. We ended up revamping that into a different role. And these people ended up doing a lot of market research and TAM. And they were aiding the product leaders and actually doing a ton of that research work to say, is this a bet we want to make? What does your product strategy team look like? And what types of work are they doing? And how do you manage that tension between them and product managers?
Chris - 00:20:22: It's a great point. And I think that is the stigma that is associated with product strategy. They're all pie in the sky, think about the long term. So the way that we combat that here is we actually have them dually focused both on they need to figure out the big bets, right? Because they are afforded the space, as I said before, to do market research, talk to analysts, talk to customers and figure out like, what is that big kind of flashy next new thing. But they also are responsible for helping substantiate the things that product management knows we need to do in the short term. And so they partner closely with our product operations team from a, I'll call it a quantitative fact based perspective to determine here is the right balance of our portfolio between I'll call it like the long term, the short term, and then like kind of the immediate term. So they're actually involved in all elements of the roadmap and are forced to come up with the right mix so that they're not just always thinking about the next major innovation. But there's also a balance amongst their focus, because if you don't give them enough time to think bigger picture, then they won't think bigger picture.
And then you become very tactical and reactive from a, an innovation and response to market standpoint. So the tension, in other words, is by design, we don't just exclusively focus them on the longer term future type stuff. Because of course, as you suggested, it would then be there would be conflict with the product team. But you know, we don't hide from conflict here as well. Because it's a very similar dynamic as typically product organizations and engineering organizations. Have a little bit of friction too, where a lot of times the engineering organization will be focused on Tech debt or wanting to medernize the things that are already there, versus thinking about, like the next bet that could be made. So kind of liken it to the same dynamic and usually just comes down to, do you have frameworks in place that drive collaboration? Do you have trust within the team right? That everyone understands that they're all playing a very specific coordinated role that leads to better ultimate outcomes for the business? So yeah, I think, we just it's a focus thing, we just make sure that they understand what's in front of us and what we need to do as well as kind of macro level where we want to go.
Melissa - 00:22:31: When you think about the roadmapping process too, some of that strategy work typically falls on like product leaders, like a VP of product or directors who report into you. How does product strategy pair with them and how do you share those responsibilities of the roadmap? Who's doing what?
Chris - 00:22:45: So usually product strategy will take the first cut of what the go forward recasted product vision and strategy is across the portfolio. So it's somewhat of a centralized, unified view. We do that intentionally so it's not bottoms up by the individual product managers because sometimes the individual product manager will be fairly laser focused on their product, the outcomes that it delivers, the state of maturity of that product, and maybe lose sight of the bigger picture. So we try and almost take a top down approach. So product strategy is responsible for that kind of recasting of the vision. And we have a formal offsite that we do every year where we get all of the R&D leaders, both engineering and product, and even sometimes cross-functional leaders across the org as well. Because we just need that third party perspective, which starts the recasting of the product vision and strategy. And then the product strategy team then works directly with the product managers. And it could be at a director level or an individual product manager, to basically translate the macro vision into what that means for the individual product. So that's kind of the reconciliation of the macro and the bottoms up type of approach. But ultimately, the product manager then takes the macro perspective and is, of course, responsible for the delivery of their roadmap with the very, very specific elements of the roadmap that makes sense for where their product is and where they need to take it based on what the broader corporate objectives are for that particular product.
Melissa - 00:24:13: What have you found works well with this way of working? What are your challenges still?
Chris - 00:24:18: What's worked well for sure is kind of the delineation of responsibilities because I find that in, I'll say, maybe some product organizations that haven't been around as long, typically they'll just have product management. And so forget product marketing for a second or product operations, these ancillary functions. A product manager is like a full stack product manager. And I find that there's just too much that is then tasked to that type of person to be able to balance constantly the tension between the long term, medium term and short term. And so I found that that delineation to give the space has been very rewarding. Now, the drawback of that, of course, is the heightened need for collaboration, right? Because if I can just make all the decisions for my product on my own and go and then operationalize them with engineering, then it's a little bit easier to execute versus having other stakeholders involved. And that obviously doesn't even, we haven't yet touched on all of the cross-functional teams that, of course, within product, we need to make sure that we are addressing the needs on behalf of. So I would say that, the pros are having the time, the con or the implication is just needing to be intentional about collaboration and leveraging tooling and means with which you ensure that information is shared effectively.
Melissa - 00:25:30: When you think about career paths, too, for your product managers, do you think, is product strategy treated as a more senior role or is it different skill sets that you bring in there or is it a separate career path?
Chris - 00:25:38: Definitely different skill sets. We actually at Xactly, I think, do a really good job of assessing talent, assessing interests. And actually, sometimes it's objective, quite frankly, where we actually leverage frameworks to determine like this is legitimately your working style. Me personally, I have a tendency to try and focus on the bigger picture, right? And of course, there are drawbacks, right? So you need to make sure you balance the people that are a little bit more execution focused, right? And so I think what we find is we just offer that opportunity. And there are senior level positions in product strategy, product marketing, product management, product ops, or design, whatever it happens to be. And people will organically gravitate to kind of the work that they have an impact on, and then the things that they're interested in. So we don't necessarily say this one function has more of a glisten to it than this other one. It's more so this one title requires a different kind of personality type or mentality.
Are you a little bit more gray matter thinking? If you are, product strategy might be good. If you're a little bit more, let's get things done, then maybe not even product management, but the product owners who are working much more closely with like engineering specifically, like they'd be better for that. Are you highly communicative, right? If you are, maybe product marketing is the way to go. And then we have some folks that are very analytical in terms of the way that they think. And they're great for product operations, because they love to number crunch and analyze data and tell us like, hey, guys, like, you might think from a subjective standpoint that this is the direction we should go in. But this is what the data tells us, right? Like, these are the things that are like, objectively working. Let's go down that path. So it's kind of just a balance. But yeah, we try and leverage behavioral traits as the means to help navigate folks to the function that makes the most sense.
Advertisement - 00:27:25: Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations.
Melissa - 00:27:55: The product owner versus product manager thing when it comes to SAFe is always a big topic there. Do you treat those as two different roles or is it like product owners can move into product management roles or what's that kind of look like?
Chris - 00:28:07: We historically had segregated them into two separate tracks. We've since found that there is more long-term benefit in collaboration if we merge them and effectively become more of a hierarchy, if you will. So typically a product owner will naturally work more internally with the R&D organization. And then as they kind of graduate through implementing and shipping effective product, then naturally we effectively flip them to be more market and customer facing. And then obviously can delegate some of the responsibility to the other incoming product owners. So we went through a shift from that standpoint as well. We didn't really like delineating the roles too much.
Melissa - 00:28:49: How have you found that to be now that you made the shift?
Chris - 00:28:52: It's worked well. I mean, if nothing more, probably the biggest benefit that sometimes is hard to measure, like the efficacy against, is just the morale. If I want to go into product management, typically I'm cut from a certain cloth that I like, want to be in front of customers and folks within the market. And sometimes you have to pay your dues. But like to think that I'm not going to have the ability to do that at any point in my career, I think it's limiting, especially from like a morale standpoint. So you just, you see this kind of bump in energy. And we recently made this shift as well. And you could tell from folks on the team that now they know that this is what next looks like. And again, the other thing too, that we try and be very open to here is there's no set path. There's the logical hierarchical progression that you can take, but I don't have to go from a product owner to a product manager. I might go from a product owner role to a product manager role and then like product operations, which is actually an example of what happened with one individual on the team. And now he's thriving in product operations because that was just, again, more akin to just kind of his DNA.
Melissa - 00:29:51: When I did the transformation at Athena Health, one of the things that we did was teach everybody product management. And then we found that a lot of people figure out what the roles we are, we needed around them were. One of that was the product strategy role. And that person was a lot of doing the research. We didn't have them actually do the big bets like you're talking about. They wouldn't place it there, but they kind of aided the Marketing VPs in going out and doing the research on where their strategies were going and trying to quantify it into what's the market opportunity, what's this going to be? How might we do this? Because they knew the nitty gritty of the product well enough, but they could also think longer term. So that's how we balanced it that way. And then we also had product operations as another role as well. And we found that a lot of product managers, once they figured out what it was, they self-selected out of it because they were like, oh, I actually am more operational. I want to do that. Or I like the analytics that's involved in product strategy and the long-term thinking. I want to go more into that role. And I think it's interesting because there's a lot of adjacencies in product management and it doesn't have to just be product management. And a lot of people, when they get into it, I find that they're like, oh, no, that's not what I thought it was going to be. And they want to get out. But sometimes we think that's a bad thing. And I never thought that was a bad thing.
Chris - 00:30:59: Yeah, not at all. Because I think people get into product with a certain, I would say, preconceived notion of what a product manager is. But the reality is there are many flavors of what a product manager is. And also, again, if it's no longer full stack, it's actually been carved up, then the disciplines are so very different from one another. So you might enter into the product domain and then very quickly, as an example, another individual moves from product management to product marketing. Because they just realize, hey, you know what, I love just talking to the go-to-market team and focusing on messaging and positioning where I don't really care a whole lot about the actual building and shipping of products. I'm more like just the packaging of it up and what's the pricing and those types of things. And then working very closely with go-to-market, a lot of times, it's almost like an enablement role, right? Like, how do you position this to be effective in the market? And so we try and be very open with, it doesn't really matter where you want to go.
We just need to make sure that the role that you're trying to enter into is one for which, make to a certain degree, you have the DNA to be effective in, and you're interested in it. So we find that there's a decent amount of organic movement within the org. And then the other thing, too, is sometimes there's boomerangs where it's, I was in product management. Then I, hey. I thought, you know what? Let me try product marketing as an example. And then it's, you know what? Nah, it's really not for me. I'm going to go back into product management. And the benefit of that, if it can be managed at the macro level, is that to the degree that, and I think I've benefited from this in my career, to the degree that you can get people to work in some sort of rotational program where they learn the other cross-functional teams, the level of empathy and knowledge of the things they need to do to help these other teams, it's invaluable. So it's almost encouraged to go try something new. And if you want to come back, then that's fine. It probably uplevels your ability in the kind of the returning role that you're in.
Melissa - 00:32:58: I've also found that most of the best leaders I've worked with have actually done different roles than just product management, right? Like they've tried sales a little bit. They've done engineering, right? They've done a variety of roles and they were like, oh, now I understand how all this all works together. I want to lead product though. That's like my thing that I want to do, or I want to do product marketing and it helps there too.
Chris - 00:33:17: Yeah. When I started my career, there wasn't anywhere near as much focus on product management as well. So it was very rare that people even knew to potentially exit either undergraduate or business school or whatever it happened to be and say, hey, I have my vision of going into product management. It didn't even occur to people at the time. So I think from that standpoint, we almost had to find our way into product. Now there's a lot more allure to product management. So people can start there, but you're absolutely right. Those people that bring that cross functional perspective, I find almost undoubtedly are the top contributors just because of that rounded perspective on business, quite frankly.
Melissa - 00:33:58: I always find that really nice. With all these different functions too, we talked a lot about your overall kind of innovation framework. Let's talk about quarterly planning a little bit more, especially with SAFe. For the people I know who've followed to the letter, I get a lot of feedback that they go to the big room planning, they do their quarterly plan, and then they will not deviate from it. And also I hear from them this other feedback of if we have something that's too long, like we'll just put it in the quarterly plan. But if we don't deliver in the quarter, it's just going to get reprioritized for the next one. And they're having a hard time, I think, with the quarterly planning and the stuff that's not quite a quarter. It's going to go beyond that. How do you balance that? And how do you involve these different team members in that?
Chris - 00:34:40: So for us, one other element that we incorporated into our quarterly process is this notion that actually overlays on top of the forward-looking innovation framework, the annual roadmapping process, and our quarterly, I'll call it execution cadence that is managed via the SAFe framework, is this notion of a launch framework. Right. It's another Vista best practice that we leverage that it allows us to basically decompose the long term with the annual and give like a quarterly perspective that can guide us. But it's all from the perspective of the end go to market state. So you can kind of bring things backwards from what you're trying to do from a market entry standpoint, because you're right. There's a lot of things that we try and do from a quarterly standpoint where they're like, this works a little bit more than a quarter. But for us, we still chunk it up into what can we get done? In this quarter from the lens of this launch framework that knows that, who knows for the work that we're doing, we might not actually bring this to market for three quarters as an example. And so at least it's almost like another view that allows us to stay true to the things that matter. I will say that with the SAFe process, and I may have mentioned this before, is that we've kind of adopted our own approach to it where we certainly do our quarterly planning upfront. But really what we're doing during the quarterly replanning is we're actually just giving space for everyone to realign on what the longer term vision and strategy is. So we're really recasting our three to five year vision during every quarterly planning process that we do. And again, we're using the launch framework as the means to hold us accountable for these are the things that we need to deliver.
And the benefit of the launch framework for us is we don't actually view it as a, ultimately we are shipping and marketing product via this framework, but we don't view it as a product launch framework. We view it as a, for lack of a better description, a company alignment framework, which is here are the three to five things that are meaningful for this year that we're going to do. And a lot of if you look at the decomposition of the framework into its steps, it's like stuff that doesn't even happen in R&D. Like the lion's share of it is just like cross-functional stuff like readiness and getting the messaging and the positioning right and whatnot. But then I think to one of your earlier points about getting pressure sometimes from go-to-market. How do I make sure that there are things are going to be new for me to sell? And when's that going to happen? Can you commit to a timeframe? If you strictly focus on like the quarterly process, it's very difficult to zoom out and know all the things that need to be done in order for you to be able to stitch together. I view the quarterly process as like harnessing of raw materials.
And how do you bring those things together so that they kind of package up together into what you can then bring the market in some sort of predefined timeframe because all of these teams are queuing up to do their part to ready for this. Then, I've seen it done in the past where people focus too much on like true agile and they kind of just keep kicking the can on stuff. They're like, we did planning and we couldn't finish this thing this quarter. So like next quarter versus we'll figure out what we can do in this quarter, but then contextualize it via the launch framework. You know what I mean? To kind of say, this is per the plan that we're not going to build and ship everything that we need in order to be like in the position for us to formally go to pilot or beta or GA or whatnot. So product management is very much the integration of these different frameworks, and like pulling on like the strength of one, but not almost like overlooking the tension that needs to be created because you got to think long term, but you have to execute tomorrow and those things are in direct conflict with one another.
Melissa - 00:38:12: What's your launch framework look like? And then how do you get things to roll up into it?
Chris - 00:38:17: We start off actually with this notion of a power score. So we have this concept of a major launch, a minor launch, and then effectively no launch. So things that we just like on a continuous deployment standpoint just ship to production. Like they just get turned on as they're ready. And then the power score, it's your typical, we balance the impact or potential impact of this launch. And that launch could be a feature, module, modernization of something, a new product, or something else, right? It's like a big body of work kind of thing. And we model the impact based on potential go-to-market impact, the potential impact on existing customers, the potential impact on our subscription gross margin, right? So like the cost to deploy this, the kind of the uncertainty about this, right? So like a great example of that is everyone trying to infuse generative AI into their applications. A really important thing that I don't think like a whole lot of like focus has been put on is what's the cost to deliver generative AI solutions given there are these third-party tools that you're going to piggyback off of and you clearly need to pay them to do that. Like the cost to operate model is different than some other tools. And it's certainly more uncertain than some of the other products or features or whatnot. So we balance all of those things. And basically it spits out objectively based on some sort of absolute weighted score. If it's a certain number, then we constitute it as a major launch versus minor versus just ship this thing. When it's ready. And then the rigor with which we apply from a launch framework standpoint is kind of dependent on whether or not it's a minor launch or a major launch. And more rigor means you get more of the teams involved earlier on to do some of the upfront work.
Minor launch means you do a little bit less and you're trying not to like unnecessarily add too much red tape to the process because the, we call it the organizational readiness is just lower. So you can just kind of ship more readily and then there's no launchers. As long as we have our release cadence that we do an enablement around it, that'll suffice. And then it's just your standard like, if it's a major launch, we make sure that we think through all of the implications to messaging, positioning, pricing, like all of that, like way upfront, like literally before we even write like a line of code. Right. Like we're making these determinations of is this thing going to be impactful and where does it fit within, I'll call it our broader narrative. And then as you kind of converge towards now I'm like in code, then you're getting into more, I'll call it like heavy enablement type work. But you'll see that it's go-to-market through to the post-closed customer experience teams, start to, get involved a little bit later in the cycle. And it's, it really is in the service of readiness, organizational readiness.
That's like the gist of the launch as well as accountability, right? Like we want to be able to tell our go-to-market teams, listen, like we're going to a certain release phase on this date. This is what we need from you guys. And if we actually don't get what we need from you in terms of enabling your teams or whatever have to be, like, we're not progressing to that stage because quite frankly, perhaps you're not actually enabled to be able to go communicate this effectively to the market. So just the same as we might miss a, like a date to ship a certain amount of code to deliver the MVP as an example. If certain teams haven't done their part, then we're not ready to move to the next stage because I think historically there's always been this notion of R&D, so product and engineering are responsible for launching new stuff to the market. And when are you going to enable me? A, give it to to me as fast as possible. And then B, I want to do the bare minimum of enablement for myself. I just want to be able to sell this thing and then I'll worry later if I'm enabled or not. Whereas the launch kind of like it sizes when certain things need to happen and it actually creates accountability across the org versus it being exclusively governed by R&D. We find that it just brings the org together, quite frankly.
Melissa - 00:41:57: Yeah, it sounds like a good way to bring the cross-functional go-to-market side and the product development side together. I think a lot of companies are missing that piece that you're talking about because there's this connotation out there that if we do that type of thing, we're not agile or that's like more process that we have to worry about. And I've found that I think people who are newer to agile, they read about our sprint cadences or things like that. And at the end, it says you need a release. And they think that release means launch. It's not like just dev release. It means launch to customers and get feedback. How do you balance the getting feedback and being able to iterate with that launch cadence?
Chris - 00:42:36: Again, we leverage a release phasing strategy, right? So we have this notion of preview where we're still in development and we're co-innovating. Literally could be shortlisting specific perspective customers or customers in this preview stage and saying, I'm going to give you an early version of this capability and tell me the good, the bad, the ugly. As an example, then we have pilot where our pilot, which might be different than how some folks define the pilot phase, is actually we're like code done. We have built all of the capability in an absolute perfect world. The code base for pilot for us will be the same as GA. So at that point, we're not obviously opening this capability up to all customers, like to the market at large. We are selecting a like ideal customer profile and proactively reaching out to customers and internal stakeholders as well. It doesn't always have to be a customer. It could be a partner. It could be different constituency groups, but very select people to say, hey, go play with this new capability and provide feedback. And while we do that, we bring the other teams along. So they're also providing their ability to message, their ability to position, right? Like the internal teams in addition to the external teams. Then when we go to beta, that's for us where customers can opt in. And then if they opt in and they adhere to the certain profile that we've defined, then they're good. And then ultimately, GA is kind of everyone can get involved. So we layer those release phases on top of our capability to constantly derive like feedback from different stakeholder groups, internal, external, and it helps us kind of right size the launch.
And then because we have the quarterly like recast that we do through the safe process, it gives us also the space that if something happened that requires us to deviate from the plan or course correct or whatever, we have a defined time and area to do that. In a perfect world, we wouldn't, right? Like we get everything right when we're first doing planning, but that's not reality. And so we just have this almost like this hierarchy of processes that help us stay focused on long term but then, give us the agility to change if we need to, but not like in the absence of a vision. And then you're all you're doing is changing because teams that are too agile, they have this negative perception that they're just changing the roadmap like on a whim. And there's zero accountability in terms of like when you're going to ship things. And then certainly there isn't the, what I find is actually the most important thing is like the alignment with the different teams. Because you can ship something if like sales or marketing or whomever isn't ready, then you're not going to exploit the things that just built. We've been very intentional with frameworks to make sure that the teams understand what we're doing and can be effective. And they have a say too. So it's not like a, hey, sales, I'm going to go give you these pieces of content that you can leverage. It's, hey, sales, for the nature of this new capability that we're going to ship on so and so date, what do you need? Of course, it's a back and forth, but at least it's not just a push. Sometimes I feel like people view R&D as like a push mechanism, right? Like to all the teams in the market, whereas now it's like bidirectional. So push and pull. Obviously we'll give you guidance for this type of new capability. Probably need these things, but you tell me if you think differently and we'll figure it out.
Melissa - 00:45:43: This has certainly been really enlightening to learn about your process. What are you looking forward to most going forward in redefining this and making it the Xactly way?
Chris - 00:45:52: For me, it's our pace of innovation, I'll say, because we, as I mentioned earlier, we went through this transformation to being a platform-first organization. And so now we get economies of scale. All of our products and capabilities are on this one platform. So we can build one service and then we can manifest it in all of our solutions. So it's like you build once, benefit many kind of concept. That coupled with this organizational rigor that we've put into place. And again, we've like, it's explained many processes, right? So we've also said, you know what? We think we've got a really good integrated framework of balancing short term and long term. Let's not continue to further unnecessarily optimize process. Now let's benefit, from the process and go ahead and execute. So we believe we have the platform. Obviously, we're infusing generative AI everywhere and all that. So that's like super cool on its own. But the platform in and of itself gives us the ability to deliver fast. And now we have the organizational muscle to like leverage that. So it's like the combination of those two is like a true one plus one equals three. That's like how we view it. Like to a certain degree, it doesn't even really matter what the innovation is. It's for us the fact that we believe we can ship stuff faster than certainly we've ever been able to. And as we do our competitive analysis, like we believe that we can ship much faster than our competitors, which will continue to build a moat from a competitive differentiation standpoint.
Melissa - 00:47:10: That's awesome. I'm looking forward to seeing what you guys put out there next. Thank you so much, Chris, for being on the podcast. Where can people learn more about you?
Chris - 00:47:16: You can reach me on LinkedIn. Obviously, you can go to xactlycorp.com. I mean, those are the probably two most logical channels to reach me. But Melissa, I really appreciate your time. Enjoyed our conversation.
Melissa - 00:47:27: Thanks for joining. And we will link to all of those links at our show notes at productthinkingpodcast.com. So make sure you go there and check out all of Chris's links. Thank you for listening to the Product Thinking podcast. We'll be back next Wednesday with another amazing guest. And in the meantime, if you have any questions for me on product management, go to dearmelissa.com and let me know what they are. I answer them every single week. We'll see you next time.