#1 Anthology of Startup Anecdotes

Originally called ‘The Startup Boilerplate’, this episode starts as a discussion on startupping. 

There is un unexpected twist, though. 

A limitation. 

Iskren and Iliya must abide by the following rule: when asked a question, they must reply with a story (anecdote). 

This is unexplainably constraining for our beloved hosts, as they are used to entering conversations with steady streams of theory and facts. 

Throughout they visibly struggle to comply with the rule, resulting in listeners calling it: “The two AIs talking episode”. 

In the end, there is a happy ending indeed – the show develops into a beautiful anthology. 

Here’s S01E01 of Life Math. 

***

Get on the email list and never miss an episode. 

Discuss this episode on Reddit.

Connect with us directly on LinkedIn: Iskren Vankov and Iliya Valchanov.

3veta
3veta.com is our startup. One platform to unify your client bookings, video calls, payments & more!

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Iliya: 0:00

Hello. Hello.

Iskren: 0:01

Hello. Hello. As we have established this is how I start all the episodes.

Iliya: 0:10

Now you have the chance to do this twice, because right now this is future us, going back to fix a mistake. In about one or two minutes from now, you're going to hear the name of this podcast as The boilerplate startup. This is not the real name and we're going to discuss naming conventions later on. So this was a very good example of why you should consider abstract names. The new name of our podcast is Iso, what is it again?

Iskren: 0:40

It is Anthology of Startup Anecdotes.

Iliya: 0:46

This is the Anthology of Startup Anecdotes episode. Welcome, and please enjoy the intro. Intro music plays Life Math. A podcast indescribably tangled; unnecessarily complex; so bad, that its good. Life Math. Hello, hello!

Iskren: 1:13

Ah, you surprise me if I old greeting this time? Hello, hello.

Iliya: 1:17

Oh, we were joking about it because Iskren always starts with hello, hello. And then we just made this intro but we had to cut it, so I just stole

Iskren: 1:26

Stealing my hello, hello thunder.

Iliya: 1:27

This episode, like any other will be a bit different. In fact, I have a rule for this podcast that I wanted to share. Whenever we bring up a topic, each one of us can tell one story about it. And this is the only way in which you can talk about it. What do you think about that?

Iskren: 1:45

Enforced anecdotability. Sounds good. Sounds good. Let's make it personal!

Iliya: 1:50

Yes. It's called the boiler plate startup. And it's very special for us because we have both worked to startups and we want to share some of our experiences. What are the most important things to think about and what are the must do's at the beginning of setting up your startup? So Iskren, can you please tell us a bit more about your start startup experience so far?

Iskren: 2:15

Okay. My background in startups goes all the way back when I was 17 and joined my first startup as an eager young software developer. And we're developing this, device with all the hardware and software and firmware. And I saw all the layers of development, both engineering wise, and then kind of more salesy and marketing [even though a bit less of that] side. And then. I hopped onto another startup several years later, about four years later. The second startup was about financial tools. It was a tool for diversification of portfolios. It was entirely a software product unlike the first one, which was a physical product. And there again, I got a taste of just how a different project could play out how a software product would be built and later sold. And then finally now in terms of startups, I've been through 3veta.com, which is another startup. This one I've been there since day 1. We've been building it for some time now, and it has brought a lot more insight for me personally - to how to be a startup, what to do, what not to do. So I have this experience now, and we're talking with Iliya that as he'll tell us in a second, he as well has experiences in some startup areas. And we just want to share with other people, our own personal view of the topic, just startups, you know, what to do, what not to do, stuff like that. We don't want to do it as a sort of course, book or something, or lecture notes in any way. We just want to share more personal stories of just what we have observed and thoughts about the process. Probably it's going to be quite anecdotal. Stories about something interesting, something of value that we have realized with time, and just want to share with you guys. So without further ado, after I have introduced briefly, kind of my, I suppose, three separate startup instances of which, by the way: one, a success; one, a failure; one currently undergoing. I'll pass it back to you. So, how about you? What is your startup background?

Iliya: 4:30

So I started a couple of years ago. I joined my first startup.

Iskren: 4:36

As people are saying - I moved to the Bay area.

Iliya: 4:41

No, not at all. So I moved home and I joined a couple of friends who are creating online courses in the beginning. I was creating online courses as well. We were three or four people in the beginning, and then this operation blew up to be our own platform with our own website, our own marketing team, our own course creation, let's say, division - it was basically an operation of 10 people that were creating courses. An operation of 10, 15 people working on the marketing of the platform. Some of these overlapping, including myself. I was there for three and a half years, almost four years, I believe. And I've learned a lot along the way. And I've been very much involved into making the organization scalable in terms of human resources, meaning that new people can come in the organization and they can start working on the already existing projects while maintaining the quality. Right. So you can think about me as the boring person who is putting all these standard operating procedures in place and telling people: No, you should, you should definitely do it our way, because this fits into the overall framework that we've created. But yeah, overall, it was a success like. 365 data science is the name of the company. By the way, we were successful. And. Everything was all right. So my track record is better than Iskrens. So far.

Iskren: 6:10

I have the quality. No, l have the quantity. You have the quality.

Iliya: 6:14

Indeed. And now we're working together on 3veta. Now, after this short commercial break, we can get into the actual podcast. How about that? Okay. So the first thing I want to talk about is communication. And not only communication, but communication in a newly created company. It doesn't need to be a startup. It has to be an operation of more than one person, right? Even if you're a freelancer, you still need an accountant or some people around you. So it's never you alone. So Iso, tell me one thing about communication that you want to share with a story.

Iskren: 6:57

