• expa.com

Allen Pike: Welcome to It Shipped That Way where we talk to product leaders about the lessons they’ve learned, helping build great products and teams. I’m Allen Pike, and today’s interview is with Milun Tesovic. Milun is a partner at Expa where he works with early stage product companies, and previously was the founder of Gitalytics, Cmd, and MetroLyrics. Welcome, Milun.

Milun Tesovic: Thanks, Allen. Happy to be here.

Allen Pike: I’m glad to have you on the show. I’m excited to dig in to the many years of experience you have working with product companies, building product companies, founding advising, and all of that. We’re probably going to have some fun.

Milun Tesovic: Yeah, absolutely. I mean, many good and mixed reviews on the years. It’s been a fantastic journey.

Allen Pike: Well, that’s how we learn.

Milun Tesovic: Yeah, exactly. The hard way.

Allen Pike: Yeah, exactly. So before we get into details, tactics, stories, war stories, how do you like to summarize the Milun story so far? I know it has various chapters, but how do you like to orient folks as to where you’re coming from and how you’ve learned what you’ve learned?

Milun Tesovic: Yeah, I mean, my first journey, I just stumbled upon entrepreneurship. It was never intentional. It was never something that I was thinking about. It wasn’t like a company that was really, truly, deeply in deep consideration before pushing it out. It’s always just been following a passion and then just stumbling into the first company. And then from the first company picking up a couple of lessons, picking up a couple of do this, do more of this, don’t do any of that. And then it became a little bit more intentional after that. So I’ve had a really interesting journey where I stole it off with relatively low amount of experience and then gradually built it up with the people that have surrounded me, with the teams that I’ve built and all the different various categories of companies that I’ve started. So it comes from humble beginnings of Bosnia to immigrating to Canada. We run food stamps and we were heavily reliant on welfare to starting up my first company out of necessity and out of passion to, now being very intentional where you evaluate a thousand ideas and maybe you pick one.

Allen Pike: Yeah, that’s a huge… Its interesting that you describe that path because in some ways it echoes myself as a teenager, certainly I was not very thoughtful about what things I would try. “Oh, I like the idea of making a card game, so I’m just going to hand draw cards and then try to sell them to my friends.” I am 12 or 13. It doesn’t even occur to me. It’s like, “Yeah, are you going to make enough cards to even make this sense?” Just throwing spaghetti and then 20 years later it’s like a spreadsheet of hundreds of things and doing hundreds of customer interviews to figure out where to invest your time. So that’s kind of one of the muscles that we learned. So the famous part of your origin story early on as a teenager was MetroLyrics, which you built from obviously nothing to the largest lyric site in the world at that time, but you’d been doing some entrepreneurial experiments and stuff before that. That was just the first one that really clicked, right?

Milun Tesovic: Yeah, exactly. It’s like I took a liking to technology a long, long time ago, and what ended up happening is you build these things out, either passion or necessity or it’s just hacking away on the weekends, and then you quickly figure out that other people faced the same issue. Way back in the day, I don’t know if you remember the show, Dragon Ball Z. I remember watching the show as a teenager and I really wanted to somehow quantify the different power levels of the different characters. And I remember going online and there were a couple of websites that already did that, and I really took a deep disagreement with how they quantify. So I was like, you know what? I’m just going to go. I think it was-

Allen Pike: That one is wrong on the internet.

Milun Tesovic: Yeah, it was like, I can’t believe the internet gave me misinformation back.

Allen Pike: About this critical topic.

Milun Tesovic: Yeah, yeah. It was very important to me. So I remember, I think it was Microsoft Front page back then, because again, it wasn’t intentionally, I’m going to go learn HTML. So there was this tool to help you bridge the gap. This is before YouTube, before most of the things. You’d have these hardcover books be printed, but by the time they’re printed, it’s already out date. So I use front page to give me a bit of a leg up in terms of learning how to create my first website, everything. So I did my own quantification of what I would think was happening in those episodes, and then I went to go put it online and quickly learned that it takes money to do that. And it was quite frankly, money that we didn’t have. So you need a hosting, you need a domain, you needed all these other things, if you didn’t want to go on GeoCities for everybody who remembers that. So yeah, my first venture was actually, I remember I was like, you know what? I can rent an entire server for a hundred bucks of. I could just sell tiny portions of it to other people out of a co-location center, and then I’m just going to sneak my website into there. So that’s what I did. And then after that I quickly realized, I was like, you know what? I can put way more than 10 people on here. And then that’s how I discovered Profit Launcher. What started off as a teenager’s opinion on just how to push my opinion onto others of what was happening at this TV show, quickly turned into a smaller little business where I was like, we had 10 servers. I ended up bringing a partner in on that and it just kind of snowballed a little bit from there. Over time, I found myself getting a little bit jealous of some of the websites. I was like, I take this website, it’s growing. It’s like they need more space, they need more everything. Meanwhile, everybody figured out that if a teenager can open up a web hosting company, so could they. So at that point in time, Profit Launcher started diminishing. You have to have lower prices to be competitive. And then it kind of got me thinking. I was like, what am I passionate about? And part of it was like, it’s like I was learning English for the most part, probably still am today, and song lyrics is a very popular way of doing that. So was something that I was looking up quite a bit. I was really frustrated with the fragmentation of the databases out there and inaccuracies, which apparently I have a knack for. And I ended up basically putting together the first database. I wanted to make it more comprehensive. I wanted to give the community the ability to edit it and then push that online. And then that’s what snowballed that into a bigger and bigger project. There were other smaller projects along the way, but a lot of those were just passion projects, and a lot of those helped me learn scalability. One of them was like a banner exchange, and I can’t remember how many tens of millions of hits we did every day, but I think we did it off of one server, and that’s when I discovered the beauty of caching. It’s like all these things just kind of snowballed into what ended up being an actual company.

