94: Startup Mentality, API Management, and Corporate Apps with Eric Caron of Caribou Coffee

If there’s a record for the most analogies used in a podcast, this one might break it.

Eric Caron, Senior Director of Digital Experience at Caribou Coffee, and Tim Bornholdt of The Jed Mahonis Group use their analogy-making skills to break down how startup mentality works in corporate settings, why non-technical people should care about APIs, and how there’s value, not shame, in retiring legacy apps.

In this episode, you will learn:

• Why anyone can be a startup
• Why companies should view their digital assets the same way as their physical assets
• How to walk the line between different customer needs
• Why APIs are vital in the digital space
• The importance of security and thorough documentation in API product management
• Why apps should spark joy
• The ripple effects of legacy code

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded September 15, 2021 | Edited by Jordan Daoust | Produced by Jenny Karkowski

Show Links

CIO Review Article “Is Your App Sparking Joy?” | https://www.cioreview.com/cxoinsight/is-your-app-sparking-joy-nid-28566-cid-19.html

Eric Caron on Twitter | https://twitter.com/ecaron

Email Eric Caron | me@ericcaron.com

Connect with Tim Bornholdt on LinkedIn | https://www.linkedin.com/in/timbornholdt/

Chat with The Jed Mahonis Group about your app dev questions | https://jmg.mn

Rate and review the show on Apple Podcasts | https://constantvariables.co/review

JMG Careers Page | https://jmg.mn/careers

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non technical look at building and growing digital products. I'm Tim Bornholdt. Let's get nerdy.

This episode is brought to you by The Jed Mahonis Group. We build the best in class iOS, Android and web apps. We do this by integrating with teams that lack mobile expertise and work together to deliver creative mobile solutions that actually solve real business problems. To learn more about us and to see our pricing, something we're very transparent about, visit our website at JMG.mn.

One small request before we jump into this week's episode, we're trying something new with ratings and reviews for our show. We know that us asking gets super annoying, but getting a review really helps people find our show. So as a thank you for taking the time to rate and review us on Apple podcasts, we will give you and or your company a shout out on a future episode. Leave a rating and review on Apple podcasts, get free advertising. It's that simple. Even simpler, we've put a link to the show notes to take you right there.

Today we are chatting with Eric Caron, Senior Director of Digital Experience at Caribou Coffee. Eric joins the show to talk about the startup mentality in corporate environments, why non technical people should be comfortable talking about API's, and why apps should either spark joy or be retired. So without further ado, here is my interview with Eric Caron.

Eric, welcome to the show.

Eric Caron 1:46
Thanks for having me.

Tim Bornholdt 1:48
I feel like we should have just recorded the last like 40 minutes of our conversation because we've had some good stuff but it'll just be lost to the the internet ether.

Eric Caron 1:57
Somehow I can always get bribed into talking more about technology and beer if we can loop those together. So don't worry, there's future there.

Tim Bornholdt 2:05
Well, we'll have to, we'll spin off a podcast off of this and I can do what we talk about is Minnesota tech and Minnesota beer. I think we could fill an episode about that.

Eric Caron 2:12
That's a deal, for sure.

Tim Bornholdt 2:14
In the meantime, though, you're a little bit busy with what you've currently got going on in your life. So why don't you tell us a little bit about yourself and what you're doing with Caribou?

Eric Caron 2:21
Yeah. Eric Caron, I work at Caribou Coffee. One of the interesting things is when I left my previous employer to go work at Caribou, they said I thought you were such a Minnesota fanboy. Like why are you leaving the state for Caribou? Caribou is based in Minnesota, what were you thinking? So I'm the senior director of digital experience at Caribou Coffee. And it's weird to feel jealous of a coffee bean. But all of the coffee that is roasted by Caribou Coffee is actually roasted in Minnesota. And so we'll buy a bean from Rwanda, it gets shipped to Brooklyn Center, Minnesota, and then no matter where it is served in the world, so it's a Minnesota based company. And I've always been a passion in the Minnesota startup scene, and being at Caribou has been very fun for me because I get to do everything from the website to the mobile app to really anywhere that customers interact with us digitally, get to get involved in it, and making sure that people have a good time. I really, I always have fun in my career, making sure that people, they benefit from the technology, but they don't see the technology, if that makes sense. And so that's what I do. And I'd like to talk about that today.

Tim Bornholdt 3:32
It's nice having the ability to have an impact on people in like, the ways that they don't see, you know. I think a lot about like plumbing and the behind the scenes work that goes into just having running water, and it feels like the stuff we do, it just enables other people, you know, using technology, it just lets them do stuff, even if it's as simple as making ordering coffee easier. So even if it's just that, that's still something that has a really positive impact on somebody's day.

Eric Caron 4:01
Yeah, done right, you don't know anybody did anything at all. But in the last year with the number of retail establishments and food service, we say QSR, so quick service restaurant, but if I say QSR that's what it means. When you do curbside, it seems so incredibly simple. Yes, I pulled up and you brought the food out to me, but being able to do the logistics of being a big box retailer and knowing this person's here I should bring up the 65 inch TV or this family's here and I needed to bring out three hot chocolates and they better be hot because it's a cold Minnesota winter. Just being able to know how to execute that and translate what the customer wants, what the technology can do to what the team knows and okay, this is the, we're in Minnesota, there's a lot of black SUVs here and knowing exactly which black SUV to carry the drinks out to and where it's parked. It has definitely been challenging, but it's also been incredibly fun.

