Listen Now

Summary Learn from an experienced startup CTO how to build, validate, and iterate software products FAST. Whether avoiding premature scaling, creating value as soon as possible, and then using the right tools to build scalable software at the right time – Upile Chasowa is sharing the step-by-step approach he used to validate his idea for WorkClub, raise money, and scale a booking platform for coworking spaces. Episode Victor [00:02] Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, development, remote work, and anything else non-technical as well as technical founders need to know to launch and scale software products. Today’s guest is Upile Chasowa, co-founder of WorkClub, he will share with us the product strategy he used to develop his platform from an early validation prototype, the MVP, and then the scalable product and how he developed each stage. Hint, he’s using an entirely different approach every time to launch as fast as possible. Upile Welcome to the show. Upile [00:39] Thank you, Victor. Hi, how are you? Victor [00:42] Super good. I’ve been looking forward to this one. But first, tell me a little bit about yourself, your background? And also what WorkClub does. Upile [00:53] Awesome sure. So background – where do I kick-off? Where do I start? I guess I can say that I’m a CTO by background, I have over nine years of experience, hands-on experience, actually spanning from software design, r&d product strategies, with big data and online marketplace applications. Previously to that, I founded three startups. Graduated back in 2012 with a computer science degree, and as soon as I actually graduated, I built my first bid business in a real estate market, and also, prior to joining WorkClub, I was a senior engineer for an insurance company, and I’ve also been involved in building an online bidding platform which managed assets worth over 10 million, and in terms of WorkClub itself really, for me, I’ve been involved in a business for the last three years now, and essentially what we do is we offer our co-working spaces or freelancers, consultants and employees to work from. Victor [02:16] And for now in London in the UK. Is that right? Upile [02:19] Exactly. So based in London at the moment, and – Yeah, it’s a London startup, essentially. Victor [02:25] So what’s the main problem that you’re solving? Upile [02:29] That’s a good question. So in terms of the problem, really, I guess what is on the high level, a common sight that we all tend to see, as you walk past a coffee shop. I know it’s a crowded and chaotic environment. And, for us, we feel like these coffee shops are filled with distracted professionals plugging away on their laptops and for us really, is to try to build a productive environment. So that’s really the first problem that we’re trying to solve. Offer employees, professional workers, and an environment for them to work and really get things done, and when you look nearby, there’s a great restaurant, great pubs, great hotels, and co-working spaces that are practically empty throughout the day. For us, we believe they’re better suited for these kinds of professional workers. So that’s really something that we’ve seen in the market, and we’re looking to tackle. Victor [03:36] Beautiful, and so you’ve found this niche or at least this problem that you wanted to solve, and now how did you go about validating that we’re building, the first thing people could literally use. Because most people would now be like, hey, let’s build an entire platform. Because that’s what we want to do. Upile [03:57] Absolutely. It is a good question. I mean, really, essentially, for us, I would say the success of WorkClub initially was to onboard as many venues as possible. So there are many space operators, there’s many of them and also be seen as a low risk, easy to use, revenue generating platform. So that was the initial thing that we had to prove. So for us, we really had to come up with something that was simplistic enough, that could really cover all those fronts, and then from the user’s point of view, the professional workers, the remote workers, the employees, etc., they had to see a range of spaces available, they could easily have access to the source again, we wanted to be seen as low risk and easy to use platform. So that was the core thing that we had to, first of all, establish before kicking off anything. Victor [04:58] And so what’s your first step in that?  What did you build? Upile [05:04] So the first step for us was, we created a simple mockup of what we wanted to introduce to the market. So a simple website per se, actually not even that, I guess a landing page, your Classic landing page is a website. If you do then yeah, so we built a simple landing page, which showcased 10 of our best venues, actually, 10 of our best venues that we believed were suitable for remote professionals. So, I remember literally built something in Angular actually, to be more precise, and Angular landing page, no back end, nothing, and just displayed in a number of images. There was no booking process in place, there were no booking forms in place, it was just simple as here, the spaces and then really just a measure the click rates, are people actually clicking on these spaces. So that was the first step that we took, we then promoted it to our close networks. So friends, family, as well as if we were more professionals that we knew. Although I have to say prior, the landing page launch, we spent probably a week or so engaging in groups just to gather momentum, just to create the hype around, hey, there’s something new coming out. So that was really the first approach that we took really. Victor [06:35] Wow. So I just want to point out here that usually, and I know that from myself, as technical founders, we usually just try to jump right into code and build something scalable, whereas you just said no, actually, let’s do the landing page and put things on their manually. That’s not something we want to do as developers and get traction. So congratulations on that, because it seems it worked really well. When did that become? – Well, not scalable enough, when did that concept start to break. Upile [07:15] So just to retaliate, in terms of why we approach this simplistic way than building a scalable product was prior that previous business spent, probably, I would say, nine months building a product, and realizing, oh, my God, we spent so much money building the best product, and nobody was using it, although the concept was great. But nobody used it, because we didn’t engage with the market. So that was a key learning. point for me, and bringing that one to work was crucial, and we had to do that. Now, when we started getting our guests to your point around, when do we realize, okay, this landing page is not scalable, we need to build something that actually works; was I remember, we launched within a week, we sort of set our goal every month, we should expect about 50 to 60 bookings coming through, we literally had 60 bookings or 60 requests to make bookings come in within the first week, and then the second week, that double the investment, we realized, okay, there is something here. So we had to scale back and sort of make clear, Hey, guys, we’re just testing the concept, and to actually build the entire initial, I guess, version 1.2, would you call it 1.1, ping the landing page, we had to put things on hold three months build out an entire system, which consisted of what’s the entire system, the initial version, which was literally taking the landing page into a booking system that I guess, when you clicked on the spaces, you have a simple form that popped up, you enter the time that you want to turn up and how long you want to use the space for? And that was it. That was the booking system. So really, it was devised that. But the reason why it took us three months to come up with something like that was that it was a lot more, I guess, moving pieces. So we had to engage with the venue operators and say, Hey, we have just been promoting your spaces without your acknowledgment online, and we’ve had excellent other attractions. So for us, a matter of really establishing contracts and agreements, and looking at, if we do have, let’s say, Victor turning up, what does it mean for you as a WorkClub, and what does it mean for you as a space operator, so really a case the work was around, really turning this into a business that could scale. So that’s how we approached it. Victor [09:46] But as an upside, you now had actual numbers and data to bring to the table. You could approach these venues with a number of requests, you knew which ones work better, I assume, and also what people were expecting. So that’s really good. Upile [10:02] Absolutely. Victor [10:04] So now you have this form, you did some admin stuff, contracts in place probably managed to get some kickbacks from these venues, and the first people are booking. Did you learn a lot during that process? Was that valuable? Did you engage a lot? Did things break here, for now, and then. Upile [10:29] So there was a lot that we learned. So again, from experience. I guess, with this approach, it was more or less really measuring. First of all, for me, as a guy building the system, I had to understand what’s working, and why are people clicking on these spaces, and so forth. That was really my core goal or my core responsibility. So for me, it was making sure, I was measuring the stats, the data, and really seeing what worked really well, and that really helped shape the next version of the product or what we had to do, and that was crucial. If we didn’t do that, we probably would not have had enough information or data to take out to the operators and then start to engage with them and say, Hey, this is how it’s working. Now, throughout the process, I guess really a key learning curve was that actually that piece of data that we sort of bought, that I relied upon to build the system became so crucial, because it aided by co-founder to figure out a great pitch per se, whether they use as a Hey, guys, this is what we can generate for you, this is what we’re doing, and also start to negotiate the pricing, and that was probably the challenging part really figuring out what is this worth, because for the operators, for them, this was a new way of acquiring customers, this is different, it wasn’t the same as Hey, we’re going to send somebody to purchase food and drinks, we’re actually sending somebody professional to sit in your space for free initially, and then eventually, if you serve them really well, they will be paying, they’ll spend X amount. So coming up with those assumptions, how long those days how much you’re looking to spend? We’re not really too sure. But we do definitely spend and so forth, building a profile for our users coming through was quite challenging. So we learned a lot through that process. Victor [12:28] And up until now, who was building that site, was that you? Upile [12:35] Yes. So, I would say for the first nine months, it was me building the entire system. So from landing pages, initial booking process, etc., and I was very hands-on with that approach, and after when we started getting more bookings coming through and more venues signing up, etc., we realized, hey, I need help. So I brought on a junior developer who then helped, I guess, build version 2.0, which was a much more robust system. We initiated the platform, the booking platform was built on Firebase, Google Cloud as an example, we then migrated that into an or do AWS, the first time having a robust system. So it was really establishing a good infrastructure, which is key. As we say, poor infrastructure, you can have the best product. But if you have poor infrastructure, it’s just not going to work. So that was quite crucial. So we brought in a junior developer for probably about, say, supported me for like six months before we really took it to the next level. Victor [13:46] And you just mentioned it, it took another level. At what point did that become not sufficient enough? What you had right now, that approach? Upile [13:57] When we started – I’ll probably say when we had issues, from customers coming through, hey, I turned up to the venue, I pay for it, and they had no idea who you were, hey, I made a booking, and I have not received any confirmation if this space is open or not. Hey, I have turned up to the venue and the staff were just rude. So that’s when we realize okay, there is now something here that we now need to figure out. So this is where you begin to build a process and the process we look, I guess, understanding what is the customer journey. Upile [14:37] So if Victor is going to use this product, what does this customer journey looks like, from finding the space to making a booking to pay, and then understanding what he really wants. But we then realized that actually it’s not just the customer that’s making the booking, you also have the venue operator that have set in expectations, and we have to educate them how this product now works. So that’s where things changed. For us realizing that, hey, we are setting people, but then the engagement between the operator and our members and users. It’s still not there yet, and there’s an educational piece that we have to do with our product and face to face. So, that’s when we realize, okay, we really have to establish a proper process, and then we find our contracts and agreements, to have a clear understanding across the board. Victor [15:40] And that was it probably scaled Airpro scale to the point we’re intervening manually just wasn’t feasible enough sending emails back and forth, we just couldn’t do it at the anymore at that point. [crosstalk] self-explanatory. Upile [15:54] He had to be self. I mean, we still work with that. The problem is, when you’re dealing with hospitality businesses, there will always have to mind your interventions, you have to get involved, you have to be there, you have to support as much as you can, the system’s not enough, there’s a lot more, there’s a huge high turnover. For example, the staff that you met last week might not necessarily be there the following week, that’s just how it works. So for us, it’s been a challenge that we’ve always had to look at. But what’s worked really well for us has been building a great brand, and also actually building a better process of our system and ensuring that our customers come in through the system fully understands and acknowledges that, hey, look, this is how the process will work after when you make a booking, and if you have any issues, this is how we handle and resolve them. So having that clear transparency is probably something that we’ve had to build outside our technology itself. But yeah, I mean, it’s not an easy process. It’s just the fact that when you’re dealing with hospitality businesses, and those types of space operators you did, there’s always going to be a manual intervention [phonetic 17:17]. So you have to do, there’s always going to be human touch, which is important. I guess. Victor [17:23] Of course. So when you set out to build the next iteration of the product, I understand that was about scale about getting these processes just right, taking those learnings, and turning them into a stable product. Did I sum that up correctly? Upile [17:41] I guess so. Yes. So how did that come about? So when do we actually make the decision to build something that was a lot more, I guess, center stage of the market. So when we started off, we were young, we were new in a market, and then we started realizing there was some competition. So I guess to stand out, there were a few things we had to do. The first thing was rebranding ourselves and stand out as competitors. Because everybody outside our competitors, or potential threats coming in, they are like wow, you are the guys with the market, but we felt that we went yet, we felt that there were a few things we had to do, and part of that was obviously looking at our pricing to start off with, how should the pricing really work for the remote worker, typical Freelancer looking to use this model, and then also, how do we want to position ourselves in the market? Do we want to be seen as a young, quirky product? Or do we want to be seen as a serious product? It was just all endless. So we had to establish ourselves and build a product around that. So for us, we went through that phase, and also, in turn, we fundraised, some substantial cash, that helped us to build out a proper system that put us in the center stage, not saying the systems that were built prior weren’t that by your guess he was just more about building something now, that would actually, I guess, the stamp of approval, add that little stamp of approval to prove that actually there’s something here. So for us, yeah. I mean, that was the next stage, and also, we had a few conversations with bigger boys are interested in getting involved and saying, Hey, we love what you’re doing. We’ve been trying to do this for years, and for us, that was like, wow, okay, we have the big operators interested in working with us. Then, it’s either we continue doing what we’re doing it to make it better so we can become more attractive. So we did. So we do with that approach. Victor [19:54] And so that was you as a junior developer up until this point. Did you continue this way? Upile [20:03] So we had to make a few changes. So I guess, to rebrand ourselves, to be seen as, okay, these are the guys to be, these are the market leaders of this new market that’s building, etc. Though a lot of things that we have to do. So the first thing is really looking at what should our system operate on, and what the up-and-coming-trendy tech, we should be integrating, building the system on because, you know, there’s a lot of things to consider, the more operators you have working with you, the more data you have to produce, the more the bigger you get, the more users you get, and so forth. So, we had to look at it from that angle, we need to build something that’s stable, that’s going to be able to handle millions of customers, and hundreds and hundreds and hundreds of space operators. So, that was a change. So up until this point, we realized, okay — well, I realized by looking at putting scoping out an initial – I guess, a roadmap of what we want to achieve by when, and then that’s when I sort of got in, that’s when I decided to get some a lot more grow my team, essentially, with a lot more experienced engineers to help us take it to the next level as well as product engineers as well. Victor [21:28] Amazing, and how did you go about finding that team? Or who did you choose to work with? Upile [21:35] So at the time, I had a friend that I knew for some time. So he used to run an agency, a tech agency back in – Are you smiling, I’m coming to you don’t worry, you know, they – but I’ll come to you.  Now. So he actually had a tech agency in Poland, by the way. So I was engaging with him. But then I also had another friend Victor. I don’t know if I’m allowed to say this. But Victor, there you go. I knew that he was working on a really cool startup that connects –if you are looking for engineers, or tech houses, etc, across Eastern Europe, he reached out [inaudible 22:23] who share a few recommendations. So I have those sort of two options. But the first option was more, hey, I have a friend that physically runs an agency that could help me well. So I got in touch, and then I’m going to tell you, Victor, as well, and Victor, yourself, I guess you recommended a few contacts that you had. But I was just blown away by the contracts that came through Victor, which were just incredible, and yeah, which I guess really, in turn, got me to work with the contracts that were committed by Victor. That over my friend that I knew for some time. But it just turned out to be that Hey, look, it was all about building a product that was great at being – I guess the brand was important for us, or super important for us, and I was able to establish that through the connections that Victor made. So we had a product team and a development team that just came on board all at once. Victor [23:28] And what did you learn? Obviously, I’m super glad to hear that, that that it worked out so well, with working with our connections, but how did you because I know that that’s not just our fault. So to say, I know that it’s also been you who’s been working very hard on preparing everything on managing everything. What did you learn from working locally with your one developer or doing things yourself? As opposed to now managing developers in Ukraine? What was the big difference? What did you learn? Upile [24:10] Very good question. I mean, when you’re building things, I would say with when you have a vision of what you need to build, and then you have to build that vision. versus when you have a vision, but then you get support and help from people that can do, I guess they can come up with – they can cultivate your vision. There’s a difference. Because when you’re building and you’re setting the vision, I guess you don’t really see the bigger picture. You always see things in the short term, you always see things okay, we need to build this now because you have to fix this, but you don’t think about the bigger picture, and that was really the working style that I established. When I was working with my junior developer. It was more okay. This is what we need to build now. Because we have to achieve this, but then never really thought about what could and what should this product be? How big could it be? Or could it become? So that was something that I never had a clear sight of. I never thought about it to that extent anyway, and when I came across, the team that was introduced to us, from a product side, it was actually my first experience really spending some time with – it was like, I had so many great ideas that I never thought of at that point for the product that we’re working on, and it just came apparent how much passionate I was for the product in spending some time to look at what could become of this thing, and that was it really, and that’s where we began realizing, oh, wow, okay, we are building something that’s actually huge here. So establishing that and spending – I think I remember, we spent over a week just going back and forth with ideas, crazy ideas, good ideas, bad ideas, you name it, it was all there, and we ended up coming up with a huge [inaudible 26:13] Okay, this is how we’ll build it. This is how the model will work, and this is how you expand it, was brilliant, something that I never, ever thought I would ever, you know… So that was one thing. I would also actually having that support line from, okay, how do we actually build a stable product, stable infrastructure that we can actually grow this whole vision that we’ve just mapped out, and that was another thing. So having support from that side and looking at it from the bigger picture. That’s where having the experience, support vision that I had for the product changed and came in. But prior to that it was just more or less disappeared? What we have now, and not really thinking about the bigger picture if that makes sense. Victor [27:01] Absolutely. So you laid out a more concrete roadmap or iterated to get to a more concrete roadmap, not day by day. Steps, hey, let’s build this today. Let’s improve that tomorrow. But more like actually having an idea for a longer-term communication that once you got there, and only then go about implementing it, is that correct? Upile [27:30] Correct. Yes, and I guess that had really a number of advantages. We had to expand the team, fairly quickly, to support the growth of the product, and just realizing, just being super clear of what’s actually being built. Having that roadmap was essential as a key because I was able to understand, okay, I need X developers or X amount of time, and X amount of budget, would you have time when you grow in a business, especially in this, if you’re scaling a business, per se. Again, if you’re short-sighted, if you’re not seeing the bigger picture, you fall into the trap of just bringing on anybody, anyone without really understanding what needs to be done, and that’s a worse position to be in because money is key/king, and when you’re scaling, you need to be super, super clear, or what you’re building because anything can go wrong, especially in technology, you build one thing, but then it turns out to be the other thing. So you have to be super clear. So that was fundamental. Victor [28:41] That’s where you were building all your entire previous experience of the landing page of the mistakes of the processes, of learnings of everything. You’re like, okay, rebuild, this is what we need to do properly now. Make it scalable, you guys do it. Is that correct? Upile [29:05] That’s correct. Gave me the back seat now, I guess. I mean, I don’t use that, just in case people might be thinking [inaudible 29:12] so now you have this now – I guess for me again, it was more or less coming to my realization and just realizing, hey, look, you’ve done the first part, you’ve built the initial infrastructure that you’ve dreamt of for this product, etc. But now it’s really making it into that thing, make it into the scale of a thing. When you speak to investors or operators or customers, it’s super clear. What is WorkClub and I guess that was part of it. What is WorkClub as a product? So that’s where it all made sense. Victor [29:51] And fast forward to today. What’s your product team set up today? Upile [29:59] So product team – Wow, another great question. So it’s a much more scaled-back team. Okay, so I guess you know, it won’t phase. So initially, it was a very small team as a starting out myself, junior developer, and then we had a massive team, which consists of up to 15 out. So if we didn’t developers, but that was more or less, we’re scaling, scaling, scaling. So we had to build fast. But within that, within that process, you know, I guess it’s more when you build a product. I guess one thing that a lot of you know, a lot of people don’t tend to see it don’t tend to actually see a witness is you have to support a product, especially if you’ve built it to a certain extent if it’s working really well, and users are loving it. So for me really get it was more looking at how do I build a team that can really help me support, build that and maintain that product, building along because we’re building more features, we’re more or less just maintaining the features or adding in a few changes in there. So we scale back from having a massive team to just having the right team to now maintain that product as we went along. So now we have three engineers that are working on the product, and the product, by the way, is a mobile app, iOS, and Android, and also we have a dashboard process for our clients and space operators, as well as teams that are accessible to the app, etc., and then we have a product owner/manager that’s really in charge of making sure that, the product, the features, the feedback, the customers, etc., we have managed that really well. So we need a product owner for that, and then the QA support, as well. So QA to make sure everything that’s being tested and bugs being fixed, maintained. So, I would say there are about five of us really managing the entire tech side for the time being. Victor [32:06] Awesome. Where are these people located? Back in London again? Upile [32:11] So we live and breathe the remote work lifestyle. So I’m the only one based in London, i.e. from the tech side. The majority of the team actually if you look at it from the overall business and marketing based in London, but we have a couple of roles, i.e. business development that’s remote-based, and from the engineering point of view, I decided to really build our own engineering team, and I guess this was from the experience when we’re scaling up the product, the centerpiece, where we realize you can get things done better and quicker if you have a remote team. It’s incredible. It’s great. So yeah, so I stuck by that, and I have always been, I guess, a huge fan of building remote teams. So right now, yeah, the team is diverse and remote. Victor [33:04] Awesome. What would you recommend to other founders? What’s the most important thing in getting that remote culture? Upile [33:12] Well, there are different ways to do so. For me, I would say, you need to be personal, I guess, be approachable, be very personal. Make sure you’re able to speak to people because it is very different. When you’re face to face with people, it’s very different, i.e. the person attaches there, the engagement is there, when you are brainstorming work, etc., it’s all there. But really, when you’re remote-based, build that person attaches [phonetic 34:06] you need to figure out how to communicate, and I guess you look at how to become better, I guess, better online advocates [phonetic 34:13], and that’s tough to do. But I would say, be very personal. Don’t always be right, we are working remotely. This is how we’re going to work, be very personal, I would say, and also set boundaries, especially if you’re a manager or leader, make sure you set clear boundaries. i.e. for example, what’s their availability time span, if you have a team that’s diverse working different, I guess, hours and zones and times, etc., it’s super crucial that you set boundaries and clear communication standards. So when you should communicate, how you communicate and how first you do a response. So that’s super clear, make sure that’s always lined up at the start, and also being flexible on taking time to recharge, I think you have to think about your team that is remote as the team that you’re working together. Let’s say not remote, so you really have to look at the setting, time to recharge, when’s the best time to take – Make sure you encourage your team to take time, don’t overwork, especially in development, there’s always something that comes up and it feels like, oh, as I’m at home, I can easily just do it out. But no, it’s not about that. It’s about making sure there’s time for you, for yourself, and be very transparent and clear with goals. Transparency is key – With that, I guess that comes with being patient, be persistent, and also be ready to – I guess, to [inaudible 35:55] things up. [inaudible 36:00] because sometimes, as I remember, I’ll give you an example, we had one of our interns, was tasked to send a mass email to clients. But actually, this was from the back of that intern suggesting Hey, there’s an easier way to do a mass email without sounding like we’ve done, without looking like we’ve sent a mass email sort of thing, a personal email. So suggested using. We said yes, just use that. But then something went wrong, which then I picked up a board and said, Hey, something has gone wrong. But then what happened was, I responded during the weekend. But obviously, nobody really answers a response in a weekend, and I wasn’t expecting a response. So the intern responded back. During I think, on a Sunday — I was busy on a Sunday, Monday came and then the intern sent me a long email to apologize, and I wasn’t expecting that, but for them, they thought they made a massive mistake. It was their suggestions, their idea, and I was like, you know what? We make mistakes, sometimes things happened. That’s just how it is. So setting that and just being very transparent and clear is super important, especially when you’re remote. I think Yeah, that was very long. Victor [36:27] This is great advice. Thank you so much, and thank you for the entire insight on this process of validating, launching, scaling WorkClub. Where can people find out more about you or follow you on WorkClub? Upile [37:37] Sure. Awesome. So thank you very much for having me. You can find me on Twitter. I’m going to share my details after this. Yeah, so Twitter, email me. Pretty good at email, you can email me directly or LinkedIn, and also, yeah, you can check out our website Workclubhq.com and you’ll find more details there. Victor [38:11] Thank you so much. Upile [38:13] Thank you very much, Victor.