Allen Pike: So you built this thing, which seems obvious in retrospect, is from a mindset of a SaaS, people build software in 2024 was like, “No, no lyrics site exists that has all of the lyrics.” And of course, build a CMS where people can contribute and crowdsource it. That seems like obvious now, but at that time it’s like, “Oh wow!” But mind blown. And of course it ends up being, as I said, the largest lyrics site in the world at that time. So you built that business over was about a decade. How big did the team end up growing from you starting as this quirky tiny project up to the biggest lyrics site in the world?

Milun Tesovic: Yeah. Well, the first five years was just hacking away. The company only became rather serious maybe around ‘07, ‘08. And at that point in time I had about 5 million visitors on the website every month, and that’s when it actually started getting a lot more traction. We started getting noticed by music labels or lists, and that’s when I brought on a business partner, Alan Juristovski, who has helped guide and mentor me all throughout the entire journey and really taught me a lot about the basics of business. At that point in time I was only 18, 19 years old, and then having him step in and really show me, okay, it’s like you might have the tech portion down, but I’m like, this is how the rest of it’s meant to be run. Over the next five years is what really kind of crafted business. So we were one of the first purely dedicated lyric websites that went out there, negotiated the deals with the vast majority of the publishers. We kind of crafted one of the first templates that ended up being applied to most of the deals happening out there at the moment. And then from there, it really allowed us to move away from this gray zone of hacking things together, seeing what works, SEO kind of activities into, “Hey, we have a legitimate business now. We’re paying our fair share to the copyright holders, and we can move at whatever pace we want to go at.” And over those five years, we’ve had traffic go from 5 million unique visitors to 55 million, and the key attribution to that would really be paying attention to what the users wanted, which was up-to-date songs. They wanted it super accurate, so we hired our own editorial team. They would keep track of things. We would snatch up songs as soon as they would get leaked, in order to be the first ones to get the lyrics out there. We did a lot of partnerships like AOL Music. We would do official partner, so they would be deep-linking back to us from every song in their catalog, but we’ve always kept it a very lean operation. This is before I truly discovered the meaning of startups and venture capital and everything. So it was bootstrapped from day one. We never took any VC money, but it also meant that we kept the operation at modest growth. So at Peak, I believe we had about 15 employees, and it was a small little nice operation out of Burnaby before we got noticed by a couple of larger media giants who then got interested in acquiring us and putting us on their property. And then that’s how we ended up at CBS.

Allen Pike: Nice. Yeah, I mean that’s a common first step in some folks that end up building venture-scale businesses is a bootstrap effort that they end up walking backwards into hit traction on something and learn a lot really rapidly. Obviously, if you’re building a business when you’re a teenager, you’re learning things, making mistakes. So before we step on to the next stage, building various other businesses you’ve been involved in, are there any lessons, things that didn’t work, things that were, you mentioned hard-won lessons or challenges that came through that MetroLyrics experience that would’ve been easier if you could send a note back to yourself as someone building a product company for the first time?

Milun Tesovic: Yeah, I think really important lesson is when building a company, be careful whose IP you’re building on top of.

Allen Pike: Sure.

Milun Tesovic: So MetroLyrics was purely reliant on the music industry. We did have news, we did have music videos, we had plenty of other content, but at the end of the day, it was all IP that wasn’t generated by us. So at the end of the day, we were basically a middleman bridging the public to IP content of other creators. And that puts you in a very difficult spot. You don’t have a lot of negotiation power. This company doesn’t exist without the IP holders and the creators, so they want you gone, you’re gone. And you have multiple stakeholders to basically keep happy at the same time. And that could be a very challenging juggling trick. I was very passionate about music. I mean, this is a great category for passion, probably not a great category if you’re looking to build up a big, long-term successful company simply because too many shareholders, too many expectations, and those expectations don’t necessarily always align.

Allen Pike: Sure. Well, you mentioned a song gets leaked to where it’s like, “Oh, this song wasn’t even released yet.” And then what your users want is, “Hey, lyrics for this song.” And maybe what the labels want is you to pretend the song doesn’t exist, I would imagine.

Milun Tesovic: Yeah, yeah, exactly. There’s definitely kind of like a tightrope that you’re walking through there, but at the same time it’s like the labels want you to maximize your revenue. So during negotiations that they could capture a bit more of that capital and users would really prefer to get everything for free without any ads. So there’s a big balance in between that. Meanwhile, we’ve had dozens of competitors operating overseas that don’t have to pay a single penny to anybody. So it was a bit of a challenging game. So that was a great passion project. It was great, something to stumble into, but it was really after that company that I got a little bit more intentional in terms of, okay, if I want to build a proper big company, how do I minimize the number of stakeholders? How do I make sure that incentives are aligned across everybody? And usually that kind of lands you in B2B categories, which is where my next two companies ended up going.

Allen Pike: Yeah. So following the chronology, as I understand it, Cmd was your next venture, very different space, cybersecurity for enterprise Linux versus lyric sites for people on the internet. How was that transition?

Milun Tesovic: Honestly, it was great, even though I’m like MetroLyrics was a consumer product within the music space and we did a lot of fun things. We hosted MTV parties, watch music award parties. We even had New York Times squares like ads and takeovers on lobbies. So there was a lot of fun in it. At the end of the day, it was still just a nerdy engineer on the back end who missed the days where you can run things off of one server and like Memcached. And so I’ve always been very much so engineer at heart as much as music might not lead to that. Once we got acquired by CBS Interactive and I joined this massive organization and I had other teams that I had to participate in and also manage there were other issues that I started picking up. That was arguably my first job post-op position where I got relocated to New York. I sat inside the CBS office. They were fantastic people there. But you start picking up a lot of these inefficiencies, where one of the biggest inefficiencies is these server outages, not necessarily just Metro alerts, but across some of the other platforms. So you end up talking to the teams that are behind it and you quickly realized there was very little transparency. Everybody had route access at that point in time, and there was virtually no visibility unless I’m like, you’re doing incredibly detailed blogging, at which point in time you’re posting through the logs to figure out what happened, provided that it’s like that event happened while the logs were still running. And it really got me thinking. It was like, well, there’s got to be a better way to handle this. And out of all of that data and engineering, it was a bit of an interesting thought exercise to think, well, what would an ideal solution for something like this be? Which we took the most difficult path, which is, well, let’s do a pre-execution, so let’s do it at the kernel level before it gets executed, which for anybody familiar with Linux systems, you can type in one command and that can spawn 10,000 commands in the backend. And the last thing you want to do for an engineer is slowdown. I mean these guys will notice one or two second slowdowns out of an entire swap script.