Tim Bornholdt 5:00
You've had a storied career already. I mean, you've been a CTO at a startup, you were an API product manager at a certain corporate retailer. And now you're director of digital experience with Caribou. There's a lot of talk within enterprises about having a startup mentality. And since you have backgrounds, both in startups and in the enterprise, could you explain how the startup mindset works within a corporate environment?

Eric Caron 5:26
Yeah, we, having been on both sides of the fences, it's fascinating how, at a startup, you'll look at a big corporate and go, Oh, they've got all the money, they can do all the things. And then at a big corporate, you're like, Oh, I wish I had more money. And all those startups, they can just do absolutely anything they want. And what I've enjoyed is making sure that all the companies really face the same problems. And you and I could probably do another podcast talking about what it is to be a startup, like the difference between a startup and a small business, if we go back 15 years, startup was just a name for a very fresh brand new company. But we now have companies that have been around for 20-some years that they consider themselves a startup. And I would love your take on it. But I believe that a startup is a company that still feels pretty comfortable pivoting what they're making. Whereas when you transition from a startup to a small business, you know, okay, this is our product, we're going to grow it, but this is the thing. We're just going to make it bigger, and then corporate sees the startup mentality as, okay, we know, generally, this is a problem space we're going to need to solve. Now go do it. And that's where the pivoting inside of an enterprise becomes more doable.

In Eric Reese's book, The Startup Way, where he talked about doing this at GE is that exact same thing where, okay, we know we had to solve this problem, we don't know how we're going to solve it. Well, let's implement agile here, let's learn from our lessons. Let's talk to customers. That's when a company says, Hey, we want to act like a startup. It's just we don't know how to solve a problem. We know this needs to get solved, go find out how to do it. And it's super fun. I don't know why everybody doesn't want to do that full time.

Tim Bornholdt 7:13
It does feel like the difference between startups and small business would be that process. Like once you've honed in on some sort of process for doing, delivering whatever it is you deliver, like that's when you start, in my mind, you start to pivot out of being a startup and into a small business. But yeah, you get companies like MailChimp that just got acquired, like, I'm sure they still consider themselves a startup, even though they were bought for what?

Eric Caron 7:39
12 billion.

Tim Bornholdt 7:39
Yeah, 12 Instagrams. Like it's baffling that people think you just kind of can go in and out of that startup mentality, I suppose, or like to call yourself a startup versus being like an established company. But yeah, maybe you're right, like the line is a little bit blurry. And it seems like it comes down to more of you, as a business, being willing to, like, you know, pivot quickly and change course, and, you know, take those, I guess, I don't want to sound facetious, but, like courageous choices of being like, Okay, we just invested, you know, however much money and time and effort into this thing. We're gonna, you know, forego the sunk cost fallacy and just dump it all and move in a different direction, you know, and do it in a strategic way.

Eric Caron 8:31
Yeah, I could see that. And in some ways, you could say, MailChimp definitely is because they started as a newsletter system. Then despite their name, they pivoted into the CRM space. And they're doing okay, there. But then you look at other companies like SendGrid, who, it wouldn't make any sense for them to say, okay, within SendGrid, we're going to do CRM and so they're going to start up a separate company under the Twilio umbrella, then have that be a CRM and SendGrid would still stay just doing email where MailChimp is the umbrella that everything lives within. So I mean, really, everybody could be a startup. And that's really the message that I'd like everybody to get across is, technology is the same thing. Anybody can do it. It's, I don't know if I can quote, can I make a Disney reference on here? Are there lawyers going to come after us?

Tim Bornholdt 9:18
Yeah, I think we can handle it.

Eric Caron 9:20
Okay, we'll tow the line. But in Ratatouille, they talked about that, you know, anybody can cook, not everybody's gonna be a great cook. But anybody can do it. And technology's the exact same way that anybody can make, anybody could make an app. Some people are gonna be a lot more efficient, but when you demystify it, and you say, yes, here is the way that the app actually comes together. It's simple. It's not brain surgery. It's not making, the startups and technology have that same persona that if you haven't been involved in the day to day they seem downright magical. But when you take the time to make people understand, this is what the process is, here's how it is, you can do this too, well, the whole world gets better.

Tim Bornholdt 10:06
And taking that further like cooking is very similar to technology in that there's different reasons why you cook like there's sort of a utilitarian reason to cook is because you need to eat your food and you need calories to live. But then there's other times that you cook and you want to make a nice fancy meal where everyone sits down, and you make it a big experience. And it's something that's provides a lot more value than just, you know, opening a can of Spaghettios. and dropping it in a bowl. And I'm not, that's I'm speaking from firsthand experience on that front. Technology is very similar. Like, you don't need to go out and do like a big, native custom app solution with, you know, a big scalable, Docker powered back end and everything like that, like you can do that. And that's the appropriate response for certain cases. But if you're just trying to solve a problem within your own business or your own life, there's nothing wrong with using like a no code solution or spinning up a WordPress website, or Squarespace or something. And just getting it done. Like we have the ability and it's just feeling comfortable with jumping in and going and learning and expanding from there.

Eric Caron 11:15
Yeah, a couple weeks back, you did that native app versus hybrid app versus PWA podcast. And I thought that was a brilliant point you made there is you don't always have to make a full-on solution for absolutely everything. Sometimes a prototyping in a PWA is more than good enough. And I appreciated that part of the message because you don't always have to launch an app to the App Store to to prove a concept. There's sometimes scrappier ways to get stuff done.

Tim Bornholdt 11:40
You just really wanted to pivot into that, so we could fight about Flutter, right?

