Working a Multi-Product Roadmap w/ Charles Caldwell, VP of Product at Logi Analytics

Hey everybody, this is Mike Belcedo, co-founder of Product Collective, and we're back for another industry interview. Uh, really excited for today's session. I hope that you are as well. I can see already in the chat we have people from all over the world joining us, so wherever you're at, um, thank you for taking the time for this. I just wanted to share a few quick things before we get right into the interview. Um, for some of you, this is probably the first time that you've ever, you know, joined us for an Industry Interview Chat. I also see some what I would call regulars as well. So for the regulars, thanks for coming back. But if this is your first time, I just wanted to share kind of a little lay of the land. So we plan these usually twice per month, and they're really, you know, video chats with product leaders from all over the world. And it's a chance to dig in on a specific topic, but also get, get you an opportunity to actually ask the questions that you're really curious about too. So On that note, you'll notice there is a chat and then there's also an ask a question section. Ask a question section is actually at the very bottom. So if you do have questions for our guest today, whether it's right now, maybe there's something that's on your mind knowing the topic or, you know, maybe something pops up as we're having the discussion, go to that ask a question section and just list your question there. I'll be monitoring that throughout. And I would love to ask your questions, you know, above my questions. I do have some of my own, but usually our audience has a lot better questions than I have. So if you could go ahead and do that at any time, that would be great. But the chat, and you're already doing this, that's a great way to share just where you're from, what products you're working on, and it's just always fun to see where everybody is from. As far as other things that we have going on at Product Collective, so, you know, this video chat, this is actually a part of Product Collective. We're a community for product people, and And we've actually had Product Collective for the last few years. And there's many ways that you could get involved with Product Collective. If you sign up at productcollective.com, you'll, you'll get invites to sessions like this. You'll get our newsletter every week, an invitation to join our Slack group. I think now there's over 8,500 people in the Slack group. It keeps getting bigger and bigger. It's almost at that 10,000 mark. But we also put on a conference twice a year called Industry: The Product Conference. And I am wearing my, one of my Industry shirts. In fact, I'm kind of thinking of making Industry t-shirts. That should just be my normal Industry interview outfits. I think I'm gonna do that. But we have our European edition coming up in less than 2 weeks now. Actually, 2 weeks from today would be the last day of the conference. So kind of weird to think of it in those terms. That's in Dublin, Ireland. And then we also have the global edition of Industry in Cleveland, Ohio this fall. And I'm excited about both editions. We should have probably 400 people in Dublin, 1,200 people in Cleveland. Those conferences keep growing. If you want more info on that, go to industryconference.com and you can check that out. But with all of that said, I want to get into the topic today because this is, this is one that for me, I've had a little bit of a luxury of being at places where we only were— or at least I was only really focused on one major product at a time. But for a lot of product people, maybe the most product people, they don't have that luxury. They're working on multiple products and they have to manage roadmaps for those multiple products. So today I have Charles Caldwell from Logi Analytics with us to talk that through. And Charles, I'll, I'll say hello to you now. How's it going?

Good. How are you doing?

I'm doing really well. Doing really well. So, no, I'm glad to— glad to have you on for this. And it seems like in your career, like you've had to manage this conundrum sort of multiple times. Is that right?

Yeah, well, and I'm definitely right in the middle of that right now at Logi. I mean, one of the things we've been blessed with is we're private equity-backed now, we've moved out of the venture phase. We've got a great marketplace and our investors have sort of empowered me not just to drive the product roadmap organically, but also through acquisition. So we're becoming quite acquisitive as well. So not only do I have to sort of work with products that I've dreamed up and sort of brought to market and managed, but increasingly we're starting to acquire products and have to rationalize those as well. So it's been fun, it's been sort of the next level of that game. So it's totally cool to be able to accelerate my own product roadmap, but you also, you don't just acquire pure IP, you also acquire customer base that you have to take care of with those existing products as well. So definitely living that dream right now, for sure.