Allen Pike: Famously, we had a huge security thing caught recently because someone noticed their terminal sessions were slightly slowed down by some attack.

Milun Tesovic: Yeah, exactly. So it’s a double-edged sword. Yeah, so at Cmd, I brought on another co-founder, Jacob King, who was fantastic. He had a security background unlike me. I had a bunch of system administration background going back to my hosting company and all of the other ventures that I’ve done and then observing it at CBS. And with Jake, we really wanted to see if we could push the limits of what we could build. So we were one of the few agents out there that would try to authenticate every single command before it hits the kernel to pick around who’s the user, what is the context of their command, can they execute it, should they execute it, and then either give it a pass or deny? That was a very typical endeavor, but we were lucky to build an amazing team and really, truly find amazing talent within the Vancouver ecosystem to help us do it. And that basically led to the product CMD.

Allen Pike: One of the themes that’s come up in the show, and I’m curious how you think about this, is sometimes when teams are building early stage products or trying to go over zero for one, they’ll take the mentality that’s like, “Let’s build the simplest thing that we can to try and improve demand for this.” And other teams will look at it and say, “Well, if it’s really simple and easy to build, then we’re not going to have any competitive advantage of anyone else anyway. Let’s try to do something hard.” And obviously you’ve just described the latter, they’re trying to do something hard. From this example and other examples in teams that you’ve worked on and companies you’ve invested in or advised or whatever, do you think there’s any sort of durably useful tactic there around deciding when it’s worth trying to do the really hard thing that is kind of requires a bunch of risk and implementation challenge versus when it’s just like, “Ah, let’s worry about that later, or let’s try to keep our software as simple as possible”?

Milun Tesovic: That’s a great question without any form of answer that I would classify as good or above.

Allen Pike: Yeah, okay.

Milun Tesovic: The best that I could do here is say if you have the kind of idea where you can validate aspects of it early on, and I think idea validation is a great topic on its own because with an idea validation, if you’re convincing enough and you’re charming enough, you can get anybody to say any ideas virtually good. I think there’s a science behind it in terms of how you can approach experts within the field, potential customers and truly listen to them in a meaningful way where you’re not trying to lead them to the optimistic yes that every founder wants to hear, but rather truly read between the lines and get a deep understanding of, okay, is this just a nice to have because most people are going to be nice to you and they just don’t want to give you the bad news, or is this something that’s maybe not the right timing or maybe it needs a little bit more work. Within Cmd, one of the reasons why we knew that, I’m like, okay, this needs to exist and we should just take the long-term approach is, I’ve had experience with CBS Interactive and I’ve seen it firsthand how messy these systems are, and I’ve seen it firsthand how difficult it could be when you try implement access controls. Where you try to move everybody away from root access and the ability to move quick and fix things to a very standardized user access type roles where things break, things get clogged up in red tape, servers go down, nobody’s sure who has access into it and you can end up in this mess. So our goal was let’s not try to change the behavior, which is the ideal way from my opinion, most of the businesses and just try to provide a solution that could fit within the existing patterns. Jake came out of Hootsuite, so he had a lot of experience with a very fast-growing startup, also based out of Vancouver, incredibly successful. He experienced very similar issues. So when we finally got together, it’s like we had a lot to discuss. We had a lot of headaches that we dealt with for the exact same problems. We, at that point in time, were fortunate enough to be involved with a couple of individuals from Uber, so it’s like we spoke to them in terms of like, “Hey, how does it work within your systems?” And it’s like we did our best to, what I was saying earlier, listen in a very subjective way to truly understand, is this a product that’s needed? And we got enough conviction to say like, “All right, we’re going to go spend the next year and a half trying to achieve this sub-millisecond authentication for command.” So the engineers still notice that tiny little spike in CPU usage. So I’m, because even 2% across a couple of hundred servers, it’s like we’ve now become a rather hefty cost addition to these companies, so it really needed to be dialed in. We ended up achieving that, but then it’s like any other B2B enterprise business, especially when you want to operate at the current level, ran into quite a few other issues.

Allen Pike: Yeah, well, I mean, don’t envy trying to sell a large regulated enterprise on let me run a code every single time. Every single command is running at a criminal level. I mean, we’ve seen what happened with CrowdStack recently, why some companies could be a little bit challenging to accept that kind of thing. But you said something in there that I think is maybe is a durable lens at least is useful to think about. It’s like when you’re thinking about doing hard things and how you’re building your product from zero to one, obviously if you can prove something out without taking a big technical risk, then that’s great, but also something that’s maybe, or I think often agreed to be even more dangerous than a big technical risk is betting on being able to change user behavior. Like, oh, it would be great if everybody… I mean the infamous business ideas that tend to just not work, it’s like, oh, if all the users just did this, everything would be better. They just have to all change to this other pattern. And it’s like, yeah, in theory and eventually maybe we’ll get there, but your product is probably not good enough to make an entire company’s mindset about how people do their jobs flip. Every once in a while a product comes around, but that’s often even harder than writing code that does something in less than a millisecond or something like that, which is itself hard. So maybe there is a durable nugget there.

Milun Tesovic: I mean, look, I’ve learned adapt less than the hard way both personally in my projects where you’re like, of course, doesn’t somebody want to be more efficient? Doesn’t somebody want something better looking, better functioning? It’s like all these different bells and whistles that you could put on it. And then I’ve also learned that lesson the hard way through my investments. It is one of the lenses that I’ll look through companies right now because if a company approaches you, they’re like, “Hey, if we could just get people to do X, we’re going to have this great company.” I’m going to have a lot of questions around, well, what is the motivation for that? Behavior change takes a lot of motivation. It takes a lot of willpower, it takes a lot of top of mind memory for them to truly care about your product and keep it in mind every single time they want to perform such an action. And I would say the vast majority of companies within that category, fail. There are a few to make it through and they break through and they become great companies, but the odds are so stacked against you that quite frankly, it’s a category I decided a while ago just not to participate in.