Eric Caron 11:45
Oh, there's so many areas I want to go. I want to talk about API's. I want to talk about Flutter. This will be the first of 17 topics if you let me control the show.

Tim Bornholdt 11:55
Well, we'll just we'll have to make this more, just a part one. And we'll come back with future episodes and drill in further. But one area I actually want to talk to you about because I've really been interested in this kind of topic. So you know, you're director of digital experience. So how do you direct the digital products within Caribou? Because I would imagine that there is certain like competition internally with where to focus your developers' attention. And so I'm curious to hear like, do you have like a mindset or a methodology or approach that you take to dealing with how you focus your developers' time and attention?

Eric Caron 12:37
Yes. I have two answers to that one. I'm going to go with the quicker one first. Talking to humans, it's so incredibly easy to forget that that's part of, you know, no matter what company you're at, you're building something that is going to eventually be consumed by another person. And the longer you go without talking to the people that are going to consume your product, the more risk you have in building something that people don't actually want, like that Homer car in The Simpsons from 30 years ago. So what I encourage of my teams is make sure that, you know, at Caribou, it's easy. Go to a store, watch somebody order a coffee, watch somebody drink a coffee, when you're at another restaurant, watch how people are ordering and how they're thinking. So even though it's a digital experience, it ultimately translates to a physical experience, whether or not it's somebody shipping coffee to your home, or you ordering it from your phone, and then going there. And it's just sitting there because it's 6am. I don't always want to talk to another person. I just want the coffee sitting there. And I'll have a conversation later in the day. Other times you want to be chatting so you want to go and you want to, Hey, do you have any creative ideas? I'm feeling this that or the other thing, and it's okay that the person walks to the counter and talks to a barista. So I have my teams make sure that as often as they can, go out there, interact with the customers, interact with our peers and our other employees, and figure out if what you're doing translates to make their world better. If it does keep doing it. If it doesn't, well, let's have a talk because you're not working on the right thing.

The second area that we talked about for how I do digital experience, is you have to think of what you're building, just like you're actually building something physical. So if you compare building an app to building a retail location, you know, there's many apps out there that have cost 10s of millions of dollars to develop. And when the company thinks about, okay, we spent this much money on this app, well, then it's easier to continue to invest in features and to make sure Oh, well, are we actually going to throw it away? Does the entire app need a rewrite from scratch? Or is it just like a building that we built in 2004. It's okay, it just needs a couple fresh coats of paint and maybe some other areas that are brought up to modern standards. So when you look at what you're building digitally, it's so incredibly, incredibly easy to just think of it in terms of lines of code produced, number of API calls, number of hard drive space used or how much processor power it's taking up. But when you take a step back and you treat it like a physical asset, then it's very easy to say, well, yes, this makes sense to invest more time in it or no, you know what, that's good enough. Let's go build another store over here.

Tim Bornholdt 15:34
It's funny because I use building homes as the analogy for building apps all the time. And I don't think I've ever brought it all the way to that conclusion, in my own like, head. And I think that's a really good point like you are, when you go and build a house, it's not like you just are done, you're continually thinking like, oh, it'd be really nice if we redid the porch in the back. Or it'd be really nice if we repainted it or did this and that and you kind of have to, there is just like kind of basic maintenance upkeep that you have to do to your physical products and your physical assets. It's the same with your digital assets, like you kind of, if you treat it as a true investment, then you're probably going to get a lot more value out of it in the long run, as opposed to just Hey, we have an app, weee, like, look at us.

Eric Caron 16:24
Yep. And tracking is so incredibly important. It's not just metrics to see how many people downloaded our app, how many people opened it, what was the crash rate? It's how many hours did we put into this experience? How many hours and dollars did we put into marketing this experience? And I'm not saying set those as a goal up front. But when you track them, when you talk about them, when you make sure that within your company, people have visibility, you know, oh, this is how much this investment is. Well, I'm going to, you know, give it the respect it deserves. When you don't attach numbers and when you're very opaque about the amount of work that went into a thing, it's so incredibly easy to dismiss it and undervalue it. And I just, within a company, the more you can democratize the data of your investments, the easier it is to make sure that your next investments are the right ones.

Tim Bornholdt 17:17
I want to hold your feet to the fire a little bit about something you said earlier, too about like talking to your users and thinking about your users. Because I think, yes, absolutely, you're right, like full stop what you said was 100% True, like you do need to go in and look and watch your users and see what they're doing. And that's the stuff you should be focusing on. Now, taking that a step further, it'd be one thing if you were a mom and pop coffee shop, and you had one location, and you had one way of doing things. But seeing that there's, you know, 1000s of Caribou locations like there's, it's a huge, huge footprint that Caribou has with lots of different users and different types of users. There's probably within like focusing on your users, there's probably other things that you want to, you know, optimize for, like how do you say like this user here is the problem that we're going to focus on or the outcome that we're looking for, as opposed to, you know, this user over here? Is it as simple as just the most users possible? Or is there some other metrics you're looking at?

