Jason Knight 0:00 Hello and welcome to the show. I'm your host, Jason Knight. And on each episode of this podcast, I'll be having inspiring conversations with passionate product people. If you like the sound of that and want to hear from me and some of the finest product thought leaders and practitioners in the world, why not head over to one night in product.com, where you can sign up to my mailing list? Subscribe on your favourite podcast app or follow the podcast on social media and guarantee you never miss another episode again. On tonight's episode, we talk about getting our products to market in an effective way rather than just dumping them onto product marketing at the last minute. We talk about making product marketing a strategic partner in our product development efforts, what we need to think about when planning our launches and what the impact is if we don't. We also ponder whether all this agile stuff works very well when you're releasing complicated products to clients with a long sales cycle. and how we might give ourselves the best chance of success. For all this and much more please join us on One Knight in Product. So my guest tonight is Derek Osgood. Derek is a self-confessed sci fi and fantasy nerd former Playstation product manager, one time horse rider and show jumper who worked in a variety of marketing roles before jumping the biggest hurdle of all into company foundership. Derek wants to address the underappreciation of marketing in the world of tech, and wants to make sure we all give our go-to-market activities the right level of investment and attention. He’s doing that with his new startup Ignition, a platform that boldly claims to save you 30+ hours on your next launch - that’s the sort of figure that would put Elon Musk & Jeff Bezos to shame. Hi Derek, how are you tonight? Derek Osgood 1:30 Not too bad. Not too bad Jason. Excited to chat Jason Knight 1:33 Should be good... looking forward to getting some launches going. But first things first, before we talk about all of this cool stuff. You're the founder and CEO of Ignition. So what problem does Ignition solve for me? Derek Osgood 1:44 Yeah, so Ignition is really trying to solve for a lot of the stakeholder alignment that happens around launches, trying to simplify that, as well as also just help companies build bigger, better launch plans, you know that so we kind of hodgepodge together a bunch of different categories of tools. So we give you project management baked into asset management, as well as documentation. But we've actually layered into those a bunch of best practice based workflows to help you actually execute the work around launches. So we'll dynamically create plans alongside you will actually help you to conduct things like pricing research. And then we'll also bake in, you know, AI copywriting to help you generate assets as you're getting to market. So there's a whole bunch of different things that we're doing. It's kind of a big, unholy beast that does all sorts of stuff. Jason Knight 2:27 But we'll talk about about that beast in a minute, and go-to-market topics in general, but by trade, you're a product manager back in the PlayStation days, although I think to be fair, that looking at your LinkedIn that was a lot more marketing focused as well like this, a lot of the product management work you're doing there seem to be kind of getting these games out into the market and promoting these games. So not quite what we'd call sort of digital product management, as I'd know it. And also, then obviously, moving on into marketing and growth in other companies as well. So you obviously a marketer, through and through. What was it that made you decide to jump into the deep end of the startup swimming pool? Derek Osgood 3:03 Yeah, it's interesting. I mean, I think, historically, I have viewed marketing very much through kind of like the lens that I would say traditional kind of brand management roles do where it is a bit more holistic, and like mirrors product management a lot more closely. And I think that that goes back to, like you said, my PlayStation days, I was a, you know, quote, unquote, PM, but really, it looks a lot more like a brand manager role in kind of a publishing ecosystem like that. So you know, I think, generally, one of the things that I had been frustrated with being in pure play marketing roles for a while was that until more recently, there just wasn't as much impact on product that you really need in order to effectively market product. And so I think, you know, startups inevitably appealed to me, because they just allow for a lot more kind of like cross pollination between product and marketing and growth, and you're ending up working more holistically across the full stack as opposed to living in you know, one small little slice of Marketing Land. Jason Knight 4:06 Yeah, so what was that first jump then into more of a product marketing role? Like, was that a very intentional or did you kind of happen upon it, when you were working for a company that happened to be doing product stuff, as well as traditional marketing? Like, how did that transition work? Derek Osgood 4:19 Yeah, it's funny, I feel like, I feel like product marketing is a very, very new role in most cases. And you know, back when I made the jump from PM to PMM, it really didn't exist for the most part. And I think I ended up joining a company that just happened to have a CMO who was a big believer in product marketing and he kind of just looked at my experience at PlayStation was like you're doing product marketing. It's not called product marketing today. But I think you know, we should put you in this bucket. And so you know, for me, it was it was a pretty logical jump. I wasn't intentionally seeking out you know, a role titled, Product Marketing Manager, but I was looking for something that had more kind of holistic go to market management. experience. And that was kind of where I landed. Jason Knight 5:03 Yeah, it's funny. Like, I've spoken to a bunch of PMs in the past, like product managers who've said that they've sometimes happened upon product management in much the same way. Like they were doing some work for a company, probably building some kind of product, somehow, and what would have been called a product manager at the time, but at the same time, they kind of all of a sudden, like, wake up one day, like, holy crap, I'm a product manager. So it's just like, kind of like a parallel path there. Derek Osgood 5:27 Yeah, totally. Jason Knight 5:28 But let's get back to that beast. So you've been building this, I think for a few months now. Ignition, the platform. Yep. And you've kind of touched on it that you are covering a bunch of use cases, presumably, there's a bunch of use cases that go to market people need to fulfil. So that's why I've done that. But if we were talking about traditional lean startup type thinking, then you'd probably just pick one of those things, and get good at or even if we go to Marketing Land, like Crossing the Chasm. You'd go in there and you'd go super tight, you would really specialise and own a certain area for maybe a certain segment of the market, and then expand outwards. But you seem to have gone a bit wider than that from the off, like, is that something that you did very intentionally? Or was it something where, as you were building it, you just realised that it wasn't sustainable without some of this functionality? Derek Osgood 6:15 Yeah, it's a little both, you know, I think the challenge with any kind of platform product, like what we're building, it is, you know, very, very difficult to identify, like, what is the starting point. And I think that's fundamentally the the core product strategy challenge that we've been dealing with. And I think user feedback has definitely pulled us in the direction where we've ended up building more than we originally intended. And so we started out and we were really just kind of a documentation tool, it was a good place to like house plans in a way that was digestible for everybody. But then, as we've talked to people, there's been more and more requests for collaboration, functionality, there's been more and more requests for actually helping to execute some of the work. And we've also discovered that building pure play documentation, tooling, just kind of didn't differentiate us enough in the early days from existing documentation or roadmapping tools. And so we wanted to, and we always wanted to build these workflows into the product. And we just thought that we would do them later. But as we've gotten feedback from people, we've just discovered, like, hey, we need to build this as well. And I think the other interesting thing about go to market as a problem space, which is kind of uniquely forces us to do this, is there isn't one individual pain point in go to market that is so acutely painful that like people have a really high willingness to pay for it. And they're really willing to unseat their whole existing process around it. There's like 10,000, little paper cuts. And we almost need to solve for the 10,000 little paper cuts, because people are dying of it. And they're like, go to market is incredibly painful. And I need it solved. But without solving all of those little problems along the way, you don't really solve for the big painful, hairy problem. So I think that's kind of like how we ended up evolving into that over time. Jason Knight 8:00 But I'm presuming that you, if you raised money, or if you bootstrapped, then you kind of did that with a certain amount of, for example, engineers and a certain amount of time, certain amount of runway you had in mind to get that done. And it sounds like what you then ended up doing is presumably quite legitimately scaling up your ambitions from the off. And that presumably then meant that you didn't have enough engineers or that it took you longer to make like, is that something that you had to struggle with them? Which way? Did you go? Did you have to make it take longer? Or did you have to hire more engineers to fix that? Derek Osgood 8:31 Yeah, totally. So I, it's funny, because I, when I originally came up with the idea around ignition, my plan was to bootstrap it and like do the indie hacker thing. And I was, I was gonna basically solopreneur this and build a no code version of the product. And I started building one myself. And you know, it came out pretty well actually, I was like, very impressed with myself as a non tech founder for what I ended up making. But essentially, you know, I put it in front of people. And I just realised there was a lot more functionality that we needed in order to solve for this problem effectively, that we ended up going out. And like when I met my co founder, we ended up going out and raising, you know, a pre seed round. And in talking to investors, there was so much resonance with this problem, like people just really understood how painful this was at, you know, bigger companies. And they're like, No, you need to go a little bit bigger on this. And I think we generally agreed after having seen some of the early feedback. And so we ended up Yeah, scaling up the team. We did like take a little bit longer to get to market than what we had originally, you know, mapped out in our milestone roadmap. But ultimately, part of that was we just discovered there were more product requirements than what we had originally specked out. And we ended up needing to scale up the team. So we now have a team of 11 folks, mostly engineers, and we just shipped a product last week and we've been basically building for nine months when the original spec was to build for about six months and then get to a beta but took us little bit longer than that. But we're here now. Jason Knight 10:02 Oh, there you go. And congratulations on the launch. How did ProductHunt treat you? Derek Osgood 10:06 Well, well, we we got a couple 100. signups we got we were in the number two spot of the day for most of the day and, you know, ended up kind of slipping very at the very end, but still ended up top four. Yeah, when went really well. We're getting great feedback now that we're live from from folks that are seeing the product been onboard, you know, been in kind of nonstop onboarding calls for the last couple days, which has been fun. And nerve wracking. Jason Knight 10:31 But product led growth is one of those things that's very on trend at the moment as a kind of acquisition and an onboarding strategy. Is that something that you've been talking about onboarding calls? So it sounds like you're not 100% in that area yet? Because you're presumably offering hypercare to your first clients and stuff like that. But is the goal to be kind of from a marketing perspective, a product lead and acquiring through the website and doing all of that sort of in our pop selling? Or are you going to be kind of going white glove for a bit? Derek Osgood 10:59 Yeah, so I think I'm a firm believer in kind of hybrid go to market motions, where you actually have, you know, a product lead component, because in part, it forces you to actually build the product in a way that's intuitive. And it forces you to build a flow that's useful to even somebody who you onboard through a sales call. But obviously, you run into some some customers who, especially with a problem, like go to market where you know, they have multiple stakeholders that they need to get bought in, you have longer buying processes. And you know, or they're just bigger companies that need a little bit more hand holding. And so our view is that we're going to do both. So we'll probably inevitably have like one salesperson who's kind of going out and headhunting, larger organisations, but then for most of the companies that we're bringing in, we'll try and convert them through product led growth. And today, what we're doing is I'm personally trying to just get on as many calls as I can, like most of these people probably would rather that I don't talk to them. I need the feedback for the product. So you know, in our onboarding flow, we've actually embedded a bunch of prompts to try and get people onto demos with me, even though they don't have to take those. Jason Knight 12:05 Okay, so you're kind of combining a bit of product discovery in there as well, which all people should be doing. So good call. Derek Osgood 12:12 Yeah, most of these onboarding calls, or people probably don't need them there. But I'm using them for feedback goals. Jason Knight 12:18 Fair enough. And did you use your own platform to plan your own go to market activities? Or did you have to use a competitor because you weren't quite ready yet? Derek Osgood 12:25 No, we did. I was, it was nice, because we were planning it out. And our product definitely was not quite ready yet at the time I was going through it. But luckily, we were kind of pushing fixes. And I'm sure my Inge team did not appreciate me constantly being in there mapping things out and blobbing slack messages on a daily basis about things that were broken that were already on the roadmap, but yeah, we did. Jason Knight 12:48 I'm sure you've given them all a nice little break. And you haven't just started whipping them again, straight after lunch as well. Derek Osgood 12:53 Yeah, we take some time off for the holidays. So everybody, everybody got some little R&R, but I still probably need to give them a little bit more. Jason Knight 13:01 Wow, there you go. I'm sure if they're listening to this, they'll be horrified. But go to market plans. I mean, in theory, it sounds simple, right? Like, we just need to go to market with our stuff. And in an agile world, which we're all claiming to be in these days, we're iterating all the time, we're continuously deploying value to our customers. And that seems to kind of collide a little bit like if we're continuously deploying value to our customers and iterating all the time, then surely, we don't need to go to market plan at all. We can just push stuff out whenever we want, right? Derek Osgood 13:32 Yeah, I think it's funny because there's this friction that exists today between the way that product development has evolved into, you know, a truly agile format, where you are just shipping things, and you're iterating on them constantly. And the way that like marketing has to function, which is much more waterfall based. And it's like anytime you want to make an announcement, there's this whole cascade of work that has to happen in order to make sure that customers you have the assets needed in order to actually communicate that to customers in order to make sure that you actually have the sales if you have a sales team or a support team that those folks understand how to talk about the product. And we really are trying to solve for kind of meshing those two things in a better way. I think, generally you have, if you're a company that is very much like growth, marketing heavy, oftentimes, they feel like, you can just ship things, and then you'll iterate on them. And then you'd like maybe send an email to customers. And that's all you need to really get the thing launched. But the reality is like your open rates are probably best case 60% on your emails and customers are opening, half of those are probably opens where people aren't actually even reading the full email. And they forget about that thing that you just shipped very quickly. And so you actually need to have a much more concerted process where you're explaining things up multiple different touchpoints to users, and enabling your internal teams more effectively in order to actually have them be your best champions because ultimately your team is your best marketing channel. And so I think companies tend to forget that they tend to think like, oh, just because we built it and put it in the product, and we have some notification that went out to customers, everybody now knows that it exists. And you there's actually a much more ongoing educational process that's required in order to get true adoption around products. Jason Knight 15:20 Yeah, and one thing I've been thinking about recently, and again, this is in this kind of Agile world that we all claim to live in, is how much that agile mentality clashes with, for example, companies that have really long sales cycles. So like, if you've got like a three months, six months, nine months sales cycle, that can be a problem, because if it takes months to sell the product, we don't just want to like Kick off those marketing efforts, like you say, at the point that that gets launched, because then we're not going to see any sales for 3/6/9/ months. And also from a product perspective, even if we didn't care about sales, which we absolutely should, we're not going to get any feedback on those features, not real feedback, not like live feedback for that the six, nine months. So it's obviously an issue and you've caught it out yourself there. But are there any? Or have you managed to solve this in any of your roles, or people that you've spoken to when developing this product, like a way that you can try and smooth or ease the pain of that disconnect? Derek Osgood 16:18 Yeah, well, so actually, before I jump in and answer that question, I want to add one more point to your kind of the previous question. I also think it's really easy for companies to hide behind the idea that like we're agile, and that we're constantly testing various things, and say that, because they're agile, and because they're constantly be testing, and because they're constantly iterating, that they don't need to go through the rigour of actually thinking through like, who are we building this for? Why did we build it? What is the value that we're delivering, and those are the real work that are involved in a true launch process? So having a good process is equally as important for just forcing you to go through the strategic rigour that you need in order to actually like deliver real value to customers and communicate that value. So to your question about marrying the two, I think, you know, the biggest thing is actually not something that our product can solve its process problem, which is that the product team and the go to market teams just need to be in communication earlier in the process, like, it's very common at most companies, for the product team to start building something. And the marketing team doesn't even know that the thing is on the roadmap until, you know, months, months later. And it's when it's a couple of weeks out from actually shipping. And so there's just no time to actually effectively plan. And we do a little bit around that in our product, like we will surface things from JIRA, and from product board that looked like they may need a launch plan around them in the near future. But it's kind of imprecise. So really like where this, where this starts to get better is when you actually have effective roadmapping tools on the product side of things that are communicating upcoming stuff, to the go to market folks. And then you have the go to market team actually having a launch process where they can execute it quickly enough that they can actually do the planning work like that's the other area where companies often fall down is that they don't have a quick enough nimble enough process that's actually adaptable to the different like sizes of launch that that occur, that you they just kind of like hand wave it away. And they're like, oh, we can't launch that we can't go through a process on that. Because we don't have time that things you know, we have five other launches going on. And that thing's launching in two weeks, we'll just send an email, we'll just shuffle it into the company newsletter. And what we do there is we really do actually have dynamic plans that help you to create the plan faster. So you can spend the time on the actual important like thinking work that's needed around planning, launch, establishing strategy, writing, copy, that sort of thing. Jason Knight 18:55 So you've mentioned dynamic plans a couple of times, and obviously you touched on the kind of AI copywriting. But have you got any AI functionality like building those plans? Or is it more of a decision tree based around a few scenarios that you've kind of pre planned? Like, how advanced are those plans get? Derek Osgood 19:10 Yeah, so today, it's pretty much a decision tree, we plan to actually like build in some machine learning logic into that and make it a little bit more intelligent. But the decision tree itself is already a big time saver for most companies. Because if you think about it, like when I am going through a planning process, even just putting in line by line, like all the dates into a project plan and saying, Hey, here's the things that need to get done. Same work back schedule that we've run 100 Different times on 100 Different launches. But now I know this launch is landing on July 3, I need to now go line by line and a project plan and update exactly what those dates are. That takes a long time. Then you have Yeah, once you've laid out what my promotional plan is, and you're like, Hey, I'm gonna run promotion through the company newsletter and Facebook ads, etc, etc. Just going through that list and saying okay, What are the five to 10 different assets that we need to create in order to support all these channels, it requires just a bunch of additional thought and cognitive overhead that burns people out and makes them just decide to skip the launch process. So what we do right now is we'll look at as many signals upstream as we can, like launched here, the type of thing launching the channels that you've chosen to select to promote through, and then will cascade out like task lists will cascade out asset plans, that sort of thing. And today, it's a it's a pretty simple decision tree, but still saves hours of time. Even just with that. Jason Knight 20:36 30 plus so the advert says, but are you aware of any real world failures, either ones are anonymized because they're secret, or ones that are publicly available, or ones that you can just share anyway, and don't care if anyone finds out of companies or products that have kind of skimped on their go to market activities or kind of skipped on their launch plan and ended up crashing and burning? And in ways that really could have been avoided? Like, are there any cautionary tales from your career or examples you use? Derek Osgood 21:06 Yeah, I mean, I like I don't tend to have a specific example that I pull for this. I mean, I've seen 100 of these companies that I've been at. And unfortunately, you're like talking about the the negative scenario where it's like, we don't know if those things would have been successful, had they been properly planned, or we don't, but I've definitely seen, I mean, especially like at PlayStation. And I think you've probably seen this at a bunch of different Google products as well, like Google's notorious for shipping things, and then not really putting adequate resourcing behind them, and then having them fizzle out. PlayStation Move was a good example, when we were there, it was the first motion controllers for any console, and we shipped it and you know, I think it got some kind of lukewarm reception at first, and then immediately, like, kind of got under resourced. Following that, but it had been under resource from the start, there was like, one person kind of shoved back in a corner, dedicated to planning this thing with limited like cross functional coordination, and like, no budget support. And you know, I think it just kind of fizzles out and dies. And this is common across software companies, it's common across physical products, companies is just when companies do not actually invest the time and energy in trying to get adoption around a product that it doesn't get adopted. And everybody thinks, like, oh, we built it, and we push it live, and we send out an email. But without a little bit more than that. It just never gets gets picked up by customers. Jason Knight 22:32 Yeah, no, that makes no sense. And I think it's really important to make sure that you have that alignment. I mean, I think that's one of the things that has come up several times in this call is like, having that alignment between teams and making sure you're on the same page and you've got a process mapped out seems to be kind of the key to all of it. But is it just as simple as just keeping aligned and making sure everyone's on the same page and updating your project plans or other kind of other aspects in your mind? Or in your view of a perfect go to market launch plan? What does that look like? Derek Osgood 23:05 Yeah, so I think there's some strategic components to this too. So oftentimes, the other big pitfall that companies run into is they just don't do any research round a launch. So typically, the product team will have done some upfront discovery research because they have to in order to build the product, but the teams that are actually responsible for communicating that product, they never talked to a customer, or they never actually, they never conducted any surveys, or they never collect any kind of input into their messaging. And all they do is they take the product teams brief. And then they turn that product teams brief into copy that sounds marginally similar to the existing product spec. And I think that this is an area that, again, gets like overlooked because of the fact that teams are just trying to work so quickly. And there's so little time to actually go through the planning process. And going through the process of doing a user recruit for user interviews, or going through the process of conducting a pricing study that actually gut check whether or not the pricing that you have structured is the proper pricing and packaging strategy. Those things just take time. And without tools that helped people to actually just do that stuff faster. They get overlooked. And I think, related to that. There's also some general strategic issues that companies run into when you know, especially you have like junior folks running the launch, which is very common you off, like product marketing, as I mentioned, is a relatively new role in the industry. And so you have a lot of people who have come to product marketing from non product marketing functions, and they're trying to figure it out. And they think that the strategy is the copy that they write. And the reality is there are actually very, very different kinds of approaches to the channels that you're selecting very different approaches to the types of assets you're creating very different approaches to the way that you communicate the product that come dependent on the kind of adoption strategy that you're targeting, whether it's category creator category penetration, whether you're trying to switch users from a competitor, all of those things really dramatically impact the types of tactics that you're using, as well as the way that you're talking about them. And companies just often don't even think about that stuff, they just write some copy and think that it's a one size fits all approach to every launch. Jason Knight 25:20 I guess your decision trees will say otherwise. Derek Osgood 25:23 Yeah, totally, we actually have I mean, it's, again, pretty simple format right now, but we have some tools that help you actually come to the conclusion of which objective and kind of general marketing strategy you should be using, we actually cascade out promotional plans based off of your objectives and based off of your budgets, so all of those things, you know, we're taking into account Jason Knight 25:44 Sounds good. But you've touched on it a couple of times about the relative newness of Product Marketing. And we've touched a little bit on some of the problems you might have when you have a disconnect between, say, the product team and the product marketing team. And obviously, as a product person, myself, I think that's a terrible situation to be in I well, I want marketing and product to be as close as possible. But what are some ways that we can, or what are some things that we can do to help bridge that gap and get the product marketing and product management teams together and kind of aligned and going sort of hand in hand down the road, Derek Osgood 26:20 I think the biggest piece of advice that I would give is just like roping product marketing, like viewing product marketing, not as like the mouthpiece for the launch, but actually viewing them as like a partner going through the development process. And I think the best aligned product and product marketing teams, typically they're viewing product marketing as an input at the very earliest, like product discovery stages, and they're going out and like tag teaming, user interviews, and then you know, actually feeding the market research that the product marketing team may be doing into the actual roadmap itself. And that also gets that eliminates so many downstream problems that eliminates the problem of, oh, hey, now all of a sudden, the product marketing team is getting blindsided by a launch they didn't know was coming. That never happens anymore. Because all of a sudden now they're actually involved in the earlier roadmapping stages and understanding exactly what is getting built and why it's getting built, because they've actually been involved in those customer conversations from the start. And I think that is probably fundamentally the biggest way that those two teams can get aligned. The other, the other big one is just really getting clear about roles and responsibilities and like understanding exactly what the definition of Product Marketing is at your company, and what the definition of product is, because I think there's a lot of, there's a lot of like, overlap between those two roles. And you know, it can be really fuzzy if you haven't actually explicitly defined where one starts and where the other ends. And you know, I think I've, I've historically tried to articulate this as like, both are kind of p&l owners, but the product teams kind of owning the P part of the p&l, and they're really owning kind of the bottom line. Whereas you know, the, the product marketing team is kind of looking at the at the top line revenue. And those two things can't exist independently of each other. They're, they really have to be tightly matched. Jason Knight 28:08 Yeah, for sure. But we spoke before this about the future of Product Marketing. And one of the things that you called out was, as you put it, the verticalization, project management tools, and how all these tools are too flexible. And you need specialised platforms really to hit the spot for product marketers. Now, to be fair, if I was just about to launch or just launched a platform for product marketers, that's exactly what I'd say to. But what do you mean by the verticalization of project management tools? Derek Osgood 28:35 Yeah, so I think the the project management tools today, they really evolved, because I mean, inevitably, we all need to somehow track the work that's getting done. And you know, when you're talking about like larger teams, you need to be able to track all the work that various folks across the team are doing in order to build manage them. And that continues to be true. And that's never not going to be true. But the reality is like, oftentimes, the tracking of the work gets in the way of the actual doing of the work. And I think when you are a very verticalized team, like an inch team, you know, a dedicated, like a single project management tool that only does project management only does task tracking can be really useful to you, because everybody's kind of working in exactly the same way. And they're working on exactly the same type of stuff. So tracking it in one consistent platform makes sense. But product teams and VMM teams, they end up having to straddle multiple different teams. And so oftentimes, like it's impossible for them to even track everything in one tool, because you have the design team living in Asana, and you have the team living in JIRA. And then you have somebody on the marketing team living in a Coda doc. So when you don't have a tool that's actually verticalized, around the use case that you're trying to solve for, in this case, product marketing teams with go to market, you end up actually spending more time jumping between these tools trying to track the work that you're doing than you do on the actual work itself. And so my take is that the future Have where tools in general are going to end up evolving towards is that you're going to have a stack of departmentally focused tools that are really verticalized around a use case. And in our case, we feel like we're doing that for Product Marketing, where you have workflows baked into those tools that actually help you to do the work involved in the process. So for us, you can go and you can conduct research, and you can create assets, and you can actually houses assets, and you can communicate all of this cross functionally. And the tracking of the work like the project management component of our tool is really secondary, it's kind of a byproduct that happens as you go through all the different steps that are involved in getting a product to market. And then what we do is, rather than trying to own the project management stack, and I think this is where a lot of the existing kind of horizontal SAS built around, whether it's documentation or project management, falls down is that because their goal is to own the entire organization's project management, they fundamentally like require everybody to fit within their structure of how this work happens. But all these different projects look totally different. And so by verticalized, in this stuff, you can then give every team a thing that fits their exact workflow, but still connects into the ways that other teams are tracking their work. So you know, I think that you're gonna see a lot more of these kind of vertical tools pop up, you're starting to see it already with product team tooling, like product board, us for product marketers, you know, I think you you see this with, like, Gainsight for Customer Success teams. And so there's a bunch of tools popping up that are much more departmentally verticalized. Jason Knight 31:39 But you touched on it a little bit there, this idea that some of these teams are straddling multiple different teams, because of the work they do the sort of cross functional initiatives that they're working in. So ultimately, no one wants to log into 12 tools. Right? So yeah, I guess the argument there is that we just want to make sure that they all interoperate as much as possible, right, and have those kind of on ramps and off ramps to get the right data in and out. Or you've touched on that a little bit with your platform. I think St. You can get stuff in from say Jira, for example. So is that really the the way out of the 12 login problem that you see? Or do you think that there's going to be inevitable, almost like reverting back to that in due course, when people realise that they're going to have to log into 12 tools? And they probably just want to go back and use one again? Derek Osgood 32:21 Yeah, I think I think the biggest way to solve it is definitely interoperability, like building out integration ecosystems that are really actually fit the work that's happening. In our case, we don't care if you do all your project management, in Asana will let you import all of your project tasks, from asana and our tool. And so you know, we just try and make it as open and flexible as possible. I also think that there's another thing that happens where, within organisations, there's only like, a certain set of information that everybody across the company really wants and needs. And so, you know, you'll probably see a few tools. I mean, in our case, our philosophy is obviously that like our tools, one of these tools were launched information is something that people across the organisation actually all care about. And so having a dedicated tool around it makes sense, because it's a piece of information that people are actively trying to go and access. Yeah, whereas you know, if you're talking about like the project plan on the engineering side of things like most of the company doesn't really care about that they care about, like, when's the thing actually launching, and what's the tool, so they don't want to go look at reports in JIRA. And I think we'll see more of these tools pop up where there are certain ones where they focus on trying to bring people in and be the visualisation platform for the company. But the rest will kind of just have to fall into a integrated experience that works interoperable with other tools. Jason Knight 33:44 Oh, that's everyone's backlog sorted for the next couple of years. So now, I'd like to ask you for one piece of advice for anyone sitting there today struggling with their go to market progresses, unable to launch their products effectively, and not really sure where to go next. And obviously your platform might help them with that one day. But before they sign up for that, what's one thing that they can do to make their lives a little easier, or one principle that they can try to live by. Derek Osgood 34:10 For one thing, I would say hire a product marketer don't have one already. Another big one is don't spend it this is gonna this is gonna sound funny, but it's don't spend too much time on launches. But also don't spend not enough time on launches in the Goldilocks zone. Yeah, get really, really good. It's actually not even about the Goldilocks zone, though. It's really about get really good at identifying what launches matter and spend there build out a tearing infrastructure like if you don't There are so many companies that I run into that don't have an existing tearing infrastructure for identifying which launches should we actually focus attention on. And so they end up spending hours and hours and hours on these little tiny launches that don't really move the needle. Yeah. Versus under investing in ones that really they should be spending probably 80% of the company's time on. Jason Knight 34:59 Yeah, so making sure they put the right horses in the race is the key there. And where can people find you after this if they want to chat to you about go to market or launch plans or maybe come out and try your product? Derek Osgood 35:11 Yeah, totally. So we're at HaveIgnition.com kind of like we have ignition ... a little play on astronauts. And if you want to get a hold of me directly, I'm always available over email at derek@haveignition.com Jason Knight 35:23 I will ensure that that is launched onto the show notes. And hopefully you'll get a few people costing an interested eye over what you've got. Well, that's been a fantastic chat. It's obviously really grateful you're taking some of your valuable time when in between these customer calls to talk a little bit about the platform and some of the things that it solves and some of the issues around go to market in general. Hopefully we can stay in touch but yeah, as for now. Thanks for taking the time. Derek Osgood 35:45 Yeah, thanks so much. This was a blast. Jason Knight 35:50 As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to pop over to OneKnightInProduct.com, check out some of my other fantastic guests sign up to the mailing list or subscribe on your favourite podcast app. Make sure you share with your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest. But as for now, thanks and good night.