Allen Pike: Doing a hard thing in hard mode basically. So that was Cmd. And then the next company was Gitalytics, which I know a little bit less about. I know that it was an analytics product that ended up exiting to GitHub and it’s now GitHub Insights, which is cool. Its the origin of a feature that still exists today. But you want to tell a little bit of how that started and then lessons that you learned during that similarly to, say, some of the lessons that you learned doing Cmd?

Milun Tesovic: Yeah, absolutely. Gitalytics, also similarly, it was inspired a lot of CBS interactive. So at CBS I have multiple teams within different time zones and different categories. And I guess the theme between both their companies has become disability, and as soon as I started working with engineers that were remote, one of the key things that I’ve noticed is you have the product managers, you have the designers, you have other stakeholders within these larger organizations. They’re constantly looking for updates. And they’re looking for updates, they’re looking for efficiency reports, looking for, “Hey, what are you guys working on? What was the blocker last week?” And you could certainly have more meetings to communicate all of this where it gets funneled through an engineering manager, they decipher it and then they pass it up to management. But the tool that we set out to build was really, “Hey, can we provide a few more insights around engineering teams to management that both parties can agree would be of value?” So what we avoided heavily would be lines of code added, removed. That’s not the category that we want to stay with it. Where we wanted to go is I’m like, “Okay, well what’s happening to the port requests? Are they lagging? Was their intro team conflicts based on the comments that were being left within the port requests? Which engineer was complimentary with another engineer?” So in the event of somebody leaving, moving, being sick, who is somebody with deep knowledge of that specific code that the other engineer was working on, that could be passed on, it was a lot around who might be burning out. You could track it. It’s like this individual’s checking in 12 hours a day, which we all know can lead to bugs and inefficient code. So it’s like are you being reasonable with what you’re asking of your team? So we try to be a little bit more proactive where we could give non-technical people slightly better insight into what’s happening within their engineering resources without making engineering feel like they’re under a microscope and they’re like, “Okay, you know what? I’m just going to pattern it with 50 lines of code to make it better.” So we’ve really tried to stay away from vanity metrics and try to provide something that both parties can be like, “Yes, thank you for communicating on my behalf. The thing that I’ve been trying to tell them all along.” And for engineering manager, sorry, the non-technical stakeholders, for them to be able to look at it and be like, “Oh, okay, I understand what happened within last week. I could see what’s happening to the pattern. I could see that maybe I’m asking for too much and I could see that people are going to start burning out. And also I could see an increase in bugs because I’m like, a lot of the tickets and PR requests, they do get tagged.” So I’m like, I could see there’s a massive big increase in bugs when I’m pushing the team too hard. So I’m like, they’re just doing what they can, but am I causing that? So that was really what Gitalytics set up to do. What was really interesting about that product is we launched it for about a month. We had our first couple of customers hop on, and at that point in time, it’s like we were approaching a couple of other companies. We were like, “Hey, it’s like we just built this. I was like, we’d love to do it kind of partnerships if you have your teams, anybody like that.” And then that’s how we got chatting with Matt Reedman at GitHub, and he is like, “Actually, this is really good timing.” He’s like, “We’re just discussing this internally. We do see a trend and a need for this and this is something that our customer base has been asking for.” So we went through a discussion where they were like, we’re either going to build or buy, and I walked them through some of the difficulties. I think we were very transparent. They’re like, look, if you guys want to enter the market, I was happy to give some learnings. And then we ended up deciding that GitHub might be a better place for this product given the scope of their customers and everything. So yeah, after just a month in the public view-

Allen Pike: A month in market.

Milun Tesovic: Yeah, exactly. We got a good offer that the investors and everybody was happy and we ended up getting it acquired to Microsoft. They were really impressed with the team. So we didn’t have anybody, certainly not engineering who ended up leaving as part of the acquisition and most of the team ended up staying there. The deep integrations with the rest of the GitHub ecosystem, the product ended up being part of their enterprise suite. And yeah, I think it was a great little transition, a good little story where we all had a product idea that we wanted to just get out into the world and then see you be adopted in a meaningful way for such a massive organization. It was actually really fulfilling.

Allen Pike: Wow. So it’s interesting that you say that the investors were keen on that because one of the stereotypes of venture-backed startups is, if you take the investor’s money and then a year later you’re like, “Ah, actually we’re going to be acquired instead of try to make this a giant IPO track thing,” the investors are going to try and say no, or at least strongly dissuade you from doing that if they don’t have the ability to say no. So it’s interesting that, I don’t know, maybe there’s something about the circumstance or the investors or maybe it’s just a good offer that made that happen. But it’s interesting sometimes I hear the opposite story from founders who resent 10 years later that they’re like, “Our investors got in the way of this. What would’ve been the best opportunity for this startup that we instead got pushed to kind of keep pushing for five years and then GitHub ends up killing us by giving the thing away for free,” or whatever their fate ends up being.

