In this episode we discuss: How do you build an organisation to compete with Google? We are joined by Omid Ashtari, ex-COO of Streebees and President of Citymapper.
We chat about the following with Omid:
References:
http://www.linkedin.com/in/ashtari
http://www.startuppragmatism.com
Biography:
I have two decades of experience in tech and worked in sales, business development and strategy roles for Google across the Dublin, London and San Francisco office during his 7 years there. As the first international employee, I set up Foursquare in Europe as Managing Director. I subsequently joined Citymapper for 6 years as President running the non-engineering side of the business. I then joined Streetbees as COO running operations, international expansion, finance and legal. Throughout my career I have raised north of 100 million dollars of funding for businesses I have worked for.
I am an angel investor in more than 45 businesses and advise many of them in all manner of things including strategy, operations, business development, fundraises etc. I am also part of the Mayor of London's Business Advisory Board, and a Mentor at Seedcamp and Entrepreneur First.
I am also an aspiring writer for my blogs startuppragmatism.blog and thefullspectrum.blog.
Summary:
Brandon M 0:05
Hello, and welcome to another episode of the operations room a podcast for CEOs I am Brandon Mensing. I'm joined by my lovely co host, Bethany Ayers, how're things going? Bethany,
Bethany 0:15
they are fine, Brandon, nothing too exciting to announce today, I'm afraid. How about you?
Brandon M 0:22
it was like a time capsule of:Bethany 4:09
Did anything make the edit? Did anything get shipped back? Or is that all just remaining in Canada? Yeah,
Brandon M 4:15
yep. So not a lot made the Edit to be honest. There's some artefacts from my travel not a lot, but just a couple of pieces that I wanted to keep with me. There was my rollerblades. My daughter is now into rollerblading, which is great. So brought those back. We'll do some rollerblading in the summertime. So that'll be fantastic. And then just the usual personal effects and some photos and whatnot. And that is it. So not a tremendous amount. I would say. It's amazing what you can cut out of your life when you don't need it anymore.
Bethany 4:43
ll of her journals from like,:Brandon M 5:22
That's a lot. Yeah, I think doing your own stuff is fairly straightforward. You know what, what matters to you. But when it comes to your parents, yeah, that sounds hard, like what to do with all that.
Bethany 5:33
Which is why it's just sitting there. I would say slowly rotting, except it's, you know, in the desert. So it's not, it's just slowly drying out.
Brandon M 5:41
You need to feed all the journals into some machine so it can be transcribed or something like that. I don't quite know
Bethany 5:47
that, Stephen, want to know what she was saying.
Brandon M 5:53
It's better not to know them to know,
Bethany 5:55
definitely, I think yours is probably a bit more fun.
Brandon M 5:59
I suspect. So. Alright, so we've got a great topic today, which is how to structure your business to get work done. We have a great guest for this, which is Ahmed ashtari. He's the ex CEO of St. Bees and president of Citymapper. Just before we get to that, I wanted to ask you a couple of questions, Bethany, and the first one that have a softball here, but how do you fundamentally think about organisational structure? And where is your starting point?
Bethany 6:27
I love how you consider that a softball.
Brandon M 6:34
Organisational just throw some names on on a chart.
Bethany 6:38
Yeah, I don't like I think there's a few things. One is a mistake I see people make a lot. And I think we all tend to do this in our first passive org structure is to make our existing team happy, or to create a structure that works with who you have. And you can really tell walking into a company when that's the case. Because you have like these weird made up titles, and you have three people half owning one thing, you have too many people in the management team, because nobody wants to have the conversation about how like the person without any direct reports, who's focused on 1/8 of the business really needs to still be on the management team. And I really get it, I'm sympathetic to it because I do it as well. And I'll find that I'm like, Oh, well, that person is really interested and they have those skills. So I'm going to like, say that we need these skills when we really don't. So as soon as I noticed myself doing that, it's taking a step back clean sheet of paper and start with what are the skills that you need? will actually start with? What is the outcome you're looking for? And therefore what are the skills that you need? And then how do you find those skills? Not how do you find the skills in the market, but at what shape of person tends to have the skills that you're looking for? And which skills tend to come together in a lump? And then work from that into? Who are the pre existing people who can fit into those chunks? And what are the other skills that you need to recruit for. And that's looking for an outcome, but needing to figure out what it is that you want to solve or produce in the first place. So
Brandon M 8:20
I would triple down on that. I think you're exactly right. I think what often ends up happening is you're morphing structures around people as opposed to the reverse. And ultimately, it comes home to roost because at some point you realise the company's just not working because you have a huge amount of confusion as to who's doing what and who's making decisions and what this person's role is versus not. And there's a lot of frustration that starts to develop over time. And you can see it too. How do we create value as a business? What's the operating model of the business? What's the strategy, the business? What are the challenges of the business and the opportunities of the business? If you're clear on all of that, then the outcome of that really is your organisational structure, or perhaps actually even better said, the skills that you need to satisfy all that.
Bethany 9:02
And then also, when you're in a start up and a scale up being flexible around. When you get bigger, you'll have like a rev ops person and a systems person and a reporting person or you know, and teams and the rest of it. But you can actually like for V one, roll up a lot of skills and what will be future three or four jobs into one job. And then know that you'll be splitting those jobs out and specialising as you get bigger. But you don't need to have all of those specialisations to begin with, but you did need to have all of the skills. Yeah,
Brandon M 9:40
I love that. I think that's actually good planning because in your head, you know that ultimately as the organisation grows, you're going to be splitting that out. And if you know that from the outset, you have a clear pathway in your mind as to what the structure is going to look like over time.
Bethany 9:52
Possibly and then you know, the world changes.
Brandon M 9:55
Yeah, exactly. Then the rug is pulled and you have a different plan. So here's my hard question, what is the most controversial or risky or difficult or extract your decision that you've had to make? I'll throw this one out just because I'm curious what you think. But at my last business, he had self serve subscribers, and what was classic direct selling to enterprise. And both require, in my view, different skills from a marketing point of view. And to your point, I was thinking about, what are the skills that we actually need here. And what also occurred to me was that we need some foundational positioning and messaging for the organisation as well. So what I ended up doing was saying, look, I think we need two different roles here, I think we need a product marketing manager for positioning and messaging fundamentally, we also need a product marketing manager that has a skew towards self serve subscribers. And then in addition to that, we also need to have what I call the go to market manager and the go to market manager was all about the go to market for the sales side or for the enterprise direct selling side, what I need is for those two people to work very closely together to ensure that we're doing the right things. I had a lot of pushback at the time, because a lot of people were concerned that I was doubling up that it's the same person for the same job, and why you're hurting two people, and then they're going to be confused in terms of the overlap between the two of them between messaging and whatever else. And I was pretty adamant at the time, I was like, No, we need both, we have a magnitude of requirements on the sell side that is never going to be done by this product marketing person, there's not gonna have the capacity or mindset to get it done, because they don't have the experience dealing with pipelines and whatever else. So I went down the path of both both hires. And, you know, in retrospect, I would do it again, because it worked for the company, which is we had clear go to market push on the Enterprise selling side, that person was a phenomenal collaborator with the product marketer in this case, and there was a recognition that they were responsible for the positioning and messaging, but that person definitely had a contribution into that as a stakeholder, but it was owned by the PMM in this case, and you know, was there some level of overlap that I might be overlooking or glossing over? I'm sure there was, but I think ultimately work from the business,
Bethany:it makes sense to me, because what you're doing is looking at the outcome, and you have two different business streams, and they need the skills and actually makes me think about our conversation with Mark Logan, which I am not sure as before, after this one around people having the skill access to the skills and resources they need. And that's basically what you're doing. And if they have the same title, then maybe they need to have slightly different titles to make it clear that they're not doing the same job. But it sounds logical to me, and it works. So it's great.
Brandon M:It works. That's the big thing.
Bethany:So for me, it's maybe not like an org structure that I've been controversial about, but I've hit up against people not wanting to do it, both in businesses that I've worked in, and businesses that I've advised is investing in a thinker early. And that thinker can come in loads of different shapes. And it's interesting, because now with the rise of Chief of Staff's is, I think that is a way of wrapping in that thinker, as like an extra pair of hands for the CEO and early stage businesses. But to have that person who can come in and isn't busy doing everything, and can start to think about and analyse what is it that makes the CEO successful at founder led sales? What makes the salespeople not successful? Are we leaving money on the table? How do we figure out product market fit, who's talking to customers, and thinking about that journey, and gathering a tremendous amount of information and analysing it is perceived as a luxury role. And yet, if you don't have somebody who has the time to think, as their job, I don't know how you're actually going to figure out product market fit and grow the business that you need to, I have basically been that person twice, and different views or like when I came in, I was the thinker. So I think you need a thinker in early and then the next thing you need is somebody to do your rev ops Well, or your full Biz Ops well, because otherwise, you're flying blind. And so if I'm the person who's the thinker, then the thinker very quickly needs data. And then they need to be fed data by somebody who loves systems. And those would be for me, perceived early luxury roles, that I don't see how you succeed without unless you're just really lucky and you properly have product market fit to start with. And then the other way that I've seen is you end up with accidentally hiring a strategic salesperson, and then that strategic salesperson plays that role. But I've never seen a company realise that they're hiring a strategic salesperson, oh, in retrospect if they realise that they've had somebody that has those skills.
Brandon M:So last question, what are the signs that Your organisation needs revisiting or the organisational design rather needs revisiting.
Bethany:People are unhappy and confused and don't know what they're doing.
Brandon M:Yeah, that's a good one.
Bethany:Lots of questions, running into walls, like you know, where you're everybody's running one direction, but But isn't the right direction because like, there's nobody stopping to think about what's needed next. Because like, when you're in a scale up, and you're growing quickly, the challenges are always changing. And so you need to as a COO, think ahead, see around corners as the Americans like to say, and so is your cost base come going out of control? Do you have your enps plummeting because all of your employees are really unhappy? Do you just not have enough managers? Do you not have enough people that you can promote? Do you have a high level of churn like it's basically some other issue will come up and you'll look and realise that your org structure is either causing that issue or not in a way to not structured in a way that can help you solve it. And then you need to restructure.
Brandon M:So why don't we move over to our conversation with Ahmed and we'll come back with that chat.
Bethany:I am delighted to welcome umaid ashtari to the operations room.
Omid Ashtari:Thanks for having me.
Bethany:I don't actually know what your title was just I've seen your operations person in a variety of businesses, including Citymapper.
Omid Ashtari:Yes, a CEO, President and head of business, various different kinds of titles. Yes. General Manager, Europe, all the titles.
Brandon M:Oh, the title is awesome. Just a manager, manager kind of guy. Yeah, that kind of dude. Yeah. Just to get a baseline question. What's your role thinking when it comes to org structure when it comes to the stages,
Omid Ashtari:the different business units in any given organisation are going to be solving different sorts of problems across the different departments. And that's why it's probably worth looking at different operating systems and different ways of designing that organisation. For instance, figuring out what the right business model is for city mapper was a very different problem than launching the 150 city that is enabled in the app for people to use the app. And so you know, even though we were at Series B, the problem of monetizing was still very much an important problem that needed a different approach than launching the 150th. City. The other thing that I would say is, that is more of a meta point is probably that when you think about an organisation, their breaking points that come with the employee number, so it's probably less about the funding time of it. And of course, funding time is kind of equivalent to probably how many employees you have to an extent, but I would probably want to disassociate it a little bit more from the funding round and anchor it more at the employee scale and say, if you're seven people at a table and a desk, and we can just shout across the table to get everybody aligned, it's a different issue than if you have a whole room of people all of a sudden, and there are multiple desk clusters. And what happens when you have two rooms and what happens when you have people in other offices and, and so their natural breaking points, and then lines of communication and command that come at different scales. And I think you have to be cognizant of that and making sure that you're basically running the operational system adapted to the problems that those organisations are solving at that specific scale. To give an example, I think you've realised quickly that things are breaking down when, say, information is not disseminated efficiently anymore.
Bethany:Yeah, how do you realise that before it's too late,
Omid Ashtari:you will realise it probably after the problem has occurred, we're usually like, proactively figuring all this stuff out is quite hard, because then you have to expend a lot of energy in the immune system of your company. And you actually want to also expend a lot of energy of your company into the metabolism of the company as an in forward motion, right? Usually immune system problems as in like issues that pop up, should pop up, and then you can address them, you have to have a passive awareness of what's going on in your body, quote, unquote. But you know, you don't want to expend too much time on proactively wanting to solve immune system problems.
Bethany:Metabolism seems to be a thing like we're metabolising our feelings, we're metabolising, our ideas metabolise metabolise, but I've never heard the immune system part of it. Did you invent that? Or is this like a new thing that I've just missed coming out of Silicon Valley that I need to learn? This was just on the fly. Okay, cool. So I'm not like this some sort of new analogy I've missed.
Brandon M:Sounds very sophisticated, very sophisticated.
Omid Ashtari:This is why the RX philosophic, reom podcast, so the immune system being the system that recognises problems and the organisation and you can obviously spend a lot time say, on proactively designing the communication, let's say lines of communication, anticipating a step change in the organisation when you hire your 150 employee, or what you can do is embrace a little bit of that chaos. And when you hire that 100th employee, and you realise they didn't get the onboarding that was relevant to them, you realise after maybe two or three people who have been wrongly on boarded that you actually have to redesign the onboarding. So you figure these things out, when you're in a meeting, and somebody doesn't know something that's crucial for their workflow. All of a sudden, you're like, Oh, you didn't know that, okay, maybe I need to do a better thing about designing the communication. It's that same communication side. And then you know, when you think about the command side, what could happen is, obviously decisions are not being made, decisions are slowing down, you realise that, you know, you waited a whole week, because somebody actually said, Oh, I didn't know what to do here one day after the last weekly meeting, but they waited a whole week to address this problem that's too slow, depending on what you're trying to do, and what stage you're at at a startup and how important that problem obviously is. And
Bethany:sometimes it's actually worse than that, where they just need some guidance. And the worst part is when people spend a week trying to figure out who's allowed to make the decision. And nobody really knows who can make a decision.
Omid Ashtari:That's really a great example of lines of command being completely broken, the responsibility is not properly assigned, or you know, when there are bottlenecks in decision making, etc. There's also compound problems. So if you think about, for instance, the command and communication being both broken is, for instance, when the product team isn't aligned with their customers or users anymore, the sales team, they're so far removed. Yeah, or the sales team. Yeah, they cause a lot of trouble most of the product team, I think even worse, because usually engineering is kind of a very expensive resource of the organisation. And if it's misaligned with the goals of the customer, it's the lag time between the feedback can actually be put into a product roadmap is usually a lot longer. So that is crucial breaking point that you don't want to avoid. So
Brandon M:maybe just riffing off of that. What's the highest impact communication approach that you took to to solve any number of challenges that are happening as you scale that business? Can you just give us maybe one good example of using the symptoms and you addressing the symptoms by doing a B and see, funding events
Omid Ashtari:usually lead to the company thinking that you're more secure than you are? And they're more than you know? Yeah, exactly. You know, there's basically this success bias that you all of a sudden have you, you lose a little bit of humility. The other thing that I think was really important also with Citymapper, very often as we were sitting in a city that we were winning, word of mouth was great usage was growing. And yeah, this is not the case in Paris. This is not the case in Singapore, this is not the case in Hong Kong, this is not the case in New York, there's a lot of stuff that is going on in every market, which makes it hard to internationalise a product like this, but also worth doing. And so both getting people back to baseline around the fact that our product is winning here, but it's not in other places, and readjusting people's humility after funding event, I think two really important kind of events that I would maybe want to focus on in this example. So with the product thing, what we did was we were reading in a weekly meeting, user reports of how they hated the app and how things didn't go well for them with the app in different cities. And we had this reporter issue button on the results page of transport results that we send people. So we were getting a lot of inbound stuff on this route is not working for me, oh, you're totally missing this bus disruption was wrong, et cetera, et cetera, or, you know, I would love to combine the bus with the bike. Why don't you do this? Oh, I do a lot of parking, right? Because I live in Chicago, and I take my car to the train station, and then I take the train, why don't you support that? All these type of things were things that were trying to curate and bring up a meeting so that people were continuously facing these issues, and that they're continuously recalibrated to the experience of the average user in a different city. So that people are just natural, quote, unquote, monkey behaviour, they go to a party on the weekend and say, I work for Citymapper while you work for Citymapper. That's amazing. Such a cool company, you know, and they feel good. And they go back to work. And they're like, no problem. Everything's going well, but no, the user in Chicago meetup, which we did, every time we were travelling was a very different story. So what we also instituted, were actually encouraging a lot of the engineers and a lot of the employees to go travel and we would cover some of that budget. If they would go and do these exploratory trips. I did multiple of them myself, where you'd go and then do user meetups where you could hear what the users were saying on the ground, basically looking at various different problems yourself that people had reported and taking those journeys to see how it's broken and experience all that. So this is not necessarily super scalable part of it. But I think that being close to your customer in various different cities and elevating that problem to a weekly meeting was, I think, a great way to get people realigned to you know, we're not like there yet. And I think around fundraises, the most important thing is, I think, and this is an issue that I see quite often as with startups is they have a very narrow definition of product market fit. The narrative finishing of product market fit is I have traction, therefore, if product market fit. And the broad definition of product market fit is I have product market business scale fit. And it's only when you have product market business scale fit, that you have a business that can scale to a billion dollar valuation. And most of the time, you have to still readjust them on a continuous basis to test hypothesis, re, iterate, learn change direction, and
Bethany:the markets always changing. So you have market fit, and then you don't. And so product team drift from the market from the customer, from the sales team, or the sales team just doing weird shit that, you know, destroys everything. Have you seen any interesting structures that make that work so that product people, by default, don't migrate away from who they're building product for?
Omid Ashtari:The framework that I apply when I think about these kind of organisational problems, is thinking about the different types of problems that are trying to solve. And for me, there are three distinct ones. And the first being the kind of businesses usual problems, the second being the figure outer problems. And then the third being the scale problems. And I think you need a different type of person and a different type of operating system for each of these different buckets of problems that you're trying to solve. We
Bethany:had a guest on who I think will be before you, but who knows, talking about the importance of questions and figuring out what the right question is, before you answer it. And it just seems like from what Jen was talking about, that's very much what you're talking about is making sure you know what you're trying to solve. Before you solving.
Omid Ashtari:Let's talk a little bit about business. As usual, I think an easiest way of thinking about that is the finance team, there's a clear cadence and structure to the communication and meetings with the finance team, there's not a lot of room for creativity, you have some accounting leeway, and you want to kind of optimise the budget and want to make sure that you have like the outstanding invoices kind of minimised and stuff like that. And there is a little bit of creativity, obviously, that should be part of that, right. It's not I'm not suggesting that judges should be no innovation when it comes to business as usual. But the innovation is usually in the service of optimization and optimization in the margins, not like revolutions. Right? So that's what I would say is business is huge. And I want what is important here is the regular cadence, the very clear frameworks that you're using. And people who are very happy to not necessarily have very creative jobs isn't you don't want to hire somebody who wants to reinvent finance, as like CFO, if you're not the organisation that requires the reinvention of finance, but like, needs a very clear cadence and very clear kind of structure. If you think about scale problems, they're they're obviously different. You know, what you want to do, you want to do it fast. Within the frame of that there's room for creativity, no doubt. But it is an issue where you have some sort of product market fit and you're testing your growth hypothesis, you just want to do pedal to the metal and expand internationally, or you want to expand sales, that is kind of the traditional scale issue or a scale problem. And for that, for instance, what you need is you need very aggressive goals, you need a very clear marching direction, you want to make sure that there's also a very clear blueprint as to what has to be done. And what you want is you want people with very high roller related knowledge. As a matter of fact, what you don't want is probably like complete novice as your head of sales when you're trying to get super skilled sales, right? You want to have somebody that ranks very high on role related knowledge. And so again, it's important that you hire the right person that has done this probably three or four times before, and then make them adapt their style a little bit to your organisation and to your synchronous ease as a team for them to kind of take it to the next level. And my favourite, the figure outers, these are problems, where the roadmap is not clear whatsoever, you have an idea of what the solution is supposed to look like, but you don't know how to get there at all. And here, it's like figuring out the business model for city mapper was one of those problems right? What do you want to do is role related knowledge is not so important. Other than you know, the people who are basically functional leaders of that team say in engineering lead and maybe a design lead a product lead, but the rest of the team it's actually more important that they rank high probably on general cognitive ability, I would call it
Bethany:like they're smart euphemism for smart.
Omid Ashtari:Exactly. They're smart. They Ask a lot of questions, they have a lot of energy to take a lot of data in. They're flexible in their mental capacity to change paradigms. I think general cognitive ability is more than just being smart. Because mental flexibility requires a lot of resources from your brain. I mean, there were days where I would go home and I was completely drained. Because we were changing so many directions. And all of a sudden, we were optimising for something totally different in the evening that we had considered in the morning. And like going through that and changing your own mental paradigm is it requires a lot of energy. So you need people who are willing to do that. It's important to hire people that are also okay with navigating ambiguity, like your CFO is probably not the right cultural fit for that type of team. And what you want to do is actually within your team, look at people who may have the most entrepreneurial mindset and put them into that organisation, or into that business unit. So for instance, to give you an example that exemplifies this, we at some point, believe it or not run a night bus in London, the smart bus. I don't know if you ever saw that. But we saw like a demand supply gap in the London Transport System, based on all the demand data that we had from A to B's, and realise there was one gap there that we figured a bus could fill that would go from Highbury, Islington, over Dalston, down to Whitechapel. Because TfL is highly regulated, it's kind of space, nobody can just run buses in London, right? We had to fight for it. And we managed to get a night bus route because we couldn't get the daytime. And we ran this and the team that was focused on that sat in a different room, to the rest of the team, the figure out a team wasn't a separate room, they were all in the same team. And we didn't make it a functional team, we made it a business unit. So there is like the engineering person, the design person, and the product person were sitting at one desk in that separate room so that they can continuously communicate as they're figuring stuff out. And we had the business people and operations people all next to each other in that room. So everybody could shout across the room. And they were all talking about the same team, what we managed to do is we had ad hoc meetings, we didn't wait for weekly meetings, we didn't schedule weekly meetings, as soon as somebody had to make a decision. And it was a cross functional one, we just grabbed each other and sat on the desk that we had created, which is in the centre of the room that you know, people would just pull up to. And when somebody pulled up to that table, the other people noticed that there is a meeting being called basically, because you wouldn't pull up willy nilly to that table. And everybody would gather around that table. And we'd have a conversation about a problem that needed to be addressed very quickly. So you know, we just created a whole separate unit with a different DNA and operating system to approach that problem. Well, the main room, which was the bigger room, we're still churning out product on a day to day basis to beat Google Maps and everybody else who was competing in the transport app space, and secondly, to continue to launch cities. And they were doing it at a different cadence with regular meetings and different types of the team DNA etc. So that's basically it something that I think every team has to keep in mind. I think it's natural that companies as they get bigger, go from organisations where there's more informal conversation, it's agile, people wearing multiple hats, flexible to pivot, close collaboration, and quick decision making to say more formal, specialised data driven and consistency, conscious or risk aware kind of organisations, and that's okay. But if every department, every part of your organisation atrophies to that rigidity, then a yours chances of survival are not very high. And I think that's really the point that I'm trying to make here. And that's why, you know, you always have to have different operating systems across the organisation based on the problems that you're solving. And there's always going to be innovation problems if you want to survive right Innovators Dilemma, etc.
Brandon M:I was wondering about how I would apply what you just said to, let's say, I'm in a series, a company where it's a lot of figuring out there's maybe some level of scale, Inklings happening at that point of the business. Bau is probably only there in respect of certain rules and regulations, you need to be following related to, you know, compliance, and like I said, some finance roles and so on, but, and some basic rules in terms of the structure of the company, and so on. But if you take what you just said, and apply that to a series, a company as an example, or Citymapper, can you maybe just describe to me how that impacted, I guess, the way that you ran the business, the
Omid Ashtari:main problem of the company was to figure out how to have retained organic growth. And we didn't launch other cities, we really just focused on getting retained organic growth in London, then we knew that everything else would be a distraction at that point. So there was a myopic focus on the most important thing at the time, and that was figuring out how to get that and I think that was mainly a product issue. I wish I could take any credit for you know, the amazing product innovation in the organisation, but I can't and I want to pass that back on to the engineering and design teams and as my co founder of the business was also really chief designer. And that was really unique and they tried a lot and they they updated the up every week and you know, took information and from people's feedback on an ongoing basis, and it was, that was the focus, I was just the babysitter there. And I was kind of making sure the operations are fine at the beginning. But then as soon as we kind of realised, hey, you know what, we got retained organic growth month on month for many months, you know, when we should launch other cities, we feel confident that this is now a different company. And so we went from this figure out or mode, first of all, changing the whole metabolic rate of the company from, you know, just focus on this one problem here to figure out to change our thinking to Oh, no, we have multiple problems now that we are considering that is growing in various different cities. And these are different problems in each of these cities. And we need to have our ear close to the ground as we're doing that. So there was a business problem that was how are we going to get the data and all that, but then there was a product problem, which was, how are we going to adapt our existing formula to those markets to make sure that people feel the similar way, as we launched a couple more cities? And that was around series? A, we very quickly realised, obviously, you know what I mean, we are in a, in a very, how can I call this monopolistic market, because you have Google Maps and Apple Maps pre installed on every frickin device on planet Earth. And we're competing with those guys. So the growth game is a tough game to play as in a game where you want to compete on numbers with Google Maps and Apple Maps. So we should figure out a sustainable business model for this thing. And therefore, we need to transition in thinking about product market business fit. And there, what we had was the ongoing innovation engine of the product that continued to stay ahead of Google Maps, and Apple Maps. I mean, Apple Maps is very hard. But still isn't Yes. And actually, you know, what was really funny, because I worked on Google Maps at Google for four years, I helped with launching Google Maps across Europe. And I know that the team there was kind of like, a little sleepy. But as soon as they saw us emerge, and another startup or an app setting a different benchmark for the kind of experience that people wanted to see transport app to deliver those guys restructured, I know, that sounds crazy, but like, when you think about, like Citymapper, having an impact on Google's transport strategy, but I know for a fact that we did. And at some point, you know, launching cities became a scale problem. Because in the beginning, we just taped together all the data. And at some point, were like, Okay, we can't just have engineers being able to launch cities. Now let's build the tooling. So that technical non engineers can build the cities. And so that became a scale problem by the figure out or state, the business model and the most entrepreneurial people that had the highest resilience that, you know, were happy to take a beating and fail in public. Were the people who worked on that. And then the people who, you know, want it to kind of stay in the confines of the existing paradigm of this is the app, we're gonna optimise this and like, we want to scale the cities state in the different departments, if that makes sense. So
Bethany:it seems to me and normally, I asked you this question, but I'm going to, I'm going to answer it for myself. And then I'm going to ask you, the question is, the consistent theme that's come out, is understand, take time to diagnose what it is that you actually need to do, figure out the problems, and then hire the right people or structure around the problems. But like, it sounds like at City mapper, you were very, very clear on the three types of problems you were solving, and then finding the right people for those three. In retrospect, perhaps looking at your face, I'm guessing was maybe not that clear at the time.
Omid Ashtari:When I just wanted to honestly admit to exactly it is obviously in hindsight, I realised all these things. And I think in the moment, we were doing a lot of these things, we did call to figure out our problems, no doubt, and there was business as usual stuff. So we did call it this type of stuff, too. But I think you're very often it is absolutely fine to be a bit clueless as you're on this journey. And this happens all the time. That's basically what I'm trying to say is like, the bar is not this high that you always have to know exactly what's going in our organisation. I think what's important is that you ask questions, as you said that and if you've been messing around for a while, it's never too late to adjust and reorganise. We sometimes reorg, the whole team, every quarter, and some person came from one team into the next. And that requires a lot of emotional maturity and people who are flexible around their titles and that are also happy with not necessarily having the career that they exactly anticipated within Citymapper. And moving around. And you know, we're launching smart ride, which was our Uber Pool competitor, which was kind of a bus cap hybrid. We had about, you know, hundreds of cabs in central London serving Zone One, two, you could book it, but you'd have to walk to a stop or something like that and was more of a cab system. We had to hire 250 cabs. We took people from the team and just Put them into this smart write team to help recruit drivers and people who had nothing to do with, you know, operations all of a sudden ended up in operation. So you know, you just figure out what you need to do at any given point, and it's fine to readjust. And it's fine to reorg. And I think what's important is that you hire the right DNA of people who are willing to go through all that mess, because it is a mess. Before product market fit.
Bethany:We've spoken about lots of different things and multiple body parts. If our listeners we're going to take we're going to take one thing away from this conversation or the wisdom in your mind, what would that one thing be?
Omid Ashtari:Wow, this is such a as I really hate, like superlatives. And just making things about one thing, the world this way too nuanced to say one thing only, that our brains
Bethany:can only hold so much information. So you can only remember one thing, you're forcing my hand.
Omid Ashtari:I think the most important thing is that you don't get hung up on any specific metric of success. And that you continue to reassess with a very honest view on things where you are on this journey of product market fit, business scale fit, and that you make sure that the way your organisation is designed, really optimises to solving the most important problem of your organisation. Rather than comfortably, coasting with what you've had previously and figured worked all along. The organisation will change, the problems will change and you will have to adjust. Never feel safe, always be paranoid. I so
Bethany:100% believe that and experience it. And I think as an entrepreneur, it's even harder because everybody tells you, you have a stupid idea. And it's never going to work and nobody wants it. And you have to believe that they're all wrong. And most of the time they are but sometimes you have to also understand when you're wrong, and how you figure that out, which is part of what you're talking about, and then look at the actual reality and solve that problem is super hard. And it's not just intellect. You've talked a lot about emotional intelligence today, and flexibility and humility. 100% agree. monogram
Omid Ashtari:percent. Absolutely. The key to being successful as an entrepreneur, fundraising, running through the gamut changing the organisation adapting all the time. You need to be confidently insecure.
Bethany:Yeah, brilliant.
Omid Ashtari:Because you always have to be insecure about where everything's actually working properly. But you have to do this confidently because some venture capitalists need to invest in what you're doing. And you need to you know, fake it till you make it
Bethany:and you need to wake up in the morning.
Brandon M:Awesome, so wide ranging conversation. Thank you so much for joining us on the operations room. And if you like what you hear, please comment or subscribe and we will see you next week.