In this episode I talk to Trevor Ewen about providing software solutions to the non-technical buyer. Trevor shares with us his experience on who a non-technical buyer is, why he enjoys working with them, how they differ from the technical buyer, along with advice on how to get the best out of the relationship.
Or listen at:
Published: Wed, 05 May 2021 15:56:47 GMT
Our Guest: Trevor Ewen
Trevor is an experienced software engineer, real estate investor. In 2021, he received his MBA from London Business School and Columbia Business School.
He is a Southport Ventures partner and the CEO of Southport Technology Group. He builds full-stack projects in clean energy, insurance, finance, and media. Notable engagements include Morgan Stanley, HBO, Bloomberg, and Honest Buildings (now Procore), Black Bear Energy, and PRco.
Trevor currently resides with his wife Diane in Weehawken, New Jersey. Just outside of New York City.
Links
- The E-Myth Revisited by Michael E. Gerber UK US
- Google ThreadIt
- Southport Technology Group
- Trevor Ewen
Transcript
Mark: Welcome back to the Better ROI from Software Development podcast. It's taken to this very special 83rd episode, but we finally have our first guest. I'd like to welcome Trevor Ewen to the show. Trevor, tell us a little about yourself.
Trevor: Thanks, Mark. Yeah, I'm a software engineer based in the US, you probably tell I'm American. And I currently run a small firm that works with non-technical clients, which is something that you talk a lot about and kind of the way we connected. So thanks so much for having me.
Mark: In this episode, I wanted to explore how you, Trevor, interact and provide services to those non-technical customers. You operate what we in the UK would describe as a software house, a business providing software solutions to its clients. And from what I can see, you're doing an excellent job for those clients, achieving an impressive 95 percent return rate for additional projects.
Trevor: So like a lot of service providers, you never quite know what the reason they come back is. I mean, on one hand, it could just be you're the only plumber in the neighbourhood, so they have to keep calling you and they've never really been happy with your work. I'd like to think it's a better case for us. And part of that is that we're engaging in continuous improvement with them. And so, like a lot of this, some of the customers, I have almost accidentally fell into my lap and you know them to personal relationships. A lot of times, you know, from being in software, they even confuse what you do. You're a computer guy, you do this. They probably assume it's the wrong kind of problem you can help them with. Something like a big storage or Excel based issue that they're just having in their own internal operations. Later, they actually find out what you do and lightbulbs start going off. And, you know, in the case of some of the people I met early on, they were actually pretty sophisticated. And that was one of the things I think we'll talk about a bit is how to how to target that exact right buyer.
Trevor: And it's more than just the customer, but also the person you're going to be interfacing with throughout the whole process. So it's the person I often refer to as the champion who's going to be your internal. Your internal contact with whatever customer you're interfacing with. And I was very fortunate, that the first one I think back to, the first customer I've worked in, to use the British term software house, for a long time, but we did more of an agency model when we were coming on board larger companies and working by the hour. And I've been doing that kind of work since 2011. But when I started working with these more these smaller non-technical clients, people who don't have customers, the very first one I did, I was very fortunate, they knew exactly what they wanted to build in a way that's almost kind of impressive, actually, for a non-technical buyer. And that was a great ease into the communication and learning what this this kind of customer is like exactly.
Mark: We've used the term non-technical buyer a number of times already in this episode. What is your definition of a non-technical buyer?
Trevor: Probably the sweet spot that I like to be in, so I think of this as kind of a spectrum in terms of the level of sophistication technically that a buyer will have. And there is, I looked at three groups, I think of if you look at a percentage scale, someone who's over the middle in terms of technical sophistication, that's someone I think of as technical in part because once you get up to one hundred percent, you're talking about, you know, machine learning, data scientists and people who just no way more than me actually about technology and about the kind of things you can do. And then there's on the other end of the spectrum, the zero to 20 percent is a very you know, these people I mean, they're your relatives who who call you up for help on basic things on computers, right. And they really don't have a good foundational understanding of how things work, how they would put some kind of project like this together. They probably never worked in a super process oriented realm that had a lot of technology. And then what I made up in my, just the chart that I recommended to you, is there's this kind of 30 to 50 percent range of sophistication. And that is a perfect buyer for where I am sitting, because that kind of customer knows enough they know enough about what it can do and they may even be able to help you in terms of the concepts and system design. They're also just a little better at making decisions and figuring out exactly what should be the capabilities of a platform. So that's the first thing that I want to do when targeting this kind of buyer, this kind of customer.
Mark: Do you find it different working with a non-technical buyer than, say, a chief information officer or a chief technology officer?
Trevor: Yeah, I think I think this is where where there's kind of the meat of the discussion is because I you know, I'll just put it out there, I really like this kind of customer. I don't do it just because I can't work with the other kind, but I enjoy it quite a bit. But there's a number of things you got to know about where this person, person I say, or even it could be an organisation within a company lays, and one of one of the biggest things is that they are not concerned with the same kind of questions that a development team normally is. Right. And so there's a lot of use a term in the states inside baseball. It just means it was an old I believe it's a radio show back in the day. And it just means there's a lot of information about baseball that is only interesting to people who are actually involved in the sport and have a lot of knowledge about the sport. And outside of that, it's not really important anybody. And so when you get into an inside baseball conversation, that's that's you know, we know those conversations. That's the developer conversations of what frameworks are using. What tools are using for this or that pattern is not good. This approach is not good. We aim for this kind of idiomatic style in our framework or code based development. Those kind of discussions that come up a lot in between developers and people we know.
Trevor: The non-technical buyer just does not care about that stuff. Every now and then you will get a comment about "oh, I hope you're using this latest technology" because they have some reason for caring or think, they have some reason for caring, but their primary concerns are going to be what is the actual solution you're building? How is that managed for them? What's the cost? And then, you know, uptime and probably usability concerns at the tail end would be another thing as well. But even that they're going to be less opinionated than your average tech savvy buyer, who I think is someone who would know a lot of the frameworks, a lot of the UI kits, how to build a responsive Web app or something like that. The non-technical buyer is going to have much more, I just want a simple understanding of that, which is make sure it works on my phone, make sure it works on the tablet, you know, simple stuff like that.
Trevor: And then the needs are going to differ massively from the kind of pure technical buyer when you're working with the CTO's office.
Trevor: So one of the dichotomies I talked about a little bit was, at the top of the funnel early on when you're talking to these folks, they do want you to know a lot of information. And what that means is they will just throw 15 to 20 different APIs or services at you or different concepts, and they'll expect you to be able to speak to all of them. And part of that is that they're just playing around with different ideas, different issues in their business. They don't recognise all the time that developers, people who work in software, we know just a little bit about any given platform. And in the moment we do an implementation, we're going to pore through the documentation, which is typically how you do it. But then once you start working with them, they're going to grab on to a few specific topics. And that's what I talk about, lower down in the funnel, you're going to need a few things to deal with them. So much so that my best customers at this point are really asking us for one consistent kind of implementation, working with the same kind of system, because what they've done is organise their whole business now around these aspects of the system.
Trevor: And then a good example here would be insurance underwriting. Every single platform we build for one customer of ours all taps into the exact same insurance underwriting platform. So we know not a large number of things, but we know a lot about that platform because we keep integrating with it over and over again. Probably the thing I love best just from my background is the architecture and infrastructure. It is not really derivative. You know, we're we're pretty much there to be the experts. So they're never going to tell me that there's something wrong with a certain kind of infrastructure or architectural approach. The only thing they're going to be concerned with is cost, especially on the server side. And, beyond that, I would think design and UX is not as important as you might think, because a lot of times these buyers are not producing a product that is targeted at the outside. They're often dealing with internal workflows and internal tools, and therefore they are able to accept a more limited level of design and UX. And that varies from time to time, but we've we've done less work where it seems like they need mobile or tablet support and certainly less where they need robust design.
Mark: Are there different problems when it comes to working with a non-technical buyer?
Trevor: Yeah, I mean, I think you're always choosing, you're kind of choosing which problems to deal with in life and you're going to have one set or another set. It's a one one kind of thing that's very common, and it's been the root of a lot of relationship ending that I've seen more of the enterprise technical buyer side, is the fact that teams can't agree on frameworks or architectural patterns. So that virtually does not happen here. Once again, I said that's not super important to this kind of buyer. But then there's other things that are going to become new problems that you maybe never encountered before. You've always worked with teams with a high degree of technical understanding,
Mark: With a non-technical buyer, their coming to you for your expertise? So not just to do the job, but how to do the job?
Trevor: Right, right, right, so I think and I think it's important. The power, if you think about the kind of the Venn diagram of knowledge, the the diagram is so heavy on your side of the technology and they really don't want to enter into that too much. Cost is the one area where they they are going to have questions typically. And their business is the area of the Venn diagram where they have the most knowledge and you probably don't have a ton of overlap, because if you've worked a lot of different kind of businesses, you're going to have to remain fairly agnostic. You're going to have to be pretty open to whatever new curveballs they throw at you and say "oh, no, that's just the way it is in the underwriting business". Which can come as a surprise to people who are used to working in a very rational or process oriented way. I would say one of the big ones that we see a lot of problems is customers misunderstand what QA is like exactly. And it's a misunderstanding on both sides of that spectrum. One is,how to do it and the fact that they do need to continue doing it. And the fact that because they are the best user, they will actually know the hidden little parts of the system and so we need to have some kind of robust QA strategy in place.
Trevor: The flip side of that is they are often unaware how big of an aspect ongoing defect review and QA is for other companies. So we'll have a moment sometimes when we onboard a new client where there will be a bug in the software and it's it's quite a freak out moment relative to what it would be in any kind of organisation that's used to having that kind of stuff happen and say "oh, no, it's not a big problem, we'll just fix it. We'll redeploy. Right.". So there is this education process. Sometimes people forget that they bought software that they may think they bought a bridge or something where, you know, now we've got this defect and someone's going to get hurt. And obviously there are bad things that can happen with people's data and that things can happen with security. But one of the things we emphasise is just the continuous improvement aspect of it is very easy. And if you haven't worked in this environment, you can take that for granted a little bit
Mark: Long time listeners will know that I heavily promote that continuous improvement mindset to get the best return on their software spend. And I know that is still a message that will take time to be accepted by many non-technical business owners. How do you gain the confidence of those business owners that you know best how to serve their needs?
Trevor: Yeah, this is this is a big one. I mean, we're spending a lot of time talking about this right now because I think it was the area where we need to evolve most. So, a couple of things I did, one is I put together a proposal for, and I regretted not having this but a lot of it had just been had been managed on a one on one basis. But I realised we need to standardise it more. So one was just having an on call schedule through our team and then providing a standardised SLA document to every one of the customers to just say "Here's what you could expect" in terms of people actually dealing with issues in the system. And this is obviously really important just to make sure that our lives are kind of normalised and we were able to spread these responsibilities to the team, but it's really good for them to know too. On one hand, that they will get immediate feedback on an outage even if they're waking up in the middle of the night. The flip side being minor issues with a workaround, you know, there's going to be a little bit of a wait on those things are going to have to just go into the queue.
Trevor: The thing we did is we're trying to be proactive about upgrades and platform reviews. So we've started to do that on the quarter. So we will manage a number of systems that aren't undergoing a lot of feature development. And what I wanted to get habituated through the customers is the idea that every quarter we're going to just go in there and run a bunch of upgrades, you know, mostly just look into the package manager and making sure everything's up at the latest minor version so that we're actually getting a lot of the bug fixes and most importantly, the security patches. So that has been something that if you do it every quarter, it's a lot easier. And unfortunately, I've got a couple of applications that, you know, it's been a few years. Right. And they're fine. They're running fine. But there's probably some security issues that we need to deal with in those. And that's why I just force that to happen on the quarter was a good call for them and for us. It just makes our our maintenance overhead a little lower.
Mark: It's sound advice to help the client think about the long term maintenance of their systems. Often I find that the clients consider only the initial cost of the software's creation. Not the ongoing maintenance that it needs through to the end of its life. By being proactive with the customer, you're setting clear expectations on responsibilities and what they could expect from the relationship.
Trevor: Absolutely, yeah, and I think for me, one of the things that's been a realisation is just is people can't quite see what's in my brain. So there is an outpouring of just, you know, proactive information. It was said to me at the earlier part of my career, and it's just true every day, you know, people people always tell me, you know, your technical skills are going to get you in the door, they're going to get you started in this career. And long term, it's going to be some of those liberal arts fundamentals, knowing how to write, knowing how to communicate information that are going to be the things that ultimately make your success at the end. And that's a big one. We've started doing just weekly updates with everyone who has an ongoing contract with us. I mean, it was it was just incredibly stupid that I was not doing this before, right. It has miraculous ability to just calm them down, to say, oh, that issue we talked about last week, it's getting looked at this week. And someone proactively told me that instead of them, you know, shooting me a message and saying "Hey, when is this getting looked at?". And actually it's on my project planning board. So it's easy for me to just say "Oh yeah, it's going be look that soon". If I can be even more proactive about it, I mean, the trust is just there.
Mark: It's clear that the more that we, in the I.T. community, communicate the better that level of trust becomes. That that level of trust is critical for any organisation that relies on us so heavily.
Mark: Let's move on to the working relationship. How do you achieve the best for your clients?
Trevor: So, the key thing here is that they are not going to pay an endless amount of money to get something out the door. In the way that an enterprise customer has got huge, huge problems that they need to throw a lot of people, a lot of hours at, and they'll pay the bill as long as the thing gets to market. On this side of the spectrum, you're dealing with a much tighter budget, a much tighter understanding of what it means to build a project like this and maybe actually some flexibility on turnaround time and certainly flexibility on the choices that you make in terms of how you run the technology operation.
Trevor: One of the biggest ones would just be to, we use standardisation like crazy. And a book I will plug here, is it's not a technology book, but it's a book called The E-Myth Revisited by Michael Gerber. And it's a fantastic business book. It is focussed on standardisation of process to a ridiculous degree. And the businesses he studies in the book are actually franchise businesses, mostly restaurants. And, you know, Gerber is not focussed on the restaurant business so much as he's focussed on this idea of if you can create a repeatable process that is so ironclad, you then reap all the benefits of that value down the line. And that is the thing you've created. Your business is not, say, hamburgers. Your business is actually the repeatable process of being able to make that hamburger with the exact same way every single time and every single place that everyone orders it.
Trevor: It's a little harder to do with custom software, but there have been a lot of things we've been able to take from that. For one thing, you know, with all the developers I work with, the project is always set up in the exact same way. So you could think about that in terms of folder structure, the read me docs are the same. We have a standardised developer handbook that goes across all of our code bases. And even code bases that aren't up to date, we're often saying yeah, that one's not up to date with the latest standard, but here are the gaps. So we actively document what those gaps would be. So they know A, where they could go with it, and B, what the actual desired standard is regardless of what they're doing. And this has been excellent because we've had, especially on the staffing side, we've had developers just jump between projects very fluidly. And we're talking about customers in completely different businesses doing different kind of work in terms of their platforms. But the big thing that we standardise on is the technology. So that's one huge one. Can't recommend that enough. And that's that's very hard to do. It's almost impossible to say go into Goldman Sachs and go into HBO and give them the exact same kind of thing, because they do have concerns about the technology, they do have a concern about what kind of architecture you're using. But these these customers want, once again, they want a working product. And because you have all the leverage on the technology side there, they're going to accept the standard product on this one.
Trevor: So the other part is delegation. We allow our developers to be very independent. And this is actually less about non-technical buyers, but it's more about the way we run the firm. And we want them to contribute to the products as if these projects were opensource. And that doesn't mean that we just open them up. They're obviously private client information. All of the developers are working for us and they're obviously working under an NDA for the client. With the opensource aspect of it is they are making forks of the projects and they're submitting independent pull requests, they're evaluating issues, they're logging issues to the project as well. So what we're trying to build in that continuous improvement on the developer side, which is something that I actually think a lot of our customers don't even know that this is happening behind the scene. But it's it's a really cool thing that I think they would be happy to know that there's people, developers who work with us who maybe don't even know them super well, who are sitting around thinking about defects on their products and fixing those things, sometimes for a bounty, sometimes because we ask them to. So that's a big one. And that goes with the standardisation because it allows the developers to move quickly between projects.
Trevor: And then the biggest one on our side with the customer relationship management is how do we manage time. That's the ultimate asset in this business.
Trevor: So if I tell each customer I'm going to have a two hour meeting with them every day, I've lost almost all my leverage. So we do try and limit meetings. We we try and get them on request as much as possible, get emails going out instead with updates. And that's why proactive updating is a big part of this. If we are doing some kind of, you know, checking meeting, we want to have a pretty robust agenda and pull up all the items that we would need to deal with with that customer. So it could jump around to do a lot of different topics. But that way we're just being pretty efficient with it. So, hey, we had some issues with this. The system's not connecting. What do you want to do about this. We've got this open contract. Also we're awaiting payment of this. Kind of stack up all the issues you have.
Trevor: And I love videos. I do video demos like crazy. And just even this week, I just switch to, I'll make a brief product plug here, Google's new ThreadIt product. I don't know if you've checked that out, but it's just a it's a free video recorder that lives right on the Chrome plug-ins. And it's really nice. You can create a multi-stage video with screen sharing with whatever you want, and then you can just create links to it that are either scope to a certain Google users or fully public links if you want to.
Mark: I assume you're using those videos to provide product demos and updates to the customers and then to elicit feedback from the customer?
Trevor: Yeah, yeah, 100 percent. That's the way to avoid lengthier check-ins. And I, I probably overuse them, to be honest, but I've been very happy with it. You know, sometimes I'll just give them a video update about a billing issue or something as well. And ThreadIt that I just started using this week, but I've been using different screen recorders now for a decade, so it's just gotten a lot better because people are integrating with the browser now. I think Loom was the product that was really big in this in this area. And it looks like Google is looking to eat their lunch. And that's why they created this ThreadIt but it integrates very nicely with Google in terms of the permissioning. So that's really nice for us because we use Google workspaces to manage our permissions.
Mark: Again, long term listeners will know that I advocate rapid feedback cycles. Be it to confirm you're heading in the right direction or sometimes even more valuably, that you're heading in the wrong direction. I can see video being an incredibly useful tool for that.
Trevor: Yeah, and the best, I mean the best thing that happens is the customers start to imitate you and all of a sudden they're sending videos back. And that that's that's truly a magnificent thing when you start getting defect review and feature review from the customers in video format. And you can just take those and you can throw them right into the project management system that you're using to make sure "Hey, developers, here's what the customer said. Here's exactly what they need on this and from their own words.". And that helps us. It enables, you know as you're in the UK, time zone aspect of that. We have one customer that's based in Australia and so trying to find times to meet with them is not easy to begin with. So they're just more attenuated to that as well. But as time zones become less of a barrier for people working together, whether within the same organisation or as customers and service providers, I think this is going to be becoming more and more common way. People are going to communicate with one another
Mark: As we draw close to the end of our time, is there anything else that you would like to cover?
Trevor: Well, thanks so much for having me, Mark. I really appreciate it. And if you want to know anything about our firm, you can find out about us at stg.software. You can also shoot me an email trevor at stg.software. And I'm just happy to talk with anyone who's interested in this space. I think it's had a good run in 2020 as more and more folks like us have gone out on their own and maybe decided to work in a slightly different way. Pushing remote forward as well is helping a lot of these kind of customers think about their potential, too. So I think there's a lot of growth in the space.
Mark: I'll add your contact details to the shownotes. It's been a real pleasure speaking to you today and learning from your experiences. Thank you again for giving up your time to be the first guest on the podcast.
Trevor: Thanks, Mark. I know you're going to have many more great ones, so I'll keep listening.
Mark: And to you, the listener, thank you for taking the time to listen to this episode. And I look forward to speaking to you again next week.