Milun Tesovic: That’s another great question, not a great topic. No easy answer to it. Even at Cmd, we had a lot of pressure from the investors not to sell and that was a fantastic offer, especially looking back on it now, it doesn’t get much better than that. What it really comes down to is what does the founder want to do? At the end of the day, I’m like, you’re the heart of the company. And for some founders they’re like, “Great, you know what? I’m just very passionate about this company. I want this to exist, but I don’t want to make this my life mission.” So it’s like we all have products that we want to see come to life. That doesn’t necessarily mean that this is something I want to give up money 10, 20 years to try to push it all the way to IPO. And when you see the market uptake, it’s like that specific product to me is also, which leads to another category, which is like, is it a company or is it a feature? And this one here, I kind of came to the realization, you know what, this will be a tab on GitHub. They’re just going to build a tab and when they build that tab, why would anybody go open up a new browser window, log into us, go through all of this, connect their GitHub account, handle over all of their code for analysis, when it’s like they’re just within the same platform? You got your port request here, like 10 pixels over you got a new tab. Just click on that, you got the exact same info. So for us, we achieve two things. We’re like we could get this thing adopted and we could see it out in the world, and it’s like we work really hard on it and the team was incredibly talented. You get to see the fruits of your labor out there. And then the second part of it is, we don’t have to compete against this tab or the small, what would be a tiny little feature on GitHub that quite frankly would be really tough to justify when you’re trying to sell it to somebody specifically, because this is a very defined set of a product that doesn’t really leave a lot of room for interpretation once that’s developed. That’s why if you have look at these types of products today, they’re relatively similar. So I think it was the right call at that time. Cmd, it’s still a question mark, whether or not, should we have pushed on to make it bigger? I think we were like 50 employees at that point in time, the vast majority of engineers. But again, it was one of those where under Elastic, we just saw massive adoption, tons of company using it, and as a founder and as a builder, that becomes incredibly fulfilling. The thing that you’ve built is now getting a lot of adoption and I like, it’s creating this value.

Allen Pike: Well, I’m certainly sympathetic to that. As a founder and builder, I like building things that people use and give value out of rather than the sort of well, just grind out and the thing’s probably going to die, but just stick with it in or death. So certainly sympathetic to that mindset. So you’ve built a couple startups then with different mindsets and I’m sure also advised and worked with startups that were doing this that you didn’t found yourself, that were in this developer tools and selling to developers, working with developers as your target market. Is there any kind of tactics or mindsets that you’ve built, lessons learned around developers and dev teams as a market? Asking for a friend who is me who is currently doing that.

Milun Tesovic: Yeah, another friend. My developers, it’s a very, been a key target. I still do a lot of my own coding, a lot of my home projects. I would absolutely not push any of my code into the production, but what I go back to is developers, they want to be efficient, they want to work on things that are really interesting. They want tools that help make them better, and that comes in many different ways and forms. I think if you’re going to be building within the developer marketplace, it is so important to listen to them from day one. And I mean, listen, well, don’t just try to get buy-in, temporary buy-in, just ask for a credit card later and for it to never appear. Truly get a deep understanding of what is the workflow, why do they need this, what is the value that it provides? There are so many different developer tools out there that are all vying for attention. They’re like, oh, it’s like help you code faster, I’ll help you read code, I’ll help you discover new frameworks, I’ll help you… There’s way too many. So it’s really zero in on what is that one key thing that the developers usually what… They dislike doing and then help them solve that without asking for too much behavioral change in return.

Allen Pike: Yeah. Well, I like that mindset. Certainly there’s a long history of developer tools where they try to take away something the developers like to do and then it’s like, “Well, I don’t want you to do that part for me.” Those startups, which is obviously awesome built like this foundation. Since then, your focus has been advising and investing in businesses and helping them get their starts. I know you’re an early investor in Uber, Discord, Stripe, which is a pretty amazing, even just if those are the only three. And then obviously, you don’t get three successes that big without making various other bets, some of which that do succeed and some of which that don’t succeed. I’m curious, is there any favorite or go-to things that come to mind when you think of pitfalls or traps that product teams that you’ve been involved in kind of get stuck in when they’re in this pre-product market fit stage where there’s so much uncertainty, you could go in a hundred different directions, you could always find some odd advice or Y Combinator blog posts that says you should be doing the opposite of what you’re doing, and so there’s all these holes you can get stuck in. Are there any kind of ones that you’ve seen in particular that you kind of try to coach people out of or steer people away from when they’re in these early stage product teams that are trying to get that initial traction?

Milun Tesovic: Yeah, I mean when it comes to those free companies, I’m like, I wish I was early enough to see any of that. So I’m like, I’m certainly not that early, but one of the key things when I’m working with any of the teams on product and I’ve explored and do that quite a bit, is really getting a better understanding of how are decisions made and why are those certain decisions made? So is this something that the founder believes should exist and then they’re pushing the will onto others? Or is this something that they truly listen to their customer base and they iterated on until they came up with something that will serve a broad base to help justify targetable market? That would be the biggest thing that I found when it comes to product is just getting a deep understanding and questioning why are we building this? Who requested it? What is the purpose of it? What value does it add to the user? Is it a nice to have or is this a must have? The second one would really be getting an understanding of what’s too much of a minimal product. Seen some teams go out, they push out, I would even say bare minimum to just below bare minimum. And then come back and say, “Okay, the customer didn’t like this.” I was like, “Well, did they not like it in that form or did they not like it in general even going forward?” And then I’ve seen founders give up or abandon, be it the entire company or a specific product branch simply because they’ve done too little in order to help truly get them to the answer of, is this something that’s going to flourish into something that would be valuable?

Allen Pike: I find that so hard as a founder that cares a lot about design and user experience. And I get attracted to markets and people and problems where a really great user experience could be 10 times better than what people have cobbled together today. Because I can come up with a theory which is like, oh, if we had a really great workflow and user experience, it was super smooth and it was really low friction for people to do X, it seems like there would be a real market there, but it’s easy to say that. Then it’s like, “Okay, well let’s go and actually build that and sand off the corners and make a really nice MVP.” And the minimal part of MVP starts to become really challenging when you’re trying to test a really delightful experience. And so that’s one of the things that I struggle with the balance in between that. I’ve certainly made errors in both directions of over-polishing and then it turns out my theory was wrong. They don’t want this, even if it is really polished. And under-polishing and presenting something that it’s like, “Okay, I should be strict and not over-polish the thing,” but then I demo crap and then people are like, “I don’t want to use crap.” And then I’m like, “Well, I guess they don’t want it.” It’s like, “Have I learned anything? I don’t know.” So I don’t know if you have any lenses or tactics that you use to split that difference or if it’s just fundamentally hard.

