From prototype over MVP to scalable software – the right developers for every stage with Upile Chasowa from WorkClub

Product Stories
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.

Listen to other episodes!

Subscribe to the podcast newsletter

Subscribe to the podcast newsletter