Jake Kim: I kind of ran out of money to support us, I was like, and you know what? before I go out, I'm just gonna like put the final version of my vision out there and see if that gets any traction. And when I did that, I think we were able to find customers who believed in us, find VCs who, wanted to invest. Niklas: Hi and huge, welcome to you, my lovely listener. So glad you're here. Today you're joining me for chat with Jake. Jake is the founder of Zero AI, which builds Agentic TPM. Agentic TPM, what is it, Jake? Jake Kim: Yeah, so as engineering organizations adopt more AI, there's a lot more coordination that needs to get done. there was a role for it, right, in larger organizations called TPM, technical program management. you can say almost every company beyond 300 employees have a TPM equivalent role, whether it's called TPM or an EPM. I know a lot of companies are like trying to solve this space and calling it different things, but our philosophy is hey, like there's already a hundreds of thousands of people doing this job, right? so we want to kind of help extend their coverage to the agentic realm, right? because before they only had to coordinate human effort, now they also have to coordinate all the downstream agents. so we're building the infrastructure for that. Niklas: think this this is actually very challenging and it's also a space that is evolving very, very rapidly. before we dive into the space more, I think it's also interesting what led you there. So maybe I would be really interested in your journey. Jake Kim: Sure. So before starting, Sarah, I was an engineering manager at Apple. I was a part of the ops organization where we built data collection software that collected data from all the Apple's product lines like iPhone and iPad, so on and so forth. That means our software was on a critical path to launching iPhone, launching iPad, and so on. we worked with a lot of like world class TPMs there. And I think that's when I really learned about the role of a TPM, how important it is at scale. and when I had this kind of counterintuitive thought that hey, like with AI, people are gonna think TPM is gonna be the job that gets replaced first. But in in in reality, it's gonna be the hardest thing to replace because you have all these vertical agents like coding agents, design agents, product agents, right? a TPM agent is a a TPM inside the company is a horizontal function. so it needs to be able to coordinate work between all those functions, right? and I saw that there's a gap and it's largely misunderstood. So I thought it would be a good opportunity for me to Niklas: I think especially if we look at these more complex roads, a lot of a lot of companies have tried to replace workers. And I I looked at it, I remember that was one of my first topics that I looked at back in twenty twenty-three, beginning of twenty-three actually, when like chat GPT started to take off and people were seriously considering that. We I thought, okay, yeah, there must be a way. You give them company loadage, you build some AI employees. And then I watched some startups in the space, and I'm still watching them. And my at least my feeling from the sideline is they are not really doing this well. So they they have settled on these AI SDRs that I s that I see a lot. And then when I talk to people about it, then it's a lot of Cold outreach via email, and at the end of the day you just get r roughly spoken more spam. So so you have Jake Kim: Mm-hmm. Niklas: to kind of the the it's a crazy competitive market to do Jake Kim: huh. Niklas: like automated outreach. It might work for a while, later on it won't. Then on the other side, it feels like especially these these roles like what you're tackling, the progress is not that large to be very clear. careful. They aren't solved yet. What what are the real big challenges and what will you do different? Jake Kim: Yeah, so surprisingly, tackling agentic TPM is very technically challenging because by definition it's a horizontal and cross-functional role, right? so they have to understand like code bases, like design, and so on and so forth. And while there's like like code bases for developers and Figma for designers. There isn't really a tool for program managers other than you know, you might say Jira and Linear, but those are projects, right? Programs are different. Programs are kind of longer running things that the company wants to get better at. and I think the thing was before companies never had to had that many programs to run at scale. But now with AI, almost everything becomes a program. because you know people are moving so fast they're not talking about features or products anymore. Right. the way we work in our company is we kind of give everyone like a track to own. you know, whether it's like long horizon KGQA, which is like knowledge graph agent, or you know, making CERO really usable, right? Could be a program. So what's challenging is programs Don't have a native data s d database yet, native system of record yet. And programs are one temporal, meaning You have to be able to like trace decisions back, right? a code base isn't just a snapshot for TPM. it's how what decisions were made, why we made certain sacrifices here and there, when we decide when we thought we were gonna like tackle it later, right? and like finding out all the dependencies over time. So it requires infrastructure, temporal storage infrastructure. and i for the agents to be really good at navigating it, right? And and this is a really difficult problem that I think a lot of companies are solving with like company brain and like shared memory, but not in our domain. Niklas: Yeah, would even if I if I look at like more classic industries, I would say it's it's a lot of manual work still. And and it's also like if I look at program management like in a classical corporate, it's a lot of requirements, gathering requirements, coordinating people, and then obviously building the the work packages, breaking it down, as you said, like like doing this. What I would be really wondering about is You need a lot of company knowledge to do this, right? So how how do you plug into the existing systems? Well how do you get this knowledge this is very company specific. Jake Kim: Yeah, we integrate with almost all the tools that the company uses. when we go in and what we're finding is TPMs and engineering leaders are very welcoming us, you know, connecting to as many sources as possible. we connect to code bases, meetings, docs, ticketing systems. and chat. Niklas: If you if you think about a gentic TPN like in a very simple way, how would you define it and how and why might it even be more infrastructure than something job threatening? Jake Kim: Yeah, Agentic TPM it's important to distinguish is technical program management, not technical program manager. when we say agentic TPM. There's more demand for T PM than ever and that is outpacing the amount of T PMs there are in the world. There's a hiring freeze with TPMs. I'll give you a real example. the company we're working with has two TPMs for a 300-person organization, has 75 recurring reports. Right. So you can imagine these like you you can imagine how AI has helped the coding people, the design people. But middle management, they're still staying up, you know, like trying to drill into like the statuses and so on. with AI, with Cloud Code, they are you know now doing a lot of prompt engineering, but that goes stale, right, very quickly. so what we do is we take all these signals, organize it by program, make it available to everyone in the organization. So like all the, you know, documentation, procedures, decisions, different parts of the code changes get attached to those programs. So that when program managers or engineering managers wanna find wanna ask a question about like, hey, how did we do like tell tell us the entire epic story of our team evolved, right? It can do that in like very fine grain detail. so the first use case we tackled is like long horizon reporting, which other AI cannot do. but I think that's like automating reporting is just like showcasing how we are able to do like long term reports really well, better than like doing it on cloud or any other tool. but it for us internally it's just like a internal goal, right? Like if you wanna have a have TPM agents helping human TPMs and human engineering managers coordinate all the work, they need to have this long term memory of the organization, right? So that you know like you So that we can move away from like one person prompting one agent or like one person prompting many agents, right? We want to get to many people orchestrating many agents together, and there's like a missing infrastructure there. And that's how we see ourselves. that's what humans have been doing, human TPMs have been doing. and we want human TPMs with agents to do that next, but there's no like digital extension of human TPMs yet, if that makes any sense. Niklas: Yeah, a large challenge in all these spaces, I think, is Jake Kim: Mm. Niklas: pro the memory layer. And I would really Jake Kim: Mm. Niklas: be interested in how you're solving that because that's also something that a human program manager would would do a lot, right? They would gather information, consolidate it. So so how did Jake Kim: Mm-hmm. Niklas: you solve it on a technical side? Jake Kim: Yeah, we I think even before knowledge graphs were very popular, we knew LLMs are models, right? and AI agents are only as good as the dots it's able to connect. and you need some sort of like especially if you're doing like long term reasoning, you have to have storage of like past events, right? Past snapshots. so that's how we think about it, where we are building temporal knowledge graph infrastructure and building AI agents that can construct it in real time based on any real time signals and navigate it in real time based on you know real time queries. Niklas: And w how does the interaction work? If I now have the human TPM, I I imagine this working as an assistant for for that person right now. How how would the interaction work? Do I prompt it somehow? How how Jake Kim: Mm. Niklas: does the interface look like? Jake Kim: Yeah, so right now our TPM agents do quite a lot in the background. So first of all, it constructs a Gantt chart of all the ongoing programs for your company. and it maps out all the milestones and it it ships with a continuous alignment feature, right, which continuously checks if like the top five you know fields of like a program definition are drifting, then it would like alert the program manager or engineering manager who's in charge of the program. And then you can and they can add any kind of like prompt based widgets to, you know, alert them when something happens, right? When a code gets like a new PR gets pushed, which might impact this these other programs, right? but yeah, there's definitely a chat interface to it on Sero as well as via Cero MCP on like Cloud or Codex, whatever tooling you use, to extend that program memory to your agents downstream. Niklas: Before you arrived at this, I think you did a lot of pivots during your company. What did Jake Kim: Mm-hmm. Niklas: what did you learn on the journey over the last two years? Jake Kim: Yeah, so when So when I started, I think we had like a we started with a smaller vision of the same thing. we wanted to so back then we were also doing like temporal code base understanding. so the idea was if you analyze the code base and like how and like follow the developers kind of footsteps you can learn about what kind of a developer they aspire to be, right? And the composition of those, you know, that developer knowledge will help you hire better people. so as we were building that, we realized, you know, like actually AI at the time by itself was not able to like get us the results that we needed. So we kind of like di dove really deep into like the the back end portion, like how do you make make sense of like derive this like really cool insight about developers and projects from code bases and like code symbols right over time. And I think that's how we evolved it eventually. one thing I learned is especially as an Asian founder Asian founders tend to fall into this trap a lot. We tend to be very like try to be humble because that's like a virtue in the Asian culture. And we try to tackle like smaller stuff that sound more realistic. but I think we were when I think right before I kind of ran out of money to support us, I was like, and you know what? We're I'm going out. before I go out, I'm just gonna like put the final version of my vision out there and see if that gets any traction. And when I did that, I think we were able to like find customers and who believed in us, find find VCs who, you know, wanted to invest. So that's the biggest thing I learned. So there's no need to be like shy about your vision. Like you should think ahead. Like if you were successful all the way through, what would you be building? and and and and work on that. Niklas: Yeah, I think for venture capital it's very clear, right? So the VCs like in basic math, they should only invest in companies that can return the fund. So you need a market that will become large enough, like if the company is successful, that is large enough to return the fund. And therefore you you can You need like the big vision because otherwise you cannot invest in the company. So I think this is clear. On the other hand, the bigger the vision, you you cannot forget the small steps that you need to take to get there, right? Jake Kim: Mm-hmm. Niklas: And I think this also changes a lot over with with at which stage you're raising. I think precede seed probably a lot about the vision, about the product, about the team, series A probably more data driven. So so what Back from the big vision down to the smaller one. So what's the product that then actually got like the first customers or first users that were really interested? Jake Kim: Yeah, so what got us the customers were reports, high ROI reports that companies do with a lot of manual work that couldn't be done with you know Gemini or Cloud Coast. So there was one very specific report called R and D documentation. So in US and Canada, companies can Claim credit for developer salaries. And that's millions of dollars for companies, right? But to claim that you have to provide a audit ready documentation on whether or not like at every given date, right, if a developer's work qualifies as RD or not. Right. But because we have that temporal infra, we were able to produce that report. so we could go into large enterprises and be like, hey, we're tackling this really big problem. you have a frozen headcount on TPMs, right? But the work is piling up. We want to solve it, we're not there yet. But one of the things, one of the reports it's able to generate will pay for itself. and so we and now we're at a place where we go in and after they integrate everything, we detect all their recurring reports and automate them like day one. And we're also able to do R and D documentation, right? which we worked with PWC on. so you're right, like Vision itself for customers doesn't really mean much. but I think it's a combination, right? Like you have customers that believe in your big vision, but also you have to provide them with like enough like substance so that they can champion you to like their leadership and be like, hey, actually these are the like concrete ROIs we're able to deliver, right? and and then do what the teams want you know like over long term with their support. Niklas: If you if you look at this, I think this is a very interesting space in B to B. how do you think about distribution and pricing for something that kind of sits on this coordination layer in between? Jake Kim: Yeah, we try we're not like trying to be prop very profitable right now. so we basically charge our infrastructure costs and usage costs. and for large enterprises, we charge by program usage. So so the any program that is tracked and human managed, we charge like a hundred dollars baseline. And if the usage increases, we charge for the overages, kind of like cursor. and then there's like a infrastructure cost because they want dedicated infrastructure. which is which depends on like the size of the company. For startups, we are actually about to launch a startup tier. we charge like 45, we are gonna charge 45 dollars per. Per seat and then overages beyond. So kind of like cursor. Niklas: If you I think there's has been a long discussion around is a software as a service dead? Is it alive? How will it continue? What's your take on this overall situation in that market? Because you're going into this classical proceed pricing, I think. Jake Kim: Hmm. No, so for enterprises we're going for per program, not per seat. And that got a lot of good feedback from our enterprises. because we're kind of aligning to their outcomes. You don't you don't want a program where you can't justify a hundred dollar a month, right? so our customers find that's very unique. And we do unlimited seats for enterprises. For smaller companies, we don't do that because we I think for smaller companies, programs is a kind of a new concept. and also you know, we don't wanna have that kind of like minimum threshold that they need to use us for. but it it is a little bit challenging because You know, maintaining a knowledge graph is quite expensive. because it continuously like builds memory for you and then like raises it up for you for you to review. so like a lot of AI running in the background. So yeah. so we we wanted to do like some usage based pricing for startups where you know like we can just pay we we just like don't eat into the costs, but like as cheap as possible, basically. Niklas: We've we've seen a lot about I think vector databases in the past. Now you're talking about like knowledge graphs. Why why not focus on like the product of a knowledge graph? Why did you decide to go into this eccentric agenc TPM layer? Jake Kim: No, we we we thought about it. I think we started out with a real problem that I wanted to solve, right, in the world. And knowledge graph was like a you know like a natural, you know, technology for us to reach to. and then at one point we realized we're doing knowledge graphs really well. But the thing is, every knowledge graph looks different for every use case, right? you and And even though we're doing really well with like program native knowledge graphs where it's like long running initiatives tracking knowledge graphs, and like we're really good at like resolving conflicts in real time. But there's so many use cases that like other like for instance, if you're trying to build like a coding agent, right, there's no need for it to like know the entire context. like of the past, like who did what. Right. It just needs to know every code right now the best. Right. Like what what it could impact. So the focus is different for every use case. So that's why we were like, actually no, this is gonna be really, really challenging to like succeed as a knowledge graph company. Because it means what we're gonna have to do what we we've done for Cero for every company we support. and that's gonna be really hard. Niklas: If you look two to three years ahead and you look at fully nat AI native engineering organizations, what will a Gentic TPM look like? What will the organization around it look like? Jake Kim: Yeah, so It's not hard to imagine a world where the enterprises want to manage the system of memory, right, for AI. Can you could you agree with that? I think l large companies, for instance, like if if there's like a system of record for memory, which every agent in your company subscribes to, it'll need to be managed in large enterprises. Right. so that's what we're building. We're building kind of AI that reconstructs history by all the initiatives going on that agents subsc agents subscribe to. and this is really important because the big, big future vision that we imagine is like If you could really have like a AI native org and had AI as not just like agents but like as part of your team, then you want one of those roles to be a TPM role who you can like who can help you make sure everything is ready to get shipped, right? I is this feature ready to get shipped? hey, have we checked with that team? Like if if they're okay with us releasing this, right? And that TPM agent will probably do a lot of like context preparation for downstream agents. Right. Like, hey, like, remember like to take this design context from this team that they published, right? and hey, remember like like actually Jake just had a discussion with Sid about, you know, this new way we're gonna do things, right? So we see ourselves kind of filling that gap. and and that to us is infrastructure. Niklas: Yeah, I I agree. So when I back back in the days when I did my PhD, we we looked at planning processes and we used something called ontology, which is a concept in informatics, also to con construct graphs that represented relationships between entities in a planning process, for example. So so I think there's and I I think that also Palantir calls their information layer ontology kind of because this this way of like separating information and building these relationships in the information that you have in an organization is I think it's really challenging. I think it's a huge topic as you said, solving agentic systems in larger organ organizations is processing context and generating the right context at the right time. and to do that you obviously have to know that this context exists first. So I think this is this is really big. And also I think it's really challenging for organizations and itself, not only in your your respect, you're already saying it's very hard for different use cases, but in general for organizations it will be really challenging to make the knowledge accessible. And they obviously will want this proprietary knowledge and process it that are their alpha. They want to keep it in house. So th this is also like keeping building a company that can do this kind of stuff in in any form. I think it's really challenging and interesting. If you have like TPMs listening now, what what would be a concrete recommendation for them to get started on this way? Jake Kim: Yeah. So a lot of TPMs we reach out to have shared with me that they feel threatened by the development in the AI. I would say have more kind of confidence in like the role that T PM plays in large organizations. it's an essential role which is which serves a horizontal function. Right. It's the only horizontal function in engineering organizations. which aligns all the vertical functions. Without it, you have like regardless of speed, everything cancels each other out. Right? It's a innately human function also. And I think you should think about how how can I extend my reach and my impact, my influence as a TPM to the downstream agents of like the developers and different teams, right? without having to be physically there. Right. How do I design a program in a way that every engineering manager, product manager who's running a program can leverage it? and ha run better programs, right? Without adding new processes. How do I give that, you know, like long term memory, long-term visibility to leadership, right? And and engage your leadership with this conversation, right? engineering leaders would really appreciate If you're when you're thinking about these challenges and like thinking ahead and yeah and just being kind of forward thinking instead of like worrying too much about the job security. Niklas: Really interesting take. If people wanna try Sarrow, where will they find you? Jake Kim: they can find us on Cero dot AI. and if for this show specially, if you reach out to I guess we'll create a coupon code for Nicholas, and then we can get fifty percent off first first month. Yeah. Niklas: That sounds awesome. Jake, thank you so much for being on the podcast. It's been a fun conversation. And to you, my lovely listener, see you next time. Jake Kim: Thank you.