Summary Overwhelmed by constant communication, unsure how to keep people accountable, and how to plan todos even just for the coming week let alone several months? Anders Thue Pedersen shares with us his very simple TimeBlock methodology that teams use to plan their work, keep themselves accountable and avoid constant coordination. Episode Victor [00:02] Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, development, remote work, and everything else non-technical as well as technical founders need to know to launch and scale software products. Today’s guest is Anders Theu Pederson, partner in Danish consultancy Abakion and co-founder of startup called Milt. Welcome to the show. Anders [00:30] Thank you. Victor [00:32] Anders has over his time in IT and software development, he’s come up with a very simple methodology. Well, in theory, very simple, at least the concept is very simple. But we’ll definitely dive into that methodology to estimate and plan software development work. Anders, why don’t you give us a quick background of yourself and how you’ve even found yourself in the position that you needed to just come up with a better framework of managing software development? Anders [01:08] Sure. So I’ve been self-employed for 20 plus years, have had consultancies in different sizes, I merged my latest consultancy in Abakion to become part of that, and one of the issues, as I’ve always had, has been when we got larger projects is estimating and tracking progress. But also, when hiring people being able to differ if they were missing technical skills, or they were missing personal skills. Because of technical skills, you can easily do something about personal skills as more hard to work on. So I’ve struggled with Bose for many years, trying to grow my business, and in the end, I ended up going on a Christmas holiday thinking I might as — I had like five or seven employees back then. I ended up thinking I might as well just close down my shop because I had a project that was running aground and I gave up on the entire managing people idea. So that’s my initial, that’s where it started. So it’s born out of desperation, of actually getting things to go right instead of getting things to go wrong. Victor [02:51] And so you were in this place, it was Christmas, you had more negative than positive thoughts about your business. You didn’t like managing projects? What changed? What did you find or maybe even read or how did you get to a new framework? Anders [03:15] So I’ve always been testing a lot of stuff, and I’ve always been reading a lot of books, and I’ve started attending MicroConf, where we also met many years ago at a conference for soul founded entrepreneurs, and Robin Mike in the podcast startups to the rest of us they talk about in one episode, it’s just a mentioned, but they talk about how it’s you should always be able to break down a task into half-day chunks. I mean, no matter how large or how small, you should always be able to say, the first half of the day, I’ll do this and the other half of the day, I’ll do that. So that was one thing I’ve heard recently, and giving a lot of thought about that concept of breaking things down because how long does it take? Oh, it takes a week but what are you going to do in that week, and people had no idea what they actually were going to do. The other thing I’ve read was a Paul Graham post. I think it’s called Maker time and Manager time or make a manager scheduled perhaps, which is the difference between being a manager where it’s driven by the Outlook calendar or whatever calendar you’re using you blog in half-hour or an hour at a time and you have a meeting and it’s an hour and you have a meeting that lasts an hour. No matter what you’re doing, basically, and then you have makers, people who actually create stuff, and that can be software developers, it could be writers, it could be painters, it could be all people who are doing creative stuff, actually It doesn’t have to be software developers, I’ve trained other people in the methodology. And they need flow, they need deep work, they need this concept of forgetting time and space, and being in that sweet spot where you just push yourself enough to forget about all the troubles in your life, but not so much that you are struggling to get progress, and it’s a really sweet spot to locate. But when you’re there, you can really perform and the thing about flow is it has a lead in and lead out. Mikhail MIhai  has written a book about it, it’s not the easiest read of all, but it has a lead in, it has a lead out, and if you get interrupted in flow, there’s a lot of studies on the last one, you lose around 25 minutes of productivity, and then I’ve read a lot about transparency and vulnerability and how to get people to that you need those things to have innovation, and all the things came together during that Christmas holiday where I were thinking about what should my next move be? And I decided that I’d made some small, simple rules, and if you didn’t follow them, you would get fired. Well I’m kind of black and white that way. So I was like, either this work, I’m going to fire everybody. Right? And, and I tried it out. So January 5, the first Monday of the year after New Year’s Eve, and all that. I gathered my team and said, we’re going to try something new, and the new thing is that you’re going to estimate everything you do in these half days’ chumps, we didn’t call them time blocks back them, we call them, whatever, and then you’re going to end I told them, you’re going to do that now. So sit down for half an hour and plan your week. One block, when you meet in on the morning, one block after lunch, and the same for the rest of the week. 10 blocks in total, and then we’re going to sit down and talk about all 10 bucks. What are you going to do? What are you playing for this week? And then next Monday, we are going to do a retrospective on that. So next week, we’re going to say, of those 10 blocks. What did you get done? Oh, cool, and what did you not get done? Oh, shit. Sorry. Oh, whoops, and then we’ll ask a few questions. Why didn’t you get it done? Because this and that. Okay, so what have you learned? And that’s a much harder question. Because it’s easy to say, Oh, I didn’t do it because bla, bla, bla, and I asked a coworker. So what have you learned? And he said, “Ah, it was because blah, blah, blah”, and I said, “Yeah, but what did you learn?” And the fifth time I’ve asked him, he stopped, and he said, “Oh”, you know, then he started learning. “Oh, I learned that we need to coordinate before we blah, blah, blah”, and I said, “cool”, and then I asked a third question. So what will you do differently this week? What will you actually change in your behavior to make sure you’re going to accomplish your goals, because the most important thing for makers are to get 9 out of 10 blocks accomplish every week. So they can be a hero, they know they have a job next week, they know that the boss is happy for the progress, and as a manager, I don’t care how much you get done. Basically, of course, I do in a broader sense, but basically, I need to be able to trust you. So it’s more important that if I had to rank them, it’s more important for me to know that what you promise me you will get done, then how much you get done. Victor [09:15] And the interesting part here is, of course, that there’s sort of similar concept, but not quite, which now, everybody knows and everybody’s talking about and nobody’s implementing correctly, and back then it wasn’t even that popular yet. But I’m obviously talking about Scrum and the Sprints and estimating and learning from what was the last Sprint establishing once velocity as you call it, which uses the concept of points instead of time blocks to give some meaningful way of estimating but what that doesn’t, is put focus on this flow aspect. Like one giving somebody enough, like half day block to really do something meaningful, and I guess were the differences as well is that in Scrum, you also say that one task shouldn’t take longer than a few hours. So the benefit is okay, I have to break down things into smaller chunks, and that helps me realize what I might have missed in estimating things. But it’s not enough of a guideline, so that people actually get clarity on this. But I think if people get to use in these half day chunks, of which are there’s only 10 in a week, they might get a better sense of their own time. Is that it? Anders [10:50] Well, there is multitude of different aspects of “why”. I think this works so well, when you implement it, and one of the things I realized just when you told me about this, now is that when you have these points, I’ve never thought about it this way. But if you have the points, you also have some people who can do more points than others, and let it start becoming a competition, Am I good enough? I’m not as good as developers — Victor Oh, shit, I got to do more points, and then it becomes competition, and I become focused on myself and you become my enemy, and that’s why I talk about, I don’t care how much you get done, it’s more important that you want, if you’re feeling psychologically safe, you’re going to do a better job than if you feel that you’re not as good as your peers. So it’s moving away from measuring people against each other, to measuring them against themselves, and the reason I thought of this is because on the other end, you know, if if you ask me, as a consultancy you, you have to do billable hours, you have to email an invoice to someone. And, you know, time registration has also always been a huge struggle for people, and I just realized the other day that I think the reason why people hate time registration, or a lot of people hate it, not everybody is because they basically don’t feel they have as much well us, you know, the next guy, because he has more points. So when they write the time legislation, they don’t feel to give the same value to the world as the peers, and that’s why time registration and planning and all these things becomes hard because it instead of being you know, you’re doing good, you start measuring yourself against other people, and I honestly don’t care, it’s a one on one thing, what you should get in salary and what the star programmer should get. That’s nothing for the group to discuss. So the Monday meeting has a huge upside in building trust, and you have to remember that if we don’t build trust in a team, when the shit hits the fan, everything beeps up. So you have to build trust. While that’s no problem. I have to. I know you don’t have kids yet. But I have a kid, and one of the things about parenting is you need to spend time when there’s not a problem. So when they end up in trouble, you have a relationship that’s strong enough that they come tell you, and it’s the same with the team, if you don’t have a strong relationship with your team, and have built that every week, when a project goes haywire. Everybody starts blaming each other, instead of together solving the problem. Victor [13:56] But I think what it also does is that 04 hours is this sweet spot between micromanagement, and it’s impossible to estimate everything in 15 minute blocks, everything’s going to be off in that case, and nobody will pay attention to the estimation anymore, because you just can’t hit it. Versus if you estimate in chunks too large, you won’t notice soon enough that you’re lagging behind. Versus here, you usually do every day notice when something’s just not getting done. So I assume that is also the benefit of this and why this works so beautifully. What kind of projects do you use this on? Anders [14:38] I use it on our day to day support of our clients. So I’m not project just on? — Well, one of the things you learn as a consultant is that we have a few clients where we don’t know what but we know they’ll eat a time block or two every week, and if we don’t plan for that, but fill the week out with other projects, and we know the client, on average uses the other ones, then we have to let down both the project client and the ad hoc client. So you learn how much time you have for your products, and you learn how much you have to reserve for other stuff, and it just gives a sense of tranquility for the developer or for the maker, when they meet up Monday morning, after the Monday meeting, that they know what they’re going to do, then they feel safe and leave feel secure and having enough stuff to do for the week, and it’s better to get more done on the project, those we were the ad hoc customers don’t reach out to you than under delivering week after week and it takes three weeks, when you’d get a new team. When I’ve taught people this methodology. Anders [15:56] After three weeks, everything starts to click, and people start to plan for the — if you have 10 time blocks, as a developer here, in Denmark, we work around 40 hours a week, you will have approximately 20 hours of development time the other 20 hours is email, chat, meetings; is being interrupted by me or the other line manager or whatever. So you actually only have 20 hours of flow time, but when we plan the first week, people put 40 hours of flow time into the calendar, and I’m like, so do you really think you’re going to do that all this week? “No”, but why are you planning it? And they’re like, “you know, there’s this disconnect”, and then we start removing until people say, Yes, I can, this is a reasonable week for me, and three weeks later, people, they hit the sweet spot of reaching 09 or 10 blocks a week, we want to push our limits, we want to learn, we want to be faster. So we always want to push our limits. But usually, that’s where we end up. Unless, of course, we are talking about the odd employee who — for some reason, insecurities won’t promise anything and won’t deliver, and this is a good methodology to finding the toxic players on the team who actually is not trying to build trust was not willing to be vulnerable, and open up and have a look at what they perform and they shouldn’t be on my teams. Victor [17:37] Is there anything that you do or is there some coaching or some second chances that you give? Or what do you do if someone simply can’t get their — I don’t want to call it quota, but make whatever they set themselves for the week and that… Anders [17:55] That’s never going to happen. I haven’t seen that happening yet. What I’ve seen is that people — When, I look people in the eye and say, “So, can you commit to that week? Are you going to Promise me that you’ve gotten everything done next week?” And they said, “no”, and it’s okay to say no, the first few times, and I said, “Okay, what should we remove?” And sometimes every now and then, is very rare. I end up with a guy who ends up removing everything before he can promise he gets anything done, and I’m like, “Okay, there’s something really disconnected here”. So it’s not about not, it’s about they won’t commit. They don’t trust themselves, and they don’t trust their abilities, and they are uncertain, and no matter how uncertain you are, how new you are, how green you are, you can commit to something. So if you won’t commit, it’s a different psychological problem, and they’re just toxic. Because they’ll say something. Yeah, I think I’ll get this done, and everybody will count on our team members delivering and they won’t, and everybody will get frustrated by that team member not delivering week after week after week. Again, it’s not about how much you deliver. It’s about being able to trust you. Because Firstly, I’m going to do something I have. I need your delivery Monday so I can do mine Thursday, and if you don’t deliver again, I’m just going to roll my eyes and think bad thoughts about you and the team is going to suffer. Victor [19:33] The very interesting takeaway here probably because Startup Founders listening to this may be thinking okay, but billable hours aren’t that important for me or even? Well, I do have deadlines, but it’s more important for me to get some things just right and spend a bit more than having people just promise deadlines but what probably the most important thing or the takeaways here that people who give themselves a scope and not have it assigned by someone but agree on a scope for themselves and then commit to it, actually do it. Is that what it is? Anders [20:17] It is. So you build accountability, people have to train their accountability to adhere to this methodology, you have to be accountable, and they train it, and they take it as a personal failure if they don’t get stuff done, and they’re going to reach out, and you want accountable people, you want people who when they see something is wrong, they fix it, instead of thinking that’s not my area of responsibility, especially in a startup. You want people to notice, or this is a good opportunity and do it instead of waiting for someone else to tell them, we want people to be really accountable, and you need trust, and you need vulnerability, and you can only build that when everything is going good. The other thing, the other takeaway from this methodology is especially and I’ve used this a lot, when using remote teams is that; with my consulting clients, I sent an email out my team sends an email every Monday morning with, we’re paying this and we didn’t get this done last week. But we did this instead, et cetera, et cetera. So when I work with remote teams, I just gently try to nudge them to email me every week, say, this is all the tasks we know, this is what we got done last week, this is what we are planning to do this week. Because again, that builds the trust that they have this accountability, they know what they can do, and they adhere to it and they deliver. I asked every remote guy I’ve ever worked with to do this, and some does, and some doesn’t, and if they don’t I have to call them, I have to check up on them. But if I just get an email every week, I have No — They don’t pop up in my head, like, what are they doing this week? I’ve just know. So I can concentrate on other things to put out fires at other places. Victor [22:25] Which is great. You mentioned it, especially in remote environments. Does that also work with contractors who are not full time? Because what I think is that they may want to commit to something, but then something completely unplanned from a different environment than yours comes up as it always does, and that probably destroys that that vision a bit. Have you worked like this with independent contractors as well? Anders [22:58] Yeah, and the problem isn’t different from me having clients in my consulting, because the rules, whenever we can’t deliver on something we committed to; to a client, we have to tell the client. As soon as we know. Victor [23:21] So it’s also about communication. Anders [23:23] It’s about communicate, [crosstalk 23:17] Yes, this is not a methodology to get work done. This is not an estimation methodology. This is a communication methodology. It is a framework for getting the very important communication running. It’s nothing else it’s about communication, and I’m sitting right now I have a remote team, and we’re way behind schedule, I got hit by Corona. Not me, but my team got hit by Corona. Now we have a team member with a broken rib. So it was really going great, and just as my primary on this project, got back from Corona, the remote team got Corona, and everything goes haywire [phonetic 24. But luckily, I knew it the same day as he knew it. Victor [24:19] Of course. Anders [24:20] And then I could call the client who are depending, really waiting. I said, sorry, we’re not going to — You know, now they’ve been hit by Corona. So now we’re at least four weeks behind schedule, and for the first time my client said, Oh, it’s starting to be a problem because it’s a new ecommerce system we’re building, and we’re starting to lose customers because we haven’t switched over and the old one is an update on the stock info, and I was like, Oh, Jesus, I wish you told me that early, and they said, Yeah, but we didn’t think it was going to be a problem. But now I’m telling you, I’m like, Okay, I’ll build a connector from the new economic system that is working into the old shop system so we’ll can update the inventory and get that working. Anders [25:03] So you don’t lose customers because they get angry because they order something that isn’t in stock, and if I hadn’t reacted immediately, on the information from my side, they wouldn’t tell me that they will lose and customer. Trust would start to deteriorate because they would sit in the camp singing, why is Anders delivering that stupid ppppp? And I would be like, why didn’t they tell me bah, bah, bah, bah, bah, bah, bah and think they were stupid, and we would roll our eyes and the cooperation would go to pieces. That’s just by being proactive and honest and transparent. This didn’t happen — And now that you can wait indefinitely for the update, because I’m just going to push the inventory out in the old subsystems. So they don’t have any rush anymore, and it was just one quick 15 minutes call that made — something that could have gone haywire. Just work. Victor [26:00] That’s a beautiful takeaway. Maybe a last thing that that we can discuss to wrap this up is now if anybody’s listening and they want to say, Okay, I would like to try it, you already said takes about three weeks. Any tips or takeaways and how to implement this with an existing team to try this on in an easy way? Anders [26:23] You have to do it fully for the entire team. At sub teams and teams below, you can do it half-heartedly. So playing with it, it’s as simple as taking — We started just on a piece of paper, and just 10 blocks on a piece of paper, and with post-it notes, you can put them down. I said, “This is my week, do that start there”, and then just be honest about, did you get things done or not? I’ve been at first weekly meeting where people discovered that they didn’t test their software as a thought, where the manager was like, Don’t we have those test cases? No, no, they haven’t been running for weeks or months, you know, skeleton dropped out of every cupboard at all, and it’s not like, it wasn’t there before, nobody just knew. So it’s more about starting to communicate about what you’re doing, and giving everybody on the team five minutes of time. Nobody should talk less. So if you don’t talk, you just sit silently for those five minutes, but everybody should tell what they’re doing, and then just follow up next week and follow up, and a bit of caution, I’ve been doing this, we’ve been doing this for four or five years, I can’t even remember anymore, and every summer vacation, and every now and then; I am too busy, I have to do something Monday morning, and I’m not there for a month because something our client or whatever, and we stopped doing the Monday meeting and we forget about it, and then all this noise and all these problems start creeping in, and I’m like, “Huh” and we sit down and we do it, and we have a lot of calls to make the first week, and then everything quiets down again, and we’ve seen this four or five times. So it’s not easy. Because if you have any self-worth issue or self-confidence issues, they will try to argue why this isn’t a good idea. So it’s always a battle between the lazy side of you or the and the side that want to perform, and you just have to consciously decide that we’re doing it. No matter what we’re doing it. Victor [28:53] Nice. Got to stay persistent. Awesome. Thank you so much. That was super, super helpful and super insightful. Where can people learn more about you, about the Time block methodology? Where would you like to point people? Anders [29:09] Well, they could go to timeblock.com and read a little bit about it, and they should reach out to me, and we can talk about training or coaching. I also do coaching. So there’s a lot of possibilities for improving your performance. Victor [29:29] Wonderful. Thank you so much. It was nice to have you. Anders [29:32] Thank you for having me.

Summary Listen to how Kyle Racki and his co-founders have built a 100-person SaaS business from within an agency. Find out how they come up with the product, validated it, and how they separated resources from ongoing client projects. Learn how he’s managing a 50-person product team, and why they have just completely removed roadmaps from their development process. Episode Victor [00:00] Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, development, remote work, and everything else non-technical as well as technical founders need to know to launch and scale software products. Today’s guest is Kyle Racki co-founder Proposify who started his product within his marketing agency quite a while ago, already and grew it to a SaaS company of almost 100 people now. Welcome to the show. Kyle, great to have you. Kyle Racki [00:31] Hey, Victor, thanks for having me. Victor [00:33] So, 95 people, that’s a LinkedIn account, but not everybody has LinkedIn. Have you passed 100 people yet? Kyle Racki [00:41] That’s a good question. I have to check our HR software and see where we’re at. But I believe it’s around the 100% mark. If you count, we’ve got a few Co-Op students too. So, I think we’re around there. Victor [00:52] Nice. That’s a pretty big mark. Would you like to tell everybody a bit about the product, and what it does? Kyle Racki [01:01] Absolutely. So, it started as essentially scratching my own itch with proposals and working in agencies where you want your proposal to look fantastic. But the actual process of getting proposals made efficiently and quickly, is really painful and really disorganized. So, it’s kind of started there. And where we’re now, as a company is: Proposify helps sales leaders in scaling, sales teams, essentially get control over their closing process. So, a lot of teams will have CRM and sophisticated upfront sales and marketing tools and lead gen and lead qualification tools. But often, when you get kind of to the end of a sales cycle, there’s not a whole lot of process often.  And we often find a sales rep are kind of doing their own thing sending their own PowerPoint, or PDF or Word docs to essentially put contracts or proposals in front of clients. And so, the sales leaders have very little visibility into what’s going on, often brand standards aren’t being met, or there’s out of date content, or the pricing is wrong, or they’re using a term, they’re updating terms, they’re not really allowed to sort of present to the customer. So, this lack of control, lack of consistency is essentially what Proposify solves. Victor [02:20] So, understand right now, the target audience is more professional sales teams, right? Did that start this way in the early days? Kyle Racki [02:29] It started with small agencies really, because that was the market that we knew that we came from, so we knew them well. And you and I actually met on our first podcast that we put together called Agencies Drinking Beer, which was fun to do for a while. But then as the company grew, I think we realized that there’s a much bigger opportunity when you move up market into kind of the mid-market and enterprise. And that’s where there’s a lot of pain, and not a whole lot of innovation happening currently. So, we’ve been pivoting for the last several years to move up market and to sell to those bigger teams, where there’s more pain, and where there’s more steady, consistent use of a product like this versus sort of the sporadic usage of very small customers. Victor [03:18] And that makes sense. And that’s how you evolve into a bigger company, I guess. But at the beginning, as you said it was scratching your own itch. So, you were running an agency back in the days, as I remember, and you wanted to solve that problem for yourself, how did you decide to actually build something in-house? Kyle Racki [03:42] It was a really long, slow process to actually get the product made. I think I had the idea as far back as around 2006 when I was still even employed at an agency before I even went out and started my own. So, I had in my basement one night just kind of for fun thought about it’d be cool to have like a proposal tool, sort of like a base camp but for proposals. That was where I started, that was the idea. And I wanted all the functionality of like design for making the proposal look right and not just be kind of a Word document or a quote.  So, I mocked up like what a wireframe of the app could look like. But I sat on that for quite a few years, started my agency, a lot of learnings and lessons in business just from doing that. But then as we got about four or five years into the company, my co-founder and I really wanted to migrate towards products. And we had tried a few ideas for SaaS. Proposal software was kind of one of the ideas in the mix that we tried out. But as we actually got out and started verifying the pain in the market and showing it to people we found that it resonated strongly. There was a huge need for this type of product. And so that gave us the first evidence that maybe this is an idea we should pursue. And then over the course of several years, we got some funding to hire a developer in house to start building out the product and then eventually migrated away from the agency and sold it off.  Victor [05:17] So, you actually went out for funding, that wasn’t a cash flow thing from within the agency. How many people do that? I think that they just set aside a few developer hours from their existing projects, or whenever a developer idle, they will use them, which often results in  the product never getting done, essentially, right? So, you really went all in. You got funding, and you separated that pretty early on? Is that correct? Kyle Racki [05:52] Yeah, we had fallen into that trap ourselves. But I had heard other lessons about that. And so, I was pretty aware that that was a risk to this product ever getting. Because you’re right, if you just leave it  and  you treat it like a project in your agency and have developers work on it sporadically. Looking back 10 years later, without a product still and just wondering, where it is.  For us, we had to have a developer that was hired specifically for this product. And that developer was essentially not working on any client work. He was completely separate from the agency. And that was how we were able to get it off the ground. Now, if we were a more profitable agency, we would have been able to just self-fund this. But thankfully, where we live, there happened to be government programs, grant programs that we were able to tap into to help cover the cost or at least some of the cost of the developer. Victor [06:53] That’s interesting. And how did you decide on the early MVP feature set? Was that also scratch your own itch or was there any customer or early customer development insight? Kyle Racki [07:05] I didn’t approach customer development the way I would today, but essentially, we showed the solution. And we showed kind of the prototype to a couple agencies around town. The product had a landing page, I started with that. And then the developer that we hired was able to come in. And within about three months, he had a MVP ready to start bringing customers into and using it. And it was terrible. It was a very early stage, very rudimentary, but it was a that starting point, this would have been around April 2013, to just invite some people in, have them tinker around, most of them left immediately and never used it. And then it was probing and asking why and trying to figure it out.  So, it took about probably a year and a half  of just constantly iterating and talking to customers pushing updates, talking to customers. And that whole process was about a year and a half before we started to really find some traction, and people were really enjoying what we were building. Victor [08:21] That’s super interesting. And how did you continue developing that? When you saw some more traction, some more users signing up? Did that already become profitable or did you seek more funding? How did you scale from there? Because product market fit doesn’t always mean, we have enough money to build that entire deputy, right? Kyle Racki [08:43] Yeah, we were able to raise a seed fund in around May 2014. We raised 250,000, from a local VC called a Nova Corp. So, they were able to sort of give us cushion on that runway, where Kevin and I could step out of the agency afford to live essentially. With Jonathan, our developer, we were able to hire one more developer. And that gave us that little bit of runway to just keep going with what we had. We had about 10 or so paying customers when we raised the money. No serious MRR happening but the investor believed in the problem, we were ready to execute on it.  So, it probably took about maybe four months longer after we raised the money until we actually started to really see that uptick in not only customers signing up, which was never a problem. It wasn’t hard to get people into a trial. It was always hard to get people to use it and then pay at the end of their trial. And we started to crack that around October. Victor [09:55] And moving forward, you see that massive uptake you start scaling, you start growing, people start paying and sticking around. Fast forward to today, what’s your team setup now? How many people are in product? How big is that entire department to speak? Kyle Racki [10:21] So, we have currently four product teams or squads we call them. And then outside of that we have directors of engineering, DevOps, managers, that kind of thing. So, all in all, we’ve got probably about 40 to 50 people in product Dev, QA, and the support roles around that DevOps and so forth. That’s how it’s set up today. And then essentially, those four product teams would involve Product Manager designer, about five engineers and QA. And those are the teams that go and sort of solve specific verticals within the product like integrations or the document editor. Victor [11:00] So, they’re very focused on certain parts of the application, or does that change around? Kyle Racki [11:06] Yeah, I mean, this is always changing, whatever process we have today, it’s probably going to change in two months to something different. So, we’re just always evolving it. But as it stands today, we aim to have a broad context and understanding of how customers use the product, so that there isn’t just, you know, a team that’s in a silo and all they know with one part of the app and nothing else. But generally speaking, a team that’s focused on integrations is going to have more bench strength around back end stuff and API, whereas the team who’s in the editor doing more front-end type of stuff, they’re going to be stronger in JavaScript and all the other sort of more front-end technologies. Victor [11:51] And where are you guys located? Are you all in-house? Kyle Racki [11:56] We aren’t. We are mostly based out of Halifax, Nova Scotia here on the east coast of Canada. But over the last couple years, and especially it’s been accelerated with COVID, we’ve been expanding. But a year ago, we hired our first true international hire Andre, he’s based in the Philippines, and he’s our customer success, one of our customer success representatives who’s able to sort of tackle the time zones on the other side of the world, especially our Australian customer base. And then ever since then, we’ve been hiring some people out of the US, some people out of Brazil, actually. We’ve got a few people spread out. Victor [12:36] That’s interesting. How is your experience here? You’ve been around for a while and you said a year ago, you’ve hired your first international hire. What was your experience? Have you ever worked with remote people before or external service providers? What was your experience here? Kyle Racki [12:57] Yeah, I mean, over the course of 10 or 13 years, or however long I was in the sort of design and tech business. Yeah, we’ve worked with contractors overseas, we’ve worked with you and on getting some help, I think when we were looking at different product initiatives, mobile and experimenting with different parts of the product. So, we’ve always had that. I mean, it’s a little bit different, though hiring like a contractor and hiring somebody who’s at least treated if not technically on paper, in the cultural aspect, they’re treated like an in-house employee, they’re on a team, they have one on ones and all that kind of thing.  So yeah, that’s what I think we’re fairly new to. I mean, a couple years ago, we did actually have a sales rep out of the US. I didn’t really count that as an international hire because we sort of, we tend to think of Canada in the US as being pretty well the same thing. It doesn’t feel international. But yeah, like the first, really far away hire was Andre over in the Philippines. Victor [13:56] Interesting, and what do you think with COVID, everybody’s working from home right now? Kyle Racki [14:07] Well, yeah, we are actually all working from home. We have an office here in Halifax, so people are still free to use it. We actually don’t have too many cases here in Nova Scotia. We’re one of the safest places currently in the world from COVID. I think it was a New York Times article recently that listed Nova Scotia is the safest place in North America or something like that. We just have very few cases, we were down to zero for many months in all and then we sort of had a bit of an uptick, but we’re still around 20 or so active cases in the whole province.  So, with that we have office people working from home but we’re able to have if your team needs to have an offsite or if the executive team meets to sort of go over quarterly plans or something we do hang out in the office. I would definitely say COVID accelerated the remote hiring because prior to that, we had actually established a pretty interesting recruitment channel out of Brazil. We had hired about six or so talented engineers who came up from Sao Paulo and we were actually able to use a government program to fast track their immigration. So, they’re all living here. Because a lot of them wanted to get out of the country that they were living in.  And we were sort of on track for that, but then COVID hit so then the people that we wanted to hire down there, we just couldn’t get them up here. So, some are working out of Brazil temporarily until we’re able to get them over here. And then, you know, as it happened, we just ended up hiring some developers who were you know, one is in Mexico, one in coupler in the US, and, and there’s no plans for them to move here. Victor [15:52] Got it? Would you say that everybody or most people working from home kind of enabled that situation? Or would you say, it’s just as easy if everybody was in office with a few people scattered around? Kyle Racki [16:07] You know, I personally think remote has pros and cons. And the feeling and the collaboration of people sitting around physically, you know, a table with their laptops, working on a shared challenge or problem, having a whiteboard to just quickly discuss and brainstorm ideas. I think we use technology to try to get as close to that as possible. We have zoom, we have Slack, we have digital whiteboards, but it never really replaces the in person feel. So, I think the pros of remote, obviously, is that you can open up your talent pool, and talented people from anywhere in the world can work for your company. What you give away is that really close collaborative aspect of work, And I think we’re still like, probably a lot of people trying to figure out how to get better at that. Victor [17:05] Yeah, there are very interesting companies who really succeeded like “37 signals”, which is a classic, of course, although they’re smaller than you guys to be fair right there. I think, just about less than 50 people I believe. But then again, it is like 1200 people who are fully remote, which is insane. Kyle Racki [17:31] Yeah, it can definitely be done. And I think even 37 signals, they still do some in person stuff, I believe they still should have an office in Chicago for meetings. Also, they’ve always been a bit of a rare unicorn on their own ride, they’re very much like anti-growth and anti-moving fast. They’re all kind of like, take your time, everybody just hires smart people who want to work alone and don’t need a whole bunch of management and talking and collaboration and all that. So that works for them. I don’t think that works for most companies. Victor [18:09] Yeah, I would agree. Everybody needs to find their own pace here. Moving on to more of the product development side how it’s currently happening. And I know you have a great product manager, Ricky. Is he head of product? Kyle Racki [18:30] He is Senior Product Manager. Victor [18:30] Yeah, senior product manager because he’s the person that I know within your company. How do you decide which features to build? Because I assume at that stage, everybody has an idea. And every customer is submitting requests. And there’s probably a lot of features to choose from. Kyle Racki  Yeah, this really interesting topic and a lot we can talk about. You know, the actual team structure in the way we have it now where there’s a PM in every squad, so we have 4 PMs, with Ricky being the most senior. That’s the way it’s set up. And the way that we’re tackling the roadmap. I think roadmap is a general, interesting topic on its own.  We’ve made a recent decision to essentially kill the roadmap. And that initially sounds quite scary to most people, especially sales and customer success and marketing, who always want to have this Gantt chart somewhere that shows you what when all the features are going to launch. But the decision to essentially kill that mindset of roadmaps came from reading the book inspired by Marty Kagan, which is a huge book recommendation for those who want to know how fast-moving product teams operate at scale. It’s got a lot of great tips in there.  And so, the idea is essentially that what we’ve migrated towards is OKRs. So, for those who aren’t familiar objectives and key results where you kind of focus on outcomes versus output. And then individual teams set their own outcomes, their own objectives. And then the key results are how you measure that objective. How do you know you’ve gotten there. It’s a very different way of thinking, because most teams and most companies focus on output, management gets together and decides what features are most important. They feed it down to the teams and then the teams are expected to just take their tasks and get them done. The OKR model is very interesting and very kind of a mix between top down and bottom up.  So, we’ve migrated to that, and now that teams have their OKRs set. The OKRs are essentially what customer problems they’re aiming to solve. And all that is based on the target market that we’re going after. And if we flip that mindset and go after talking about customer problems and business outcomes, then the feature really is not… You know, we don’t need a roadmap to tell people what feature is going to launch when, because “Hey, it’s going to be wrong”. Whatever we put down, whatever date we put down is going to be a lie. We’re basically just throwing darts at the wall and praying that we hit them. It gives the people from outside the product team some perspective into. Let’s just say “Okay, we know there’s this team over here and they’re solving this customer problem”. It’s around trust and reliability in the editor.  So now we don’t necessarily need to say “Well, okay, well, there’s a thing about page flow. And there’s a thing about pricing tables or whatever feature set is within that editor”. We know that at the end of the quarter, this team wants to make the editor more reliable, and trustworthy. As they get in and they start experimenting and running discovery and testing prototypes, they’re going to find what are the right features to build, what are the right usability improvements to make. So, at the end of the quarter, they can say, “Okay, we’ve achieved a measurable improvement to this outcome”. Victor [22:00] And that makes sense, because in the end, what counts is not the feature. What counts is that customer problem being solved. Kyle Racki [22:13] I’ll just add that in order for that to work, the product managers have to be very closely in touch with customers, because they’re just guessing, or they’re just relying on sales or customer success to tell them about customer problems, there’s always going to be divide that layer in between that interpretation or bias. The only way for this to work is that the product teams are deeply engaged with customers, especially their target customer, their ICP’s. And they’re able to show them ideas in the early stages and ask about their problems and ask about their current workarounds and deeply understand it, because then when they’ve tested their prototypes of their ideas, and they’ve gotten them to a delivery stage. Then they’re able to say “Okay, we’ve achieved this measurable outcome.”  Now, sales don’t care, as long as their deals aren’t being blocked. Sales really don’t care what feature gets built. But oftentimes, they resort to telling product what to build, because they feel like their deals keep getting disqualified because of lack of features. If their deals aren’t getting disqualified, if their pipelines are being opened up, they’re happy. Victor [23:22] And that’s a great point, especially on the product managers being in touch with customers, how do you ensure that on scale? What process do you have internally? Kyle Racki [23:33] There’s a lot of tactical things that you can do. I’d say like the first thing is you have to make sure that customer success and product have a good relationship and they trust each other because if they don’t; customer success can get very possessive over their relationships, especially the larger customers. They want to make sure that product isn’t getting in there and sort of maybe taking an at-risk account and making it worse. So, you have to open up those lines of communications. But from a tactical level, there’s a few things that we’re trying. And we’re actually in the process now of moving over NPS survey follow ups from CSM to product managers.  So, the idea, we now have a shared calendar for the product managers. So, when somebody especially the target segment that we’re focusing on as a customer base, when they fill out an NPS, and it’s less than glowing, it’s less than eight, let’s say… They’ll actually get an email inviting them to a call with a product manager to talk through how we can make the product better. And they’ll just have a link to the shared calendar. So then, the idea is that your product managers show up on Monday morning and they see their slots are already filled with customer calls. That just ensures that they’re regularly talking to customers across the broad spectrum of the product. And then as they dig into, say a specific problem they’re trying to solve they can go into Gainsight, Salesforce all the tools that we use that have tags and sort of conversations linked. And they can read through those conversations and reach out to specific customers who maybe have talked about this one problem before and invite them to have a call. Victor [25:17] Do you use any specific in-product analytics tools? Kyle Racki [25:22] We use a number of them, primarily segment is what’s used. And then there’s different tools like Mode and others, on which we can run different types of reports on. I’d say probably the most useful is Gainsight and PX currently, because then that gives us the really the one central place for product managers to go. So, they can see not only the conversations between the CSM and the account, but also like, what is their NPS? And what is their MRR group? What kind of features are they using? What do they have turned on in their account? All that information is in Gainsight. Victor [26:01] And that’s very interesting. So, as I understand the development process or the overall decision-making process is from setting objectives and key results within the teams. They themselves understand how to tackle that problem and reach that goal. And if you move one level lower into actual tasks, at that point, you do get into concrete features and issues. Do you do work in sprints? Kyle Racki [26:37] Yeah, exactly. So, the actual development process is agile. And I think, it’s always debatable how agile but I think the goal is to get as agile as possible. So that you’ve got your sprint planning your retros, your sprint goals. You know, there’s daily stand ups with the Scrum Master, all that kind of stuff is in place. But essentially, on the product side, they’re living most of their time in discovery mode. So, they’re kind of always talking to customers, always showing them ideas, always validating assumptions involving their team in those conversations, inviting them to the calls and whatnot. But then essentially, when it’s ready to build like, okay, we’ve taken this thing, we understand the customer problem, we know they’re going to buy it, or they value the solution. We know there’s no serious risks to the business that helpers feel comfortable about the technical approach. They’ve maybe validated some technical uncertainties upfront.  We’ve actually even tested the prototype. So, we know customers can figure it out. It’s user friendly. Well, then at that point is ready for delivery mode, where it’s like sprint planning, how are we going? What’s the end goal look like? But then what are the Sprint’s along the way, where we’re going to measure something small contained to production. Make sure that it plays well with the other code. So that it’s stable on the release.  Victor [28:04] And you mentioned prototypes to test before you even develop, what do you use for prototyping? How do you do those? Kyle Racki [28:14] You know, it’s a really interesting question. We’ve been talking about this lately is that prototype can mean many different things. And everybody has their own interpretation, the way I like to think about it is like prototypes is your tool belt, and you’ve got many different tools in there. And it’s about kind of picking the right one for the job.  So, if you’re really concerned at the moment with just like, hey, do customers even care about this thing that we’re trying to build? You know, your prototype could be a keynote, it could be a sketch on paper, it could be a wireframe… Invision has that freehand tool. Lots of different ways to just get some sketched boxes in front of a customer to just say, like, this is what we’re thinking, do you think we’re on the right track? Would you use this thing? But then when you get into like usability, then you probably want a clickable prototype using Invision or Marvel which all the cool kids are using I guess now. But then you can also get into technical prototypes.  So those ones obviously take longer to build and you want to be judicious about how you use development resources. But if the developers are like, “Look, we’ve never even looked at this type of technology before. We’re not good. Don’t ask us for story points or t-shirt sizes. We have no idea what we’re even building”. Then take a couple of days and just throw away code. This isn’t an actual production ready product we’re trying to build. We’re just trying to validate assumptions and see how it works so that the developers can go “Okay, we went down a few roads that were like false starts, but I think we have a pretty clear idea”. So there are tons of different tool for the job Victor [30:01] Maybe even as a proof of concept once you put developers on it, right, is that like, what kind of roadblocks do we have on the technical side is probably where you would throw developers at a prototype, an API you’ve never integrated before or technology you’ve never used, right? That’s probably the best use of their time here. Kyle Racki [30:25] Well and also architecture panel, that’s something that I’ve got established within the last 12 months is our engineering team has an architecture panel. So, if there is something if there’s an idea that we want to test out the engineer on the team can look at it and say “This has major implications to our whole how we build things, I’m going to take this to the panel”.  And there’s that process in place so that the engineering panel or the architecture panel can look at it and come up with a proposed approach to how to actually build the underlying architecture behind it. So that’s one of the ways to do that. Victor [31:01] Do you have something like that for design as well? How’d you decide on the actual UI design or is it not that important? Because at that point, you already have the wireframes and everything figured out? And you have a brand guide of course, or how does that play in there? Kyle Racki [31:22] Well, the designer on the squad would primarily be tasked with coming up with a visual solution to the problem. So, in most cases, you can leave it to the squad to figure out how that design is going to work. And the designer is going to collaborate and work with other designers across the squad to sort of show them ideas and get feedback and whatnot. But we are actually in the process of hiring a design director. That’s sort of the goal of that hire is that the person is going to come in and help establish that cohesive, higher level plan behind the product design. Victor [31:58] That makes sense. And now is the last question really, just out of interest to see what’s out there and what’s being used. What’s the tech stack behind your product? Kyle Racki [32:12] So, we are still on PHP for the backend, we use CodeIgniter as the framework. And we use essentially JavaScript for most of the front end. There’s a custom written framework that was built for that. But yeah, I mean, other than that, it’s the typical kind of stuff, Bootstrap and jQuery for certain things we use. A lot of the work lately has been on the Salesforce side. So, we have a developer who writes in Java and builds within that Salesforce AppExchange sort of framework. But yeah, I think where the Dev team is going is more of like the API first approach. I think there’s probably plans to move out of CodeIgniter to something else. And I think the real future of where they want to take things is with microservices and have a very segmented architecture, but I’m sort of speaking out of turn now, because that’s not my domain of expertise. Victor [33:13] Of course. Since you’ve been around for 10 years now, and not many SaaS applications actually have had a product this long on the market. Do you feel feedback from the engineering team, that there’s something getting too old, or that some technologies are not up to date anymore, or even maybe, since we have a market that we have that some engineers don’t want to work on a 10-year-old codebase or anything like that? Kyle Racki [33:46] The way I’ve seen it evolve is that it’s almost kind of the mark of a more established senior engineering leader, like a VP or a CTO is that when developers are less experienced, I find them often wanting to go the route of rebuild, and retool, and especially use the latest greatest framework. But I think as you see, the more seasoned engineering leaders grow and emerge, it’s much more about iterative improvement. And we kind of liken it to rebuilding the foundation of the house while there’s a party going on and not interrupting the party because the last thing that anybody wants to do is tear down and rebuild from scratch and then deal with migrations, and we’ve been down those roads before, and we’ve made a lot of fumbles. But essentially, it always sounds great on paper. Oh, it’s just easier to start over again, with a whole new framework and like the world’s your oyster, you can do whatever you want. You’re not hampered by legacy but in practice, it always turns into a shit show. Victor [34:48] Awesome and on that note, what’s coming next for Proposify, what’s the next big thing? Kyle Racki [34:57] I think in terms of the product, where we’re getting with it is, we’re very focused around helping sales leaders and sales teams at SaaS, especially Sales Tech Companies. And to do that, we’re working towards building an extremely tight Salesforce integration with managed packages and other integrations with HubSpot primarily. And then the core web app is just going way more down the road of control and visibility into the sales process.  There’s a really cool thing we’re experimenting with now, which hasn’t been announced but it’s essentially like a real time analytics engine so that you could actually watch a replay of somebody who’s reading your proposal. The people we’ve shown it to are pretty excited about. A lot of tools like our competitors and us ourselves will show you the sections that customers view and how long they’re on it, but being able to actually see a visual replay of their session, which is actually not even recording anyone’s screen. It’s just recreating it all from the data. Victor [36:08] It is like a hot jar for proposals. Nice. Awesome. So where can people find out more about you and connect? Kyle Racki [36:19] I’m fairly active on LinkedIn, if they look at Kyle Racki. R-A-C-K-I. They can connect with me on LinkedIn. Otherwise, the product is Proposify.com.  Victor [36:31] You have got .com lately, or it’s been a while already probably? Kyle Racki [36:37] A couple of years, maybe two or three years, we have the .com. I finally tracked down the owner and negotiated. Victor [36:43] Awesome. Well, thank you so much for being on here. I think there was a ton of useful tips and advice on scaling a company on the product side. Thanks for being on the show. Kyle Racki [36:57] My pleasure. Thanks for having me.  

Summary Learn how Salesflare is taking on big competitors with a limited development budget, smart prioritization, and a strong core product team. Also, learn more about the Google vetting process they had to undertake to have access to people’s emails. Let’s get into it! Episode Victor:  Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, software development, remote work, and everything else that technical, as well as non-technical founders need to know to launch and scale successful software products. Today’s guest is Jeroen Corthout, co-founder of Salesflare, and we want to find out how he’s built a CRM that competes with the big brands. Jeroen, welcome to the show. Great to have you.    Jeroen: Yeah, thank you. Happy to be here.    Victor: You’re a non-technical founder and I’m getting this question all the time. How did you find your technical co-founder, your current counterpart here in this venture?     Jeroen: Yeah, I’m half non-technical.   Victor: So what’s your part? Where do you see yourself and what were you looking at in a co-founder?     Jeroen: Yeah, so I indeed studied engineering myself, so it’s not like I don’t understand what happens in all that, which is an advantage when working with the technical team. But I’m not a coder so indeed I always need someone to take up the lead on the development side. With my co-founder we just met each other in the founder Institute. I was in there with a startup idea I had, and he was in there and we were in the same group. We had to help each other a lot. We enjoyed that, and had a lot of good conversations. I was on the way to work in my car and we would be calling and then go to our day jobs and then afterwards calling in to figure out what we’re going to do.   We lost touch for a while. And one day he calls me and he says: “I’m going to Vegas with my company (he had a startup company) and we need a sales guy. Do you want to join?”. And we did that. We had all the fun together. I started collaborating with him on his company and it’s from there out of frustrations we had with managing our sales pipeline that we decided to start Salesflare. So I didn’t go out and look for a technical co-founder, it just happened.  Actually at some point when I had another startup company, I was looking for a technical co-founder. It can be very difficult because you basically need to find someone who you want to work with, first of all. But secondly, also you need to convince that person that you’re onto something. And when you came up with it alone, that’s much harder than when you come up with something together.     Victor: That makes perfect sense, actually. When it comes to Salesflare, you already mentioned you were looking to manage your sales pipeline and you find a tool that does exactly what you want. Can you tell us a bit about what Salesflare is and who it caters to?    Jeroen:  Yeah. So Salesflare is a CRM (customer relationship management software). It’s more of a sales CRM, so focused much more on the essence of the customer relationship in many cases. In essence, a company  builds a product or provides a service, and then it’s sold. Especially in B2B sales. So we focus on that sales relationship. And what it does – if you think about it very practically, it helps companies to follow up their leads. From the moment they meet the lead, or they have a lead, towards closing that deal. And then also often afterwards, like following up that customer relationship after the sale. We focus on small and medium sized companies, not on the big ones that need something enterprisey like Salesforce or SAP or so, because these companies need a completely different tool.   They need something that adapts to their company. An army of consultants come to set up a system fully custom made. It’s when you buy building blocks and then the guy starts building. We built something that comes out of the box, that is really easy to set up. We’re actually the number one most implementable CRM on g2.com. So it’s really easy, you just connect your mailbox, start working and all that.  Where we distinguish ourselves from other CRMs like HubSpot and PipeDrive is that we built our software from the ground up for automated data inputs. We saw that there’s a lot of very nice software tools out there, but they create this false expectation.   Somehow they are built on the premise that sales people are going to be this insanely disciplined group of people. Everything they do, they put into a system while they do it. They email someone and then they put that in the system and then calls someone and then somehow they meet someone and they have this trigger in their head that says: “I need to put this person in CRM”. That person passes their phone number. They think like “Oh my God. Now I need to put that phone number in the CRM.” And they’re so focused on the CRM, that in the end, this CRM, is this perfect database on which they can fall back, to do their sales follow up, manage customer relationships, and never forget anyone. It becomes a second brain almost, but they’re so focused on that CRM that it works.   The problem is if they’re not that focused on the CRM, it doesn’t work at some point. It falls apart because somehow you forget to put some stuff in there. And when all that data isn’t there, it’s not qualitative. The system just starts falling apart. At some point we were working on sales follow ups for the company I went to help Lieven with.We had a lot of leads from a conference and we had to follow those up at scale. We were looking for a system for ourselves, trying different CRMs but we always noticed that we just couldn’t keep it up to date properly. After that we started tinkering and we figured that actually most of the things we were inputting were already available somewhere else digitally.   And we figured why don’t we just pull these things together? We just connect with the mailbox. We pull out of there emails, the email signatures, the contacts themselves, how often you’re in touch with them, what are the relationship strengths? So many things you can pull out of a mailbox. Then we’ll add a calendar, call history which is in your phone, social media and all kinds of databases out there that we could integrate into this. Also web tracking and email tracking. We saw this whole system, which will basically track all customer information, but also all touch points you have with customers automatically based on the information that’s already there. I think that we are still the only CRM system that is built with that in mind first. Many other CRM systems started syncing information to automate some stuff, but they’re not built with automated data inputs as the first thing in mind. So if you use the software, you’ll see that the flows are very much manual data input with some syncing in, but we use the opposite approach.     Victor: CRM in general is already not a simple micro SaaS to build. And especially with that in mind, that sounds like quite a big project. How did you go about really deciding the minimum feature set and building something to test out that must’ve been tough?    Jeroen: That was tough. I must say we built sort of MVP but it was very far like a minimum viable product, which was very, very far from a minimum sellable product and even much further from a minimum lovable product. Our MVP was basically a plugin you had in Gmail and outlook, which would show you all the emails you were exchanging with a specific company next to your emails. And people wouldn’t really understand what the value wasn’t such a thing. And they were like “I have emails on the left, why do I need emails on the right as well?”. But they didn’t see our complete vision which was that everything was going to end up there and the thing was going to automatically keep itself up to date and make sure that you always knew what was going on. So people didn’t get our very first version. It took us three months to create that minimum viable product. It probably took us another three months to even convince one other person than myself to use it actively. And it took us another seven-eight months from there to sell it the first time.   Victor: How did you go about distributing it to people, about getting feedback? Enough feedback to really understand how, what should we do with it from there.   Jeroen:  It was all about, and it still is very much about having very close customer relationships. We did not do any significant marketing, back in the day. What we would do is try to get attention in the press here and there, with which we would get bursts of attention, bursts of leads to add to our pipeline. I would do a lot of customer interviews, to really understand what software people were using, what was wrong with it? What were they trying to do in sales? What couldn’t they do? Then when we had leads, I would take them all the way. I would show them what we built, I would install it for them, because you have to connect your emails and it was very hard at first.  You have to connect your G-mail inbox to IMF, for instance, and open up some security settings here and there. Nowadays it’s just one click and it all works. Then I would set it up together with them, make sure it all worked properly, show them around, did the support. At every step, like every single thing I would do with them, I would be like: “Oh my God, this is not working properly yet.” Then people would ask a question in some direction and every single time that I was in touch with customers, I had a list of stuff in my notepad, to go back to the development team, put it in GitHub,and start tracking stuff, start prioritizing, and start fixing.     Victor: Do you think that was actually a good thing that you were so in touch or that your customers had to get so much in touch with you to even set it up? Or would that have been way easier if you just integrated with the Gmail API, so to speak directly right from the start?     Jeroen: Uh, no. I mean, connecting to the Gmail API would maybe have been a better idea. That’s another thing, but staying close to customers, I still believe that’s something we need to do very actively. It’s when you sort of lose touch with customers, that it becomes much harder to build something valuable, knowing what little things are wrong with your product. Very often customers, especially the ones, who pay a lot of money are not going to tell you what’s wrong with your product. They just think up work arounds and all that. It’s only when you’re really in touch with them that they might tell you. So we find that really, really important. And especially in the early stages, I can only recommend going that way, because if you immediately make your SaaS software available freely to the public and everybody just signs up and then immediately turns from the trial and you don’t know why, the only thing you can rely on is Hotjar videos and, and a survey here and there.   It’s going to take an enormous amount of time to figure out how to best build the product. While if you’re actually in touch with people, you can talk to them, they send you pages of feedback after you’re together, you see things happening because you’re there with them. That’s when you can create the quickest improvement product-wise and I think it’s also one of the only ways in which we can really, really compete with these giant companies out there. It’s being closer to customers because what happens inevitably in these larger companies is that they start building barriers between them and the customer. And these barriers can be simple. That could be a newly hired customer service agent who has no idea what the product is about, which is a very effective barrier. With this terrible customer support you don’t learn anything about the customer because the dialogue is just impossible. There is no proper link between customer and product. That’s what we’re trying to avoid very much. We give a lot of importance to being close to customers. Because of that we can improve our product more, have a better product, and also know where we want to go with the product.     Victor:  And you also mentioned that you launched on AppSumo, one day. Did that improve customer feedback even more? Did that give you more exposure? Was that valuable for you?     Jeroen: That was an enormous help when it comes to customer feedback. When you talk to people who have launched on AppSumo or wanted to but didn’t, you’ll very often hear that people on AppSumo don’t pay anything and expect the world. It’s sort of true, but the flip side of the coin is that you finally have people who want to give you feedback, or they bought into your product and basically they decided that whatever it is they need, the product that they bought will adapt to their needs and they will give you all the feedback. So you just have to let them say it, write it down, track it well, and you have a huge volume of feedback.   Now the only pitfall there is that you start confusing the needs of the AppSumo audience with the needs of your larger customers or the customers within the direction you want to take the company audience. So that’s something you need to watch out and track it well. But apart from that, every little thing that could go wrong with your product, you will have heard it if you have an AppSumo audience on your product, because they’re just so much more engaged than the people who actually pay you.     Victor: Jeroen, we’ve been talking so much about your early days. How long has that been since you launched initially ?   Jeroen: Our very initial MVP, almost six years ago.     Victor: Wow. That’s, that’s been a while. So fast forward to today, what’s your team set up and team size right now?   Jeroen: That we are a team of seven, we’ve kept it stable over the past two years, because we want to grow our revenue a bit quicker. Surpassing the team size and growing a team also comes with its own issues. Like the one with the customer service agents that I just mentioned. If you grow too quickly then you have people on your team who don’t really know everything deeply and that makes the quality go down. So that’s also a reason for us to take it a little bit slower. But we have over 2000 companies now actively using the software. And we serve those with this team. The team is made up of my co-founder, who is mostly working on development things, not developing himself, mostly, development related things to get to with three developers. And then there is me mostly working on marketing, there’s Curie, mostly working on partnerships and Taylor, mostly taking care of customers.     Victor: Awesome. And so you have three developers, your co-founder, who’s like a product manager or CTO development manager. Do you have a designer in-house as well?     Jeroen: No. We had someone, who externally made the designs for both the website and the app. And for the past few years we’ve been building from that blueprints further and further, we also use Google material design. We very often follow the rules of Google material design to figure out our designs, and we work further on things we already have to make sure everything stays consistent. So we haven’t really been in need of a designer over the past few years. At some point we might do a redesign though, and then we’ll get someone again, but we definitely don’t have the need to employ someone internally.     Victor: And what’s your structure? Are you remotely, or are you in an office? What’s your philosophy here?     Jeroen: We are usually in an office. But for the past nine months we have been working fully remotely. We have seen each other, I think, once in a bar and another time in a bar. But we have not seen each other in a work setting, just due to COVID. It wasn’t a huge jump for us to go remote because we were already remote with our customers. They’re all over the world. So there was no switch, we already had everything digitally. Our communication was running anyway through Slack. It was just mainly the meetings that we had to take online and sort of systematize the communication we have between that. We were somehow relying a bit on being in the same room and you have the sort of natural/accidental communication going on when you’re in the same office. We have to make things way more systematic. Despite all being in our own homes, we all know exactly what everyone is working on, what the latest things are decided and all those kinds of things. Actually I wrote a blog post about that if you’re interested.     Victor:  Absolutely. We’ll definitely link that up. And how did you manage to do more creative tasks? People are always saying that brainstorming, deciding on strategies and our directions to take that’s the hardest to do remotely. How did you find a way to replace that more or less, or was that the bar meeting?     Jeroen:  No, the bar meeting was just meeting each other and not about work. The way we usually attack that is, we very well define first together what the goal is, what we are going to brainstorm and why, what do we want to achieve? Then everybody does some brainstorming over the period of a week or maybe two weeks, you can get some ideas, you write them down, you make a list for yourself. We come together. We explained to each other what the ideas were that we came up with, we grouped them together in one list. And then from there, when everybody has explained very well what it is ( not just showing the list together without explanation) we go into a process where we give them scores. Everybody can, for instance, choose the top three, depending on what we are doing. And then they get a score three, two, and one, for instance (we don’t have a standardized process for it). And now we see what comes up with the highest scores, more as a piece of information, rather than really having that fully defined the decision. It’s always just the model, but the model can be the decision maker. You can still have a discussion about it afterwards.   Victor: Moving into more of your development. How do you decide on new features or how to document them? What do you use to track your software development within your three, four people, product team? What works best for you in this setting?     Jeroen: Yeah. Our product team is actually broader than just the developers. Actually our product team is made up of myself, sort of the product owner, Lieven, my co-founder is sort of scrum master, CTO. Then we have one of the developers, the one who’s been with us the longest and knows product’s in and out, he’s also in the meetings to sort of represent the technical side of things. Then we have our Taylor in the meetings who takes care of customers and Gary who used to take care of customers. So I have a product team of five and what we do, we have different meetings, which we run through different aspects of the product development. Let me first explain to you where we track stuff.     So we work in Intercom for our customer conversations, like all the support related stuff runs through there. A lot of the sales related stuff as well. And every time somebody says something that constitutes feedback in any form, then we log that in GitHub with the name of the person, name of the company, what they specifically said and a link to the Intercom conversation as a comment to an issue. And that issue is something that is wrong or can be better in a product. We generally have three types:   features – whole new functionality.  improvements –  functionality that needs some sort of improvements.  actual bugs – things that are broken. Like we built something and somehow it doesn’t do a certain thing, which you envisioned it would do.   This second group, by the way, we brought to life, because at some point we just had bugs and features, and there was this space in between like product improvements.   It just all fell down into a nondescript bucket. And it was very hard to improve on the product. Once we did that, we saw our product improving very fast and both for the bugs and your improvements we have a priority system which currently is urgent, high, medium, low, and also instances when something needs to be fixed instantly. For the features we do a much more elaborate scoring exercise because there are much bigger things we need to decide on. What we currently have in that scoring system is how well does it align with our product vision of where we want to go with the product. And then to a whole set of scores that define the impact in all parts of our funnel. These would be: what is the impact going to be on the amount of trials we get?  What is the impact going to be on how many trials turn into paid customers? What is the impact on how many people stay with us? What is the impact on our support levels? How much support do we need to deliver? We give all those scores and then we have this formula that calculates what the business impact is going to be together with the vision alignment. That’s somehow built in there as well.  We do this with all the features that reach a certain threshold of popularity. So we can focus on the right ones that are often asked. We also have a series of processes to keep prioritization and planning alive. I’m not going to go into all the details, but it’s really a running machine. As soon as things go live, we close the issue. What happens is that the Intercom conversation with everyone who asked for its open up again, and we can personally tell people that the thing went live, whether it’s a bug or an improvement or a feature, it doesn’t matter. We also ask for feedback, like “Hey, what do you think about what we did now?”. So that we can keep closing that loop. Finally we’ve just started using Acute which is also very interesting because it sort of makes the mapping for us now between Intercom and GitHub. It enables us, for instance, in Intercom to see what things people have asked in the past and also to add feedback very easily from Intercom.   But we’re still sort of figuring out how that would work best in terms of tools for feature planning. We use Trello, but we’re currently actually looking to see whether it is something that could provide us with a better overview. We work with this kind of feature stories as small as possible, which would turn into Trello cards and then people work on them through the development pipeline. But it’s sometimes hard to know when things are going to land and what we’re exactly working on, how long it took. So we’re looking whether there’s anything better there, if you have any suggestions, very welcome.     Victor: We’re actually going to be interviewing Joanna Bastow from ProdPad on the show. And that could be an interesting tool. I’m just going to tease her it right now for prioritizing features depending on customer feedback. But I think we’re going to do a more in-depth rundown of that on a separate show. But that was a super interesting insight, especially on how you use the GitHub issues and how you connect that with Intercom, which is probably very useful and efficient to manage that customer feedback. Do your prioritization in a spreadsheet or where do you do that ?   Jeroen:  We give things labels. At least for all of the bugs and improvements. Features are in a spreadsheet because that’s a more elaborate model, but it’s a small set of features really like big things that we’re working on and that we prioritize there.     Victor: Interesting. Just to quickly mention it for completeness, what is your technology stack?     Jeroen: It’s a full JavaScript. In the backend we use nodes and in the front end we use angular and it’s built on Google clouds. Mostly MySQL and all kinds of compute engines, autoscaling.     Victor: There’s one, one last thing that I want to touch on, because I know that you’ve gone through that. And I know that probably a lot of founders out there have been facing this issue recently, which is the Google security review. So that’s something that Google imposed on people using or having access to, sensitive data on Google using their API. Is that correct? Did I understand that right?    Jeroen: Yeah. That’s when you access sensitive scopes on the Google API, really sensitive Google user data that you’re extracting such as yes reading emails, you have to go through a security review. First you need to answer some basic stuff to Google, and then you basically get three security companies to choose from. Two of them based in the US, one has a European seat as well. You fill out a very long questionnaire for them, first to make a quote, and then they quote you and it’s extremely expensive. When you’ve chosen one, then you go through a whole security questionnaire thing again, to check off a lot of different things. And then they start doing all kinds of testing as well.   I don’t know all those things, but things like penetration, testing and all of that. We went through that last year with Bishop Fox. We didn’t have a lot of issues thanks God, because we just did it before the deadline. This year we need to go through it again, and we’re going to do the NCC. It’s going to be thankfully much cheaper than last year but still it’s a pain. Every year it costs you tens of thousands to go through this. Honestly, I don’t think it’s a huge value add if you have your security down. The security companies are not going to like hearing this, but we got much more value from the “security researchers”. We were also asked by Google to have a vulnerability disclosure program, where when people disclose vulnerabilities to us, they get a bounty. They have so much more than the security companies. We’ve been able to fix all these things, which is amazing. The security companies had low informational issues for us. And then still afterwards some guys all over the world, they just start testing and they find so many more things.    Victor: That must be very interesting to go through. You’re suddenly on the plate for so many people to be tested. So congratulations on living with that. That actually is something you can put on your site as you’re actually thoroughly tested, not just we’re thoroughly tested. That’s a great thing. Well, thank you so much for your time and the super interesting interview on how you’re building a CRM that really goes against the big brands. Where can people find you, find out more about Salesflare and learn more about you?     Jeroen: Yeah. If you want to find out more about Salesflare, or you can add to salesflare.com, you can read out all about the software. You can also try it. We give a trial, which is anywhere between seven and 30 days, or even more if you add a lot of people. We give you extra days on the trial, as you set it up further, because we see that people who actually properly set it up during the trial are way more successful. And so definitely try that and you’ll know whether it’s for you or not. If you want to get in touch with me, you can do that on LinkedIn. But please do include a personal message, that says that you’ve heard this chat on the Product Stories podcast, because otherwise you will end up in the sea of spam I get everyday.   Victor: Wonderful. All right, thank you so much for being on the show and have a good one. Thank you. It was fun.   

Summary How has Craig vetted and acquired a SaaS company as a non-technical founder? How has he embedded it within his existing productized service business? And what is the ShapeUp development methodology which he uses within his remote team? Find out on today’s show! Listen to the episode or read the transcript below. Episode Victor [00:00] Welcome to Product Stories where we explore how Founders build successful software products. This is a podcast about product management, development, remote work, and everything else non-technical as well as technical. Founders need to know to launch and scale software products. Today’s guest is Craig Hewitt, founder of podcast motor, which is just merged with his podcast hosting platform Castos. Craig, welcome to the show. Great to have you. Craig [00:25] Hey, Victor. Thanks for having me. Victor [00:27] Craig, so, you’re a non-technical founder. Is that right? Craig [00:31] That’s right. Yep. Victor [00:33] And so how have you ended up running a very successful SaaS business? Craig [00:39] Yeah, so I’d like to say I kind of backed into running a SaaS business so like my first foray into a kind of online business, as you mentioned, was podcast motor. So, a product I service that does podcast editing and production, and ran that for about four or five years. And in the course of that one of our podcast motor customers actually introduced me to a fella named Hugh Lash brook, who was the kind of original creator of the seriously simple podcasting WordPress plugin. He had taken a job at automatic and wanted to sell the plugin to someone who would take good care of it. And so, we bought the plugin and built the Castos platform, kind of on top of that, so we have a freemium model that Costos where the WordPress plugin is free, anybody can use it to host their and host their podcast files, wherever one of the options to host your files is with casters, and it’s really tightly integrated there to make kind of managing your podcast from WordPress, really easy. Victor [01:38] And at the same time, you’re still running your product I service which allows people done for you editing of your podcast shows is that right? Craig [01:47] Yep, that’s exactly right. Victor [01:49] Perfect. How did you go about vetting that plugin, so you’re being made aware by referral of a great WordPress plugin out there, you could buy, it fits your business, it fits your customer base, you can acquire more customers through it? What did you do? How did you decide to actually buy it? Craig [02:09] Yeah, so I think reflecting on it now; like a big part of it was the person that introduced me, Brad to Nord from delicious brains. So, folks in the WordPress world probably know of Brad and their business. And he’s just a really high quality, really good person in that space. So, like him saying, “Hey, you probably ought to check this out” was a big nod and kind of vote of confidence. And then from there probably didn’t do as much due diligence I should have but the plugin had a lot of good reviews and wordpress.org. So that kind of social proof. And maybe other folks doing some due diligence for me, was part of that nine, install the plugin and gave it a whirl and it worked great, and kind of just went from there. Victor [02:53] Wonderful. And so fast forward to today, basically, what’s your company setup now? What’s your team size? How many people do you have on board? Craig [03:05] Yeah, so we’re eight people full time now. Three developers, and I’m kind of the product lead, person that aggregates a lot of feedback from different places. You know, we have a product feedback board where customers and people using the plugin can go and suggest and upvote things. We obviously have like support channels that give input into the product; I have things that I want to build. So that’s what the product team looks like. Victor [03:35] Wonderful. Are you guys in an office or you are remote? How does that look? Craig [03:40] Yeah, we’ve always been remote. Victor [03:42] Where are you based? Where’s your team based? Craig [03:45] So, I live in France, so about 30 kilometers south of Geneva. And then we have folks a bit all over. So, we have developer in Montenegro. We have a developer in Cape Town, South Africa, we have our third developers in upstate New York. And then Success and Support and marketing are all kind of on the east coast in the US. Victor [04:05] Did you even decide for geography or was that all based on the people who applied? Craig [04:13] Yeah, it’s all based on the people. It’s all based on the people. But I like that we have kind of buckets. We have this kind of European time zone bucket. So, myself, and our two developers here are on the same time zone. And then in the US, they’re all in the same time zone. I think that kind of congruency is important, even if you’re not all in the same time zone for groups of you to be in the same time zone makes it a lot easier to communicate synchronously. Victor [04:44] Is there any time zone that would have been too far or wouldn’t that better? Craig [04:51] Yeah, I think especially early on in a business where you’re not as organized and not as good at documenting and have processes around things that like, for us, you know, someone living in the West Coast, or some places in Asia, probably where it would be 789 hours difference for me is just too much because like, I have family and kids, and I don’t want to be working eight o’clock at night all the time. And I don’t want to ask people to do the same thing. Victor [05:18] So even if people are well; somewhat close to you, but then further apart from each other, so to speak, people left and right, geographically more east more to the west, you end up being a bit of a micromanager or a bridge in between people. How’s that working? Craig [05:37] Yeah, I try very hard not to be. And I think that that’s an easy trap for people to fall into. Maybe even more so for non-technical founders, because we don’t understand a lot of what is going on. And we feel like we need to understand and have our hands on a bunch of things to have the confidence that that everything is going the right direction. And it’s something I’ve worked a lot on to say like, “I don’t need to be involved in every conversation, I needed to enable the leaders in our company to own the process and the outcome of the things that we’re doing”. And it’s a continuum; where maybe a third of the way there but yeah, we’re getting better at it. Victor [06:19] And how did you find your first and the subsequent developers. You have three, you said? Craig [06:24] Yeah, so Jonathan Bossinger, our first and lead developer was a recommendation from Hugh, the fella that built the plugin, they know each other, they’re both in Cape Town. So, Jonathan was just recommendation, and that’s worked out brilliantly. Danilo our second developer, we started, we hired him from Upwork. And kind of started on a project basis, we wanted to build like this admin panel. So that was a really kind of concise, boxed piece of functionality that we wanted to build. And it was a nice way to kind of start on a trial with somebody on not full time at all. So, both from like a risk perspective, and a financial perspective was easier. And then our third developer who hired about three months ago; placed an ad and we work remotely. And that’s where he came from. And that process was intended for him to be, you know, to come from outside of our kind of sphere. And to be a full time hire right off the bat. Victor [07:24] Did you also do a concise test project with him or not anymore? Craig 07:29 Yeah. So, our process that we did with him with our latest hire, we really like and we’re running it again, now we’re hiring a fourth developer. And we’re doing test projects. And now even we’re doing them as like the first step after the application. So, we have the application and people fill it in, I kind of filter and then pick the people that I think have really good potential, and then send them a test project; we have test project for Laravel, we have test project for WordPress, depending on where someone’s background is. And that’s really the first way they interact with us. And it should take a couple of hours for somebody to do. And the goal there is really to get kind of the hard data on how somebody works, what their code looks like, how well it’s documented, what their commit messages are, and how often they commit all these kinds of work and workflow things around some a developer because like writing code, as I’m coming to learn is like just a piece of it, but how they communicate and how they work with the rest of the team is super important. We’re parsing that out earlier now. Victor [08:32] What else have you learned over the past years working with developer’s day in day out? Craig [08:39] Yeah, a lot. I mean, it’s been a huge progression from with Jonathan. Starting out, literally, we had just this enormous Google Doc, and a bunch of chats and slack. And I think that’s not wrong, when you’re just starting out. Like I think people definitely can over optimize a development process. But as we got a second person, that definitely broke a lot of how we worked. And now we have a third person that’s in a different time zone. And so that’s broken a lot of how we work. But the biggest thing has been because I’m not by nature, a really organized person, the biggest thing has been to be very clear about what I want to build. So that they can go and kind of implement it successfully on their end, because otherwise, like I’m ambiguous, I say, just like a one liner, it’s like, hey, let’s go build a login page, or an admin panel. And they go build it. And they make a bunch of assumptions that when they come back and say, “Hey, it’s done, you can test it”. I say, “This is wrong, this is wrong, this is wrong, this button’s wrong color”. And that’s just like; they end up doing twice as much work. So, we’ve done a lot around kind of our product process and how I take what’s in my head and put it in a quote on paper for them to be able to go and run with. Victor [09:57] So, what was your biggest win here in that process, what addition did you make to your product process that made the biggest impact on clarity? Craig [10:08] Yeah, I think the single biggest thing has been working with a designer, because they are able to literally help me take what’s in my mind and put it in something that developers can see and understand. So, Francoise, our designer, and I talked through, you know, just like in a zoom call, what I want to build, he asked a bunch of really good questions about UX, and kind of technical considerations. And then he goes and builds the mock ups and prototypes and Figma. And then the developers then can take that and say, totally understand, like, this is what this is, and this is how this interacts, and they can go build it and get us a lot closer to quote right the first time. Victor [10:50] And at the same time, just as you said, you can also overdo documentation, you can overdo detailed descriptions. I know that from a lot of especially technical product managers who even try to do some of the developers’ job and defining data structures defining pages of acceptance criteria, what can or cannot go into a form field. And that’s probably right, in a lot of points, but maybe not in a very lean startup environment. So, you’ve said to me before, “That you’re trying to follow something that’s called the shape up methodology”. Can you give a super quick overview over what that is and where it’s coming from? Craig [11:32] Yeah, so shape up is a book by the folks at Basecamp, that talks about kind of how they do a product process. And part of it is from a kind of timing perspective, they work in kind of eight-week buckets, where six weeks of that is on where they’re actively developing things. And two weeks of it is off, where developers have some downtime and time to focus on refactoring, doing tests, updating, libraries, things like that. You know, like we say, they’re not really moving the prod product and project forward, specifically, but that they allow the developers to then go be successful and focus on building features and squashing bugs in those on cycles. Craig [12:14] So yeah, we’re six weeks on two weeks off, roughly, here, like at the end of the year, that that gets extended a little bit to accommodate just regular calendar stuff. But the idea really, is that you don’t define too strictly what you want to build right at the beginning, but you kind of shake it up. It is like a ball of Plato, you put it into a ball, and then you do a little bit of molding on it and take a look and say, is this really what I want? You might go back, but you try to as loosely as you can define what you want. And then ask a lot of questions about like, Am I really trying to make a ball or am I trying to make a a box, right? And kind of asking yourself a lot of questions about specifically what am I trying to build and it is kind of this path we’re going down getting us there is another. Is there another more creative or minimalistic path that we can take that achieves the same thing for the customer. Victor [13:15] So essentially, it’s about giving a lot of context, enough context, just enough constraints to get going. But then about molding it together with a developer with their feedback, trying to get something done, and review that quickly. Right. So, we’ll definitely link up more about shape up as well, in the show notes. For concrete management, what do you use for managing issues and tickets? Craig [13:44] Yes, we use notion for almost everything. We use GitHub for actual bug issues, but are kind of proactive Project Management stuff is all in notion. Victor [13:56] Wonderful. Do you also work in like sprints or is it more of a Kanban board or how is your setup here? Craig [14:05] Yeah, so, each cycle, whether it’s like an on or an off cycle, it has its own board. And in that board, there’s like four or five columns. One of them is our backlog. So that’s where everything goes, everything we want to build, every idea we have goes in there. And then as we’re kind of starting a new cycle, we have kind of all hands team call to discuss what we’re going to have? What’s going to be included in that cycle, either an on or an off cycle. And we kind of pull things from the backlog into the pending columns, and then there’s pending and active and testing and reviewed and then deployed. So that’s how we manage it. And then at the end of the cycle, all of the leftover stuff in the backlog gets pulled to the next cycle so that we don’t forget it. Victor [14:49] So you mentioned this backlog, where you have everything you put in there all the ideas you have probably things that come from customers. How do you prioritize that, all these requests are your own ideas? Craig [15:04] Yeah, I mean, it’s like the epitome of compromise, right? It’s like, there are things that I think you have like from a business perspective, you have to say, “This is getting prioritized because the business needs this, we need this to be competitive or gain a competitive advantage”. And then there are things like, this is an edge case bug, or this could be optimized. And for me, as a non-technical person, this includes things like updating our Laravel version, updating our PHP version, which, like before, I would have said, this is just wasted time. And now I’m understanding. Okay, this is important for us to continue to move fast in the future. And I would put things like writing tests in there that like, we need to go back and refactor this thing and write a bunch of tests for it. That has to be allocated in an “On” or an “Off” cycle. Because it just helps us be successful going forward. Victor [16:01] Have you always been writing tests? Are these automated? Craig [16:05] Yeah, we’ve definitely not always been writing tests, we started about…. Gosh, maybe a year and a half ago. So, for definitely, a year and a half. We had no tests. And that was a mistake. Right? But we didn’t know. I didn’t know. And, you know, the developer didn’t know. So, if I had it to do over again, I would definitely write tests from the beginning, because I know it makes you go faster and with more confidence as the app gets bigger. But yeah, basically, now our policy kind of is; if you’re touching a piece of code that doesn’t have tests, it’s your responsibility to write tests for it. But we didn’t kind of go back and write tests for the whole product all at once. Victor [16:47] Nice. And what are the next steps for forecast those what’s on your roadmap, if there’s anything you can or want to publicly share? Craig [16:57] Yeah. So, I think that in the podcasting space, the big kind of trend and movement that we’re really excited about is around private podcasting. So, this idea that as opposed to this podcast, which you want everyone to listen to, there are a lot of scenarios for people to say. I only want specific people to have access to this podcast. And just a couple of examples for folks to think about is like you run a membership site, or you run a course, and you want to offer a podcast to those members or those students. And then increasingly…. You know, I’m a large organization, I want to have a podcast just for my employees on this team. And so, things like HR and corporate like C-Suite messaging sales teams are adopting internal company podcast and we have a lot of really cool tech around that. And so, a lot of interest and a lot of focus for us around private podcasting, and even paid access to private podcasts that we’re getting into. Victor [17:55] That’s super exciting. Where can people learn more about Castos and yourself? Craig [18:00] Yeah, so castos.com. C-A-S-T-O-S dot com is the place to go. And for myself, you want to reach out. I’m at Craighewitt.me, where I blog very occasionally, but you feel free to reach out, I’d love to chat. Victor [18:13] Thank you so much for being on the show. Craig [18:16] Thanks, Victor.