Storytime! Okay. Communication. I think what I would like to share on that topic startup related is something I've recently been thinking about. Kind of realized that to a much larger extent in 3veta actually, and that's how much help it could be to open up communication channels between people that otherwise talk through you. And that's, I guess a bit from the perspective of managing people and because we're talking in stories and anecdotes, I'll give the precise setting, which I was thinking about this. In 3veta, I am leading a team of developers and separately, we have the design division where they make the design for the product separately. We have the marketing people who do all the digital marketing, SEO things. And so initially the way I had set it up is sort of world developers just kind of chat through me. Through me, they talk to the other divisions like design and marketing, and vice versa. They talk to developers through me and it sounded like a good setup because this way I know everything that's happening and I can't miss something. And that's kind of my job, right. To know everything that's happening tech wise with the product. But then as we kind of grew in the number of developers and in just the number of things that we're doing in separate avenues, I realize that that's exceptionally not scalable, because I was overwhelmed with having to be in the middle of various people's communications. And so then I very carefully tried to open up individual one-to-one communication pathways between various people. So say between a front-end developer and the design team. You know, as a practical step, this means explicitly creating, say a shared channel between the design people and the frontend developers on Slack. Add them there, communicate with them that: yes, you should use this actively instead of just waiting to communicate through me the same way between some other developers, SEO, marketing people, for example. And so this way you just allow people to talk directly to each other. Don't just allow, but kind of encourage people to talk directly to each other instead of through you. And it just saves a great deal of time. And it sounds a bit trivial, maybe that all people would just talk to each other. But the point is that they don't, you know, like it's very

Iliya: 9:23

May I help you on this point? Currently I'm in the process of creating this Alumni organization and we're having this issue that there is this group, where is everybody. But nobody can speak to each other rather than in the group. So nobody's speaking at all. There are no channels of communication. Like I have to add these posts on Facebook to be able to chat with them, which I would never do, right? So there is no communication going on except for one-to-one with the creator of the group.

Iskren: 9:55

Yeah. So I guess this is granularity of communication. Or if there's just a general group for everyone, nobody will be using it. It's going to be just like an announcement board. If there only private one-to-one channels, that's something else, but there's no space for general conversation. So you have to really think about the connections between people, what connects them and how you can organize your channels to encourage people to. Talk in a productive way without having to go through those extra hoops of passing through some man in the middle to just pass information left and right. So I guess that's my main communication point of recent realization. What about yours, Iliya?

Iliya: 10:32

Yeah. So to me, it's, it's quite similar, but from another angle, what I think is very important is to have great transparency in whatever you're doing, because this motivates the team much more. They feel a part of the company, even though, a developer would rarely have some, let's say, administrative decisions or design decisions. That's not always true, right. But they feel a part of the whole, if they can see this, this communication. So from my experience so far, what I've always tried to do is to bring some more transparency by creating these groups that are open for everyone. By creating these knowledge hubs, whatever. Whenever somebody finds some interesting information, they should share it. You know, there is this channel#work-reads that I'm trying to nurture, you know in our Slack

Iskren: 11:29

Still not sponsored by Slack, just saying.

Iliya: 11:33

where whenever you learn something new something cool, just share it with the rest. They don't need to read it, but they have it. And at some point they may remember about it and they will know that you know, a lot about it because you'll be interested in the topic. So to me, setting up a structure, which allows this transparency to be able to communicate outside of your day-to-day stuff is most important. And I've been trying to make it true in every organization I've been to. Okay. So we went through the communication part of it. How about the delegation part of it? How do you keep track of all the stuff that you have to do? How do you keep track of the stuff that you can outsource to someone, or you can even get help from your friend, partner, or whoever wants to help you.

Iskren: 12:23

I've been thinking about this precise question and it hasn't been just work-related, it's also life-related in our out of office life. Yeah. So what I've been thinking is how each task that are assigned it points to what extent is it delegate-able, meaning to what extent I can describe the boundaries of the task to some external person and they can do it without knowledge of, you know, 10 other things. So in terms of the software, if I want to get somebody to add a new module to the system, maybe that's a good task to outsource because it doesn't require knowledge of much of the already existing system. It is just a separate thing. They need to know just a bit to attach it to the rest of the system. If I want somebody to do like some core restructuring of some very central piece of the code, it's a poor task to offload because then this person I'm delegating it to they need to really understand the whole system. And so they need to be really well onboarded already. So in one way, I measure how well the task is offload-able. That's kind of a trivial thought. Okay. Makes sense. Now, on the other hand, the other side of it, which I discovered later in having to delegate tasks and is quite helpful to me is thinking about how easily, verifiable the task is. Right? So. If I'm looking at a task and it is very easy to delegate somebody else, I can easily describe what needs to happen, I can just chuck it at them. Then still those types of tasks split into two types. One of them is tasks that are very easy to verify that they have been done correctly. I'll give an example from personal life. If you have say some person come to your house to clean every one or two weeks, it's a task that is easily delegate-able. There's various services that you can just hire somebody. They come over and they clean for an hour or two. You pay them. It's a very easy transaction and you can very easily, verify, whether it's actually clean. You just look at it and you can see if it's clear or not. So it's a perfect to offload. However, there are other tasks that they're easily delegate-able, but very hard to verify whether they're done well. And very often code is this way because you're delegated that to somebody else. You described what needs to happen. They understand it. They're capable of doing it. They do something. And then for you to test it thoroughly, it's going to take you as long as just having done it yourself and for you to test too, just a bit, you can't really verify whether it's actually good software, whether it has any hidden bugs. So I think this, this middle ground is what I have discovered more and more recently that exists, you know, some tasks that are easy to delegate, but very hard to verify. And they are like a danger ground.

Iliya: 15:15

This is one hell of a story!

Iskren: 15:21

It was exceptionally, non-anecdotal, but, um, yah.

Iliya: 15:25

So next time you'll have you have your chance to actually get the format right.

Iskren: 15:32

That's true.

Iliya: 15:33

Breaking my format very easily verifiable!

Iskren: 15:36

Yeah, because you've delegated to me, you know, to ask me the thing. Let's see your, your play, your meta-playing into it. But anyway, there's just what I want to say on the topic of delegation. Story or not, you should be very weary of tasks that are easily delegatable, but very hard to verify.

Iliya: 15:52

It's very interesting because you're speaking from the perspective of someone who actually has a team and has to delegate stuff. Now, me being the CMO, I guess, head of marketing, I don't have a team. I'm just like trying to steal from other places other co-founders so they can help me out. However, I mean, I have this Kanban system. So there's, you know, you have Kanban, you have Scrum, we're not going to talk about this, but Trello is a great tool. It's very well done for Kanban style of work, which is: you have a long backlog of tasks. And then you just, take them one by one and you start doing them. So this is what I've employed in the past. And especially now, whenever I think of a task that needs to be done, I place in the backlog. So currently I have a backlog of more than 100 tasks. So I'm preparing for the time when another person entered the organization. Right. So I can take tasks from this backlog and I can give them to this person. And actually, whenever somebody has capacity, I actually go through my backlog and I'm like, okay, this is delegatable this person, this is delegatable to that person. And I'm trying to make the most out of it in this way. Now, this is especially useful when you're working with people that are with you full time and you don't have anything to give them. This is the worst thing, right? This is the worst thing you can do as a manager to have an employee and not have any work for them. There are two reasons for this. First of all, the company is losing money for every second that the person is not working. Right. And it's okay to take breaks, right? But it's not okay to not have a task at all. This is not a good thing. And the second thing is from the perspective of the worker, when there is no work for them, they're demotivated. They stop believing in the company. They stop believing the idea. They are like - Nobody's given me work, nothing is going on. So from their perspective, the company is not doing anything because they don't have work.