That's awesome. Well, maybe where we could start is, you know, I imagine for some people, you know, they're probably in your shoes now, but maybe they were managing products before where they did have that sort of single product culture. The roadmap was all driven around that product. And I'm curious for you, maybe we could start with like, where do people usually, you know, go wrong when they make that transition? Like, do you— have you seen sort of, you know, mistakes or missteps that some people take when they, when they try to cross that?

Sure. So I think there are a lot of motivations that people have as they go multi-product, um, and I think a lot of those motivations, uh, can be dangerous. Uh, some of them are really good. I think the, the ones that, that tend to be— well, let me start with the ones that I think are really good. I think one of the things a lot of people will take for granted is how hard it is to build and maintain and execute a channel to market. So one of the things that folks will do is they'll try to take a product and start to apply it to different markets. So, and this is still single product, but this will start to lead into multi-product roadmap. So it's the idea that, hey, I solved this problem for one group of people, let me see if I can solve the same problem for different groups of people. And you start running into trying to build those channels and how hard it is. And then you'll also get kind of product fragmentation. I think a lot of folks will also invent new products to try to expand their market into other channels or other personas. I think, I think where that becomes extremely challenging, it's not just building out the go-to-market, but then you start getting different buyer personas, which then implies different product personas. And I think it's one of the things you really sort of have to be honest with yourself about as an individual in a product organization. You sort of have to assess your ability to really be empathetic and understand the needs and remember all the details and design for multiple personas who have different objectives, hopes, fears, dreams, requirements, all that stuff. So I think one of the mistakes folks will make as they start to go multi-product is when they're trying to do something like either forward or backwards integrate into a market. I was talking to a popular database vendor the other day, I won't name any names, but they're starting to experiment with kind of visual components, which is cool, but I suspect their technology group is going to have to boot up a whole new set of skills. Their product managers, it looks sexy, right? Like, It's hard to demonstrate a database. It's really easy to demonstrate visual components. But they're well differentiated in that database segment, and they're moving into a segment that we have sometimes described as a knife fight in a phone booth, crowded market. There's a robust set of capabilities there that you have to be able to meet. So a lot of times people will have motivations around going multi-product that are, that are around market expansion or around forward or backward integration. And it really starts to change the go-to-market, the channel, the buyer personas, and the product personas. And I think that's one of the biggest mistakes you can make. I think really where the sweet spot is, is when you're looking at a persona that you know really well and a set of capabilities across that persona, and you're starting to expand the problems that you solve for them and solve new problems for them. And I think that's where multi-product roadmaps get a lot easier because You don't have to completely retrain your marketing department. You don't have to completely retrain your, your sales department or build separate ones, right? The technical field will still need to get into the details, but the high-level value proposition is the same. And then as product managers, you know these folks, you've spent time really looking at the problems they're trying to solve, the context they're solving them in. And while you may be trying to solve new problems, you're not really trying to learn a whole new tribe of people. In doing that. So I think that's kind of my main caution is, as soon as you start introducing a bunch of new product personas by adding additional products into the roadmap, I just see that as kind of at least a yellow flag, if not a red flag, and really kind of test to make sure that you're going to be able to execute long-term on that strategy and really execute well.

Yeah, got it. Well, there's actually a lot of audience questions coming in, so that's Great. Keep those questions coming because I'd love to get to all of them if I can. One of them in particular though, it sounds like they might be at the stage that you were just talking about, like, hey, maybe we've evaluated the personas. It turns out that there are new problems that we could solve for these personas. But more specifically, I'll look at their question here. It says, we're a team of 13. We have a pretty active development pipeline for the primary product already. But we want to work on that next new product. How do we find the time to work on that current product, but also, you know, start taking part of that time and moving it to the new product? Like how, I guess, where do you get started when you've made that decision?