Eric Caron 18:21
Well, first, there's a map that gets shown a lot that shows like the most coffee stores per state, and Minnesota is Caribou country, not quite yet, everywhere else. I think we're maybe 400 stores across the entire country. But that gives us the opportunity of if we're in an area where people don't know about Caribou as well as, in my opinion, they ought to, we can do some really fun like usertesting.com or userinterviews.com, where you can solicit Hey, I want an hour with 10 different people in that area. And I just want to pick their brain on how do they order coffee. Caribou, for example, if you are getting a, adding espresso to a drink, we call it mousset. Well, if you're not familiar with Caribou's dialogue, if somebody says, Hey, do you want to mousse it, like I have absolutely no idea what you're talking about, I'm leaving. But because we've got a company almost 30 years old, there's also people that are if we ever stopped calling it mousset, they'd be angry. So learning how to walk that line between those two different customer needs, it takes a lot of experimentation, creating personas up front to know, here are the different kinds of customers that we have. Here's the ones we want more of. Here's the ones that are very happy. Here are the ones that are very upset, and then leveraging the tools to figure out where those customers are. Sometimes they're walking into your stores. Sometimes you just, you know, sit outside of a Twins game and give people a free $10 gift card if you can pick their brain for a little bit. But you got to figure out where those customers are and then just have the straightforward conversation.

It never ceases to amaze me how willing people are to give feedback when you say hey, how do you like to order your coffee? I would have expected people to say, you know, that's not your business, you know, leave me alone. People just like to have their opinion consulted. And so no matter what feature we're launching, you got to know what person you're creating it for. And then find the people that you're trying to target, ask them and then also ask the other people that might be impacted. So if you get rid of the term mousset you make sure that you aren't disappointing all of Minnesota because Minnesota, when you disappoint them, they'll let you know.

Tim Bornholdt 20:32
That harkens back to before we started recording ripping on our own state, but it's self-loathing, I suppose.

Eric Caron 20:39
Yeah, I love it.

Tim Bornholdt 20:42
I think you're right, though, people do like to give their opinion. And I think there was something I heard a long time ago about when you ask someone for help, it's in a way you're honoring them, like, because you're making them feel like they matter and their opinion matters. And of course, you're gonna get people that say it's none of your business, go away. Like that's, you know, this is America after all right, like, so you are going to get people that are going to just tell you to buzz off. But I think for the most part, especially, you know, as it relates to building digital products, people think that this is like the scariest part is going out and asking people for their opinion. But as I've been doing this longer and longer, you know, some of the sites you mentioned, like usertesting.com, and userinterviews.com, like we've used those in the past as well. And people are more than willing to sit down. I mean, even if you don't have a $10 Caribou gift card to give them people love telling you their opinions. All you have to do is ask.

Eric Caron 21:41
And you learn about the adjacent possible toom the stuff that you never would have expected that somebody brings up in, convertly, like, for example, you want to go really heavy on Siri ordering. And you like okay, people need to be able to, because ordering coffee is very complicated. There's many different ways you'd say like, the size, the type of coffee, the type of milk, like the different orders that you can do it. It sounds when you're a person hearing the order, you know how to process it, computers take a little more challenge. But in one of our interviews that we had done, people, the person was commenting about how frustrated they were that people were pushing them towards voice, but they had a particular accent that their platform in this case, Siri, wasn't very easy to translate. And so we recognize, oh, we are actually going to do a disadvantage to this audience because they're frustrated with that technology.

It's another episode you had you talked about accessibility. And that's got to be a feature that people talk about upfront. It's not just voice recognition, but visual impairments, audio impairments, physical, you know, abilities, you got to keep that all in mind. And you got to make sure that you're talking to those customers too to make sure that when you're launching a feature that might be, have a lot of whiz bang awesomeness, that it's not that you aren't also shutting the door to a lot of audience that needs our support.

Tim Bornholdt 23:09
You do a way better job of promoting past episodes than I do. I really appreciate it. I think one thing that you brought up that I, this is just a pure curiosity. But from a technical standpoint, I thought that the drilling in on Siri specifically and doing the, using voice as like the user interface, does it seem still like pretty early days to you? Because to me, you're right, like the way that you could order like say, I guess like I wouldn't have thought coffee would be that terribly difficult to order. I personally am not a big coffee drinker. But then I think about it, and I watched my wife order her coffee, and it's just like, I don't know what like necromancer incantation she needs to derive this spell from but it's like just a 10 word cancophany of adjectives and I'm just like, Just get coffee, like, why does it have to be this thing? But I guess like, again, not being a coffee drinker, like if you relate it to beer, it's like, I guess I suppose I would like a, you know, a specific type of of yeast in my Saison as opposed to, you know, golden ale or something else. Drilling it back to that to my point, do you think like that we're still like, just really having to focus on like the phone, tapping on the phone as our primary way of doing it for the foreseeable future? Or do you think there's going to be a pretty substantial leap in the next five years that we're going to start using, you know, other forms of UI, whether it's voice or augmented reality or something to that effect?

Eric Caron 24:44
Tim, I'm not sure I'm the one you want to ask that question. If you look, there's a MinnPost article just after Apple announced the iPad, where they're interviewing some Minnesota technologists and I made the opinion that it was a technology that the world didn't really need and that they should keep focusing on other stuff. So my fortune telling on future technology is a little rough house. I also thought Firefox OS was going to be a big thing.

What I will say, though, is I keep waiting for a more sophisticated chatbot example than the 1-800-Flowers example that I keep seeing. They show the example of, Oh, I forgot to buy flowers for my anniversary. And then you open the Chatbot and you order flowers. I still have a faster time if I'm going to the florist website and just ordering them myself rather than the Chatbot. Android Auto and Apple CarPlay are other ones where I'd love to be able to put that technology there when if you're driving in the car, and you want to order a Caribou, that it's there in the car. But I also have a hard time justifying distracting people when they should be just focusing on the road. Then you would say, well, there's other people in the car, we;; those other people have phones and they should just order it on the phone.