Iskren: 18:08

Right. That was a great story, bro. Very personal.

Iliya: 18:16

You want me to give you a story? Okay. So our Head of Design, my wife, from time to time, she doesn't have stuff to do because the dev team is lagging a bit behind the design team for one reason or another. And at one point the design team had created one month worth of design stuff for the dev team. So there was no point for the design team to continue creating designs mainly because, the product is very likely to change in one month. So no need to create designs. Now, she comes to me and she's like, okay. So what do we do with the design team with two people that basically shouldn't do anything more because it's going to hurt the product if we do it from like today. Good thing. I had a thousand tasks. So I actually took the design team inside the marketing team. So basically our design team is working on the product with the devs, but whenever the devs can't handle them, I take them in the marketing team. So have a big backlog and whenever somebody comes to you and wants to help you - have something to give them, like I did in this story to Masha.

Iskren: 19:31

Okay. So since we're doing stories, I realized that I can give a very particular story for, what I meant for delegatable, but non-verifiable tasks. So I said a delegatable and verifiable, is say, see assessing whether a new cleaner, at the office, or the home is good, the job pointer, do you want to rehire them one at a time? And then a task that we've recently run into, well actually, we're running into it now is delegatable and very hard to verify, which is translating your product into a foreign language. Because, say right now with 3veta, we're translating into German, everything, and we have hired a person and yeah, we believe in this person, we trust them. But the issue is that I don't speak German, you dont speak German and he's going to give us some German translations. We have no idea if they're correct or not. So it's kind of, trust-based actually.

Iliya: 20:26

We do!

Iskren: 20:26

How?

Iliya: 20:28

Our co-founder Katya, she used to study in Germany.

Iskren: 20:30

But then my point is that she has to go through each and every single, you know, sentence phrase, etc., to make sure that it's actually translated all this stuff. Like it's very hard to verify. And this precisely the type of task, I mean

Iliya: 20:44

Trust issues. Have to trust the people you work with. You can't check everything they do.

Iskren: 20:49

Absolutely. That, you cant check everything, but I need to have like a general way to verify overall stuff. And with translations is very hard, like, cause there's no cohesion between like each row of the translation is its own separate, independent thing. So it's quite hard to verify translations. Anyway enough about this topic. I want to talk about something else. I want to talk about a much lighter kind of even funnier, but I think actually quite, quite important topic we've discussed briefly before, it's: Naming. The importance of naming things. And I'll jump in directly with that, with a story. And the story is that in the company I used to work at before, it's a trading company and I joined the software team. This tech stack that they were using- it had been growing for many years. For more than 10 years. There was a lot of the software that already existed, many years worth of effort for many different people. And there were many, many different Microsystems. The part of this one grand system consisting of, I dont remember now be like, say, 70 subsystems. And each one of them has its own separate name because you have to refer to it in some way. And the approach that they had taken and others do this obviously, is that, they had named everything on purpose with non semantic names that were Marine themed, meaning that instead of calling some module exactly what it does and try to be super semantic, descriptive. No. You just take this piece of software and you call it dolphin or you call it vortex, just some random words. And in that case, in that team, they had chosen everything to be Marine themed, but that was kind of arbitrary. They were just nice names. So there are many nice animals in the sea. This way you ensure that as the product evolves and as things change well, the names don't become wrong. And in this whole thick stack where everything was called, like orca and dolphin, anchor, stuff like this. There was this one service that had been left with its original name for like baaack, way back in the day, I dont even know exactly when. It was kind of just to show with a negative example, why you shouldn't name things for what they supposedly do. And it was called Greeks receiver. But the point is that by now it had evolved so much that it wasn't receiving things - it was sending things. And it wasn't Greeks it was sending. Initially it was a Greeks receiver. It was named this, the name stuck, and then it evolved, evolved through the years. It was not a Greeks receiver anymore, but it was still called this. And this example just really stuck with me that basically once you name something, it's exceptionally hard to change its name, and it's much harder to change its name that to, through natural course of things, change what it actually does. So my suggestion is always name things just with some unrelated names like Android versions, you know, KitKat, Lollipop. They do the same at Google with Android versions, always X versions for Mac, you know, Sierra Leone, Big Sur. There's the exact same concept. Yeah. I would definitely recommend it for all sorts of things. What do you, do you think about that?

Iliya: 24:29

I completely agree with you and we've discussed it many times. What I've been getting from some people though, is that they don't really understand it. And I think this example with Android and Apple is especially good because Amazon, Apple, Google, these are names that are completely irrelevant to the product that they're developing and thats the way it should be. I think that's why we called our product through 3veta, because it means nothing, right? On the other side, you have companies like Facebook, which is still a very famous brand. Right. But it literally means face-book because it used to be this book of faces of people, of university students. So I have nothing to add now.

Iskren: 25:16

But we want to story. Story! Story!

Iliya: 25:19

You want a story? Yeah. Okay. I'll give you a story. I have so many frameworks that I want to talk about and no stories, but

Iskren: 25:33

You know naming in general. It doesn't have to be about this side of naming. Just names. So the power of words, power of names, the power of labeling something. It could even be labeling.

Iliya: 25:43