Yeah, I mean, this is hard. One of the challenges with a multi-product roadmap, so the first thing you have to do is sort of recognize in your portfolio where the products are in their own lifecycle. So, and if everything is all in the same spot in the lifecycle, it's super hard. So if everything's in startup mode, that's going to be extremely hard to execute on. If everything's sort of in more of a maintenance mode, that's actually easy to execute on from a development standpoint. You've got a different set of problems from a market growth standpoint, but that is one of the challenges. And if you're able to manage products in your portfolio based on their lifecycle, that's really how you start to think about how you allocate investment to those things. You know, different teams, as long as you've got shared resources across work streams, you're going to have headaches. And I'm not telling you, you can't do that. In fact, I think we all do it to some degree, but you sort of have to make sure that where you're having shared resources, you know you're going to have conflicts there, so you just have to make sure that that also plugs in to the level of investment that a product deserves based on where it's at. With brand new products, I'm a big fan of MVP-type concepts and validating that the product market actually exists. I would like to write zero lines of code to do that. We usually can't write zero lines of code to do that, so you just get as close as you can. So the very first thing that I would do, which I'm sure you all are already doing, but as a product person, I would really try to convince myself and validate that there are people out in the market that have the problem and that they're willing to pay for something that I'm going to be able to build to solve that problem. And as I'm launching that new product, you just really need to scope it very tightly. And then as much as you are having to kind of steal resources, from the main product. If you can slice those resources off to be dedicated for a short period of time, and I would even pick fewer dedicated resources versus trying to share the entire team across two workstreams, but there's just a lot of details there. So sometimes you have to do both of those things. You— and then managing the two cadences. So for heaven's sakes, I wouldn't synchronize release dates in that situation. So if you don't have dedicated resources to workstreams, you need to split the release dates so that you, you definitely have a different cadence for the different products as well. In those early phases, if you can do MVPs and betas that are unpaid and you don't have to make support commitments during validation, that helps a lot. Right? So you can sort of loosen up around SLAs on bug fixes and patches. The way that that helps is you get your prototypes out and you ship them, and then that team is going to have to immediately return back to sustaining and support and feature development on the core product. So a lot of it, I think a lot of that comes down to kind of the detailed execution of managing the workstreams. But then, of course, as a product manager, as much as you can protect the team from actually having to write code while you're validating the idea, you definitely want to use that discipline to help yourself out.

Great. I'm going back to another audience question. It sounds like, you know, this person might be in the same boat as Logy because they talk about acquisitions and partnerships. Their question is, how do you, or should you, um, represent acquisitions and partnerships on a something like a product roadmap? Like maybe there's something that you're planning to acquire, some sort of resource that might get you some sort of product, but Can you really even put that on a roadmap? Like, how might you approach that?

