Created with Sketch.
39 minutes | 9 days ago
From Prototype over MVP to Scalable Software – The Right Developers for Every Stage with Upile Chasowa from WorkClub
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.
30 minutes | 20 days ago
The dead-simple framework to estimate and plan anything within a startup with Anders Thue Pedersen from TimeBlock
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.
38 minutes | a month ago
Starting a SaaS company within an agency and scaling it to millions in ARR – with Kyle Racki from Proposify
38 minutes | a month ago
How Salesflare built a CRM to compete against the big brands – with Jeroen Corthout from Salesflare
18 minutes | a month ago
How to acquire a SaaS to boost your existing business – with Craig Hewitt from Castos
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.
Terms of Service
Do Not Sell My Personal Information
© Stitcher 2021