Okay. Okay. Let's talk about folders. Let's talk about folders. While I was creating online courses. In the beginning, we were several people. Each one of us was creating their own courses and we were organizing them in various ways. You know, you have text files, files, audio files, video files, project files. And one course is something like 2000 files, 5000 files. There are so many files to name, so many files to organize so many files to order. Right. Problem was. Each one of us had their own organization. And now when you have five courses, it's all right. But when you have 50 or 100 courses, it becomes a problem and nobody can find anything. Nobody except for the author can find anything at all because each one of us had a completely different organization. In the end, we took these common standards, common organizational standards. Didn't work out, by the way. Everyone was taking these shortcuts and everyone was like, Oh, nobody's going to notice if I don't name this file. So when we were moving to our own platform, our own solution, and we're building it with this outside company, this is for the 365 Data Science platform. I had this rule, this ask from them that all the courses should be uploaded on a cloud. And then the system should be automatically taking the files. Right? Which meant that each file should, should be named in a particular way and organized in a particular way so that the computer program can, can read it and order it inside of the system. So at the end, I managed to enforce this naming, which was one with the whole system and every course creator who didn't name it properly would place their course in the system., and then there will be errors like multiple errors. And they'll be like - Oh, you didnt name this right, you didnt name that right. But at the end of the day, this was completely foolproof to name everything correctly, be able to find everything correctly, be able to store everything correctly in a way which lasts through time. Right.

Iskren: 28:04

Enforced naming patterns, good stuff.

Iliya: 28:08

Yeah, like this and a tiny story, just a tip when you have a folder of stuff and you want the stuff ordered in the folder, you can use numbers. It could be 1., 2., 3., like this is a prefix, which doesn't mean that they're ordered in some semantic way, but basically the way you want them to appear in the folder. And if you want something in the very beginning, you can place underscore _ before it, and in this way, it's going to be always on top.

Iskren: 28:35

Folder organization!

Iliya: 28:39

This is a commercial break. If I have to create a commercial on this specific episode, if you have to be a story, what better story than when Iskren and I decided to work together on our mutual project 3veta? Well, Iskren was working and trading in London, I was at home with my wife and co-founder Marsha. She's also our head of design. Iskren and I were just about to play some Dota. We had a friend of ours, but I asked him to get on a quick call before the Dota. We were waiting for other players for something. Little did Iskren know we had a pitch prepared for him. It was about 40 slides long. Let me tell you, Marsha creates amazing slides. So we had these 40 amazing slides ready for Iskren. And now I'm going to try to summarize them as a story or something as I cannot show them to you. It went something like this. Hey, so what do you think about this idea: A very simple tool which allows professionals to host a video meeting and get paid? Such a simple idea yet nobody has made it simple enough and good enough. So I guess he ask something like. What was the spin of this idea? Glad you asked. I have a slide on it to not be a marketplace. 21st century people care about their identity, their personal brand. Moreover it's full of marketplaces. Take Amazon for once, marketplaces become big through providers. And then these providers are increasing the profits of the company. However, once the marketplace is big enough and stronger than any individual provider, they start increasing their commissions. They start, essentially robbing the providers who made them great in the first place. This is not what we want to do. We want to be a partner that these professionals can trust forever, and you know, the best part is we can totally make this completely for free and get paid only when providers get paid. So in this way, there will be no risk for them to start with us. So, for the purposes of this story Iskren asked something like - who are the clients then? And well, glad you asked. They have like a bunch of slides on it. So, sole proprietors, small businesses, below 10 people. We want to empower small businesses because they're the creators. They are the facilitators. They're the people who care about each and every customer they have. So what do you think happened? Well, we did play some Dota that night. It was not only the pitching. The next day though, Iskren wrote to me, Hey man, let's have a call or no, no, no. You should just send me a link. I click the link and I realize it's an open source video solution that it already spun up to try and scope the whole amount of the tech work. In that very moment, I knew it. He was totally in. We hadnt discussed ownership. We hadn't discussed financing. We hadn't discussed who else is going to be on the team. What we knew was that we want to work on this project together. We knew that the idea is very good and we wanted to enable all the enablers around the world the people who care about their customers. This was the online services revolution, and we wanted to be a part of it. Now, one year later, 3veta outcome is going strong. Our product is ready. We have a big team and we have the same drive to enable all small businesses and sole proprietors and freelancers to be onlinein the cheapest and fastest way possible. So if you ask me, make a commercial about 3veta.com in this episode, these are my two cents.

Iskren: 32:53

Okay. Okay. So since we're talking startup stuff, and since we want to talk about more interesting parts of it, there's this concept that we've discussed before. It's quite famous. There are various books on the topic about failing fast and trying many ideas as fast as possible, dedicating as little resource to each one as possible just to get results as quickly as possible. So, what story can you tell us about failing fast as a concept?

Iliya: 33:26

Oh man, I have so many stories about failing fast and many about failing slow.

Iskren: 33:35

Failing slow is bad, right?

Iliya: 33:36

Failing slow is very bad. So my favorite story, I don't know what my favorite means here, but because of story about failing, so it shouldn't be my favorite, but it went like this. We were trying to build this YouTube channel and we had 150,000 subscribers and things were going well. But at some point they came to a halt, right? They stopped increasing. My understanding of this is that YouTube works in the following way. If you are very consistent, you always post videos, these videos abide by the rules, and everything YouTube is going to bring you traffic because they want to keep you motivated. They want to keep you creating videos and they want to nurture you as a creator. So what happens in many cases is that a channel reaches, say 10,000 subscribers in one way or another. And then they see this enormous spike to let's say, 50,000, 60,000, a hundred thousand subscribers in a relatively short amount of time. I've seen many channels have this growth and then you have this financial trajectory and you're like, Oh, I have completely won the algorithm. And at some point it stalls and then there's another big spike after some time, but it's never this big, right? I think this is something YouTube are doing on purpose. So I wanted to test this out. What we did was we decided to create a series of very high quality videos. So we created a series of 10 videos in which we picked the best keywords, the best videos, the best course content creators. There were two content creators who were working on it, two designers were working, we were doing everything by the book. It was not kind of prototype. No, no, no. We were like, we have a YouTube channel. It's very good. We have the reach. We have everything. Let's make this effort for one month and see if we can break through this wall of YouTube or not. And we created some of the highest quality videos that I've seen online on these topics. For instance - how to transition from economics to data science. And this video turned out to be extremely profitable because 10% of people that would click a link there would buy our product, which costs $200, right? So this was extremely good video, extremely high quality content, but our YouTube channel subscribers didn't grow at all. Nothing happened there. So the videos were amazing. The content was amazing. The team that created these things We had more than 1 million paying students at this point. And then YouTube is like, you know what? I don't like these videos. If we sold them as an online course, they would make us much more money than a YouTube. Point of the story being we made this very concentrated sprint. This was not a prototype or whatever you want to talk about in a minute. But it was a sprint with the best quality resources after which I told myself, Okay, YouTube, no more resources for you because you don't deserve them. And, I was thinking if one year later these videos, he picked up and everything was changing, then I would be wrong and we could invest some more in the same way. But, it's been a year and a half and nothing has happened. So, just to do a very good effort not too much. Don't devote a year into it. See if it works, if not, just leave. How about you?