So voice chat, chatbots, Android apps in the car and Apple CarPlay, I'm waiting for them to have their moment. I will say that there's sometimes technology like the Hue lights were when you first started buying them that one of the pitches I heard was oh buy the, install the Hue lights in your room, and every time the Vikings score, you can have the lights in the room flash purple. Okay, but I don't really, don't actually want that. But I recently replaced the lights in my home theater system, where based on the time of day, because it's where the kids also play Lego, when it's times that they would play Lego, it's got that cool, very bright white light. And in the evening time, it turns off some of them. It goes to a warmer color. Okay, it took a while for me to understand that's what the Hue lights could do. Now, I appreciate it. So maybe in another five years, it'll make more sense that the Chatbot and Siri as a way of anything other than voice and text translation, it might mature then.

Tim Bornholdt 27:04
First of all, your room's gonna be pretty dark if you're waiting on the Vikings to score.

Eric Caron 27:10
Shots fired.

Tim Bornholdt 27:12
I'm a very seasoned and loyal Vikings fan. So I feel like I've earned the right to just be perennially disappointed by them. But I think that we, like technologists especially, were really spoiled when the iPhone came out. Because the difference in technology from like the razor and the sidekick all the way up to the iPhone, like the iPhone getting dropped, like I think my jaw still is to the floor. Like from the thinking about that presentation and being like, there's no possible way that that's a thing. I don't really foresee and I mean, you know, things can happen, obviously, but I don't think technology generally happens like that fast, where it's like we instantly are at a place and I think we're gonna have to collectively struggle with like, you know, living with Siri as Siri is right now. We just have to kind of continue to just see these slow continual improvements in, you know, neural networks and in natural language processing and things like that, to get to the point where it's quick enough to order and comfortable enough that it is as fast as going to the website and typing in the stuff in and going. Like I think when you get those questions of like, What's life gonna be like, in five years? You know, my answer is I look at what life was like five years ago. And I don't know, there's not like a whole lot has changed from a technological standpoint. It's like, my bluetooth headphones are a little bit better and have better battery life. And my GPS is a little more accurate, you know, to a certain extent, and the cell signals a bit stronger. But it's not like the difference between my, I didn't even have a razor. I had a katana, which, which shows how hip I was, you know. Going from my katana to my iPhone was just like, Oh, my God. This is revolutionary. And I don't know, I just I don't think you should feel too bad about yourself for your technology predictions.

Eric Caron 29:14
Well, thank you. You kind of skipped the BlackBerry part of it, though. And that's where I think the evolution from the razor to the iPhone made sense if BlackBerry had marketed their platform as something that the everyday person could use, rather than BlackBerry was just very heavily pushed towards, Oh, if you're a professional that's doing all of the business things then the Blackberry's right for you. Where Steve Jobs said, Okay, these devices can do a lot more than Blackberry, which with a more sophisticated screen and touch interface. It that felt like a natural revolution.

Where I'll go back to voice is I think we'll eventually get to the point where voice is more intelligent, but we'll go there through chatbots. So if you're contacting customer service at any company, I would imagine that the audience listening to this is probably split 50/50 on those that are going to dial the 1-800 number, just keep pounding zero until the human answers and then talks to that human, or the ones that go to the website, do the Turing test to see, is that actual chat bot a real person. And then when they know it's a real person, prefer to type that. So as chatbot technology gets more sophisticated, you can be more efficient with resources on the company side, because one customer service rep can do a chatbot conversation with six people simultaneously. You can only talk to one person on the phone at a time. So I wouldn't be surprised at all, if we really see chatbots continue to become a lot more sophisticated. And then it'll naturally segue into voice bots via Siri to the Chatbot platform we built up.

Tim Bornholdt 30:51
I I agree. I think you're absolutely right on that front. I want to change gears a little bit. And let's dive into API's a little bit. So at a previous company, you were an API product manager. And as a developer, I mean, API's are my everything, essentially. You can't really do much without a good API. So can you explain some of the things that an API product manager would be in charge of and maybe why a non-technical person should care about that?

Eric Caron 31:22
Yeah, before joining that company, I'd founded a previous startup, and we were a API centric design. And we spent time with investors having them understand why that was a good thing. And I've held that belief now for over a decade. When you're at a company, and you're talking about integrating two different systems, you'll learn very quickly on what companies are selling the platform, and what companies are selling their ability to manage the platform. Microsoft is a great example where you can just buy Azure, you can go in and do absolutely everything you want in Azure yourself, or you can pay the service professionals to get a little bit more out of it. API's, Azure in particular, is actually just a series of API's around their services. So I have always, you know, every role that I've had, and I've given many talks on it, is people need to understand that API is just a fancy way of saying, I can get my information out of a system and I can get my information into a system, however the heck I want. When you have that as the foundation, then integrating any two systems that you want are incredibly simple. And when you talk to vendors, just asking, Do you have an API, really helps you learn how they see their own product. Like, is it, do they democratize the data and their value is what they do with the data once it's in the side? Or do they have a little layer around it, where you're paying a little bit of a premium for them to massage the data in and out? But if every, if a platform is being integrated in modern times, it should have an API first. And then you should have your own decision to say, am I going to pay a different service to do the integration? Or am I going to do it myself? That's where companies like IFFT and Zapier have really done a wonderful job is they say, okay, yes, we work with all these companies that have integrations. We work with all these companies have integrations. We glue it together without much headache. And that's all API's are.