Milun Tesovic: Yeah, I think it is fundamentally hard. I think it just depends on product to product. You can’t really push Linux modules that are too early, not trusted without proper testing, those kind of things. At Cmd, we didn’t really have the luxury of being like, “Oh, here’s an alpha version.” It’s like, yeah, because the alpha version is just going to crash a server and spike your CPU load or time.

Allen Pike: And they’ll never talk to you again.

Milun Tesovic: Yeah, exactly. So it’s in that case, those kind betas and demos, if we’re doing it in day or even dev environment, which look incredibly poor on us, that’s an example of a product that almost should be over-polished. So when you demo it goes flawlessly and you don’t end up in messy situations. On the other hand, you have all these consumer products where your target market is a billion people. Yeah, go launch it. Go launch your under-polished product. Maybe like a thousand people will say they don’t like it, they’re going to forget about you five seconds later. They don’t have a CRM of towards what they tried and tested and an email history of it. Yeah, it’s like it could fail on that one and then I might go back, work on it some more, release it again, get another 10,000 people. Even if half a million people don’t like it, you can still iterate on it and they’ll give you another chance. So it just highly depends on the category, on the product, on who your target market is, how forgiving it is, how large it is. So this is a very difficult question, difficult thing to execute on, but everybody just needs to be aware of both scenarios and then just have a good discussion with their team in terms of what feels right.

Allen Pike: Yeah, that makes a lot of sense. One of the things that I’ve over time gotten better and better about, and I think it pays off, in this type of problem specifically, which is you’re trying to test something that has part of your product theory is that a really good user experience is going to be competitive advantage is to just be even more disciplined and just extreme with simplicity. If you can have this Linux kernel module or to-do app or whatever your thing is going to be, hopefully not a to-do app, but whatever the thing is that you’re building that you think doing it really well is necessary to validate whether people want it, to be like, can we have a quarter of as many features in the first version? Sometimes it’s just featurefulness is what you’re competing on, in which case it is what it is, but if it can be sort of radically simple and that’s enough for a subset of people, that can be sometimes a nicer way to let you get further and polish without end up sort of multiplying out functionality times polish and toiling in the desert for three years before you figure out that you’re building the wrong thing.

Milun Tesovic: Yeah, yeah. I mean this is a lesson that I learned almost on a weekly basis as I work with different product teams where it’s like we try to get creative in terms of like, okay, it’s like where should the add new button go? And it’s like we think through a couple of different iterations, we push it into one. It’s like we over-thought it, we over-engineered it, and then you launch it and the users, you start getting support tickets being like, “Hey, I can’t find the ad new thing.” And you’re like, well, we put it in the place that it will make more sense. I was like, so if you really. And you’re like, “No. It’s like user doesn’t want that.” And then it’s like we place it on the simplest possible spot and all of us sudden it’s like all of those support tickets that go away. So when it comes to a lot of these user features, I mean just launch it, put it in a very simple spot, you can later on move it, keep the interface simple. It’s like I was so obsessed even at Cmd in terms of like, “Okay, let’s make the table orderable, filter. And I’m like, it all needs to be functional like Excel,” because everybody knows Excel. So I’m like, “We spent probably too much time that we should have just making this table look and feel amazing.” And I’m like, turns out all our customers want, and I’m like, don’t crash my stuff and tell me what happens when something goes wrong. They didn’t care about the fact that you can order this table in a beautiful wave with great flow of animation. Then you can click this and it’ll cascade the entire thing down. They just like very, very basic stuff. I’m like, we could have shaved a good amount of time. That’s why being, put up the table, it’s fine. They’re not going to notice it. And later on, add the feature. And one of the things that my customers absolutely love is give them frequent updates. Keep them posted. So same way they make you send investor monthly updates, do the customer monthly updates, just saying, “Hey, in the past month, look at all these amazing things that we’ve done.” And they’ll see the velocity of your development, of your work. They’ll be more impressed. Make sure you have good bug tracking happening on the site and capture before they send you a support ticket, so you see a bug occur on the website for them. Even if they don’t report it, reach out to them and say like, “Hey, it’s like I noticed you encountered an issue. By the way, it’s like we fixed it. If you try it again, it’s not going to happen.” You’re going to build so much loyalty and value in that customer’s eyes then if it simply just works okay the first time. Yeah. So it’s like, I don’t know, it’s just treat it as a very simple human experience and I think a lot of partners would get rewarded by that.

Allen Pike: Yeah. I’ve increasingly been more and more of the mindset to try and do the opposite of what we did at Apple, which is disappear for a year and then, okay, here’s all the stuff. Yeah. Just like, yeah, I understand Apple gets away with that and there’s obviously very structural different reasons why that is okay for them, but if you’re an early stage product, the more frequent you can be in conversation with the people using your stuff, every opportunity to interact with them is valuable. So yeah, obviously there’s a point where people get annoyed and they’ll unsubscribe from your daily emails, but erring on the side of being transparent about that I think is a superpower that startups can get away with. Another aspect of this just kind of building a mindset of trade-offs about early stage product building, team building and getting to this product market fit, which is the holy grail of almost every startup that starts and many startups don’t achieve. Thinking about when to stay lean and further gather evidence about that you’re on the right track versus, doubling down on the path? So a couple of topics on that that have come up often when I’m talking to other founders or people in doing early stage product work, even in larger orgs. How do you think about team and hiring early stage on? Like you mentioned some of these businesses that you founded or were on were quite lean for a fair while, but then also sometimes you were hiring up. How do you think about both when and how to think about those, bringing on the first handful of people once you get beyond, okay, the founding two to three people are making this initial research and clarity as to what you’re doing and whether or not it’s going to work?

Milun Tesovic: Yeah, I mean from my point of view, there’s no more important task than the team that you build at a company. And certainly early on. No company out there was simply built with a couple of founders who were just kind of coding the whole thing. Inevitably and eventually you have to hire people and who you hire is going to define the current company that you’re going to have. If you hire somebody toxic, you’re going to have a toxic culture, you’re going to have a really difficult time of getting more talented individuals in there. You’re going to have a tough time getting the team to bond. You’re going to have a tough time getting them to communicate, to work well together. If you are hiring somebody who’s inexperienced, it’s going to be reflected within the product. For some startups, they might not have too many options within that and they might be stuck with its like, “Well, this is all we can afford,” which it’ll be such a more uphill battle, but for me, getting those first few individuals into a startup is so incredibly important that I would say that the vast majority of the success that I’ve had at every single company, including MetroLyrics, which is way more than a decade, over a decade has been because I was fortunate enough to have the right few people around me right from day one.