Iskren: 37:22

So I guess the main point of your story was exactly that to gauge whether investing more in YouTube is a good strategy, some minimal viable path for you was, Okay, we're going to make those good courses and see what happens. It's your minimal effort to get data, whether it's worth putting more effort, right. Its the minimal scope. So you scope the minimum thing you can do to really assure whether it's worth it.

Iliya: 37:49

Yeah. It was a scope of 10 videos which were different. By the way, they were completely different. Like top five ways to do whatever, top five finance trends, then it was like, how to transition from these two dots? Then, it was like computer science versus data science. They were all in the field, but all different names or different types, some are lists some are something else. We tried everything and everything was top-notch.

Iskren: 38:13

I mean, I would even say this was a bit on the not super-fast failing side, but it's in the same spirit. I understand what you mean because you always could have dedicated much more. And more importantly, you could have continued to produce into it after this one month. So the good side is that you just stopped.

Iliya: 38:28

Yeah. In the end, the low effort, high impact things won, which were like the video we just repost on YouTube and they worked well.

Iskren: 38:38

Oh yeah, so anyway. My personal story since were still on this topic, is actually quite the similar in terms of its point, even though it settings are very different. As youre speaking, I was just thinking about what story would I give? And I think that the best example about his, I can think of from my experience, is back about a year ago, maybe, with a friend of mine. We decided to just test the waters, try out a drop shipping business model, which what it means is essentially a business model where you think of a product and then you don't go through all of the effort of creating the product. You delegate this entire task, the entire creation of the product to some external company. And then not just that, you also delegate the shipping, dealing with actual queries, etc. to maybe the same, maybe some other company, usually it's a different company. And so the only thing you do is the investment and the sales and marketing. But the creation of the product, the shipping of the product, the handling of the actual product is entirely outsourced. Even the design could be entirely outsourced. You just have the idea, the investment, and the marketing and sales. So I decided to try this with a friend of mine, just to test the waters. And that was the point they won't test. We wanted to either fail or succeed fast, to see if it's viable or not, you know, make actual money or anything right away. So we started researching how this actually works and I was absolutely, thoroughly amazed by the state of the world really, like people who know about this probably find it quite trivial. But, I personally did not know to what extent this process had been streamlined. You just Google, you find many factories across China who can do it for youanything. Any product you can think any product, exceptionally complex as a thing, but probably it's not. So they just offered to do it and they have deals with Amazon directly. You never even have to see your product in person. You just hire a freelance designer on Fiverr. They make the design, you send the designs to the factory in China, they produce the units, they ship them directly to Amazon fulfillment centers across the whole world to include the States, Europe, etc. And then you just list them on Amazon and then Amazon fulfills it by shipping it out, dealing with refunds, returns stuff like this. So this whole infrastructure I was like, Oh, wow, this is amazing. Lets try it out. Probably everybody's doing it. And then we hit this wall that, this whole thing is amazing as a structure or in some ways, I guess if you're a creator of physical goods. But, the issue is that the entry level is quite high. You can't just order a couple of items. You have to order hundreds or thousands to make it worth. Most factories will not talk to you to make 10 of this thing, whatever it is. You have to make hundreds or thousands minimum, which means that your minimum investment goes up and your involvement with this whole thing goes up right away. And we didn't want this. We wanted to just try it out. So instead, what we did is we just found a local producer to produce these objects locally in Canada.

Iliya: 42:16

What were the objects?

Iskren: 42:17

The objects were t-shirts. We just want to see if we can sell branded t-shirts with various messages. So we got the designs off Fiverr. We printed them in Canada with some local company, and yet the price per one t-shirt was quite, quite high compared to if we batch-delivery from China. And we had to deal with deliveries ourselves as well, however, this way we're free to invest a much smaller amount, have a much lower quantity produced, just to test our idea whether it's going to work. There's my story on how we were wide-eyed with the idea of, Oh my God, this is so scalable. It's amazing - the Amazon-China line, but the entry level is just too high to try it out. So we decided to be pious, we decide to be careful, cautious, we vested much less, we tested it out, and then we drew a conclusion. So in the end it was a success. We sold every single one. It was pretty good. And at that stage, if we had wanted to proceed, then it was kind of safe to go to the Chinese factories and order more stuff because we knew it works. But before that, it would be preemptive.

Iliya: 43:33

How much money did you make on this?

Iskren: 43:34

Not much. I mean, what is the point, right? This is part of the story that the whole thing is like an experiment or whether it's viable. So in the end we made like, uh, I don't know, precisely, like when you put, because there's some, a bit less tangible cost, right? But I would say like a hundred dollars, maybe some of this.

Iliya: 43:52

How much did you invest?

Iskren: 43:53

Several hundred, like maybe five600 overall.

Iliya: 43:58

You would say 15 to 20% return on investment.

Iskren: 44:01

No, it shouldn't be like, it sounds wrong. Should be a bit less should be about between 10 and 15%.

Iliya: 44:07

This is very good, man.

Iskren: 44:08

Pre-tax, though, pre-tax.

Iliya: 44:17

Good job.

Iskren: 44:18

In the end actually also we felt much better about ourselves because it was, you know, locally sourced.

Iliya: 44:24

But you're not Canadian.

Iskren: 44:26

Sure. However, by locally sourced what it means was that the audience was sold to was entirely only North America, US and Canada, which means that it was locally sourced compared to where you make it and then where you sell it, I'm out of the picture. I'm not part of it.

Iliya: 44:43

All right. So they should feel good about themselves buying from there.

Iskren: 44:47

Everybody except me should feel good about ourselves. The end of the story is actually that we did this, we realized that it works, it was a good idea, but I just don't really want to be in drop shipping as a field. It doesn't feel very fulfilling so I decided to proceed with

Iliya: 45:08