Yeah, so, you know, it's interesting. So first of all, typically in an acquisition phase, you legally have a responsibility to not talk about it at all to anybody until it's done. So I'm not a lawyer, I cannot give you legal advice, but that's my advice to you. So I mean, we sort of maintain a discipline where I don't even— I talk to my wife about everything, but not about acquisitions. She knows I might be in process, but outside of that, she doesn't know what it is, who it is, none of that stuff. And it actually makes her life easier because she doesn't have to know when she needs to lie, right? So if we have a work event or whatever, so she never has to lie because I just don't tell her. So don't ever do that, right? And when I talk about roadmap in all contexts, I will only talk about timing or capability that I understand that I'm 80% plus committed to. And the reality with acquisitions acquisitions is you're never at an 80% level until the deal's done. You sort of hover around at best a 75% probability until the deal actually signs. So in terms of representing that externally on a roadmap, never, never, ever, never, ever, never. As a product leader though, coming through an acquisition and out the other side, well, so one, targeting acquisitions, there's basically 3 reasons strategically you do an acquisition at a high level. You'll do competitive takeouts that are all about consolidating the industry. Those are generally the messiest as a product leader, because if you're taking out a direct competitor, there'll be a much more overlapping functionality you'll have to deal with. So you sort of address those things, you know, in their own unique way. There's roadmap acceleration or kind of a pure IP play. Where you are buying something to accelerate your roadmap, those tend to be a little bit cleaner in the sense that you typically don't have a bunch of overlapping functionality. With those, once it's in the door, once I know the deal's committed, as a product leader, I tend to set the expectation internally that we'll never integrate anything, right? And that's really just to buy myself time. Then as we get to kind of the integration and the roadmap acceleration, I just communicate that on the roadmap as I would communicate anything else, and very often I'm not communicating that as, "Hey, I've acquired a thing and I'm integrating it," although sometimes you'll need to talk to current customer base about the integration points because, you know, they'll have that concern. But in terms of sort of new business or new capabilities, I'll tend to talk about things that I'm getting from an IP acceleration from an acquisition the same way I talk about anything we've built organically. Here's cool new functionality or capabilities that we're shipping. Sort of the third reason you would do an acquisition is sort of a different type of roadmap acceleration. It's not by getting IP you're going to directly incorporate into your product, but it's by acquiring a product that is a near adjacency. So just a whole new capability that, you know, solves a problem for your target personas. And those are actually usually the easiest. And I don't want to say any acquisition is easy. But those actually, of the 3, are usually the easiest because you can on day 1 kind of go right out to the market and say, you know, hey, target buyer persona that we've been talking to for years, you love us for these reasons, and I know you have this problem. You're now going to love us because we can also solve this problem for you. You can tend to offer that as a standalone right out of the gate, depending on how much integration is desired between kind of the new problem set you're solving and the existing problem set. You may be able to go out with that as a standalone offering on day one, and it reduces kind of the pressure on roadmap out of the gate. But you may have to communicate integration roadmap as well. But before the deal is done, my advice is, you know, your closest confidant in your life, you shouldn't even talk to them about the acquisition, just to keep everybody kind of, you know, square with the requirements. There.

I think that that's a pretty good rule, so thank you for sharing that.

I like to stay out of jail and keep my prisoners out of jail.

Let's all please stay out of jail. That, if we could take one thing away from this session. No, but I want to take a lot of things away. So one of the— I kind of wanted to go back to, you know, especially because I think we do have, you know, folks here that maybe they're used to the single product roadmap, but now their company, you know, whether it is through acquisition, whether it is internally. Now we're getting that multi-product roadmap. Well, I'm just curious if there's any, you know, other major differences that we should be mindful of, you know. I don't know if that is, you know, way that we're communicating to internal stakeholders. I don't know if it's, you know, how far out the roadmap should be or shouldn't be. Like, maybe you could just talk to whether, you know, what are some of those major differences that we could be mindful of.

