Show Notes
This is the first in a multi-part series that will explore the various stages of scaling a company using a hypothetical startup scenario inspired by ride-sharing services.
In this episode, Mon-Chaio and Andy discuss how to scale a tech startup from its inception stage. They reflect on past experiences, emphasizing the importance of validating market hypotheses before investing heavily in technology. Mon-Chaio and Andy guide listeners through early-stage startup strategies, including conducting market research, proving concepts with minimal tech investments, and maintaining operational efficiency.
References
Transcript
Mon-Chaio: We’re back, Andy, for another episode. And we are now into November, almost mid-November, actually. This autumn has gone by pretty fast for me.
Andy: Yeah, it kinda took us by surprise, didn’t it? ‘Cause last year, we wound up our year by trying to do a recap of what we’d been up to and give ourselves a little bit of extra space. And then this year we were talking about what do we do next? And we were like, oh, it’s time to think about that, isn’t it?
Mon-Chaio: And it kind of crept up on us. We were just thinking, well, what’s the next episode? What’s the next episode? And then it came to this time where we were like, well, then there’s Thanksgiving, then there’s the Christmas holidays. Oh, we’re out of time!
Andy: Yeah.
Mon-Chaio: If we’re going to do our end of the year holiday episode, as well as these recaps, it’s about time to do so. So, we’re not going to do a recap, but we’re going to do something different for the last few episodes at the end of the year. I think we calculated we have how many left? Six total or something, I believe?
Andy: I think six episodes and five will be this, and then we’ll have the mystery/surprise/holiday Christmas extravaganza.
Mon-Chaio: Right. And it’s a surprise to us, too.
Andy: We haven’t decided what it is yet.
Mon-Chaio: A couple episodes ago, I did a VacationCast based on a listener question. And the listener question was, to summarize it simply, you all talk about never scaling your tech companies because, in general, scaling doesn’t work. So what would you do if you had a company of say, 120 tech engineers? And as I mentioned briefly in the VacationCast episode, I started by thinking about how I was going to answer this question and then it became super, super long and so I had to really, really shorten it in the Vacation Cast and wasn’t able to really answer the question in the way that I wanted. I talked to Andy and we said, well, can we make a series where we answer that question? And I think we decided that we could.
So what we’re going to do in these next five episodes is run through a hypothetical scenario that is informed by a real scenario. And the scenario is it’s say 10 or 15 years ago and Uber hasn’t been invented yet. And you and a couple of friends have this hypothesis that taxis are pretty inefficient and can be disrupted through technology. So the three of you decide to build a startup to take advantage of this opportunity. Now we’re going to talk through the next five episodes about the hypothetical scaling of this startup from simply three people in a garage trying to prove an idea, all the way through this idea gets really big and the company grows and hires a bunch of people and takes on a bunch of other opportunities. And how does that look?
And we’re going to try to focus on it mostly from an operational perspective in terms of how are you structuring your company? How are you structuring your work? How are you thinking about how do you keep tabs on what each group or each person is working on, that sort of a thing. But we’re not going to be able to strictly keep it there, right Andy? Some of this is going to devolve into how do you prove product-market fit? How do you go about getting customers, that sort of thing. We are going to keep that part small though, because that’s one, not the biggest part of our expertise – I think we’re pretty good at it, but it’s not really the biggest part of expertise – and number two, I think for the TTL Podcast and for sort of our audience, probably the tech group scaling thing is the more interesting conversation for them to have.
Andy: Yeah. I think when we do touch on it, it will be because it’s important in how the tech group is structured and how it operates. And so, the way I think about it is, in tech, you can’t forget about what your product is, and so I think really strong technical people, tech leaders, should also really understand, what does it take to do the product side of it?
It’s maybe not your focus, but you’ll need to understand it, because it will inform, what’s the structure of a team you need? What’s the message you need to be giving them? What’s the current state of the product effort? What’s their strategy? How do you need to execute things? What matters and what doesn’t matter?
So that’s when we’ll get into it is we’ll probably … coming up with scenarios about what’s the company going through at this point and they’re doing this, okay, so this is what the tech team needs to do because of that.
Mon-Chaio: Absolutely. Yep. That’s exactly right. Okay, so Andy, let’s run through this, let’s take this example. So it’s these three folks in a garage. They just have this idea. They say, look, I tried to take a taxi, it’s a terrible experience: I couldn’t pay by credit card, it dropped me off in the middle of nowhere that was nowhere close to my destination, they arrived 15 minutes late. Whatever the experience was that caused these folks to want to use technology to improve the experience. So now you’re sitting there in your garage, now what? You just start building, right? Let’s build three apps and let’s go for it, right? And so you need two teams, right? You need one Objective C programmer for the iOS app, and then you need one Java programmer from the Android app. Is this the right way to go about it?
Andy: I would say absolutely not. The very first thing is, we’re talking about let’s start writing these native apps. Which, as you were just saying, is like, we need a separate team. We need a separate specialty for this and a separate specialty for that. But we don’t even know if anyone would want to use this. We don’t know yet if this is a problem I have and no one else has. So that’s probably way too far. Okay, so maybe we write everything in JavaScript and Ruby, just a very simple webpage, and we try to test it from that point. But I think Mon-Chaio, we would both say, you’re also far too early to even bother doing that, right?
Mon-Chaio: I think I would agree. I think you’re way too early to even be writing code. And I think this is a problem that a lot of technical founders come on, is they have this technical idea of what that product might be.
Andy: ” I already know. I have this list of features. It’s already all written out in Jira. I’ve got Jira tasks for this!”
Mon-Chaio: And it’s not even that. Perhaps I’ve written it out even on a slide, and I’ve sold it to an investor, and the investor has said, ” yes, these two native apps that look like this, this is what I want, here’s some money for it!” But rarely is that the right thing to do. And I think most people end up building too early because building is one of the most expensive ways to validate a hypothesis, isn’t it Andy ?
Andy: Yeah. Because it takes us time to build that stuff. And I think right there, you got to the key of it. That at this point, the tech team – there’s no team yet – your mentality has to be absolutely on the how do we validate a hypothesis? How do we experiment? You might build software But you have to come up with that is the only thing that will give you a read on whether or not you’ve got the right end of the stick here.
Mon-Chaio: Or it’s the cheapest, quickest way to get your read, right? Because one way to do it in this scenario might be, well I’m gonna send out questionnaires via Constant Contact or something, to people who sign up for an email list. And that might technically be the cheapest way, but if your skill set is in JavaScript programming and you could build a JavaScript thing really quickly in a day or two to prove a hypothesis, that may be different than you learning how to use Constant Contact and you don’t really have any ability in cold selling and so you’re not really willing to reach out over LinkedIn.
And so, yeah, your skill set does play into this as well, right? Where for an average human perhaps the cold LinkedIn reach outs is the cheapest way to prove a hypothesis But maybe for you, as a tech person, it’s not. But I think often people fall into these comfort patterns instead of really analyzing to say look, I mean, a cold LinkedIn reach out is uncomfortable for me, but really is it really so much more expensive, or more expensive at all than me sitting in my house for six hours writing some JavaScript code. Sometimes it is possible that writing code Is the cheapest quickest way to prove a hypothesis, but I think most often it’s not and I think for technical people we tend to forget that.
Andy: Let’s use this as an example, the hypothetical Uber startup, which is, okay, we’re starting out, we’re thinking, there’s got to be a problem here. There’s a hypothesis about what the problem is and what might resolve it. So very first thing is, I want to go out and figure out, is this a problem others have?
Mon-Chaio: Mmm hmm.
Andy: And so I would probably start by just saying the answer is not in my garage. If I just sit around in my garage and think about what code should I be writing and draw up mockups, I’m not going to find my answer. So I have to go somewhere else. So at this point it would be no tech team, and instead it’s going and probably doing like, ride alongs with taxis. Or sitting in places where there’s often people waiting for taxis. And maybe chatting to them and asking them how their experiences in using the taxi and what their pain points are. Not to take their answers exactly, but to validate that my thought that there is something going on here might be true or might not be true.
Mon-Chaio: Absolutely, yeah, I tend to agree with you. Even if your expertise is in tech, and even if you are fairly sure you’re gonna build a technical product, the initial stages are not a tech team. It doesn’t matter whether one person’s more well versed in product and one person’s more well versed in technology. Both those people have to be going out and doing this legwork, right? Or the other option is one person puts in more of the upfront work and they say, look, for the next three months, for the next six months, it’s all me.
Andy: Yeah.
Mon-Chaio: And soon it will be all you writing code, but right now it’s all me. So take a break.
Andy: Well, or let’s talk about that. What could that person be doing to support the one who’s doing the legwork? Maybe they could be spending their time, rather than trying to write all sorts of systems, they spend their time on mock ups of what could this look like? And then that person can take it out there and show it to people and ask them for their feedback on it.
Do paper prototype type setups of being like, okay, well, if we set up the UI this way, if this was the workflow, this is how the system would work. Now, let me think about how that would change, and coming up with these paper prototypes that your partner can take people through.
Mon-Chaio: Right.
Andy: But not going into like, okay, so now I need to build a Redis cluster and I’m gonna use Kafka to handle all of this stuff. No, you’re not at that point yet. Let’s say that we’ve done this, we’ve gone through this kind of step of confirming that there is possibly a need here.
Mon-Chaio: Mmm hmm.
Andy: The next step on this is once again not driven by tech, but by the market. Now you’ve got the idea that people are on board with there is a problem here. What you don’t know yet is whether or not they’re willing to give you money to solve it.
Mon-Chaio: Mmmmm!
Andy: And so your next thought on building this business is what is the smallest, simplest, fastest thing we can do that will give us evidence – I’m not going to say prove, but give us evidence – that people will give us money to solve this problem for them.
Mon-Chaio: Mm hmm.
Andy: And at this point, tech might start to creep in a little bit.
Might.
Mon-Chaio: It might, but it might not. And even if it does, it might not be in any way the shape of the product that you’re eventually going to build.
Andy: Yeah.
Mon-Chaio: So let’s dive into this scenario. So you set up your booths or you’ve done your questionnaires or somehow you have now confirmed that there is a problem. And let’s just state the problem that you’ve confirmed. You have confirmed that passengers want to get to their destination via some sort of car service, a taxi, and they have many problems with being able to get to that space because, cars don’t show up on time.
Andy: They don’t show up time. They have to make these phone calls to these places and it’s just a terrible connection. And sometimes you get to your destination and you’re like, okay, can I pay with my card? And they take you to the trunk of the car and they pull out an ancient card copying machine, those chuk-chunk things. And you’re like … carbon copy machines, yeah. And you’re like, what the hell’s going on here? And they’re unhappy with the situation.
Mon-Chaio: Right. And so I think there’s a lot of problems. And maybe you identify the biggest problem is perhaps a time from when a person wants to get to a destination to the time they successfully arrive at their destination. Maybe that’s your main problem that you want focus on, right?
Because Andy, you talked about things like payments. There’s probably all sorts of other problems. But when you’re right at the beginning, you have to have a focus. You have to start small. You can’t say, well, all of these problems are problems for sure, but we got to solve a problem first.
Andy: Yeah. Where do you start? Yeah.
Mon-Chaio: And where you start can’t be, I start everywhere.
Andy: What?
Mon-Chaio: It can, I guess, if you have enough VC funding and runway, I’d suppose you could, but even then, I don’t think that’s the right way to approach the problem.
Andy: No, and to refer back to some of our previous episodes, thinking about the theory of constraints, if we immediately say the only thing that’s gonna be useful in telling us whether or not we’ve got a product is first we have to immediately solve all of the problems that we can see people are having, what we’ve just done is we’ve created a huge bottleneck in our tech team to deliver a bunch of these things.
And right there, that’s, I think, the biggest cause I see of these small companies that immediately grow these giant tech teams. Because they haven’t decided, no, this small thing is actually all we really need to be focusing on right now. Instead, they decide we have to do everything. Because without everything, it’s not useful.
Mon-Chaio: And just because the “right now” is where we need to focus, that “right now” could be on the order of days or weeks. That doesn’t mean that it’s months or years and you’re stuck there.
Andy: And in fact, it should be days or weeks, like , you want feedback on that kind of a scale and you’re not going to get that with the big team
Mon-Chaio: Right. Okay, so, we’re here. We’re saying, look, we have payments, we have all sorts of other things, but the biggest problem is it takes too long and it’s too difficult for somebody to get to their destination via taxi. So, our primary, and I think this is the time when you start thinking about these KPIs, our primary KPI is the amount of time it takes from the time person first wants to go someplace to the time that they arrive someplace via service.
Andy: Right
Mon-Chaio: And obviously there’s a minimum bound for that, right? The amount of time you drive, minimum bound for that. But you’re focused on sort of the beginning part, like how do you hail, what’s that experience?
Andy: How do you get someone faster than they’re currently experiencing.
Mon-Chaio: Right, so they don’t have to call three different companies or whatever.
Okay, so now it’s pretty clear. You start building, right? You build the iOS app. And then you build the Android app, right? And it has a map on it and you put where you are on the map. And then the drivers need an app as well, where they see all the riders, right? This is now where we build, right, Andy?
Andy: I don’t think so. We might build a small portion of it. But once again, we want to keep our team small, lean, ‘ cause we might be wrong still. It might be that we do this and it doesn’t work out. Before we get to the tech, I’m going to actually bring up the book Lean Enterprise at the moment. I’m looking at a set of metrics that in addition to that KPI of this is the number we’re trying to change for our users …
Mon-Chaio: Mmm hmm.
Andy: … the next thing you also want to do is look at some of these other metrics. They’re called the pirate metrics, the AARRR metrics: acquisition, activation, retention, revenue, referral. Early on, these are your primary measures about whether or not people are interested. The KPI that you were talking about, Mon-Chaio, is are you solving the problem that you think you’re solving for them? These are the metrics that tell you whether or not you have a funnel of people who think you’re solving a problem for them. And it could be you’re solving completely different problem for them than you think you are.
Mon-Chaio: Mm hmm.
Andy: Which is why that KPI, if you only looked at that, could lead you down the wrong path. Whereas the KPI could be like, this isn’t moving, and if you didn’t watch these other metrics, you’d say, this isn’t moving, and so let’s move on. These would say, this isn’t moving, but we are getting revenue and referrals and retention. What’s happening here? And it gives you that chance to look into it a bit more.
But at this point still, we want to build as little tech as possible.
Mon-Chaio: Right. I agree. And I like the Pirate Metrics that you brought up because it gets back to something you said earlier, which is, will people pay for this product?
So if your KPI is how to get people to where they’re going the quickest, and if we’re not building iOS apps and Android apps with maps on them, what are we building, Andy? , what would you say is the cheapest, quickest way to prove this hypothesis?
Do you think it’s still technical product or it’s still not technical product here?
Andy: I would probably start with text messages.
Mon-Chaio: Yes!
Andy: I would probably do it entirely just by text message, where someone texts in, like, maybe you do it on WhatsApp, where people can drop a pin at their location. You can say I need a pick up at this location, and we don’t even have a app. Maybe it’s these three people sitting in their garage now, frantically taking their WhatsApp messages coming in, and then deciding who to send it on to, and being like, hey, you, go pick up this person.
And seeing if they can resolve this problem and learn from the experience.
Mon-Chaio: Absolutely. I think I came to the same idea as well. So when they text message you, then you do the difficult work of calling all the different cab companies and saying, oh, I’m looking for somebody to pick up here, I’m looking for somebody to pick up here.
Andy: So they don’t feel frustration. And then you give them feedback about like, we found a driver through this cab company, they’re on their way.
Mon-Chaio: Yeah. And we’ll text you and let you know if they’re running late or as much as you can, right? And so I think that’s something that you can say, look, are people going pay for this?
Andy: Yeah.
Mon-Chaio: Now when we talk about product you might say after running that experiment and seeing that people will pay for it, you might say okay, well now I’m going to write a little bit of software maybe for the cab companies And maybe the only bit of software you want to write for the cab companies is for them to be able to communicate with you, to tell you when cabs are running late or whatever. Maybe, maybe not, right? But like, this is kind of the path that we’re going down where we’re saying … we know what the shape … because of history, because we’re looking back on this, we know what the likely shape of the successful product is in hindsight. But when you’re in the moment, you don’t have to, and it’s often wrong, to be building for that.
Andy: Which gets to, when you’re trying to build your tech team at this point, what their focus is. Now, I’m a big advocate of TDD. I would not say that this group should be religiously implementing test-driven development for what they’re doing.
I think at this point, they’re probably doing a lot of throwaway code, a lot of technical debt, but the discipline that they need to have is that every time it looks like they’re finding a success, they then give themselves a little bit of a safety net around it. So at this point, what you’re looking for, the tech team you want, the ethos they need to have, is the commandos. They go in, they get it done. They do it dirty, but they do it ready to be reinforced by the next group.
So they don’t just leave a mess behind. They leave a well reasoned chaos behind.
Mon-Chaio: Well, and I think importantly here is what they’re building and what they’re leaving behind is proving a business hypothesis. Because I have often seen this type of behavior too, and I’ll bring it back to this particular example, where they say, well, we know eventually we’re going to build two apps.
Andy: Yes.
Mon-Chaio: And we don’t have any app expertise. Or we think we might have app expertise, but we don’t know how to do it. We don’t know if GPS is going to be reliable. We don’t know if we’re going to have maps APIs. So what we’re going to build now is we’re just going to build two little apps where the only thing you can do is find your location and then call one cab company to take you to one park. And then you’re going to release that to customers.
So while it’s true that that’s kind of a thin little slice, a thin little vertical slice, the things you do have to reinforce hypotheses and when you release that app and you say, well, it’s okay that nobody’s using it because nobody just wants to go from the Embarcadero to this one particular restaurant at the Mission, which is what the app can only do, the question you have to ask yourself is when you built that what hypothesis are you proving? Are you just building that because you want to feel comfortable to see you’re building something to the shape of what you have in your mind about what the final product is.
Andy: But it does get to an interesting point, is like, you brought that up as almost a bit of a straw man thin vertical slice. But if you really pay attention to that hypothesis and you think, what is the smallest thing we could do? Maybe you come up with, there’s actually a festival that’s going to be going on. And if we can get this very simple app to act as like a little shuttle service for people …
Mon-Chaio: Perfect!
Andy: … and we only need to support these four locations, then you’re like, okay, yeah, we’re going to support those four locations. There’s no like selecting your point or anything. You just say, I’m here and I need to go to one of these four places, and then you get that out there and you see if people find it useful, if they like the experience.
Mon-Chaio: Mm hmm.
Andy: It’s using that to, as you said, test a hypothesis. You have to be tied to something that your users might want to do. But once again, the commandos, they get in there, they get that thing out there, they get it working, they are very focused on that. So, the way you’d run your tech team – you don’t start the full scrum process – no, you run your tech team very much hypothesis driven.
What I would expect to see in a group that’s doing this is you start out and you’re like, okay, what’s our hypothesis today? What’s the experiment we’re gonna try? What’s the experiment we tried yesterday? What did we learn from it? Let’s go do that.
Mon-Chaio: Yeah, I 100 percent agree. And so as the engineering leader here of your two person tech team, that’s exactly right. That’s how you’re interacting. That’s how your group is interacting. Your hypotheses are small. You want to be able to prove them on the order of days. And that’s how much software you’re writing. And if you’re ever writing software where you’re saying, well, this doesn’t really prove a hypothesis, or it’s just proving to us that we can write some code or it’s just proving that like iOS builds build, like, I think we’re way too early for that.
Like, I don’t know that that’s stuff that you need to spend time on right now.
Andy: Yeah. A bunch of your processes at this point are probably gonna be manual because you don’t know what tomorrow’s experiment is going to be. At some point , through a series of experiments, you’ll start finding like, oh, here’s the common thing where you’re having to do again and again. And then you might, you might pay attention to operational efficiency, but very likely you’re gonna say like, let’s run with this, it’s inefficient for a while, once we start seeing that traction, then we can start working on the efficiency. Or, if we’re noticing that the lack of efficiency is slowing down our experiments, then you pay attention to efficiency.
Mon-Chaio: Mmm hmm.
Andy: But not just because it’s uncomfortable to do the manual work.
Mon-Chaio: Right, right.
So one question I have for you, Andy, I think the festival idea is really good. You know that X number of people are going to go to this festival over history, you know that people generally take cabs there. So now you’re creating a small little product, right – I think we would still advocate not iOS or Android, but probably just web site type thing that works on mobile – to see whether people will use this kind of UI.
But while I agree that that product is great, I don’t agree that a product like, let’s get from two random locations in the city to four random locations in the other part of the city is good. Why is that, Andy? What’s the difference between those two? They’re essentially the same product if you look at it technically. If they’re the same product that I built technically, why wouldn’t I just build either product and it’d be okay?
Why is one great and the other is laughable and shouldn’t be done?
Andy: In my mind, I think the one around the festival, it has enough demand to create a signal. Whereas just random points in the city, I have no idea how to tell whether or not I’ve captured any demand.
If someone uses it, why did they use it? What did they get out of it? How many people could have used it and never did? Whereas with the festival, I maybe don’t know exactly how many people could have used it and never did, but I have a much better ability to estimate that.
Mon-Chaio: Yeah, II agree with you. I think it’s around likelihood of success of your hypothesis. Because in one you can say, I don’t know if this is going to be successful but maybe some people want to go to this part of the city and maybe a lot of people want to go to this random part of the city that I picked.
Andy: I’ll modify what you said because I think you actually hit it. It’s not likelihood of success of the hypothesis. It’s likelihood of failure of the hypothesis.
Mon-Chaio: Aha, okay.
Andy: Or I guess success of a hypothesis is through evidence that it’s true or evidence that it’s false. That’s success. So it’s that you had a high likelihood of disproving your hypothesis. Whereas in the other one, if it’s just random points, there’s a very high likelihood that you’ll have not enough information to prove or support or disprove your hypothesis. Which means it was unsuccessful hypothesis.
It was actually an unsuccessful experiment, but we’ll conflate those terms.
Mon-Chaio: Right, because just having a chance of proving or disproving your hypothesis in a strong way isn’t good enough. You want that chance to be as high as possible.
And with the festival idea, you have a high chance of either proving or disproving because you have the data.
Well, this many people came to the festival. Why didn’t they use the app? This many people still took taxis instead. Why?
Andy: Even though we were standing there showing them, Hey, just use this page and it’ll get you around the festival, and we had billboards all over telling them about it, and yet they still didn’t do it. Okay. What do we learn about that?
Mon-Chaio: Whereas in the other case, you have all sorts of excuses why it might not work. Well, it was the wrong time of day. Well, nobody wanted to go there. And the explanation that some people might want to go there, why wouldn’t you just write this interim app which is already on the path to what you think you want and perhaps it will show some hypothesis success or failure, that is absolutely, I think, the wrong way to think about from our perspective.
Andy: And, can you pinpoint what about it ends up being wrong? Cause if we already have this stronger idea of this bigger app and this is just a stepping stone and, so what, some people didn’t use it, we knew that they wouldn’t use it. What is wrong with that?
Mon-Chaio: I think what’s wrong with that is, especially at this early stage, regardless of how much evidence you have from your investor, from yourself, to me the market drives the evidence. And I feel like you need to try to be disproving what you believe as often as possible through the market. And so the problem with that is you’re trying to reinforce what you believe and you don’t really have a mechanism for disproving what you believe.
Andy: I think that’s hit it. The core of the scientific method – which is what we’re describing here – the core of the scientific method is you don’t do experiments to prove a hypothesis, you do experiments to disprove a hypothesis. You are constantly looking for evidence that you’re wrong.
Mon-Chaio: Mmm hmm, yep! That’s exactly right. I love it. OK, so what we’ve done is we’ve gotten together, we’ve done some surveys, we’ve asked people questions, we’ve come to this belief that the experience of getting from one destination to another is horrible.
We’ve decided that that’s going to be the first thing we’re going to tackle. We’ve done something maybe with text messages, and they text us, we call the cab companies and become the intermediary between it. We’ve seen people who are willing to pay us a little bit of money for that, maybe a dollar per text message, maybe ten dollars a month for as many text messages as they want to send.
And maybe we’ve run that experiment … again, remember, we don’t have to run this experiment for a long time …
Andy: Mmm hmm.
Mon-Chaio: … right? We have to run it for as long as it feels like it gives us adequate signal-to-cost-to-time ratio. So maybe you only run that text message service for a few days, maybe a week.
Andy: Yeah.
Mon-Chaio: Right? But possibly longer.
So we’ve run that. Then we decided, okay, this seems to work. People seem to have an idea that like the front end experience is wrong. So what might this front end experience be? We’ve come up with, oh, it might be an app where you’re able to set pins of locations and destinations. What’s a good way to prove that?
And then I think maybe we’ve landed on this festival idea. Oh, well, can we prove it in a small stage festival. And so now we’re actually building product. We’re still not building an iOS and Android app, right? It doesn’t matter. We know that people have built those apps in the past. It’s not rocket science.
So we built a little webpage. We went to this festival. We launched it. So let’s say we’ve done a bunch of these experiments and now we have some fairly, fairly strong, both market evidence as well as investor evidence, as well as our own intuition that this sort of app is going to work. So now we have, you know, an app that we know we’re going to be able to look at your location, we know that you want to be able to pin some future location. We know that you want to be able to ask for a driver. The driver needs to show up and then it needs to take you to this destination.
So you have confidence in that now. Does that now mean that you can hire three more engineers and start to build it in a different way than just this commando/hypothesis method. Or are we still too early there?
Andy: I think you’re still a little too early. You’re getting closer. I think we’re getting much closer. But I think, to me, in my mind, you’re still a little early. I think, now that you have that idea, you still run very lean. This is the point at which the team starts changing their ethos a little bit. Not everything is a throwaway experiment. Now it’s okay, we’re gonna build up this more polished app, because we want this to go out to a wider group now, and we’re gonna try to be a little less hands on. Okay, so now your team of commandos is laying down more trails and making sure that things are more secure for the infantry who are gonna come later.
But the infantry aren’t there yet. Because when the infantry land, we have to be really certain about what it is we’re doing. And we’re not quite there yet. I wanna get it to the point where, these commandos can’t take us any further.
Mon-Chaio: Interesting. Okay.
Andy: I don’t know. What do you think?
Mon-Chaio: I actually think that this might be a slight disagreement our end. We’ve had this conversation in the past about do you just experiment to death? Or is there some points where you have to have conviction?
Andy: Conviction and just go for it.
Mon-Chaio: And just go for it. And we’ve both said in this episode that people have conviction far too early, right? Far too early. But perhaps where we differ a little bit is, maybe this is the point in which I feel like we start to have good enough conviction, especially if we have money backing us, that we can actually go start to build without having as much commando action.
So I think this might be the time when you’re saying, okay, we’re going to build a team. And we know that first, what we’re going to ship is we’re going to ship the map. You’re like, we got to go get an API to put a map on this page. And then second, we need to, X and Y and Z. And not every one of those now has to be validated by market hypothesis, which is I put a map on this page. Now I need to release to some customers to figure out whether they like the map, whether the zoom levels are right. I don’t think that we need to be so tied in now to experimentation.
I do think that we still need to have some smaller experiments even in this stage, but I think we can be a little bit more heads down to build.
Andy: Yeah, and I agree with that, and that’s what I’m thinking, is you take your commandos that you already had, because I think, if I understood correctly, what you were saying, you probably had a team of two, maybe three by this point. What I’m saying is, now get them a bit more heads down in just building and making sure that everything’s ready for the wave that’s going to come later. And my understanding is that at this point, we’re saying this is kind of like the seed funding stage. At this point, the company really doesn’t have a huge amount of cash.
Mon-Chaio: No.
Andy: So they might be able to hire one more person, maybe, and fund them for maybe a year. But, that would be about it. So you still want to run pretty lean.
Mon-Chaio: Absolutely. Perhaps we can say that now our team, let’s say it’s a team of four now, you’ve hired this one engineer for six months or a year, you kind of have some conviction, so you’re building. And I think we still want to run lean and so forth for engineers to build something, you can’t really be thinking about well, what are my rider ratings, what are my driver ratings, and what about suggested pickup spots so there’s no congestion, and what about what happens when traffic is coming, do I need to have nav and whatever, right? So I think we’re still building a really lean product, but now we’re building a product.
And I think what we’re building towards is something really simple that meets that first and only KPI that you have: can I successfully get my passenger to their destination as quickly and happily, I guess, as possible? And so the app probably looks like, hey, get my location, set my destination, hit go, driver shows up, takes me to my destination. Does it have payments at this time? Maybe, maybe not. Does it have nav at this time? I would say probably not. Probably it sends you to Apple Maps or Google Maps to do the navigation, and the app itself has no understanding of routing. It just knows, oh, approximately this is the amount of time it might take.
Andy: And what does it look like day to day in this tech team, in this team that now exists? If I came in as a developer on it, say I was the fourth developer, what would I see? What would the interactions be?
Mon-Chaio: So I think at this point you start to put together some of those processes. I think now is the time when you say, look, I have a backlog of things I want to do. I’m planning this sprint board or this iteration board. And we’re sitting down here and, because it’s us, they’re co-creating. So we’re working together to create these types of things, but we do have releases that we’re planning and we’re starting to execute a release train every week. This is our goal for what we’re going to ship.
And so in my mind, this is less experiment driven by what did our experiment say last week that changes what we do this week and changes what we do next week. Our plans are pretty durable at this point on the order of weeks on the order of two to three weeks. They’re fairly durable plans And so now is the time when, as an eng leader, you start to need to focus around understanding the execution of those plans.
Andy: Right. You should be looking at, okay, what is our structure for coordinated execution? Um, I think at this point I would still warn people away from turning too much into specialties. So it’s like, oh, we’ve got the DevOps person who does the AWS infrastructure, we’ve got the front end person who’s doing the web, and we’ve got this guy who just does the backend. Avoid that like the plague at this point.
I think you should also expect that you’re starting to see a little bit of a separation between, um, technical leadership and product leadership. It might not be there yet, but you probably want to start looking for it. Because, as you’re saying, you’re now looking for your technical team to start running. And if they’re having to interrupt themselves all the time with too much of the product investigation, too much product thinking, they’re going to get caught up in that, and the context switching will just be too difficult.
So you’re going to start at this point, probably not completely, start trying to figure out, okay, who’s the product lead? Who’s the decision maker and the guidance there? Who’s the technical guidance and decision making? And start working out some of those structures. It’s all going to be very loose. So if I was coming in, I would expect it to look like everyone’s equals, but there will be certain people who it would be like, oh, they’re the ones who actually we look to for product guidance. They’re the ones who we look to for more architectural guidance.
Mon-Chaio: Right. Right. Okay. I think this is a great place to leave it for this episode. I think our hypothetical team has gotten together, they’re building this V1 product, and they’re starting to put together this framework for how they’re going to operate as a team.
I think the next episode will jump forward in time, and it’ll be a little bit later in the process. They’ve gotten a lot of market traction with still their very, very simple little product that we just described. And now this traction has caught the eye of investors who say, hey, you had an app where you could just pin two locations, a driver would show up and take you places with no other features? How are you in 50 U.S. cities getting so much money? I want to invest.
And what do we do now? As investing money comes in, and they have a lot of different features that they want, and as a team, now that you’re in 50 U.S. cities, you’re feeling a lot of strain around the things that perhaps you didn’t do to set up your app for success.
Andy: Yep. And we’ll probably also talk about how do you get ready for those investors to offer you money.
Mon-Chaio: Oh, interesting. I hadn’t thought about that. That would be interesting if we could fit that well. I agree. Okay. Well, I hope you all have enjoyed this episode. It was for those folks that were wanting to hear more about scaling an engineering group. Obviously, this is just the beginning part of it. As I was mentioning in my VacationCast, it’s not a simple thing around scaling that you can just do in 20 or 30 minutes and explain it. It really requires setting up the foundation and seeing how it grows. So hopefully we’ll be able to get there. If you would not like to wait and you would just like to know the ending, write to us. We’re happy to give you a sneak peek.
If you or your company are running into scaling problems, you can see exactly where this is going, you’re like, hey, we were there. We’re now two years past, so I can see where your episode’s going. I want to know. I want to know what we do now that we’re your hypothetical company two years later. Write us at hosts@thettlpodcast.com. That’s hosts with an ‘s’. We love conversation. We do consulting. We help individuals and companies do these types of scaling things successfully. So let us know if we can help you in any way.
Also, recommend us to a friend. We would hope that we get more and more listeners as we go along this five part journey till we come to the end and see whether our hypothetical company is successful or not. Alright, until next time, listeners, be kind and stay curious.
Leave a Reply