All right. This was a fun story. I have several other topics that I want to discuss. So I'm just going to go ahead and talk about trade-offs. Trade-offs are very important. Any business should learn that there is a trade-off between how much you get done and the quality of what you get. So quantity and quality. The quantity and quality trade-off is there everywhere. It's especially true for startups and newly starting companies, because you have your whole business in front of you. Think about a company. A company is designed is created to be a perpetual entity. A human lifetime is 78 years, whatever on average. And then you have a company which is designed to live forever, and you start on day one, and then you have trade-offs everywhere. You are to build this company, which will probably, not probably; but it can legally outlive you. So I'm going to start first. In the beginning is a new work in the workforce. I was very pedantic. I wanted to get everything right. I wanted to ...I don't know, dot every i and cross every t for anything I'm doing. Like I'm publishing some PDF which doesn't have a comma somewhere, and somebody points it out to me. I will definitely go back to the word file. I will place the coma, export in PDF, and replace it wherever needed. Now this is extremely time-consuming because you can never be perfect in anything you do. You can try to be perfect, but more often than not, it doesn't pay off. It's great to have more people around you, maybe a proofreader or some tools to take care of these issues and mitigate the risks that are involved with each one of them. But, most of the time the Pareto principle is working. So with 20% of the effort, you're doing 80% of the work; and the rest 80% of the effort is contributing to just 20% of the outcome. But, with time you've learned that there are trade-offs. How about you? What is a story that you would like to share?

Iskren: 47:29

Well, the first I want to say is I just agree fully that it seems to be a matter of not just personal preference, but also experience. When I was starting as a software engineer, definitely I was very much the perfectionist, like it was unthinkable to have any bugs, small or large, and just let it be. No, that's unacceptable everything has to be fixed, etc. Then as you kind of develop and grow and get more acquainted with how things work, you start accepting that everything always has issues and you need to prioritize, as you said. And, any particular trade-off that you discussed was quantity versus quality, right? There's the particular trade-off that they were talking about?

Iliya: 48:17

You can pick another one.

Iskren: 48:19

No, no, I think I still want to talk about quantity versus quality. It's a very good topic because it's very transferable. It applies to anything, everything not just startups, it's anything you do, theres the quantity versus quality.

Iliya: 48:35

It's evergreen. It will always be there.

Iskren: 48:37

Right. It's super universal. And on my side, it's a sort of similar story. It supports the same point, but it comes from the perspective of software again, where we had this whole signup story of the product. There's a signup page, then you sign up and then you receive an email. You have to confirm your email and then you get like a welcome page. Then you go to a dashboard it's kind of a similar feature of many different software solutions, and we had the same. And there were some known issues with it. We knew that on this screen size it doesn't look very good, something breaks, etc. And it was somewhere very down below on my backlog, a task to fix it. But I never really put it high up because it was a minor issue. It wasn't really a blocker it was more of a inconvenience for say 1% of our potential users. You know, it kept bothering me though, the perfectionist in me kept being like, Oh, come on, you have to fix this. You have to fix this. It cannot stay like this. I know it's not the highest priority, but you know, I wish for the day when we're done with the more priority tasks so we can actually fix this. In the end, what happened and really just shuttered the drive for perfection was that the time came when the product evolved sufficiently that the whole signup process got a complete revamp, it was completely re overhauled. It was done sort of from scratch because we had completely different requirements for what it should do and how it should look. And so all of those issues that stayed at the bottom of the backlog disappeared, they didn't exist anymore. They were not defined anymore. I see the same pattern happened many times over where if you intentionally don't solve some problem over a long period of time, it might even go away on its own. It's not a given that problems stick around to not only get worse if you don't cure them. That's not always the case. There are certain problems that actually can cure themselves. And if you preemptively do them, it doesn't make sense because then all of this effort to actually do the task is for nothing in the end when something changes. So, always do whats necessary in the moment and don't preempt events.

Iliya: 51:06

I cannot agree more with this is. In the same way, I have the backlog of tasks. I have the backlog of issues. I've been using JIRA as a tool to organize my work three years ago, maybe. And I had this list of issues. And, it was very long list of stuff that I have to change at some point in the future. And then I transferred it to the next tool I was using. It was a thrill. And then I transferred this list again into monday.com, which was another tool that we transferred to. So, the business was evolving, the requirements were evolving, and now we're just transferring this list. In the end, I transferred it to one note as a part of the documentation that I sent over to people and I was going through them, and I was like, Wow, this is like a typo. Some E was not an E, but it was O. I don't know, it was a completely stupid typo, which would require three people working on this in different ways. And I'm like, this is so low priority. Maybe the perfectionist in me three years ago was thinking that this is an issue, but it doesn't take anything away from the good product that you have created. Now, this thing happens to me again and again and again, that in the same way that you're saying, and I believe that the reason for this is that the timestamp of the issue is very important. So, once you find a new issue, it consumes you, right? You're like, Oh, it's a bug. I have to fix it. This shouldn't stay this way. And, so on. Now, the next day you don't feel as strongly about it, and then the next day you see another issue, which is much bigger. And you're like, Okay, issue from two days ago, you are de-prioritized. And then more time goes by, the more you realize that this issue, it was momentarily

Iskren: 53:10

Its kind of a feature, right?

Iliya: 53:12

At the end of the day, you realize that this issue was a known issue compared to all these other things that you have to do. And, finally, to support your other example, one of the courses my first course that I had created the statistics for data science I was the one animating it. I was the one writing it and everything. So me being the personal animating, it meant it was awful. It was so ugly that you can't imagine. People liked it. People enjoyed it. However, it was not pleasing to the eye. And then we had this new designer that joined our team. She was one of the best people I've ever worked with. Shout out her, if she's listening, Martha, and she was joining the team and I'm like, Okay, it's a new designer. We have to start working together in a way. And I have to give her some lower priority task, which if she fails at performing it, we could just crush that. And I don't know, get through the fur and get rid of the work that she's done. So we gave her revamping the whole course, right. It was take these animations and make them beautiful. So in the process of her making this, I actually fixed all the issues that I had this long backlog of issues. Some of them were completely cut out of it, so I didn't have to fix them at all. Many of them were fixed by Marta herself instead of me, which was very helpful as well. And at the end of the day, if I had fixed any of these issues before I would have done triple work.==================== break

Iskren: 54:59

