In this episode, Ethan shares his insights about what he’s learned about software launches and encapsulated this into 7 key tests:
- Market Validation and Interest Test
- Rapid deployment
- Being able to scale your infrastructure
- Use feedback
- Quality Assurance
- Security
- And The “MVP Shame Test”
Listen to Ethan in this podcast!
Listen now
Like this episode? Subscribe to our channel today on Youtube.
Links from this episode
Citemed
Hashtag Trending Podcast – IT World Canada
Episode Transcript
This transcript was generated using an automated transcription service and is minimally edited. Please forgive the mistakes contained within it.
Jim Love: [00:00:01] Welcome to hashtag Trending the weekend edition, where we bring you in depth interviews with experts on topics relevant to today’s news. I’m Jim Love. I’m the CIO of TWC. We’re the publishers of IT World Canada, Canadian CIO, Tech News in the US, and a host of other publications and podcasts. Now our topic today is about launching a new software platform. It is the dream of many entrepreneurs. It’s also a major deal for established companies and there’s a lot at stake. There’s a lot of hopes and dreams attached to this, and it can make or break your company. You work madly, you sleep in the office, you live on pizza, you put your heart and soul and more into it. And then comes the big day. And then, sadly, a lot of software launches aren’t quite what we hope because hope isn’t a strategy. And with that much at stake, we need to make sure that we’re really ready. Now, our guest today is Ethan Drower. He’s the co-founder and operating partner of Citemed, which is revolutionizing the European Union medical device regulation. At least that’s what Ethan’s going to tell you in there. But Ethan educates other peoples on the fundamentals of launching a successful software product and have some tips for aspiring entrepreneurs and more. So welcome, Ethan.
Ethan Drower: [00:01:17] Hey, Jim. Thanks so much for having me. I’m really excited to be chatting today.
Jim Love: [00:01:21] Great to have you here. So we want to talk about some of the things you’ve learned from software launches and you put this into something you call seven key tests. So we’re going to talk about that. But first of all, my intro, did I get it correct? Is that the type of experience you’ve seen?
Ethan Drower: [00:01:34] Yeah, you nailed it. I mean, if anything, you overexaggerated my competency. So I love it.
Jim Love: [00:01:40] Well, you got to go somewhere. So let’s talk about these seven key tests and the things that you prescribe. And the first one was market validation and interest. And you want to tell us about that?
Ethan Drower: [00:01:53] Yes. So it really boils down to the biggest mistake that most entrepreneurs make when they are building a platform is they start building something without being sure that there are going to be people that want it. And that sounds silly, but it is by far the biggest mistake that people make is they spend a year or two years building a product and then they decide to say, okay, here it is. You know, hopefully the world will come to me.
Jim Love: [00:02:22] Yeah, no, I’ve seen that. But you get into this world where, you know, you get a great idea and it’s suddenly and it’s important. And I had a guy pitched me this was this a long time ago, but he came into my office with a straight face and he said, I’ve invented something. And he showed me the graphs and everything and all his pictures and his PowerPoint. And I said, Man, you’ve invented email. And the look on his face was just it’s so into his tunnel and so into his tunnel vision that he hadn’t realized he’d invented something the world already had. Right? But the bigger problem is you start to get absorbed into the software and you forget to check it with the market need. What should you be doing about that?
Ethan Drower: [00:02:56] So you hit on it and engineers love to build and we find most of our value in building things. And what you have to do as an entrepreneur is you have to do the hard thing, which is actually go out and try to sell the concept of A to somebody. So that’s what you have to do. You have to get pre-orders, you have to get pre signups, beta launches. You need to not just ask people if this is a product that they would want, but you have to ask them to pay for it. That’s the hard part. That’s the part people don’t want to do because that involves rejection and it’s a much harder thing than locking yourself away in the basement and building for six months.
Jim Love: [00:03:36] Yeah, but testing that market is always really tough because when you ask people what they want, they tell you what they want. But is it what they need? Is it what they’re going to buy? That was I think is one of the the biggest problems, Correct.
Ethan Drower: [00:03:48] That’s where getting some type of exchange for the future promise of your product financially, that’s what makes all the difference. You don’t just say, hey, Jim, would you buy this thing if I built it? You say, Hey, Jim, I’ve got five beta users slots that cost $100 a piece. Are you in? And when you force somebody to go to that financial transaction, that’s when you, Jim, are going to actually make the decision of is this actually valuable to me or am I just trying to be nice to Ethan? Yeah, that’s what makes the difference.
Jim Love: [00:04:18] Yeah, there’s a whole segment of risk evaluation based on the same thing, which is when people start to talk about money, they get very practical. These are not ideas. This is money. So show me the money. That’s a that’s our first test. That’s a great one. Yeah. You can’t get people to step up for it and put some money down. Then maybe you don’t have the idea 100%. You talk about rapid deployment. That’s that’s your second test. You talk about how fast developers can get new code to customers. So why is rapid deployment so important in development of a software platform?
Ethan Drower: [00:04:46] This is critical in the early launch phase and kind of the immediate post launch phase when you’re really trying to nail down that fit between the product you have and the market that you’re selling to. And once you started getting some of those. As initial users, those beta users, those first adopters, you’re going to start getting feedback from them. They’re going to report problems and they’re also going to give you ideas for features to build, new things to add. And the faster your team can iterate and build a new idea and test it with current and future users, the more information that you get, the better your feedback loop is. So being able to take an idea or a complaint and turn it into actual software that can be tested and used by paying customers, it’s crucial. It’s crucial to establishing a much more mature product.
Jim Love: [00:05:38] So if our first test was show me the money, how do we test to see that we’ve got the ability to rapidly deploy?
Ethan Drower: [00:05:44] That’s much more of a management of your software. So how long does it take between the time from when a complaint is reported from a customer or an idea is given to you from a customer? How long does it take from receiving that information to actually somebody deciding, yes, we should try to build this thing to it, getting built to it, getting tested and to it getting pushed back to that original user. So it’s like how long how long does that loop take? A big company, a mature company that could take two quarters, three quarters? It could take a whole year. A startup. That process should take a couple of days, tops.
Jim Love: [00:06:25] Yeah. And even the big companies have sped up a lot. I remember reading the story about a microsoft developer who did cut and paste and and it took him almost 3 to 6 months to get his code back. And yeah, I have no idea how you can code like that if you’re a new developer, if you’re an entrepreneur, you’re building something new. You’ve got to have a pretty tight type of timeframe for getting your stuff accomplished, right?
Ethan Drower: [00:06:46] You’ve got to push it out even if it comes with increased risk of breaking things or having minor annoyances and things like that. It’s just part of the game. Speed is much more valued over stability overall in those early stages. Yeah, because you’re just getting feedback, you’re just getting information and that’s way more valuable.
Jim Love: [00:07:05] Okay, so that’s two, three, being able to scale your infrastructure. I think this is something that everybody talks about because there’s always that story of the software that went live and crashed the server, right? So how do you deal with that in a development, especially when you’re trying to keep a budget? What should you be doing?
Ethan Drower: [00:07:22] You know, I was hesitant to put this on here because for 90% of software based startups, you never even get to a point where the scale of your infrastructure even matters. But it’s on here. So the way to address this is to make your decisions early and build on a cloud based dynamic infrastructure. So that’s that’s Heroku, that’s Microsoft Azure, and that’s going to be your best way to do it. Unfortunately, the cost associated with that are they’re high. But when you’re when you’re in a rapid growth phase of a software startup, you cannot be concerned with the short term costs. What you need to be concerned with is the the short term service of a spike of users. And in two years, you can rebuild your entire infrastructure, you can pay the money and you can save 40% by going to a more dedicated infrastructure. And that’s no problem.
Jim Love: [00:08:17] Well, definitely blessed with the cloud from the old days when you had to overbuild your infrastructure just to be able to make sure you could exist. A little background noise there.
Ethan Drower: [00:08:25] Sorry about that. That’s another part of the startup life is you work in sometimes manic environments. So I apologize for any.
Jim Love: [00:08:33] Absolutely. No, no, no problem. So here’s one that’s near and dear to my heart, and that is it’s sort of the flip side of this sort of tunnel vision that we get as engineers. User feedback. Getting that user feedback is another test. How do we know we’ve got that right?
Ethan Drower: [00:08:46] You should be able to quantify it. So you should be able to tell me as a founder how often you are soliciting feedback from your users and how often you’re actually receiving it and that you should be able to show some kind of trend over time. A lot of early stage founders, they forget to ask because they’re so busy trying to put out the fires and they build a mechanism beyond a crappy little survey that nobody fills out to actually get feedback from your users. So how often are you getting on the phone with your most active users? Who’s talking to them? Who’s reaching out to them saying, What do you like? What don’t you like? That’s all very quantifiable and can be done by a good customer success person. And it should be data, It should be sheets of reports.
Jim Love: [00:09:34] What about prototyping, showing it to people and things like that? I mean, one of the good uses of a minimum viable product or rapid deployment is to be able to get something in front of people and watch them actually use it. Is that something you prescribe.
Ethan Drower: [00:09:46] If you have time? I say yes, depending on how lean you are. Like, for example, when we were getting going, we didn’t have time to schedule prototyping, demo things. We just. Pushed it out and we said, Here it is. Let me know if it works, you know? So it depends on the pace Some people in depending on the sales cycle of your software, if it’s a consumer quick to sign up or if it’s a much bigger enterprise kind of thing, yeah, you can get on calls with your most loyal customers and you can say, Look, I want you to try this thing out and let’s just go over it together on a screen share and see where they get stuck. It’s often overkill if you really building a decent user base and you’re really getting feedback from live customers. Testing prototypes individually is not always the best use of time. But yeah, it’s completely viable. It’s completely viable method as well. It’s all just a question of how much time you have to put into it.
Jim Love: [00:10:44] Cool. Okay. Next test, you talked about quality assurance and obviously you talk about medical software, so quality has to be there. But I was always told by my project managers, you got three things. You can have any two of them, you have quality, you can have time or you can have cost and you can only have two of those. Pick the two you want. But that’s not true in the modern world, Especially like you said, if we’re doing medical software, quality has to be there. How do you know you’ve got quality and how do you balance that with the need to be fast, the need to be adventurous, the need to experiment?
Ethan Drower: [00:11:14] This is one of those things that technical people try to overengineer, and that’s why I included it in here. The whole point is somebody needs to have a systematic way of banging their way through all of your software, through your whole application and keeping track of stuff that breaks. I don’t care how you do it, but don’t overengineer it. You don’t need to build a whole bunch of automated test bots. You don’t need to build a whole suite of virtual machines to run through your application in the background and test every build. But what you need is you just need somebody that’s trustworthy and competent to use your software continuously and have a mechanism for getting their feedback. And I would say in almost every early stage application, that’s enough.
Jim Love: [00:11:59] Yeah. So quality assurance and the flip side of that security, one of the other tests that you talk about is security in there and that I think you’re doomed with a product if you don’t do that thing that everybody talks about, builds security in and not on. That’s my own personal opinion. But how do you make sure, you know, before you get to market that you’re not going to melt down on security?
Ethan Drower: [00:12:19] Well, I think if I could guarantee that for you, Jim, I would not have to work as hard as I do, because that is one of the ultimate gambles is what’s the trade off in terms of risk, platform risk and financial risk to your users? It depends on what you’re building. Each company is going to have to do a pretty deep dive into the regulations that are pertinent to their space. Are you handling customer information or are you just passing everything through a payment processor? Are you shipping patient data through the EU like we do sometimes, or are you specific to a region? These are all things that, depending on what you’re building, you’re going to have to kind of make a little matrix of and you’re going to have to determine how much you can afford to spend on legitimate security testing, how much you legally need to, and then how much additional are you actually willing to pay for? The reality is for most consumer applications, if you’re using already vetted tools, if you’re already using payment processors that are vetted and server providers like AWS and things like this, you can get away with a pretty lean budget if you’re going into the health space, if you’re managing consumer data, credit card info, credit info, things like that, that’s a whole different ballgame and you just need to factor it into your startup’s budget, bringing in an actual compliance officer and auditing how you’re handling your customer’s data.
Jim Love: [00:13:49] So if I’ve heard you correctly, you’re really talking about, first of all, use established tools where you can and make sure you don’t have to rebuild the security into those know what industry you’re building for and the rules that are associated with it. And that’s fair. You could overbuild or under build depending on what you’re dealing with. But also I think you’ve said know your data, so know what data you’re trying to protect. Is that that fair?
Ethan Drower: [00:14:11] Yeah, I think that’s a good recap. And I guess the most useful advice for people getting started is even if it costs a little bit more at the beginning, use already vetted and out there tools. Don’t try to build everything from scratch because you think that, oh, if we scale this to a million users, it’s going to be cheaper. Use the tools get from 0 to 1 quicker, even if it’s a little bit more expensive to you per user because you’re going to save on that compliance back end. That’s probably the best point to illustrate is if it’s already pre-built out there and you can use it, do it now, Get your market validation. Start getting some users. You can always rebuild it later to save a few bucks.
Jim Love: [00:14:53] Great. Your last rule or test was was my favorite of them. You called it the MVP shame test. Tell me about that.
Ethan Drower: [00:15:00] So this one was poached from Reid Hoffman, the founder of LinkedIn. And his quote is something along the lines of if you’re not truly embarrassed by your product, the first version you put out, then it’s too late. You’ve launched it far too late. And the gist of it is essentially that we spend far too much time trying to make everything perfect for a world that we don’t know exists yet. So it’s far better to put it out into the world and see what comes back than it is to to try to pre engineer a problem you don’t know exists.
Jim Love: [00:15:35] Which takes us back to your full circle to that first piece where you said talk about making sure you’re building for a need that a user or a customer really wants to have. Seven Tests Give me a story from when you were applying these in your own world. What was what was the biggest thing you’ve learned?
Ethan Drower: [00:15:50] Oh, I would say the lesson I’ve learned most early on in my career was definitely market validation and interest. I’ve spent cumulative years building products that I thought were truly exceptional that nobody wanted. I’m trying to think of a funny one that you would like. We built an app for tracking the positions of of local food trucks and pre ordering your lunches on them. And it was really cool. It was an amazing platform and it was designed for office workers so that they didn’t have to wait in line at the food trucks. Et cetera. Et cetera. And they could see what was outside their office. They could place their order, go pick it up. Lunch hour is saved kind of a thing. And we spent a whole year on engineering and outreach and things like this. And at the end of the day, people just said, I don’t mind waiting in line. It’s all right.
Jim Love: [00:16:47] What do you mean you can’t? I built software. You don’t understand. Yeah, you.
Ethan Drower: [00:16:52] Right. You don’t understand, right? This is for you. You need to have the problem. I say you have, right? And so that should only happen to you a couple of times before you start to realize. Shoot. Maybe we should have tried to get sign ups before we built the darn thing, right?
Jim Love: [00:17:06] Yeah. No. And. And get people to put up money. Yeah. I had somebody claim the best piece of advice I ever gave to them was the customer has the right to be wrong. They don’t have to agree with you. Or as my first wife said, you’re right, you’re right again. So what? You know, emphasize first wife on that one. Yeah.
Ethan Drower: [00:17:24] You couldn’t say it better than that.
Jim Love: [00:17:25] Good stuff, Ethan. Thank you so much for for doing this. Tell me what just before we close out here, what’s the most exciting thing you’re working on next?
Ethan Drower: [00:17:32] So fortunately, we’ve gotten users and tested our market and we’ve kind of jumped headlong into our health product, which is a software product that’s designed to help device companies, medical device companies get their products approved in Europe. So we’re research heavy, we’re medical data heavy. It’s kind of the Wild West in this industry in terms of software innovation because it’s generally a very old school industry. So for me, I’ve really just been enjoying kind of digging into that space and ruffling some feathers, you know, shaking some things up because it’s not an industry that is particularly prone or open to brand new software products. So we’ve really been enjoying putting our stuff out there, getting user feedback and diving into the research based problems.
Jim Love: [00:18:20] I hope you pass all seven of your own tests and get off to a good start with this software. Once again. Thanks, Ethan. Great discussion.
Ethan Drower: [00:18:27] Thanks so much for having me, guys. It was a pleasure.
Jim Love: [00:18:29] That’s hashtag Trending the Weekend edition. Thanks to our guest, Ethan Dower, with his seven key tests. And thanks to you for tuning in. Now, if you’ve enjoyed this up close and personal interview with the technology leader, check us out. We’re on the air every week. We’d love to hear what you thought about the program and comments or suggestions you have, and you can catch me at J-love. At TWC. It’s J-love at TWC, or you can find me on LinkedIn and you can find me on Twitter. You can find me on, I think, Mastodon now as, as the real Jim Love as opposed to those fake Jim loves out there. But if you know of someone or some topic you’d like to see, drop me a note. The simple thing you can do is just click the X or the check at the bottom of the story that you’ll find attached to this on our website. And you can send me a note there as well. Hashtag Trending. A weekend edition is produced by the podcasting network. You can follow us on Apple or Google Podcasts or Spotify or anywhere you get your podcasts. You can even get us on Alexa. I can’t say your name out loud or she’ll just start talking in here. Or the Google smart speaker you have in your home. I’m Jim Love. Our producer is James Roy. Our associate producer is Krystal McClain. And we’ll see you next week for another hashtag trending. The weekend edition.