But we've done a wonderful job, and I say that with sarcasm, of making API seem incredibly complex. And that's because throwing around three letter acronyms is a good way to get people's eyes to glaze over. But API's are just so vital to anybody in the digital space right now. Because when I make my data flexible as an API first design would require, it means that anything that I would want down the road, it's just Legos. And that's a very, very fun thing to do. Because I don't have to keep going back and rewriting or adding different functionality. If the API can do it than anything can touch it.

Tim Bornholdt 34:04
What are some things you think about, like if you're in charge of building API's and kind of thinking about it, and from the perspective that you were mentioning of being a, somebody that wants to give out data and kind of democratize it, are there certain concerns or certain philosophies that you take when you're kind of architecting what that API looks like?

Eric Caron 34:26
Security is the first thing to keep in mind. And I really think that as a world, we're getting better. We're understanding why nobody should use the same password on every single site. And so for most technologists, they've been doing that for a while, but now that's becoming more commonplace. And API security is one where you just know when it's good, which is a really rough and a little bit more elitist answer than I feel comfortable giving. But when you see the documentation, and if they make the security feel like, Oh, this is the way that the key is versus, Oh, it's just this secret URL that we don't tell many people about it, shoosh. You know the difference there upfront because our system was handling very large number of transactions between very large credit card providers buying a whole bunch of very expensive electronics. Well, that's the kind of system where if the security wasn't there upfront, bad stuff can happen, as we learned from, shoot. Who's the trendy now data leak that just came out recently, like the T Mobile thing?

Tim Bornholdt 35:38
Oh, yeah.

Eric Caron 35:40
So security's got to be upfront. And if you have to ask where the security is, odds are, it probably isn't there. You should see it, but you also shouldn't be overwhelmed by it.

Tim Bornholdt 35:50
It seems security like on that front, it's the thing that it always strikes me as like the hardest balance to walk of you want to have a door, obviously, to give people the information that they're looking for. But it's like how strong a lock do you put on that door? And then, How thick is the door? And what kind of frame is it put into? And like those are the kind of considerations from an API standpoint, like if we're going to, you know, make it not so nerdy, like thinking about securing your house, it's like, you can have a deadbolt on your door. But if you don't lock it, that's a problem. If you leave the window open on the side of your house, that's a problem. If you put your key under a rock outside the front step of your house, that's a problem. You know, it's like, you have to take this in a lot of stages and think like, if you want to get to Fort Knox level of security, that's one thing. But there's like, probably basic things you want to do. And then depending on the type of data and transactions you're doing, that's what you want to be thinking about when you're implementing those different types of security.

Eric Caron 36:59
That's a beautiful analogy. Yeah, let's go with that. So, for example, what's the weather like in Eden Prairie? Well, I could look out the window and see it. So there's API's out there, like provided by NOAA, where NOAA, I don't know what that one stands for acronyms.

Tim Bornholdt 37:14
Oh, National Oceanic and, ah, dang it. I thought I had it. Dang it. All right. Pass.

Eric Caron 37:23
Almost had it. But like that one. Yeah, that's an open API, go and look at it, you don't need any credentials, because you could also just turn your head and look out the window. But your door, there's a lock, but you also probably in your house have a safe that has some of your marriage licenses and your car titles and different pieces like that. Well, that's not just sitting on your counter. Presumably, you have that in a safe in a house that has a different key. API's are the exact same thing. Uou need to know the correlation between the data you're protecting, and how much work it is to get or change that data. So yeah, you nailed it with that comparison to the different sophistications on the lock in your house.

Tim Bornholdt 38:01
Nice. And then I was derailing you, because you were talking about the different considerations you had when you're kind of architecting an API and going forward. So security being first and foremost, are there other things that you think about?

Eric Caron 38:14
Security is important. Documentation is vital. It doesn't have to be the the fanciest documentation. But if you're going to launch a feature, and you're not going to take the time to document how people would use that feature, why did you launch the feature in the first place? There's a concept called inner source. I know we're very well versed in what open source is, and but it doesn't always make sense inside of a company to open source everything. There's proprietary reasons, you wouldn't. And just because software exists doesn't mean you should put it up on GitHub. But the concept of inner sourcing is saying, I made this platform, here's the code behind it, because it might benefit others in the company. And here's the documentation on how to use it.

So API's, even if it's an API at a large company that is only used internally, if you're going to take the time to create it, create the time to have the documentation, set the foundation so other people know how to write their own documentation. And then when you're integrating things, you don't actually have to scrub through a bunch of code to make sure you're on the newest version. Just read the docs and understand how to do it. So I also say that. Again, it doesn't have to be super fancy documentation. There's a lot of really wonderful solutions out there. It used to be called Swagger. Now it's called Open API, that make it very easy to describe what your system is. But then when your company is interacting with another company, all the developers need to do is read each other's open API specs and they know exactly how to wire the systems together.

So documentation plus security, that's great. You can go on so many different tangents. There's lots of really thorough books that talk about API versioning and rest and semantic versioning. I don't spend a lot of time worrying about that one. As long as the system is there, as long as the system is documented, you can make it do just about anything. If you're creating an API from scratch, it's kind of like cryptography where you shouldn't go out and just wing it. Try to find some other pattern and use it. And so I think the rest pattern is beautiful. But documentation, I'll take thorough documentation over somebody that calls their API restful any day.

Tim Bornholdt 40:33
Yeah, you gave me shiver up my spine, when you said rolling out your own cryptographic solution. Oh, man.

Eric Caron 40:44
Don't is the short version on that one. Don't come up with your own password encryption scheme. Don't create your own hash scheme, use something off the shelf.

