 Hey everyone, this is Carlos. I'm the founder and CEO at Product School and today I'm here with Iba Masoud, who's the CEO at Tara.ai. Hey Iba. Hello Carlos. Glad to be here. Glad to have you on the show. Let's start from the very beginning. What do you think that brought you here? What was your story? Let's see. I think it's been several elements of the story in terms of what really brought me here to this day, talking to everyone that's joined. Thank you for joining, firstly. I think where it really started was, I think it was 19 when I had an inkling of an idea for a platform I wanted to start and the first company I actually started was called GradBerry. So it was a website for students and fresh grads to find jobs. I just didn't understand why it was so hard for entry-level folks to basically get their foot in the door. And so I got together with my co-founder. We had $200. This was back in the Middle East in the UAE and that is literally what was the first seedling to just bringing us to Silicon Valley, starting Tara and being where we are today. It's interesting. They say an overnight journey typically takes multiple years of hard work and I think we're testament to that fact that it's taken us this long to get to where we are today. So I think that's where I would really start in terms of that inkling of that idea and how we iterated and how we got to the second company. So Eva, you basically tried to solve your own problem and that led you to start a company. You are an immigrant, so am I, both in Silicon Valley. So I think this is also a testament of like, hey, if you have passion and hard work and maybe sometimes there's some luck, you can do great things. And that led you to the current company today which is Tara.ai. I know that you have been invested by incredible companies such as Y Combinator or Slack Fun. So how do you, obviously I would say like what a lot of VCs would be saying is the typical company or founder. Like how were you able to break down those barriers and prove that you are here for a reason? Initially it was really difficult because I remember like that first moment of like being in Mountain View, landing literally, you know, from a plane on a tourist visa. And going into the Y Combinator office, frankly it felt like the first day at Hogwarts basically because it's like you're coming into this completely new culture. It's something that I've been reading about, like I've been reading Paul Graham's essays. I've been on, you know, reading on Hacker News for so long and so being able to literally step foot. I mean, the first most hardest part was actually, you know, getting into the interview, getting approved because we got rejected a few times before we eventually got in. But I remember like that first day getting into YC and I was like, okay, in order to fit in I need to wear a hoodie and I need to be able to like, you know, immediately prove why I'm there. Like, you know, if any programming questions that are asked or anything like in particular about technical infrastructure, like I need to be on point and on game. And I think it took me a while to realize that I don't need to look like anyone else or to be like anyone else in order to fit in. And that was actually the hardest part of the journey because it meant that I needed to be able to be comfortable in my own skin. I didn't, because I didn't come from an Ivy League background either and I noticed so many of the founders. Now YC has I think a much more diverse approach. But back then in 2015, just everyone that I was talking to was a white male Ivy League, Ivy League founder. And so, you know, not being from that background was I think one thing that was definitely overwhelming initially, but I think over time as we realize that you absolutely do not need to come from a certain background or from a certain pedigree to start a company. I think that took me some time to, I think, get comfortable in my own skin. I would say that was a big challenge initially. That's a very powerful message. And I'm very proud of what you accomplished so far. So what does Tara.ai do? Yeah, so it actually started from our own personal frustrations with project management software. Like, why does it have to be so hard to use, so slow and specifically not, you know, friendly for developers? And so we just wanted to build something that was really simple that you could get started with immediately where you could write docs that you could write and create your sprints and then make sure that it's synced to source control and GitHub. And so when we started working on the idea in 2018. So this was different from the idea we applied to YC with and obviously after talking to YC and those iterations, we realized that again, same situation, a problem that we were trying to solve that we were going through personally. So we were, you know, advent users of several PM systems. So I had been at GE before in terms of corporate experience had been at McKinsey and my co-founder had been at Boeing and several other companies in terms of engineering roles. And so we just felt like there had to be a better way to create something that was that was easy enough to use that even students would be able to use it. And interestingly, like 30% of our user base are students at universities. So we always had this hypothesis early on that we just wanted to build something that was really simple, but powerful. And that was the main ethos that the company stands on today, which is how can you minimize the number of clicks to get anything done and and just make it super simple to just create a doc or epic. Get your tasks in and start a sprint all the while being synced to GitHub. And there is something about trying to solve your own problems, because the level of passion and commitment you have, it's, it's there. Nobody can, you're not really trying to solve for somebody. It's your first time trying to solve for yourself. Of course, there's a market opportunity out there. But when you start describing your company, of course, I've used a lot of product or project management tools out there. There's so many and they work. So what, as a CEO, as a product person, what was that aha moment that made you realize, okay, we have an angle here. This is not Microsoft docs or JIRA or thousand other tools out there. I think it was when we first did our launch to Hacker News and Product Hunt. So this was last year, April 2020. This was our beta V1. And basically what happened was we realized that a lot of the users and people that were getting started with using it were founders and engineering managers. And in some cases, they didn't even know what an epic was. Like, I thought that a lot of the terminology being used in existing PM software was hard to understand. Like, why do I need to know Agile to just, you know, start a company or to get an MVP out of the door? Like, I don't understand the principles of Agile. And this was like, you know, now I do, but back then, I mean, I didn't. And that was the basis of the company. Like, how can you build a system that's agile in a box that's really easy to use? And so I think the first aha moment was when people came in the door. So the first 2000 users were like, we can get up and running really quickly. And it takes one minute to start a sprint versus, so it was one click versus, I think it was 35 clicks in JIRA to get started with the sprint. So that was the first aha. The second aha was when people said that, because we have built an automation. So what you could do is you could just, in one sync, it was one click, sync it to GitHub and immediately start to see blockers. Like, what's blocking my next pull request, what's blocking my commit? And that's where the AI component comes in, which is like, how do we help you predictably build software? So the first pillar is simplicity, but then the second pillar is predictability. So it's like, what can we do from an ML perspective that actually allows you to see your blockers, understand where your team is falling behind, and how do you get ship done? So it was like this three words that we build it down to just get ship done. Like, what can you do to get shipping moving forward? And so it was really just that, those two ahas that we had, and it was all through that first launch that we did, where people just, our first 2,000 users, first 50 users, 100,000, 2,000, gave us that feedback. So now moving forward, you hit broad market feed, seems like something with legs, your users are giving you feedback, and you as a CEO probably changed as well, because the early stages it was more about maybe building product, now you're in a different stage of your company. So how has Ebat changed as a CEO? I think it's interesting because I feel like we are always building product and always talking to users. So one of the things that we're really set at the company is this day one mentality, that it's always day one. So what we've seen is we've literally kept the same strategy from 100 to 500 to 2,000. Now it's about 33,000 users. And basically we're like, we're keeping, it's the same. I think we're about, right now we're about 17 people, company-wide, so it's still small, but at the same time I'm still in support, I'm still in, but what's different is we have managers now. We have specific sets of people that are leading product, that are leading engineering. And so what that means is, I think personally how I've changed is letting go of the reins and really allowing the team to specifically make decisions on product and spec. And I think that's really important, right? Because you want to make sure that the team feels like they have the autonomy to make decisions. And secondly, that anytime they need help, they're able to be unblocked. And so I think one of the things that was pretty clear from the get-go was, how do I become a team enabler versus the other side, which was just basically getting things moving and executing. So for me and even for Seya, I think it's my co-founder, I think that's really been key. Exactly. I mean, I've seen a lot of what I would call product CEOs. I consider myself one, which is okay, we know how to build something, we're in the trenches, but it gets to a point where those mental models just don't scale. And if you want to grow your company and your product, you have to become an enabler, more than just a doer. So I've seen the transition go in very different directions. And I love asking this question because there is no right or wrong answer. You have the opportunity to create your own job description. And at the same time, I want to know if there are any specific productivity tricks, hacks, or call it X, or is there any way you actually leverage your product to make sure that your team feels empowered and they can also nurture that next generation of managers? Yeah, I mean, so we've been day one users of our own products. So we used Tara for our documentation, our sprints, and also to understand team velocity. So I think one of the things that happened was because we were such early users of our own product because we felt the frustration too when we had missing features, that was something that the team, like because they had the autonomy and obviously we were using it ourselves. Firstly, we also saw the difference in productivity internally when we were using it versus when we were using other tools. So what happened is at least I observed that from a team perspective, people had more belief in the product as well because we saw the difference in productivity. We saw how we were able to very quickly, you know, like ship features in terms of like into our release log and basically get into a cadence of listening, understanding why someone is asking that question or why they're giving us that feedback and then try to iterate with that. And so for example, like we have a Discord community where specifically our users give that feedback and we have these discussions, we even, you know, do design discussions with those users. But I think what it really boils down to is from a productivity perspective, like how do you, like so we were using our own tool, but internally what we also did was we did things like making sure that we're able to specifically be as transparent as possible in like all hands and meetings on Mondays. We set a cadence and a routine as well. Like I think setting the cadence is really important in the early days, especially in the first two to three years of the startup, which is where we are today. And setting that cadence, making sure that people have the ability to provide upfront feedback. So that means that you need to be willing to hear the bad and the good from the team. And I think that was something that was really powerful when I heard from, you know, from like specific engineers that I'm actually able to say what I think doesn't work or, you know, or to make suggestions even like from a strategic perspective. So I think that was also a change that we went through and it took us some time. Now personally, from a productivity standpoint, one of the things I like to do is office hours. So, you know, like setting specific times during the day. So I have a public calendar. Everyone at the company knows what I'm doing at any given point of time. I just like to operate that way. And it really helps because people know what the CEO is working on. And sometimes like being a CEO can be a black box too, where it's like, Oh, what is the CEO working on today or this week? Or what are her priorities? And so I like to have an open calendar for that. I've found it to be helpful. The office hours, I saw my combinator. I love that. And one of the things that I personally learned as well as part of another accelerator program is dealing with so much feedback and especially from customers. And sometimes that leads to big changes in the organization, the structure of the organization, the features that you want to ship. So I want to hear any word stories about if there was any big, you know, learning as you were doing more and more user research and you had to make any either pivot or big roadmap adjustment based on that. I think like one of the things that it boils down to is being opinionated in the way you think the world should work. And so one of the things we did is because we set simplicity as the base that we are always going to work from our process of simplicity. And because if you set simplicity as the core piece, and yes, you know, we have certain values, certain values at the company, but because we set that as the goal, what ended up happening is that it, in some cases, users may suggest features that actually make things more complicated or they may make the workflow more complicated or they request so much flexibility that you're basically, you know, like I think if we shipped it feature by feature and looked at it that way, we would just become another Jira, frankly. So I think like that was one thing that was really difficult and I think one of the things we did was we were opinionated from the get go, but at the same time it was opinionated to the sense that you get your user feedback and you continue to talk to individuals at these companies, whether they're, you know, founders, heads of product, heads of engineering, and you continue to like iterate on that feedback but based on those core set of values that you have. So having that strong set of values is important, but I will say that it's easier said than done. I think what we're continuing to learn is, for example, like A-B testing is really hard at early stage startups. You just don't have the resources. You can't, you know, like ship different versions of a feature. It's just very difficult. And so I think one of the things we really wanted to do was ensure that even when we have design or design prototypes, when we show them to the user, it's crystal clear as to how the interactions will work before we actually implement a design. And so I think like what it just boils down to is really putting yourself into the mindset of the user. And that's very easy for us to do, by the way, because we use our own software every day. I think it's harder when you're not using your own software and you're not the core persona that you're selling to. And at least what I've seen is, and you talked about pivots and like a big change, one big change that actually happened for us was in 2020 was the V1 beta of the product. But before we actually shipped V1, we had several different iterations of Tara. One iteration of Tara was when we thought that we would be more of a top-down enterprise product, which was like, you know, we thought that you would sync us to your existing tooling, which you do today too. But that concept was more for like VPs that they could see like some level of analytics. And what we found, at least, was that when you tried to do a top-down product, you just don't have the bottoms-up momentum or developers, frankly, just don't have buy-in into the product. So you might be able to sell like a half a million-dollar contract top-down and sell to the enterprise VPs. But at the end of the day, the developers using it will just say, I hate this, you know? Like it's been sold to me and I don't want to use it. So that was a huge learning that we had. Where we actually sold a contract to IBM and it was, you know, the developers that wanted to use it. We talk a lot about that in a podcast with other product leaders and I agree with you, this trend has been labeled now as product-led growth, but it's not really that new. What it means is really getting that buy-in from the bottom, which is the people who are going to use your product. And otherwise, it's just going to be very hard to maintain retention. You might be able to sell a contract, but what if they change that CFO who signed the contract? Exactly. Thank you. So it's really interesting. You can get to 2 million ARR really quickly. So you could pretty much, you know, like if your messaging is strong enough and that's what happened to us, right? Like we were able to get to revenue really fast, but it meant a huge change after our last funding round. And I openly talk about this because I think it's something that people don't realize that you really need to think through your go-to-market and your model and whether it actually satisfies the end user. And we realize very quickly that the developer is the end user. And you can't try to build something that is top-down. And frankly, I think we could have gotten to significant numbers of ARR with that product too, but I still, you know, we still maintained that it just didn't match what we wanted to build. It really didn't. We kept going into this instance of specifically only selling to the VP. And, you know, I think a certain product can probably be built in that avenue and arena. But I actually think the future is all about the bottoms-up user. It's the end user that matters. And by the way, it's harder to build that company, let me tell you. So it's much, much, much harder. I think it has more potential long-term, but it's definitely harder because you are trying to satisfy many more people. And one thing that we always repeat is that B2B is also B2C. Like, they're all humans behind those companies. It's not like you step to IBM. Like, there's someone behind that that got that check and there are many other people who are using your product. So I'm glad that you made that, you learned that and you made that adjustment. I also want to focus now on the future and ask you what are you curious about learning these days? I think one of the things I'm really curious to learn about it. So I spent quite a bit of time in AI ethics and specifically around how you can build ethical algorithms. So one of the things that we also learned is when we were initially designing Tara, we were thinking about a no-interface model, which was, oh, could you essentially populate a task board, populate a Kanban board with very little input from the user? What we found, interestingly enough, is that user input is very important when you're trying to generate any type of recommendation or provide an interface to the user. Because if the output that they're seeing is not relevant to why they're in the software, again, it goes back to the fact that they're humans. It's human-computer interaction, right? And so if it's just not relevant to what they're looking for, then they're not going to come back. So I think one of the things that was a really important learning for us, and one of the things I think is how do you build de-biased algorithms that aren't taking information from data sets that are inherently biased just because of user behavior? So I think that is something I'm really keen to continue learning about as well as we introduce algorithms into our own software. Because we're very hesitant, to do any kind of intelligent part of the software, which is essentially saying that, oh, Tara is saying basically that, oh, I estimate that your sprint is going to take this long or that the effort estimated in the sprint is incorrect. All of these recommendations have a big impact on the user. And now they have an even bigger impact because we have a user base. But that's something that we're really cognizant of is as we introduce the AI in Tara AI, what will it really entail from a predictions perspective? And because now there is over a year of data in the system for each user and each team. And so we can now use that last year of data to provide recommendations on how you should possibly run your sprints and work in your product. So I think it's going to be an interesting time for us over the next few months. I know there, as you speak, I'm thinking about another famous white combinator phrase, which is do things that don't scale. And how even larger organizations, CEOs, still doing certain things that don't scale because they are core to their values because they consider them very, very important, even though maybe technically are not part of the traditional CEO job description. So coming back to you, is there anything that you still do that doesn't scale? I think one of the things that I believe I'll continue to do is customer support and just talking to users and customers. And I know it's a very simplistic answer, but that's really what it boils down to, where I'm in intercom on weekends, and specifically like manning email support. And I think that is something I want to continue doing no matter what size, no matter, because we are in the post, now we're post series A company. And I have heard from several founders and CEOs that someone else should be handling support. And yes, we do have a support process, but at the same time, I think it's important to continue to talk to users and hear from them. And the other piece also, I think do things that don't scale. Specifically, I think one key area that also applies to is making sure that each of your team members are, frankly, comfortable in these really challenging times. Like, I think one of the other pieces is just making sure that you're available. Even in some cases, if I have to be a therapist for several team members, I'm happy to do that, because I think we're all kind of going through these really hard times. And from just a wider perspective, and I think that was also something that we came to terms with over the last year and a half, which is continuing to listen to team members as they face challenges and making sure we have enough R&R days. Like, we also introduced an R&R day that we got really great feedback on from the team. And last week, we just did our first office Olympics as well. So I think some of the things, in terms of doing things that don't scale, also apply internally for your own people. And I remember one of the things we did was even we built this grocery aggregator when no one could buy groceries at the very early days of the pandemic, just to make sure people could get access to it. So I think it applies internally and externally. It does. And I think it also sets an example for anyone in the organization, including new hires. You are showing how important your customers are. And this is not just about, oh, we close a deal and then we move on. You mentioned support. You mentioned people who are already existing customers and you care about them. I've heard this from other CEOs and how they are trying to scale that process because it's kind of unscalable. You have to reserve time to talk to humans and truly listen instead of just trying to sell. So I really appreciate that from you. So another thing I want to discuss with you is about the future. You talked about how you're thinking about combining AI with humans, but more holistically. We've been talking about project management tools, increasing productivity since forever. The reality is that not everyone is really that much productive, even though they seem to be adding more and more tools to their stack. So what do you think is going to happen, especially on product teams, to truly become more productive? I think ultimately what it boils down to is that a lot of the management piece and the updating of tasks and the specific issue management piece, I think frankly needs to go away. I actually think that the future is ticketless. We haven't really talked about it publicly, but internally what we do know is that ultimately the future should be ticketless. The way it should work is you have systems kind of talking to each other and the root source of the ticket is either through customer support or it's through source control in terms of a specific issue that's being worked on. So I actually ultimately think that project management software should not exist. And it's funny because it's like, are we saying that we're going to put ourselves out of business? No, what we believe is that you should not have to go in and update issues and tickets on a day-to-day basis. It's incredibly frustrating and it's so painful. And the thing is that the only reason we even provide an interface to do this is because we want to do away with the interface over time. So it's interesting. It's like that's our goal. And I mean, if you think about Tesla, right? They did provide a car, you know, ultimately to get from point A to point B, there is a car that you can use that you can manually operate. And so that's our theory too. It's like we had to provide the project management software initially in order for us to get to a point where it's self-driving. And so ultimately that's our theory that product teams should not have to go in and it goes for developers, it goes for PMs. You should actually be spending time solving problems. And that means, you know, solving the customer problem. And so high level, that's what we believe. And I think that's what we're really working towards in terms of as we design and build TARA. Initially, I remember we were thinking about it going without an interface less and going without an interface, but we realized very quickly like you need an interface initially and then you can start to really get to that ticket list piece over time. That's a great point. I think we talk a lot about tools. And obviously they are important in order to get things done, but beyond the tools like the methodology, the framework, the community around it, really making sure that we understand what we're here for, which is in your case be more productive. That's the goal. Then maybe the solution is actually less tools. And if you can apply technology to make it easier for people without them having to really understand every single step of the process, I think that's when the magic happens. Because I agree with you. I don't think the machines are replacing the humans, especially the product managers. Exactly. I think at the end of the day, one of the things that we see with PMs, especially is that they're having to do a lot of the sprint planning, a lot of the just management and consistent reprioritization. There's always new priorities coming in based on user feedback. And so I think a lot of the grunt work is what we're thinking about. And I'll give you a really good example of a super simple feature that we automated. So when a pull request gets merged in GitHub, based on the workflow, it should automatically be marked as done in your software. And you shouldn't even have to set that up. It should just be something that software inherently does. And we were just surprised that even any PM tool, it's something you have to set up. It takes weeks in order to do so. And so that was something that we shipped under the hood, under the radar. And we got such great user feedback about it because it's like, okay, obviously if the PRs merged, the developers shouldn't even have to log back into the PM software to update the status. Status should automatically update on their own. And in some cases, even the documentation should be pulled from the .md file from GitHub or even from what's already happening inside GitHub and commenting. So ultimately, I think, you know, it's time will tell, but like we have a very strong theory and an opinion around how PM systems should work. And I think one of the things that one of the reasons why we've been able to get to this point even today is because we really believe in this future. And that ultimately PM systems should make you more productive, not less. And you shouldn't have to have an administrator just to, you know, even run the software. I agree with you. It's part of the future. It's... We have a report every year. It's called the Future of Product Management and we analyze some of these trends across so many different companies and product leaders. And it's no code movement integrations and trying to make things in general more visual and less complicated are increasing productivity and happiness. So I hope things keep going well. And I'm sure I'm going to keep track of anything else you would like to add. I think overall, you know, at the end of the day the best systems are the ones that do not require setup. Like I think that's what it ultimately boils down to. How do you build systems that inherently understand your need and what you're trying to get done from a productivity perspective and then immediately generate those views around that common goal. And so I think what it really boils down to is based on the person or the type of goal that you're trying to get done. You should be able to utilize the software accordingly with very few clicks. And I think one of the things we're really excited about is how do we start to really enable that and surface blockers and surface that before they even happen. So I think getting into that ticketless future and we're already starting to iterate on that idea. I think we're really excited about where it's going to head. Some of the new automations we've released. I like the ticketless future. Think about that. It's a pleasure to have you on the show. Thank you so much for your time. Thank you so much. It's been great being here. And thanks everyone.