The #1 Implementation Killer (Rory O’Brien)

Full transcript

Welcome back to the podcast, guys. Today we are joined by Rory O'Brien. Rory, welcome to the podcast. >> Thank you, sir. I appreciate it. >> To kick this off, for anyone meeting you for the first time, what's your background? >> Rory O'Brien. Uh, been in San Francisco working in series A, B, and some C uh, startups for the past 15 years, mostly on the postale side, building and scaling teams to help, we'll say, legacy SAS companies. and then you know uh native AI companies figure out how to implement their their software and services. That's really kind of my bread and butter and where I've been living for the past 15 or so years more on the vendor side. >> And what are you building right now that you're starting your own company in client experience and software implementation? Yeah, it's um it's a very painful painful thing to implement software especially at the enterprise level but even in mid-market and even SMBs there's always that period of doing discovery when you think about the entire implementation process of software it's obviously like a lot of pre-sales and post sales kind of handover that handover is never solid anywhere I've ever been there's there's always some pain there and then you think about the entire implementation life cycle you've got the kickoff process you've got the design and discovery phase you've got kind of the the mapping phase both on the business side and the technical side.

Then you have the actual configuration. Then you have testing. Then you have go live and then you have hyperare. It's a very very long process and the more complex the software and the larger the organizations the longer the discovery phase can can take. So that's really where the pain and the delays are because you're really asking implementation architects or for deployed engineers to be expert consultants on on your software, but not only that on the business that's uh that you're working with. So there's there's really no playbooks. You know, you can build playbooks and you can build, you know, as good of processes as possible, but at the end of the day, you're still kind of living in an unstructured world. And that's where delays can happen. That's where you're actually expecting a lot of your customers to come up with their own workflows and kind of their own asis. And they're not experts by by any means. They are buying, you know, software or services to solve their problem. Um, and you're basically kind of asking them to map out their problem and that's not always their expertise.

So my thinking is there is a very large horizontal opportunity here to help companies both native AI companies and legacy SAS companies with that discovery process to bring a lot more structure to it and to speed up cycle times. If you can save 20% of your implementation timeline that means the vendor is happy because implementations are going faster and obviously the clients are going live faster. So that's where I'm exploring right now is to really help companies in that discovery paintful process. >> And in terms of the client experience, where do you think teams usually think that they are strong, but the customer feels actually the opposite? >> Yeah, it's a good question. I think when you're implementing software, they customers really kind of think that it's just uh you know configuration and really what it is, it's a lot more consultation. When you look at enterprise implementations, there is less like fields mapping and what's your tech stack and kind of technical like configuration. It's a lot more of the edge cases, the unknown unknowns, right? When you start getting into okay, well, what is your approval process?

Well, what happens when this person does this? Then that kicks off like a, you know, tribal knowledge process that only two people have in their head because they've been there for 10 years. That's really where the painful stuff kind of comes into play. Um that customers aren't quite expecting, right? They're coming in, they're like, "Okay, we're going to implement this software. You're going to give me some timelines. You're going to ask me questions." But really what happens is they bite off a lot more than they can chew. The customer really has to dig in a lot deeper to their processes and then actually go and really kind of build user stories. when they're talking to all their users who are potentially either going to adopt this or those users are going to have the benefits of the software, they really have to go and kind of be product managers and actually ask these folks like, hey, what's your life look like today? What happens when this happens? Like, okay, when you have these edge cases, what do you do? And again, our customers are no customers or product managers.

They don't have that expertise. So, you're really putting a lot of onus on them to go and really do this discovery. So, I think a lot of customers don't know that that they're signing up for that when they really build are buying software. So it's this consultative component that really kind of morphs into a big beast once you're in the thick of an implementation. >> And when you look at implementation, I think that always the assumption of how it will go is different from the reality, right? So when a software implementation goes sideways, what do you think are the most common real reasons why this happens and what tends to be the root cause? I think two things. Lack of discovery and there's a lot of assumptions and that can be both parties. The implementation architect or the FTE says, "Ah, I got 70% of what I need.

We'll figure out the rest." And that 30% is actually super important to have double clicked into during the discovery phase versus when they're in configuration phase and they get to that point in the configuration where they're like, "Oh no, I do need this business logic or I need this policy information or I need this custom business logic matrix that the customer has." And then you effectively have the second problem that creates which is rework. you don't do discovery correctly and you're doing configuration and then you go and test it or demo with a customer and they're like that's not what I was expecting or that's not what we had agreed to or that's not what really happens in real life or what we want then you're effectively doing rediscovery in the configuration phase which always causes delays and mismanage expectations and just really is kind of a sour taste in the customer's mouth because they just saw a demo of what they were expecting to be doneish or close had done or they had something in their mind and they something see something polar opposite then you start to kind of have this trust issue where you're kind of like going on on different paths and it's really hard to get out of that hole once it's kind of been dug on the implementation and engagement side.

It always usually stems back to to discovery lack thereof and just not being fully aligned on the requirements or just you know what the expectations are that the customer wanted at the get-go. So you're currently in the build phase right now. Is there anything that surprise you that you didn't expect? >> Uh I'm in discuss I'm talking to a lot of folks that are feeling this pain both at like you know prof leaders at professional services and also just like ground level implementation architects who are implementing it. And one thing that's kind of surprising to me is is they're they're realizing that discovery is where a lot of the time and the pain is, but they're really optimizing more on like the configuration side because I think I think that's just by virtue of, you know, technical people are going to just be more comfortable talking about technical stuff or like creating SOPs or templates or blueprints to make the configuration easier and better.