Allen Pike: Interesting. Definitely I agree with all of that, and that’s the primacy of that early hiring is a huge common theme in both successful and unsuccessful startups I hear. The thing that I thought was kind of most, I don’t want to say surprising, but some people can disagree on a little bit on what you just said there is, or I’m curious to click in a little further, is how you think about experience. Sometimes the founders or, I say founders, but this in general world I think is applicable when you’re building any zero-to-one product team that think that, okay, well we don’t have much budget, so we need to hire somebody who’s inexperienced and you just make a trade-off or you end up with low-cost outsourcing or something like that. And obviously that is a compromise. But I’ve had reasonable people argue and that having somebody who is very experienced as your first startup hire that they have come from an org that has really done it and really scaled it, but then maybe have a mindset about how things should be done that may or may not exactly map onto to the problem space that you’re in now, can in some ways be a trade-off that has downsides. Whereas getting someone who is really, really great culture fit, obviously not someone toxic, someone incredibly smart, really motivated, really curious, really cares about the problem, super excited, energizes everyone, learns really fast, but doesn’t have 15 years experience of scaling SaaS applications, can actually be a really good hire number of one, two or three. Do you agree with that or do you lean a little bit more on the try to get real experienced people who have done this before as your first couple people into the team?

Milun Tesovic: Yeah, wholeheartedly agree with that, with everything that you just said. What I mean by experienced individuals is not certainly somebody who spent 10 years at Google and you managed to get them away from the position and join them in. I can’t tell you how many experiences I’ve had where it didn’t work out by getting people who are too experienced, too used to big teams, too used to delegation, too used to somebody else doing the work and then them just looking it over. What I mean by experience is think of it as a seed within, I’m like of a plant that you want to grow. So it was like if you want to bring somebody in who’s enthusiastic and hardworking and I then you can kind of branch out from there. What is that it is that you want to achieve and grow at the end of the day? So for me, what I mean by experience is, if you’re a tech heavy company like Cmd, you really need somebody experienced in there if you’re going to be doing a kernel module. So you’re going to be doing things that interface with the analytics system. I can’t hire an enthusiastic, amazing person, my best friend junior dev to go write enterprise cyber security agents to be deployed in the most sensitive servers on the most valued companies on earth.

Allen Pike: In their kernel.

Milun Tesovic: Yeah. It like I need somebody… And this is a really difficult thing to find, but I’m like, again, I can’t go say enough good things about the Vancouver ecosystem and how underrated it is, is people who are both great team players, who have that passion, charisma of both helping level up the rest of the team, but you need them at the helm. You need them. Well here I’m just going to talk about Cmd very specifically. You need them to be able to help direct and figure it out if you are within that category. If you’re building something that’s like plus tech reliant where I’m just like, “Yeah, a couple of bucks here and there,” of course it was optimize for culture and that’s always one of the highest things on the list anyway. But yeah, when I say experience, I certainly don’t mean like lifers at massive enterprise companies with a lot of experience. I think there’s a lot of experience. People who have been former founders, they’ve learned a lot of lessons. They know how to do it again. If you can bring them on board in most of the capacities, they’ll share that with you with the team, it’ll be reflected within it. It’ll help you achieve those goals a little bit faster. And I’m not saying also not to give an opportunity to the less experienced individuals, but again, I’m like, there’s not one solution that fits. Instead, it really is a case by case basis. So I can make the argument either way depending on the product and the company you put in front of me.

Allen Pike: But it sounds though like there’s a thread there or a lens, which is that, if you are building something where there’s a big technical risk like executing technically this really challenging thing is the biggest risk to whether or not you’re going to succeed or not, that having people who have already learned their hard lessons at failing or succeeding at technically achieving something that has a comparable challenge, is going to be worth trading off other things for. Whereas if you’re building something that has more product risk and certainty, I’ve talking to some of the folks building early in Shopify, famously, Shopify really built a culture of hiring people who had a growth mindset and that really just were curious and had a lot of potential, but may not have done really any of the things that they were going to be doing necessarily in the role. But that they would be resilient to moving really fast, maybe requirements are changing rapidly. Maybe the thing that you were going to be working on today in four months, that department doesn’t even exist anymore because we’ve totally changed the way that the whole everything is changing, but you are resilient and excited by that and you’re learning and growing into it. Not that they weren’t doing difficult things at Shopify do to the scale that they were hitting, but often Shopify was executing based on product exploration rather than on writing a kernel module that reliably doesn’t crash or something like that.

Milun Tesovic: Yeah, absolutely. I mean, it’s like, look, both can be true.

Allen Pike: Another early kind of trade-off thing that comes up is spending on marketing and domain names. A couple of the startups that you’ve been involved in have had some really cool domain names early on, which a certain part of my marketing brain is a little jealous of that, of like, oh, yeah, we could spend and get a cool.com. But then it’s like that’s one of those things I find interesting because I hear very reasonable founders disagree on the value of that specifically, as well as, just the broader thing of really leanly proving out the product and add the exact marketing and exact name of the company and the domain or whatever. Figure that out once you have traction in it or a product market fit versus, other reasonable founders will say, “Hey, you’re going to be putting all this effort into marketing something and building a reputation,” which is in some ways all you have early on. As well as hiring companies, improving people that you, you’re legitimate if you’re going to bring on really great talent and that relatively investing on that can be a high ROI thing. How do you think about that trade off?