Yeah, so, um, Man, there's a lot. I mean, in terms of— I don't think stakeholder communication really changes that significantly, and I think with stakeholder communication, you always have to balance sort of this sense that you can never communicate with them enough on one hand, but on the other hand, you've really got to watch, you know, what I like to call cognitive load. If I dump too much stuff on you at once, or if I'm just they're all the time dumping stuff on you that tends not to be helpful. With multi-product roadmap, and you've already started to kind of hear me say this, in my perfect world, if I can have a persona buyer, technical economic buyers, that the marketing department will largely be able to kind of target the same personas in the same segments across as many of my products as possible, that reduces cognitive load on them and complexity on them. And as much as the individual value propositions plug into that, that helps a lot. So as a product manager, that sort of requires me, while I'm going to be super caught up in cool functions and features and all of the details, it does require me to look across my multiple products and say, okay, when I go to my CMO, what am I going to communicate to that CMO? And generally it's going to be about how much has the value proposition expanded or changed, how much has competitive differentiation changed or evolved, and, you know, can I avoid sort of having 5 products but 8 value propositions, right? You know, if I can have 5 products and kind of a core value proposition with some drill-down, that's better. So sort of my requirement. You always have to do that, even in single product you have to do that. And it's same thing with sales, you're right, you really want to tell them here's how you compete, here's how you qualify, so you're kind of next level down. Technical field is going to have to deal with more of the details because now we're really into the technical weeds, but your burden as a product manager just gets greater in the sense that with the single product you have to make those interfaces and translations, with multiple products you now have to not allow yourself to fall into the trap to say, all my children are special and different, and you must know everything about all of my children. That just won't work. So you do have to be able to go to stakeholders and give them kind of the news that they can use. Release cadence does become important. There is definite value in kind of synchronizing release cadences across products. The trick is, and again, sort of never underestimate the go-to-market and what is required to channel a product out to market and to sustain that channel. So while synchronizing release cycles can help you touch the field as few times as possible, you also just want to make sure if you do have 5 or 7 products, that won't be digestible. So doing things like kind of packaging up release cycles where the release cycles that synchronize make sense from a problems that they solve and the personas that they touch perspective. They're easier to market, they're easier to press release, the technologies are in alignment. So if you do have products that are on multiple technologies, or if you're channeling those through different field teams, you have different SEs or different support teams, synchronizing release cadences so that you're loading those teams on a cadence that they can absorb. I think all of those things are important, and it's interesting, none of that's really different than a single product, it's just now you've got to think about that across multiple work streams and kind of multiple value propositions.

Well, and on that note, and this question actually came in from the audience in a couple different ways, like how do you particularly manage it? Like, are there specific tools that you're using, or I guess what's been helpful to you to to sort of like nuts and bolts manage the process?

Yeah, I mean, so, um, I suspect all of our tooling is pretty similar to what everybody's using out there. I mean, at a detailed level, we're in Jira to kind of manage sprints and stories. I think the— for this particular problem, the tools that I tend to use to try to manage that tend to be between, um, sort of mind map PowerPoint style documents. So, you know, MRDs and PRDs down to Trello, so more Kanban level. And at the Trello level, we tend to manage roadmap deliverables in Trello as a Kanban at that higher level, and that's what helps me see past the detail and not get caught up in all the individual features. I deal with that as well, but that helps me see the story of what's coming and when it's coming. It helps me take those pieces and assemble them together and say, does this make sense? What's going to hit the team? How are we going to talk about this in the market? What is it that support's going to have to learn? And then making sure that we're timing those things in a way that makes the most sense. We also do have products that kind of have relationships with one another. So we do have— we deliver kind of a overarching platform product, and then we have modules that will plug into the platform product. So there's also kind of relationships there where you may be making core engine updates that will have later impacts on other releases, and whether you choose to bring those out together or stagger those can have impact on the team. And that, that higher order look— so the MRD kind of informs me on what's useful to the to the product or to the market and what personas. So that kind of answers the question of timing on hitting different personas in the market and the problems that we're solving. It's that Trello board that helps me see that, you know, enough detail to start to answer the questions of what things should come out when, but not so much detail that I can't sort of see the story behind it as well.

Great. Thank you.

I have, of course, rely, rely on product management team that I work with as well. So I do have folks that I work with that, you know, kind of help keep me straight as well as in making that translation between the details and the—

and I'm sure you are very grateful for them.

Yes, I am.

Well, I— there's another, and we don't have time for too many more, but I definitely want to get at least, at least one more in. Um, it's coming from the audience. It seems like this particular person's in a situation where their, their product, they're battling some technical debt here, you know. And so it's getting to that point where they may have to make the decision, hey, should we rewrite this altogether? Their question is, how do you treat that? Do you treat it as a whole new product altogether? Are you kind of now managing— is it like a multi-product roadmap even though kind of the same product, you still have a product to manage. Yeah, just any advice for them?