Tim Bornholdt 40:52
Like I know people that write those for a living and even they are like, you might want to do something else. Oh, man, yeah, no, I think that's a great start for any API that you're thinking about writing or, you know, taking it to anyone that might be listening to this, if you have data that you want to either share with the world or share internally or anything like that, coming up with, thinking of those two things, first and foremost, when designing an API are really important. And then yeah, understanding the concept of rest also, that in and of itself does not make a solid API, like you have to extrapolate on that and make it apply to your certain case. But I think those are really great pieces of advice for anybody that are, you know, trying to figure out how to, you know, work into this world of crazy world of API's.

Eric Caron 41:47
Is there a limit for the maximum number of analogies that we can come up with on a episode? Or can I add one more?

Tim Bornholdt 41:54
I only talk in analogies, so I hope not.

Eric Caron 41:58
If you think about API, if you think about your company as I'm gonna say the Deathstar, because that's a new Lego set I really want.

Tim Bornholdt 42:06
Do it.

Eric Caron 42:09
If what you've created at the end of the day is this big sculpture, think of API's as the little Legos that build it together. If you just made the entire thing as one gigantic, four foot Die Cast mold that you can't take apart, then when somebody says, Hey, by the way, we're not going to make the Deathstar anymore, we're going to change it into Hogwarts. You don't want to have to like melt it all down, and then recast the whole thing. But if it's all a whole bunch of little Legos, it's pretty easy to dismantle and reassemble or add new pieces on top of it. So that's why I really encourage the API centric design philosophy when your company is creating technology, creating API and then just build everything that consumes your API. Cause then when you're working with other outside partners, they'll be able to consume your API itself, when you have to launch that new, when BlackBerry makes some resurgence, and now we've got Android, iPhone, and Blackberry, well, you've got this these API's, that you're just teaching BlackBerry to talk to rather than having to create a whole new internal code base.

Oh, and it's also a wonderful way to understand the technical sophistication of any vendors that you would want to work with. You learn so much based on, Do they have an API? How well is the API documented? How easy is it for you to get access to it? Do they provide third party libraries for you to be able to resource itself, you know, going on Ruby gems going on NPM going on packages, just is the company described there?You learn a lot about how the company sees themselves, where a company sees their value. So whenever I'm talking with a partner, even if they've got a fully baked off the shelf solution that I want right now, I still ask them if they have an API, because that lets me know that the next thing I want with them, even if they don't offer it themselves, I know my team will be able to build it.

Tim Bornholdt 44:05
I do have one more topic I want to touch on. And that's you wrote an article recently for CIO Review about how apps should spark joy. And we're definitely going to link to it in our show notes, because everyone here should definitely read it. I think in it you mentioned there's really no shame in saying our company doesn't need a mobile app. And that line particularly hit me because I often tell people that I'm the world's worst app salesman, because I'm constantly talking people out of building mobile apps, because for the exact same thing, like you don't necessarily need to have a mobile app. So I'm curious, why did you write this article? And why should apps spark joy and why should companies have this mindset when it comes to their digital efforts?

Eric Caron 44:50
Earlier on when I talked about you have to measure and you have to know why you're developing things, so often people assume they need a mobile app because they need a mobile app. And that's, to me, that's so dangerous. Not only does it add clutter to the app stores, does it add confusion for people installing a bunch of apps that get abandoned, it's just in the theory, like all ships rise with the tide? Well, if you also put like a whole bunch of apps out in the store that nobody actually wants and is just clutter out there, well, then other people have bad experience, they stop liking their phone, it's just, I really believe that a company should look at their digital assets the same way they look at their physical assets, what I mentioned earlier. And if they only made an app purely for the investors, and they got the investors and they close their series C, and now they can move on, great app did what it did. We don't need to spend any more time on it. We'll just close it on the App Store and move on. But if you treat your app the exact way you treat a new physical location that you open down the street, well, it makes people have thoughts about the company.

So the whole thing just came from drawing the parallel between if you invest in something physically, you should invest in something, and you should just have that same level of logic too if you invest in it digitally. And you might not be thinking about your app that you haven't provided an update on for the last two and a half years. But if you're still linking to it in your footer, well, then your customers are still stumbling across it. And when your customer is clicking and installing an app that hasn't been updated since bevel and bubble and shadows and Twitter bootstrap 1.0 where all the rage,

Tim Bornholdt 46:29
Skeuomorphic.

Eric Caron 46:31
Yeah, people are gonna think poorly on your company. So you got to always be aware of what are all the assets that you have, that your customers can interact with? Is it reflecting well on your brand, and if it's not, there's absolutely no shame in saying, you know what, we don't need this. We're gonna sunset it. And then later on, when you say, Oh, we do have a new need for it, bring it back. But code just sitting out there rotting makes a company look bad. It's a security risk. There's just no reason for companies to keep apps out there simply because they made it in the past, and they're shy of depreciating an investment.