And obviously you need that for the for the product side. But I think a lot of people just see discovery as a unsolvable kind of mess. Like you the more at bats you have as an implementation architect or deployment strategist, you start to just get better at discovery in the context of the solution that you're configuring for. So that's impossible to kind of like train and and get new people to become effective in uh discovery for being a deployment strategist or implementation architect. You can't learn by just at bats. You have to have some structure, some sort of framework to do discovery. And I think a lot of people aren't focused on that just because they believe like all right we're going to go into a room start with an empty whiteboard and pray for the best and just ask all the questions the hope that we get kind of you know the idea of what their ASIS state and then we can go we meaning the vendor can go and take that asis state and get to the 2B making that translation process of what the client's world is today and what it should look like when we implement you know the the solution there's not a lot of focus on it from from what I've seen everyone knows it's it's not great, but they're not spending time trying to fix it.

They're spending time more where they can have control, which is their own product, their own processes, which is usually on the on the technical side, not the discovery mapping side. >> And if you could give these companies any advice around actually doing discovery, what would you say? >> The first thing is the amount of data that a lot of companies already have on implementations that they're not using is pretty crazy. Think about all the gong calls. Think about the hundreds of emails during the sales cycle and the demos that SE's are doing and just the amount of uncaptured information that's in that data and then the uncaptured information that's in the sales engineer and the AE and the solution architect capture all that data and put it through your own agent. It doesn't even have to be crazy. It can just go be a GPT that is just super custom to your application and you just upload all the transcripts. This could be super manual. you can actually start to create a really nice, we'll say like 90% of the way there handoff document or process from pre-sales to post sales.

A lot of companies aren't leveraging their own data in the sales cycle to even give the implementation team um a head start. And that's just on the pre-sale and post- sales handoff, right? Like there's there's a lot of other data that you can be using from your previous implementations themselves. If you have 10 previous implementations that have all the caller recordings, the transcripts, the workflows, and all that, like do the same sort of process on this new implementation that you're going to do based on the previous 10. Like there's a gold mine of data that a lot of companies have, but I don't think they're using that you don't need anything special for. You just literally need transcripts, the data, and be creative with the prompt that you can then have Claude and and OpenAI actually create the prompts for you. Like you don't need a heavy lift to just start iterating on that. Um, obviously there's a lot more in depth that you need to do to do proper discovery, which is where I'm spending a lot of my time. But that would be my advice to companies is leverage LLMs, create your own agent just to do its own mining of your own data and then see what it comes out with.

>> What do you think about Open Claw? >> I've got it right here on my really up right here. Yeah, I was right before this call. I was actually reading a whole uh huge article. I've I've got a lot of stuff I'm I'm using wherever I go next and it's not creating my own thing and this goes by the wayside. I assume that there's going to be an open claw, whether that's claw co-work that everyone's going to use or whatever openai's open claw product is actually going to be that's probably not the open source open claw since they bought it. Like everyone's going to have their own personal agent that's just doing stuff for them. I've got this whole like Twitter uh scraping like it's just doing all of my Twitter feed for me because I don't want to be on X and Twitter, but I do kind of build my audience. I've got this knowledgebased agent that that I've created.

I just copy and paste URLs and I want to store it and then I want to like search it all the time and then I want uh the the agent to actually be giving me a lot of information um based on the article that I can use later. Like there's a bunch of just like little tools that uh that you can kind of create. Um and then you can obviously have a code, right? It's connected to my claw code. So it's building stuff, you know, behind the scenes while I'm sleeping. So I've got high hopes. I don't know if it's going to be open claw specifically in the future because it is very buggy like kind of a pain to deal with. Um I'm thinking of changing to a virtual a private server just because literally having this laptop is kind of a pain and I don't want to go buy Mac Mini. Um but I think the the the concept of it is got a lot of legs.

I think Cloud Co, they're going to be doing a lot of work to that to to compete against OpenClaw. What do you think about the security side about it since a lot of guests that I talk with them about this? They say that it's not enterprise ready since there is just a huge amount of leak exposure that can happen without them even realizing. >> Yeah, I was reading a lot into that and using my little KB article. I was actually finding a bunch of open cloud security best practices. So I could probably ask him right now like give me a list of like the 20 most important security measures to put in place for OpenCloud and it'll probably create a really nice article that I could send you. So I I've got a lot of those best practices and it's great because I just ask I called my bot Boris. I just ask Boris to go and hey make sure that obviously like our EMP files are are not exposed. Never share open or AI API keys.

Is my gateway only accessible to me? It's not open to the internet. So, there's like a bunch of basic things that it can it can set up, but I also don't have it connected to any of my personal emails or Google. I've just created its own account. Um, and if anything, I just forward emails to the email that it can um actually access. And then there's a very simple prompt that you can actually say is basically you are not to have right access or do anything unless I specifically say so in my Slack channels. I don't use Telegram or anything. I have Slack. So like it can't it it shouldn't go and do write access or anything like that and it'll only listen to me. So email, Twitter, everything that it can scan is just information only. It can't actually write and post to anything. So I don't know. I'm not a big security guy, but like if you just do probably a few basic things, I think you'll be fine. And I'm not going to let it connect to my Gmail and all that stuff. >> Okay.

Well, great. Thanks for taking the time and uh joining the podcast. I will leave a link so people can check you out and we will see you in the next one. Awesome. I appreciate it.