In this episode, Iliya and I share with you our experiences from having built various startups. As you know, right now, we're in the process of building our first joint company, 3veta.com. And, you know, it would be really cool if it were to go viral? How could that happen, you ask? That's where I call upon you, dear listener. Tell your family, your friends, your colleagues, about 3veta. Spread the word. Best of all, how good would it be if some of them were looking for a solution just like that, and they start using the tool you suggested to them. Youll be forever revered as the tech startup guru that you truly are. So why not begin now? Think of anyone out yourself who could get paid for an online meeting and send them a link to 3veta.com. Let them discover it for themselves.==================== break So to close this topic about the quantitative versus quality trade-offs, I think what's very important to stress though, is that you're only allowed to de-prioritize things as a very, very conscious realized choice, right? You don't just close your eyes about issues and sweep them under the carpet without really cautiously thinking about it and thinking about this trade-off that you're committing to. If you see an issue and you just kind of don't feel like dealing with it, so sweep it under the carpet, maybe even subconsciously some people do it subconsciously, only to realize they have ignored some issue that's really bad. Like never do that. The point is that you're consciously choosing not to focus your energy on dealing with whatever issue there may be. It doesnt have to be an issue. It could be an awesome try-out of some new ideas, some new branch of a program. And, youve consciously chosen to de-prioritize it. That's fine. And let's say in my Trello boards, I have those no action labels precisely for this. It's an idea that Ive assessed an issue, then I decide, Okay, there's no action here at this point, but I know about it. By the way, the bells of Rome are tolling again.

Iliya: 57:08

Flex

Iskren: 57:13

Flex from Rome. So I would say let's have one last topic on the boilerplate startup. And if our listeners enjoy this topic, you guys can let us know. We can talk about this topic four days in a row. We can talk about this for ages. But, for now we're failing fast. So, well just want to do one episode and see how you guys like it, and then we can proceed. Let's choose one last sub topic within the boilerplate startup. Overall topic do you have any choices? I believe I have one, but what about you? Do you think you want to pitch an idea?

Iliya: 57:59

I don't want to be the one giving the last time because I have so many others that I want to talk about.

Iskren: 58:05

Okay. I'll just say mine. And then, you know, in boilerplate startup 2.0, we can start with two of yours. That's a trade-off right there. Let's talk about incentives. I know it's something you have or we've discussed before, and you have a really interesting view on, as you call it, incentives theory and just how to use incentives in various ways. I think it's quite the useful conversation. So, how can you apply to the startup conversation incentives and playing incentives right?

Iliya: 58:41

Okay, I can talk about incentives for ages. So I'm happy that we didn't talk about my other idea that I wanted to bring up. Now, incentives a very quick overview. So what are incentives? Incentives are like motivations motivators. How do you make somebody do something? There are many different ways in which you can look at the issue. However, as a manager, you want to give the right incentives to your employees so that they work better, and that you have aligned incentives. As co-founders, you have to have the same incentives in the sense that you have shared equity. Usually, if the company does well or the co-founders or all the equity holders for that matter are aligned and there are different mechanisms that exists to achieve this. When we're talking about a company, it's a very clear: equity holders, debt holders, for instance, why would the bank give you a loan? Well, they have the incentive because it has higher priority than equity. So if the company goes fast, you pay off the debt first. The whole financial system is very well accustomed to this and the incentives are completely right. Now, it's more interesting when you have people, and you have random people, that you have to incentivize in some ways. So let's think about it from a marketing point of view. Now you have a product and you have to make it work in some way, right? You have to start selling it to people and you have some price, and then you have to incentivize them in some way. One way is to give them cash. Let's say you give cash to someone to, let's say, review your product. This is a very well-defined incentive because it involves cash. Another example is on a lower scale, I'm going to promote you if you promote me, right? So the incentive is let's be friends and cross-promote each other. Everything that you do, everywhere that you go, you have incentives which are at play and you have to be very good at juggling through those incentives. Now, I have to give you a story. Its this. Why am I a bit wary about this incentives conversation is because a lot of manipulation is going through incentives. So if I tell a story about how I incentivize someone to do something, it's basically me telling the story about how I manipulate this person toward what I wanted them to do. That's how manipulation works. You have to incentivize the other person in some way. Now I have to think about this.

Iskren: 1:01:25

If you want, I can tell, I don't always think it's going to be a personal story. But I can give my 2 cents about incentives that something I've talked about with actually several people in completely non-connected [in any way] instances and always about corporations, is that corporations to some extent, fail to incentivize activity and boldness, right? So with several people, I know acquaintances/ friends, who've worked at large corporations. They have discovered the same issue that corporations often seem to fail to incentivize being bold, being rigorous in your activity. On the contrary, they disincentivize failure. So if you attempt something and you fail, you incur some costs, you bear like a massive burden and you get fired, you get demoted or something. But if you're just kind of don't do much just coast, corporations generally seem to be okay with this. They fail to incentivize that you have to be bold, you have to take this extra step, go the extra mile to be really productive, versus startups usually is the opposite. It's a small enough organization that you can't really afford to just coast and go with the flow and don't really do much outside of the bare minimum. And so, in terms of this disincentivation to not be dormant , in the trading company I was working at, to a large extent, they had the right structure there, because the way it worked is that everybody's divided into trading teams. Each trading team, or most trading teams are fairly small, maybe about a dozen people, maybe even less.[Unintelligible] what would this mean is that each trader is very much directly impacted by how much money the overall trading desk creates because they get a bonus based on this. They have a super direct incentive. If you'll make money for the desk, that desk makes a bunch of more money, and you get a larger bonus. And so, you have this interest to just act, like you can't just afford to go with the flow and do the bare minimum. You have to be out there. You have to find the opportunities. You have to be active because in the end, your bottom line depends on it. And, I liked how they incorporated the software people in this structure. That's what I wanted to give an example because, you know, I entered the company as a software engineer. And generally its the traders who are pushing for those let's try this, let's try that they want to be more active, they want to make more money. The bottom line is very dependent on, not just from the salaries, but on the bonuses they receive from successful trades. At the same time, software people in trading companies are in this very precarious situation because the same applied to us: we still had no bonuses rate to how well this was doing. We're still very much incentivized to be very active and proactive and find opportunities, you know, deploy new and newer strategies that might be a bit riskier, but we are expected to make money. But at the same time, because we're the software developers, we cannot afford to have bugs in production a trading software, because we don't know how it could react. You have to turn everything off immediately and stuff. And so we borne the risk of, you know anything going wrong with the software could incur enormous costs for the company. You know, automated trades could cost millions per minute if left unchecked. And so software people were in this funny situation where each software developer has the incentive to be super proactive and push for releases of new and newer strategies to make more money. But at the same time, there's an enormous cost if anything goes wrong. So we're incentivized to be exceptionally cautious about it, because if the software has issues, it's very easy to track to who caused the issue and they'll be fired or take some financial hit or something. The subtle play of incentives there of how to both incentivize the software people to really chase after a novelty and be bold and push new products out, but at the same time, make sure they don't overdo it that they're very cautious was by A] allowing them to share profit from the overall profits with a bonus [non-fixed bonus], but also really punish any type of software issues that blatantly lift and disagree or anything just on the spot, like fired or something. Those were my experiencestheres very careful play of incentivizing action while still really disincentivizing failure.