Tim Bornholdt 47:07
Yeah, I think my core belief when it comes to apps is that people hate them. Like, I genuinely believe that most people hate apps, like if you drill down into it, people only use apps to accomplish a goal. Now you could look at something like Facebook and Twitter and social media apps and say that, you know, the goal is really like they've just got hooked into the dopamine release lottery, slot machine system. But that's, you know, neither here nor there. We're talking about apps for your business or for your internal team. I don't know very many companies that say, you know, we spent all this money on our own internal software, and I love it. It makes me so happy to go into this app every day and use it. Which is a shame because I think there are little things you can do to make your apps spark joy and and be delightful and give people a knowing like nod or some you know, whatever kind of humor you want to inject into it. There's just little things you can do to make the experience enjoyable. Because at the end of the day, people just want to use apps to get a job done. Like whether that's ordering coffee, or filling out a sales form. Or, you know, we have an app that we're working with a company called TurnSignl, and it's like that app is is helping people stay safe when they get pulled over by the police. It's there's all kinds of different reasons for an app and I think, but I don't think people necessarily think of like, the apps, when you on your internal team are thinking like we have to have an app, it's like, Well, do you? Is that what's going to help people find value and get their job done and move on with their day or accomplish a task? That's the stuff I always think about when I'm convincing people not to build apps.

Eric Caron 48:57
Yeah, couldn't agree more. And it applies to absolutely everything in the physical space, in the digital space. If you have an account on Snapchat that the company just isn't maintaining anymore, it is okay to say, You know what, we're not updating this anymore. If you want to follow us and see new stuff, click over here. If you've got a website that nobody's actually using anymore, don't just leave it out there because you spent money on it years in the past. I mean, you and I can talk about like capex and opex and depreciation and all sorts of finance stuff later. But really, if it's just still up there because it's up there, but you are trying to actively discourage customers from stumbling across it, well ask yourself, should we just take it down? Everything reflects on the company and if it has the risk of reflecting on the company poorly and, you know, adds a lot more noise and we have such limited opportunity to capture that customer's signal on where they care about our company. Like, get rid of anything that isn't sparking joy in you and sparking joy in your company. It applies to everything. And when you just accept that it's okay to say thank you for your service code, move on, even though I mean, we stopped talking about Kondo's methods, what, two years ago now. So it's a very outdated reference. But the moral of it is still and will always be incredibly true. Feel free to say thank you. This technology, you did its job. I'm going to turn you off.

Tim Bornholdt 50:32
You can also take it the opposite route, though, and be like the Space Jam website from from 96, which I seem to reference a lot on this show. But you know, there's a point where your technology becomes retro and cool. And everyone wants to see like, oh, look, when remember when we used to do like image maps for websites, because we couldn't have like, you know, CSS.

Eric Caron 50:51
Yeah, I couldn't do a rounded corner. So I had to slice a GIF into four different corners. Yeah. Good days.

Tim Bornholdt 50:59
But, it's true. Like, I think people tend to just want things to just sit around. And I think, you know, everyone has that box of crap in their basement that they've been carrying with them from when they were like, you know, kicked out of their parents house basically, of stuff. Like I still had, the other day, I was going through that box that I have in my basement. And it had all these like, marching band awards, and like, the captain certificates and stuff. And it's like, they've literally just been sitting in this box, like they're doing no good for anybody. And it's just like, it is like you said with Kondo's method, like, it's not sparking joy in my life, it's just taking up space and making me feel guilty that it's just sitting around. And you can take that same approach with your technology and say, you know, this was a cool idea a few years back, and we got a lot of value out of it. And now we're not so, say adieu.

Eric Caron 51:51
And spring cleaning has many benefits. It provides room for new stuff that you want to buy on and for security down the road. Let's use the example on, you've got an app, you haven't updated it in four years, you've had no other plans to use it, you've only got three customers that use it once a week. But you keep it up there because you always have. Well, then another team is looking at their services that they provide. And they've got an API out there. And they can't turn it off because there's this one app that's still connected to it. Well, so that API is still out there, that API has a security risk, they could have just as easily sunset that API because you had sunset the mobile app. But there's ripple effects about leaving legacy code out there. And every company, if you are storing any information about your customers, it's your duty to make sure that you're storing as little information as you possibly can, and that you're doing as much work as you can to keep that data secure. So good housekeeping, getting rid of old apps, lets you do a better job in making sure that you're enforcing the customer's security that everyone deserves and expects.

Tim Bornholdt 53:00
That's beautifully said. I'm so glad that you came on the show today. Because I think we could have definitely done another two hours of just going off on any of these topics. So I will, we'll have to get you back on. But in the meantime, if there's any way anyone can reach out to you if they have questions, or just want to get to know more about you, where would be the best place to send people?

Eric Caron 53:23
Twitter's good. I'm at @ecaron, at E C A R O N and email's good. Me@ericcaron.com. Always, I believe that the Twin Cities and technology we all get better when we work together. So always happy to help anybody out. And just thank you so much for doing this podcast. Again, the more we're talking to each other, and the more we're sharing the knowledge wealth, the better we all make each other. So Tim, thank you and your whole team for having this podcast.

Tim Bornholdt 53:54
Well, I think the more like people can hear two nerds having a conversation about something nerdy and realize that there's not you know, a whole lot of magic behind it, I think it is doing a net positive for the community. Man, that sounds like I'm tooting my own horn. But I just, I'm really glad you came on because I think it was a really valuable conversation in a lot of ways. So thanks again, Eric. I really appreciate it.

Eric Caron 54:21
All right, talk to you later.

Tim Bornholdt 54:25
Thanks to Eric Caron for joining me on the podcast today. You can learn more about Caribou at Cariboucoffee.com.

Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast. This episode was produced by Jenny Karkowski and edited by the nifty-gilifty Jordan Daust.

As I mentioned at the start of the episode if you could take two minutes to leave us a rating and review on Apple podcasts, we will give you a on a future episode as a thank you. Visit constantvariables.co/review and we'll take you right there.

This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at JMG.mn.