Milun Tesovic: Yeah, look, I mean, the only domain that I purchased, and it only cost me I think four bucks for any of the companies in our thought was MetroLyrics.com. Cmd and Gitalytics were fortunate enough to be releasing out until certain milestones are hit. At which point in time we would convert it at cost. I would probably fall in the camp of don’t spend too much money, and that’s going to vary start up to start up in terms of it costs too much money. If you raise 5 million, it’s going to mean something very different to you than if you raise half a million. But what you can do is get creative. There’s a lot of amazing domain names out there that are very underutilized, and a lot of those domain holders, well, some of them, they’re passionate about. It’s like they want to see, do something cool. They want to see somebody use it in a meaningful way, and they understand that it might not fit a large company at the moment where they could just flip and sell it, so they’ll be in it with you for a journey, the same way that an investor might be.

Allen Pike: Okay. Can you tell me just a little, because I’d never heard of this idea, maybe I should have known it and I hadn’t heard of this. Basically, someone’s owns, let’s say, it’s cmd.com or we can make up a fake thing, so you’re not giving NDA details if you’re not allowed to copy the details of that. But it’s like somebody owns valuable domain.com, you’re a startup or you’re a new product at a company that’s small enough that you can get away with a deal like this. Obviously, if you’re at Apple, you can’t be like, “Oh, let’s lease the domain and see if we end up wanting it.” They’re just going to know. But for a lean team, you can propose to some domain holders, “Hey, so we would lease this from you. We’ll pay you, I don’t know, a thousand dollars a month,” or something like that, “and then we have an option to buy it at this price in two years.” Is it like that kind of deal shape?

Milun Tesovic: Yeah. I mean, look, you could be as creative as you want in these kind of deals. I’ve seen deals where I can pay monthly. I’ve seen deals where it’s like, “Look, here’s a one-time payment of what we can afford now,” and then we have the optionality to buy this at series A, whenever you think the company might be ready for it. I’ve seen pure equity deals where it’s like, look, it’s like this is where we are. At C, that can get very expensive, but I’ve also seen equity deals be converted at series A, so the domain names work. I’m just going to make up numbers, a hundred thousand. And just be like, “Okay, look, we’ll give you a 25% bump if we make it to a series A and that’ll be converted into equity along with the rest of the investors.” And what a lot of these deals have is the crawl back. So it’s like if the company doesn’t make it, they get their domain name back. Worst case scenario, they get a bunch of back links. It’s some bit more authority within the domain. And as somebody who’s subscribed and analyzed the Crunchbase database a million times over, I can tell you there are so many companies reusing domain names all the time, and it’s okay. A domain name that was previously used is just as good. There is so many companies out there, nobody’s going to remember it. Nobody’s going to be like, “Oh, wait.” Unless it’s one of the really big ones that failed, that it’s like, “Oh, wasn’t this company before?” I’m like, “No.” Google does a fantastic job of keeping it recent to the front, all of it. So you could be creative with it, but I would certainly follow the cap of use your capital for what matters, and usually, the risk for startups in the early days is not the domain. It’s more of the product and the team and a lot of the other variables that go into creating a startup.

Allen Pike: Awesome. Well, I’m glad I asked that. We have time for one last question. I had asked a couple folks for questions and Steven Liu had helpfully encouraged me to ask you about hard one lessons, which I did multiple times as we went through, so I’m glad that that came up and I think we got some good ones. Dennis Pilarinos, our mutual friend, encouraged me to ask you, what can kitchen gadgets teach us about product design?

Milun Tesovic: Okay. All right. So the reason why Dennis is saying that is I’m famously known for buying every kitchen gadget under the sun. I don’t even cook that often, but for whatever reason, it was like, if I do cook, I am obsessed with having the right tool at the right place at the right time to help it make more efficient or to help make the end outcome what I would want it to be. I think that tell me, because one of the things that kind of comes to mind and how my personality would translate between kitchen gadgets and start ups is I love to try new tools and I love to see them like, okay, what hooks me? What gets me to that better product, that better recipe, that better end outcome. Whether or not it’s like being an early adopter of Figma or an early adopter of a framework that looks like it has a lot of potential or it’s going to be up and coming, or really pushing the boundaries of, it’s like, how are passwordless login is back in the day? Those kind of things. It’s something that would certainly strike true because if something is out there and I’m like, “Oh, but that can make me better, faster.” That curiosity growth mindset that you were talking about earlier, I think that’s what resonates more than anything. I think that’s something that I probably share when it comes to kitchen gadgets and startups which are unique overlap.

Allen Pike: Yeah, no, I like that. And I think there’s something inherently interesting and good for a lot of founders and investors and folks that are involved in startups are busy people, and so we maybe don’t necessarily make time to try things. Maybe be like, okay, well I’ve got all my stuff correctly, or like you and I share, I think an interest in productivity tools and maybe trying different to-do systems and stuff. It’s like, yeah, maybe I’d be more efficient if I was like Dennis and I only just used a flat to-do list that scrolled forever, but I want to find a tool that makes things better and try something. And the worst case scenario, you’ll learn something about this product and how they thought about things, even if it doesn’t end up clicking for you.

Milun Tesovic: Yeah. Yeah, absolutely. I mean, I think you got spot on.

Allen Pike: Awesome. Well, thank you so much for your time, Milun. It’s been awesome chatting about this stuff. Where can people go to learn more about you and your work?

Milun Tesovic: So Expa.com, we’re a startup studio. We work with founders all the time at all the different stages to help them launch companies. Right now on Expa we have dozens of amazing dictionary word domains that we do unique deals with all the time. So if there’s any founders out there that want to build with us and we take a very, very hands-on approach on design, product, hiring, legal structures, financing, branding, domain, we cover all bases. They could go Expa.com or they can reach out to me mt@expa.com or milun@expa.com, same inbox. Yeah, I’d love to hear from any of your audience members that want to learn more.

Allen Pike: Awesome. Well, so we’ll put a link to that in the show notes. Thanks for being on the show. It Shipped That Way is brought to you by Steamclock software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. And that’s it for today. You can give us feedback, follow us on social media, rate the show, or tell us who you would like to have on as a future guest, a suggestion for us to bring you as an interview. You can go to itsshipped.fm/contact. Until next time, keep shipping.