Iliya: 1:06:39

The only problem there that whenever you and your colleagues from this company talk about this, the only problem that I have with whatever examples you're giving is that all the people that work there are extremely exceptional and they are self-motivated at the highest level. We're talking about entry jobs that are in top 00.001% of salaries in the world. The people there are so self-motivated that the incentives that you have to place there are, Do your job. Dont make a mistake and stuff like this. Now, what actual companies are actually facing are other types of issues. Like you have employees that don't want to work or that they're slacking. Or, I heard that guy, this is the best story. I was looking at his computer and he was supposed to be doing whatever. And it was this blank worksheet, like he's watching the page. He started glitching. And then he's like left and right, left and right. It's super strange. And I'm like, Oh my God, something's happening to him. Some stroke is happening to him. I'm really concerned and then, you know, there's the word file. And then there is this when you're starting to write there's this straight line, which is just like ticking and it's like appearing, disappearing, appearing as if you're just about right. And the guys glitching and the thing is just giving him some rhythm to the whole thing. And then at some point I'm like, what should I do? Then he stops. And then after 30 seconds, it happens again, like what is going on? And then at some point I started staring at him for straight five minutes because I want to understand what's going on. Then I see him that every 20 seconds to 40 seconds he's out and tabbing, and he's actually watching a livestream of StarCraft two. And he's been listening to the whole thing. So he has the whole commentary and he's glitching because he's very nervous about what's going on, where he can't really watch it because hes working and now you have to incentivize this person and no, you cant have equity, you cant have different things that you give. But, at the end of the day, it has to be some manipulative mind game, in my opinion. The incentives there are different. And most of the time it's like this, you know, that someone can do a very good job, but they're not doing it for one reason or another. And you have the carrot and the stick, right? These are the two things that generally work. However, I've been trying to avoid both because I don't want to give a carrot. You know, when someone has this very bad behavior, which is seriously bad. Then I don't want to be like, I'm going to give you a bonus, if you get better. Like, to me, this is not the correct approach. I'm only giving these bad examples. I just want to give some good examples. I just want to say, whenever somebody is doing a good job and they care about their reputation, you should definitely commend them publicly. You should be like, You are a very good worker. You have done an amazing job. Everybody, please cheer a bit for this person. Like it's extremely, if you find that someone gets joy from being publicly commended, do that publicly. If they prefer private, do it privately. Find the way they prefer it because there are these people, they've done an amazing job and I'm like, Yeah, the whole team come on. It's an amazing job. And this person, she felt really bad about being publicly commended because they're shy about it or anything. And then in a private one-on-one conversation, they told me, you know what, I really don't like that you publicly commended me. And I'm like, Wow, sorry, I didn't expect this. So since then I have always come in with this person a one-to-one and never said anything publicly.

Iskren: 1:10:54

Yeah. So what you're saying about commending somebody, and that you should do it, there's the best part, you know, because having to manage some process of people [a team] it's quite a task. There are many aspects to it. And the best part of it, I think, is this part when, some tasks has been done, it's been done well and you get to congratulate somebody for doing a good job in front of everybody else. And you're super happy because the thing got done, the people are happy. You're happy, other people in the company from outside let's say your team, are happy because it got done. This is the best part of it. So this is the most rewarding part - when something gets done well, and you can just lavish people with commendations and praise. So bottom line of incentive so far, there's various ways to do it. And you should. It's kind of the analogy of using the carrot or the stick. Its also that you should incentivize people not to make mistakes, but also not to stay dormant to move forward, but not make mistakes. Because if youd only use one side of it, then you risk them being either idle or reckless. And these are also bad. So it's about basically keeping them between the carrot and the stick. But, not way too much in either side.

Iliya: 1:12:22

Well, we can talk about incentives for four episodes.

Iskren: 1:12:26

You call it incentives. You also call it manipulation. I was going to say, I call them manipulation, whatever you call them. Well, we would like to hear our listeners opinion on this and whether we should talk more about it. So, feel free to contact us. Tell us, what do you think about this. But for now, we should say our closing.

Iliya: 1:12:49

This was the most non-boilerplates out of the episodes we ever recorded. How about we give it another name?

Iskren: 1:12:59

We can rename it now that we've actually done it. I was actually thinking about this in the last session as well. Now that we've recorded, it could be just, and its the point about naming what we made, right. Like we name this thing, we say, This is the boilerplate startup. And it evolved completely out of scope and now it's hard to change it.

Iliya: 1:13:18

That's why man, I wanted to call the other episode snake steak because you know, you just go into the random name and it's

Iskren: 1:13:27

What did they call this one the cheap steak. This could be cheap stick

Iliya: 1:13:31

Uh, it's the cheap stick ... Oh, it's a negative.

Iskren: 1:13:35

No, its a bad name. It has negative connotations. Ah, naming is hard. See people naming is hard.

Iliya: 1:13:42

Well, carrot and stick. But it's not what the episode is about. The episode is about realizations and depth. And..

Iskren: 1:13:52

These are the type of conversations, anywhere would we have this conversation. So it's kind of the afterwork pint conversation we just had.

Iliya: 1:14:06

Afterwork pint. Hmm. It's kind of a lessons learned.

Iskren: 1:14:10

Okay. Start up lessons anthology.

Iliya: 1:14:11

This is good. This anthology is a good one.

Iskren: 1:14:11

We had to use anthology

Iliya: 1:14:11

Startup lessons anthology

Iskren: 1:14:18

Anthology of startup anecdotes.

Iliya: 1:14:28

Okay. Do you want to record at the beginning? Let's do it.