Yeah, so, so, so my high-level advice is, is, you know, rewrite it and treat it as a new product. Let me give you a little bit more nuance though, because we don't live in a world that's quite that simple. The way I think about this is, is it refactor or is it rewrite? And that is a It's a continuum. You're going to have to kind of decide. But if what you're talking about is sort of, I'm going to take 20% of the products and I need to refactor it, and that's kind of big, but it's really a refactor, and at the end we end up with the same product that just has, you know, a lot, quote unquote, of new code, you're still on the same product and that's a refactor and it can be painful. If you're doing things like complete rearchitecture or you're sort of at the 80% of a rewrite, I would rewrite it. And the way I personally view this, if somebody's going to commoditize my product or if they're going to steal my market share or steal my lunch money, I'd like it to be me. So I tend to, when we get to that place, and this is where I was talking about that product lifecycle, technical debt can happen for a lot of ways. It may be that the product's 15 years old, very mature. So you just got a ton of lines of code. It was built on an old architecture. Maybe you built it wrong. Who really cares? But at some point you're going to look at a codebase and either because of market adoption or because of the technology, you're going to say, I need to move this into maintenance mode. And my advice to you is you probably need to do that before you feel comfortable doing it. It's one of the scarier decisions we have to make as technologists. And as a product manager, I would encourage you, and you're going to have to sometimes drag your engineers, they're fighting, sometimes they're out ahead of you, but you're going to have to bring them along. And with the big refactors, I would absolutely encourage you to treat it as a new product. It's a new startup. Start rewriting that code earlier than you think you have to. And in the launch, and you will have to figure out how you bring existing customers along, that's a, it's an important concern that you'll have to to consider, but you're going to have it no matter how you do it. So I would sort of free myself from, you know, answering all the backward compatibility questions right up front. I would free myself from sort of prevaricating about the decision, and I would launch it like it's a new startup that's designed to put the old product out of business. And that's not being negative internally, it's just like, that's the spirit that you should have, and that's the way you should pursue it. And in the roadmap, the conversion of the existing customers just needs to become part of the roadmap once that new iteration is mature enough for it to be able to address the use cases of the customers on the existing product. And then of course, that existing product, you need to commit to having a maintenance stream there that's going to keep your existing customers in a good spot while you're getting that new launch done. So that's kind of how I think about it.

Yeah, I think that's a— I think it's a great way to think about it. So thank you for that. And, and I'd love to ask you a lot more, but We're really at the end of our time, so time always goes by fast, but I appreciate you being a part of this. And maybe, because there are some questions that we didn't get to, is there like, what's the best way for people to keep tabs on you and your work?

Yeah, well, so a place you can always sort of see what's going on with us is logianalytics.com/blog. So we do a lot of content. We are very much focused on product managers and developers. We build platforms for them to embed analytics in their product. So a lot of the content tends to be relevant to an audience like this. We talk a lot about a lot of the things we were talking about today and other struggles around launching products. So you can always check us out there. If you go to the logianalytics.com website, you're going to find my email on the leadership page. It's charles.caldwell@logianalytics.com. So I'm not going to hide it from you because it's already out there. You can always feel free to reach out to me if you have questions or things you're struggling with. I'm more than happy to help any of you and The only thing I ask in return is I might want some advice or good ideas in return. And so I'm always happy to have those exchanges.

That's awesome. Well, thank you for offering that up. I hope people take you up on that. And thank you for being a part of this. And to everybody attending today, thanks as well. I know this takes time out of the day, but hopefully we'll have you back for future product interviews here. And we have a couple more coming up. So for everybody else out there, check those out. We also have— we're in the middle of a new season on Rocketship.fm, our podcast. So it's a— we took a little bit of a different turn. So it's a story about what's going on in Cleveland, Ohio, as the city's trying to become a blockchain city. It's kind of interesting. So a little bit out of the product, sort of, you know, the usual product episodes that we do, but it's pretty fun. So check that out as well. And yeah, hopefully I'll see everybody soon. And Charles, thanks again.

Absolutely, thank you.