Building GitHub for Product Management: How Momental Uses AI to Find Merge Conflicts in Strategy

Welcome to Just Now Possible with Theresa Torres. My name is Mattias. I'm a co-founder of Momento, which is like GitHub for product management. I'm mostly focused on the product and tech side, and I've been a product manager for about 15 years, companies such as Epidemic Sound, Spotify, Google. And yeah, we've worked with AI since about 2022. So definitely a passion of mine. I'm Charlotte. I do product and everything else for Momento, which is right now I'm fully focused on our design partners and making sure that we're ready for launch, which is pretty exciting. I also have a background in product management. I started in 2014. I got my first role as a product manager at Spotify, and then that's been going on. That's 12 years now, and I've been doing the past 10 years as a product management consultant, helping lots of different companies in Stockholm, Sweden, where we're from. Excellent. There's a lot I heard that I already like. I want to get into design partners. I want to get into building with AI since 2022. I definitely want to get into what GitHub for product managers means. So why don't we start there? Yeah. So developers have always had GitHub where they input all their code. And now we see that all the tools they're getting right now in development with Cloud Code and Cursor, it's all based on GitHub and that they have one source of truth that they can base it on. And what we realized is that a lot of the problems in product management is related to different people believing different things of what the reality is and what goals you have and what decisions have been made. So what we do is that we help product managers know what to build and why. And one way we're doing this is that when people add their documents to our platform, we look for conflicts, just like purge conflicts. So we can say, oh, this team, they said in their PRD that they're going to focus on increasing retention. And then this other team who also added a PRD, they say that the most important thing right now is to improve conversion. Then what we do, which hasn't really been possible before, is to identify that, okay, here's a logical conflict. They could be coexisting, like you could have different teamwork focusing on different things, but it could also be that you're completely misaligned here. So that's what we call like a merge conflict in strategy or in product strategy. And that's the GitHub analogy and where it's coming from. Ah, this is more interesting than I realized. I thought it was just going to be, I thought you were going to talk about like, I'll share one of the things I hear a lot because I've been writing a lot about cloud code is everybody asks me, like, how do you keep like cloud from destroying your stuff? And I'm like, well, it's in Git. And they're like, yeah, but I don't know how to use Git. So I thought you were like literally making it easier to use Git for product managers. But I think what I love about what you just said is it's more around like alignment of strategy, coherence of product. And this really resonates with me because one of the visions I had for the opportunity solution tree is if I have one team focused on retention, and that's what their tree's all about. And I have another team focused on conversion, and that's what their tree's about. There's always overlap in the opportunity spaces. And so the question is, should one outcome take precedence? How do those teams negotiate those boundaries? And like the vision in my head would be, they should both be looking at their trees, seeing those conflicts and having a conversation about it, right? But I've never seen this happen in practice because it's really hard for teams to get together and see those conflicts. I think it says on data somewhere that product managers spend about 60% of their time in meetings. But even those 60%, if that's true, which it resonates with my experience as a product manager, that's what I've seen. But that's a lot of time. And I don't think even that is enough to cover all ground, to sync with every stakeholder, to sync with every other PM that you need to check dependencies with. And at the end of the day, you don't know what you don't know. So even if you happen to be aware of a sort of a conflict, not meaning a conflict where you're angry with each other, just conflict of interest or conflict in your data or conflict in whatever you're doing, that may prompt you to set up a call. But if there's a gap, meaning it's something you don't know you don't know, you're not going to set up that meeting. So we're really trying to build a system to track all the learnings and the decisions and how they relate to each other. So you don't have to have those unnecessary meetings and instead can focus on what actually matters to you as a product person, which hopefully is what does the user want? And what are we trying to achieve here at this company? And also one thing you mentioned that you set up like Git for Cloud Code. And I think a lot of people are trying to figure out like, how do I provide the right context to my LLM? And that's part of what we're solving. Because when you input, figuring out what to give to Cloud Code, that is product management. And we see that for a company or an enterprise to figure out what context should they give to provide their agents that are going to start working with the context that you have, and you need to make sure that everyone has agreed on what it is, and that it's aligned, that it's no conflict, so that one team's Cloud Code focuses on improving retention, while another is focused on conversion, because then they're going to be conflicting because they can't see the whole picture or have these discussions. Yeah, there's so much that's interesting here. And just in terms of like identifying conflicts, how do you resolve conflicts? But I think what I love about what you're describing is these conflicts happen all day, every day in an organization. Just conflicts, like I also imagine this type of system could help with spreading ideas in an organization. So before we hit record, we were talking about the opportunity solution tree and how Spotify developed a similar idea, I forget what they called theirs, and how like even those ideas spreading within a company can happen in two different ways. And maybe I think conflict is too strong of a word in this example. But like, especially as a company size grows, keeping everybody on the same page, whether it's avoiding conflict or just spreading good ideas, gets harder and harder. Yeah, and I mean, we thought a lot about how do we actually map out context? What do we actually, what is it that a company do? And what does a product manager do? And what are you creating in your work that is so tangible, that it can be broken down into small little pieces that we, an AI can pick up and work with? So we came up with this chain, we call it the product chain, which is basically that we start off with a signal, basically data. And from that signal, you're going to be able to extract some type of learning. And from that learning, you typically have a decision coming out that you're going to do something or not do something or commit to something. And if that learning is, can be generalized and repeated, that's really a principle. So we see that as the product chain, and we use it all the time. And it turns out that it's a fantastic tool, not only for people, I think, the people we talked to, but also for AI that can really track down this chain to understand the root cause of a decision. Then since, I mean, what we're doing, I mean, you've mentioned spreading ideas. What we see is that when we take documents across a company or transcripts from meetings that happen within a team or retrospectives, sprint planning, everything, and you put it in, and then we map it to this, we start seeing, okay, here was a decision that you made, just you're aware of it. And here's how the AI maps out, momentum maps out how it connects to what it can be based on. So then when things change, we can alert the user and say that, hey, you know what, this learning or you're basing this decision on that users love your new feature, but actually new data came in and it says that they don't love it. So maybe you should revisit your decision. Okay. This is great. I, you know, there's so many things, like I love that, like I think about context all the time. Like Matias, that's like something that I'm like, oh, I'm going to love this conversation. Charlotte, you just hit on something that like, I'm a little bit of a critical thinking walk. Like I nerd out on John Dewey's book, How We Think, which like he describes this really specific and very, very archaic knowledge, like language, this way of like understanding the priors that your belief depends upon. And I almost see it as an opportunity solution tree. Like this belief is a function of these prior beliefs and this idea of like, you're making a decision that was based on these assumptions, but I have data that suggests one of these assumptions is wrong. You're almost scaffolding critical thinking in an organization. Yes. Yeah. We're going to have to make sure that we stay on track because there's a lot of ways I can nerd out with you guys on this stuff. There's one problem I see from a product standpoint, maybe you can help me how this works. So like, let's say I work at a company and I love the idea of what you're doing. Do I have to put all my company documents in your tool? Like I already use Google Drive or SharePoint or OneNote or Confluence. Like how does this work in practice? So it does connect with Google Drive, Notion and the most common tools, or you can just upload. And then we recently added a new feature that we weren't sure. It was more, most for our own convenience that we wanted to add stuff that we're having because it's just the two of us, but we added just a record button. So you can just, whenever you have a thought, wait a minute, I want to decide this or, oh, this is actually one thing I was thinking that this is a constraint we need to consider. You can just hit your record and it's also added to your context. Yeah. I think this hits on one of the sort of learnings or insights we had about product management or companies in general, which is that most knowledge is actually in people's heads. So it's not going to be in documents. And even if there are documented truths and even single sources of truth, it's going to be outdated. So having this ability to have a, so right now you can record, so you can record for your meeting or you can just sit and talk to the app. But also having further down the road, we're planning to have the ability of sending out an agent that can interview people for you. And we think that's going to be a very big part of gathering context in an organization. And even you can even imagine a scenario where people would record their standups or maybe certain parts of the standups. If you also have the sort of a social gathering, but recording the parts that matters to organization. And then you can very easily see those standups almost becoming like a real time update for the entire organization as AI is very good at summarizing those standups to the next layer. So it will, I think it's a very interesting way of thinking about capturing information, audio. And one thing we also see that we can do is we can look at, look at the whole map. Like it's a living map on what the product, the state of the product and the plans for the product. And we can see that as you, as we discussed, we can see that, okay, here is a decision, but where's the reasoning? Why did we make the decision? And we're going to notice that, send out a prompt, prompt the user to just answer the question like, what did you think here? And then they can hit record and add information as it goes. Yeah. Okay. So there's this concept that's starting to gain in popularity called the context graph. Have you, are you familiar with this term? Yeah. For listeners is this idea of like, how do we document not just facts about an organization, but the decisions that are being made. And this is often what is not in our documents. And I think the original article gives an example of like Salesforce might reflect that this customer has a different price, but it doesn't reflect why they were given the discount. And when I read this article, I laughed because one thing that I personally have been experimenting with is I now work all day, every day at a Claude code. And I have Claude, I wrote a skill where Claude documents every session in a document called process notes. And I have a process notes for literally every project that I work on. And it's like a running decision log. And what this has unlocked for me is now I can say, Claude, look across all my coding projects. What are the most common decisions that lead to dead ends? What do I need to learn from that I can stop wasting my time? And it's this really amazing reflection tool that I do nothing to maintain other than I have to remember at the end of my session to type slash process notes. And I could see how this could be really powerful across an organization of just how do we think about thoughtful capture so that it becomes inputs to our intelligent brain that runs the organization. Yeah. And I guess that one problem you run into fairly quickly here as an organization, I think it sounds like a really great system that you have. And I have something similar and I think everyone probably should as you really want that long term memory for the model to be able to operate effectively and learn from its mistakes in a way. But as an organization, you may end up having millions of these. So even with the best rag techniques, research show that the retrieval rate of retrieval quality, I guess you should call it, it goes down a lot. Somewhere after 50,000 documents or chunks, whatever you call it, it's going to go down and it ends up somewhere around 12% as effective as it was from the beginning. So this has been one of the challenges and I think it will be one of the big challenges here now for 2026, 2027, when more and more people and companies realize that it's not enough to just feed the AI with 200,000 documents. You need to actually be quite picky about what you say and that it fits. And that's why we ended up with this GitHub thinking that if you, because if you have a truth somewhere that says one thing and you're going to focus a lot on onboarding and then there's another document that says that no, you're actually going to focus much more on growth or whatever. That's not the best conflict example, but the AI may be confused because both are literally saying that's going to be your main focus. And then you have confused AI and you're going to have really low quality output. It doesn't matter if you're using flawed code to write code based on that, or if you're writing private briefs, it's going to be much lower. So you really want that consistent truth and you want a quick, fast way to retrieve vast amounts of information. Yeah. You know, okay, so there's so many topics here. Like we're getting into context and just how do we, how do we even find the right context? We're talking about limitations with a rag and with embeddings in particular. I was just reading a bunch of the research on context rot and like one thing that stood out to me is that like with chunks, if you have a chunk that's small and it's in a vector database with a lot of big chunks, it doesn't really matter how relevant that small chunk is. It's just less likely to get returned just because it represents less of the data, which I find fascinating, which almost seems opposite of the like needle in a haystack benchmark tests that get run. And I think like we're, what, a couple of years into this, a lot of this we're learning empirically by people just running a lot of experiments and figuring out what we get out the other side. I can imagine with your product, like this is one of the things I'm always curious about. Your product could have a really large footprint. We're going to take every document on a product team across the organization and look for conflicts. I know you're early. You said you have design partners and you're getting ready for launch. How did you define your, and even, how did you identify and then ultimately define your starting point? To be honest, I think our starting point was already in 2022. We, as soon as we got our hands on the first OpenAI model, we applied to get access to DaVinci 002, which was, I think it was one of the GPT-3 models. So it was not smart at all, but it was still exciting. And I remember that I took a conversation, I was having Slack with a stakeholder and I added it to DaVinci and you had to give it quite a lot of context. It wasn't that smart and it could just answer questions like it can do today, but it could do completion and it completed with what I was supposed to answer and it was not too far off. And we were like, okay, this is going to be big for product management and what we're doing. And eventually it might be able to do my job. But we started, so we started developing then and we built a prototype where we did the whole thing of help me define my metrics and review my product brief. And we went out to the clients that we were working with then and showed this prototype. And it was pretty interesting because the reaction we got then was, I don't like this at all. The thing I pay my product managers to do is to think, and you're going to leave that to an AI, that's stupid. And it's pretty interesting now in hindsight, because Throckmick's slogan or tagline is even your thinking partner. We were a bit too early, I think. And yeah, it didn't work right in 2022, but that's when we felt like, okay, but we should do something for product management. Yeah. Well, it's interesting that first reaction. I remember that. I had the same with the customers that I interviewed or potential customers. And it was almost like something offensive about the fact that not only is a computer better at doing calculations, it could actually be to some degree replacing your human creativity and thinking. And obviously this has been a big debate in the past few years. And I don't think we're anywhere near that yet, but it was incredibly offensive to the people we talked to. But now I think we're nearing a point in time where we are able to build something with the right context that can greatly strengthen a product manager and make us faster and more efficient. And that's a very interesting point in time to be at. I think people probably overestimated this AGI is going to replace everyone theme. Maybe it will happen in the end, but after sitting a lot with this right now and reviewing output and comparing output between people in AI, we're far from it, but with the right context, we're closer at least. I have another to add back to the question that you were asking, like how did we decide on the problem? I think, I mean, we always had this, we should do something for products. There are so many problems in product management that we know well, we want to solve them, we can solve them and we're very well positioned to solve them. So when we started out this, or we started out last year, we were thinking that what if we create a product team of agents. So that was actually a starting point because it felt like if we can do that, I mean, we will solve a lot of problems. We will solve alignment because they're going to align between themselves and they're going to do a lot of the boring work and they're going to help us. And that was actually where we started. And we got like fully functioning team up and running. We had a developer agent that was cleaning code. We had a product manager that was doing slides and doing sprint planning. And they felt pretty human and it was working and they were doing handoffs between each other. And whenever we made progress, we, they, it felt with our extended teams, we were writing on Slack, Hey, we got this call with a customer and they went, yay. But what we realized was that they were their LLMs. So they're thinking fast and they're working fast. So what happened was that they kept asking questions and we're like, this is so much work. We need to answer these questions all the time. And we started asking ourselves, like, but do the questions make sense? Yes, they do. They make perfect sense. A human would ask the same question. So why are they asking all these questions? And that's when we realized, okay, but we haven't solved any problems here. We just simulated a product team, but it keeps having the same problems, like a real product team, which is okay, but how do we align here? What are we working on? What are the greater outcomes? What are the principles we're operating on? And I think that's when we realized, okay, we need to build a foundation, which is momentum. Yeah. So we ended up building a super advanced, curious, outcome driven and very confused product team. So we may be able to use that at some point, but we definitely need to do our homework first in terms of context. You know, your story, like, sounds like it could be the tale of my personal experience with cloud code. Like when I first started using it, I was like, man, you interrupt me constantly. Like why don't you just figure it out? What I realized was like, it can't just figure it out. And I've invested a ton into my local context for cloud. And the more I do that, the more it works autonomously and builds stuff. It's building something for me right now as we talk, which is pretty amazing. Like, and your comment about like, at first, this idea of LLM doing the thinking for you is offensive. I look back over the last three years, it is absolutely shocking how much we've gotten comfortable with this technology, how much we've learned about it, and also how much more is still to come. Like both are true, right? Okay. So it sounds like, Charlotte, from what you described, you had this team of agents and the problem they were experiencing is they didn't have the right context. So they weren't that helpful yet. And that led to your current product, which is all about how do we build the right context? And if we do that, there's also this nice benefit of it can help to avoid conflicts. It can help to like examine flaws in your thinking. I can see this was a very not straight line, but very connected. Yeah. No, I think what will happen is, or what's happening now is that we put out all these agents, and they work really fast, and they're smart, and they are faster than humans. But that also means that it just run into the same inefficiencies and mistakes and misalignments and all of the issues that we're having as humans. But they're much more noticeable because it's annoying when it stops all the time. So I think what we are part of doing and what will need to happen over the coming year, years is that we think work and what are like build really good foundations because agents need them. And I think that will make work for humans a lot better. This is a theme. able to be out there operating and being proactive and curious and outcome driven that the cracks in the wall starts becoming very noticeable very quickly. And because you are essentially simulating a human worker, right or wrong, but that's the agents that people try to build now. So you're going to have to give it the same context as you would give a human. Some companies have a policy that it's okay to onboard someone for three months. That's a lot of information. That you need to take in. And we're trying to shorten that not just for agents, but for people in general. We can do, like I said, more productive and fun stuff. Okay. I want to dive into the technical bits a little bit here. It seems like your product is ingesting a lot of documents, a lot of inputs, and I can imagine this becomes hard very quickly. Mattias, you said something earlier about, I forget what your flow was to a decision, but it sounded like you've already come up with a very structured way to think about like data to decision. Do you want to remind me what that was? And we can maybe get into that a little bit. I'm actually going to zoom out a little bit because I described to you the product chain, which was signal, learning, decision, and principle. And that's the chain of thought for some PMs. But actually we realized that we needed more than that. So we really, we talked about this before we started recording that, but we greatly appreciate the product opportunity, the opportunity solution tree. So we realized we need something like that, like a product tree. We can, we started thinking about it in terms of OKRs at the top. We have the vision and you have the objectives and you have the key results and somewhere it starts trickling down into something that could be described as an opportunity solution tree. And somewhere after that, it becomes epics and tickets and subtasks. And it's this really this gigantic product tree really. And I think a lot of companies that we've spoken to, they don't even have the top part almost, they have the top part for leadership, but they don't know what's going on in their company. So just this tree alone, visualizing what the company does for the entire company with the help of the opportunity solution tree and other tools, that's good in itself. That's going to be excellent context for humans and agents. But you also need this wisdom tree, which is another tree, which is essentially the signals and the learnings and the decisions and the principles and how they are connected and related to each other. And then there's the third one, which is who's working on what and when are they working on what really the time aspect of things, nothing will happen by itself. It's always going to be a person doing something. So if you can, if you can model that with these three trees, you're going to have, you're going to have a very good context. And it turns out that a good advanced LLM, such as Opus 4.5 can extract a lot of meaningful information for all of these. If it's allowed to work over extended periods of time, filling these trees in. And even if you're not going to be able to fill them in fully and have a hundred percent coverage of every single person and what they're doing and every single opportunity and every single signal across the company, just having something is so much better than what most product managers, poor product managers, by the way, having to operate in this constant chaos and information overflow. So that's how we think about it, how we break stuff down. So is the idea that as teams upload documents, you have an agent in the background or maybe multiple agents in the background, like extracting data that ends up in one of these three trees? Yeah. So for the past three years, I've tried to build the perfect agent and we have two right now and they work in the lean startup. They talk about DOOP, which is what was the sort of what the build, measure, learn loop was based on during World War II, the five pilots, if they panicked, they were told that you should first observe and then orient and then decide and then act. I think that's an excellent model for an agent. And I think if you look at the extended thinking or equivalent that Claude and other Gemini and other models have, that's what they're doing, but you're going to have to do that, not just for a couple of seconds, you're going to have to do that over longer periods of time. And so we try to build agents that are based on OODA loop thinking and are able to work on tasks for not just a couple of seconds, but even weeks if they have to. And we have two of those. And one of them is very good at understanding documents and it's not the cheapest agent in the world. It costs some money, but I think the quality is probably worth it as it is very outcome driven and curious and it gets frustrated when it doesn't get it right. And I think this emotional part is really important, that it feels something around what it's seeing and that it is curious and having this agent really acting with sort of like its own agenda, but with the outcome that you're giving it. Okay. I definitely want to get into how that agent works, but you said there was two. Do you want to briefly describe the second one? The second one is what you talk to. So that's an agent that's very good at information retrieval. So we have the first agent is very good at extracting and processing and finding conflicts and gaps and so on. The second one is very good at the information retrieval and really having a large number of tools in order to extract information from our vector databases based on various keywords and terms. And now we're getting into the secret sauce here a little bit, but we have ways of breaking down vectorized data that makes it a lot easier for us to find things that are not necessarily semantically similar, but they should be attached to each other anyway. Say for example, that we have a usability test where they said that they loved visa payments and that's what they love. And then we have another usability test where they said that in another part of the product, in a completely different flow, they just happened to mention that PayPal would be a nice thing to have in the product because that's what they're used to from a product point of view. That's not necessarily going to collide with each other from a vector point of view, but they are meaningful to you when you ask them, what are we doing and what's our company thinking within payment methods? Then you still want to know about both of those. Yeah, OK, so it sounds like you have one agent that's just kind of always processing documents. Tell me a little bit about that processing. Like, what can you share about how is that agent structured? What is it looking for in those documents? I imagine I can see both things being true, that like we can make some assumptions about a company and the types of entities that would be meaningful and useful to extract from documents. And I can also see that each company has a lot of very unique data that might be hard to know what's meaningful. So I'm curious about just maybe just share a little bit about how that agent works. I can start just with relating back to the context graph discussion that I've been reading a lot about. I think it's pretty interesting that I came across those articles and realized like, hey, this is quite similar to what we're doing. But we always started with what do we need to solve and what makes sense for a product organization? And then we realized, oh, here's what we're doing. And we found the technical words for it. And then I come across another article, Mattias is busy building, I'm on Twitter, apparently. And I read this, oh, now everyone's doing recursive agents. And it's, oh, yeah, that's the part. Yeah, that's matches what's how I'm thinking. So we never really thought about it, like from a technical point of view, we never set out like, oh, we need to build this technical thing and explore it. But rather, OK, what do we need to solve to make this make this product work and solve these problems for product managers? And one part of that was like figuring out this whole structure. OK, but what's the mental model of a product organization? OK, it makes sense that you have goals, you have you make decisions, you have the questions you're going to ask are going to be about the roadmaps. We need the time sense. And I think that was a starting point, like figuring out like from our experience, what's the mental model? I think what you realize quickly, I mean, we started with this in a way in 2022 already when we did our prime brief generator that just feeding, we talked about this a lot now, but just feeding it the document is not enough because the document in itself has a greater context that you probably could talk about for months if you wanted to with all the ins and outs. And if I've been at some large tech companies where the comment wars have made it very apparent that even a document can be can be something to be discussed for a very long time and to expect an AI to just pick that up in a document extraction process is that that's setting the bar really high. So just having a traditional workflow where you basically say extract chunks, save chunks, vectorize chunks, that quickly becomes meaningless, especially at large amounts of information. I think it's fine to do for a couple of documents. But if you're going to do this for millions of pieces, little Lego pieces of information, then you really need something that's more intellectual to look at it. And I think we started when we started in 2022, we didn't know the solution, but we know we needed something more. And that's why we didn't continue. When we built the multi-agent system, we realized that, like Charlotte talked about, the agents are very good at gathering information. We gave them an outcome and they proactively try to search the web in order to find information, ask people about the information. So we were like, we need to use that ability of being able to ask the right questions because that's really the key. It's like the Hitchhiker's Guide to the Galaxy. They build this supercomputer and they get the answer, but to get the actual question, that was really hard. That took way longer. So you need something to be able to ask the questions and not just process the workflow. And that's why we wanted to put an agent on the job, a fairly expensive agent, not just the workflow. And then one thing that we do that is like a natural part of the flow that we built is the human-in-the-loop part, where if you input a product brief and we extract documents, you will actually see this is what the agent found. So this is the decision that you made and this was the assumptions that you made. And it's fascinating that when we input, we can have a discussion with each other and we record it, we add it to Momental and then comes, oh yeah, that was actually implicit decision that we didn't really realize we did. And we did, we say we're going to prioritize that. And then it becomes formalized. And I think that is like a really important part to make sure that the context ends up with good quality that you've seen. What did I actually say? I said it implicit, then Momental makes it explicit and that's what's going. Yeah, it's interesting to me that you're framing this as like the agent can ask the right questions of the document. I imagine a lot of that is part of this structure you're talking about, about you have this model of these three trees. You're really focused on decisions and looking for conflicts and decisions. I imagine a lot of this has to do like a lot of what the design of the system must involve, like how do we turn, Matias, as you called them, what do we call it? Lots of pieces into things that the LLM can interpret. And this is something that has come up a lot on this podcast, where people are developing almost like these data models that are like a pyramid, where at the base of the pyramid, there's a lot of raw bits. And then there's some processing that happens to like the next layer up is smaller, but maybe more meaningful. And then that happens again. And then a lot of the design is around how does the agent know which level to engage at or can start at one level and then dig deeper as it needs to. Does this resonate? Is this along the lines of what you've had to do? Yeah, I think it's a good way of doing it. I think there's a lot of talk about graph databases and how everyone should use that. And I think that's one way of doing it. Just do a lot of hops in the graph database. And if you're a meta and you want to ask a very specific question where you put filter on filter on filter, yeah, graph database is good. But I think what you realize with an agent, because they're good at asking questions and they can use tools, they can use almost any database. It's going to be more or less fast depending on how good a database is and how you labeled it and so on. But they can use almost anything if they're given enough time because they can look at something in this ODA loop that we've talked about. They can observe what they fetched and they can decide to do some more digging. And that's an extremely powerful database mechanism that I think more and more people are starting to discover right now. Yeah, I am hearing a lot of people like their RAG step is not just query a database. It's let an agent go search a bunch of stuff and determine when it's found something that's relevant. You know, one thing you just said that made me think of is Cloud Code is actually a really good example of this about you give Cloud Code grep and awk and sed and suddenly it can search a whole code base no matter how big it is. And keep trying until it finds what it's looking for. You mentioned this, though, as databases, though, is do your documents primarily get in? Like you mentioned embeddings and vector databases. Are you primarily using like chunking strategies and relying on embedding search? Is there a mix of strategies? Like what are the types of tools you're giving this agent? Maybe that's the right way to explore this. Yeah, yeah, it's like I say here, we don't I can probably say that we don't use the documents much. They're too long. And as you said, they can be unproportionately important just because they're long. But just because a document is one hundred and fifty pages long, it doesn't mean that it's more important than this single data piece that we are actually basing the entire corporate strategy on for the next five years. Yeah, that data piece is that little signal that you found somewhere in some that's going to be much more important. So we want to democratize the information for the AI in a way. Well, that's one way of thinking about it and giving it a good understanding of what it's worth and telling it what it's worth, not just by feeding it a vectorized sentence, but also helping it understand how it should judge it. So temporal awareness is a word that and content dropped. Our content, it spoils over time unless someone updates it or reaffirms it. I think that's one way of doing it and ensure that the content that you give it is always relevant. So, yeah, we do vector search and we sure, but we do a lot more with it and we do a lot more markup of the data to put it in the grand context and scheme of things, connecting it to the other pieces. And like I said, the temporal aspect and just talking about who's talking about it, I think that's very important. If you have a signal that says our signup flow doesn't work and then you have another signal saying our signup flow is fantastic. OK, which one is it? Both can be true because one was made with customer A and the other one was from customer B. So who said it is a very important aspect of this. You start getting into these nuances of context that as a human, you just take for granted. But an AI is not going to be able to navigate around unless you literally told it to. And if you don't tell it, it's going to start hallucinating. So this is also a way of stopping hallucinations to giving it more metadata. And I think one interesting part here is also what we need to do technically depends on how it will be used and how people want to use it in an organization. So while we can see this amazing context, like context pool where things are really weighted for what they're worth and what should be listened to, we have this within organizations, like should an opinion, if it's companies come with a lot of opinions, should that be valued then like signals and learnings and other things that are from other parts of the organization? So how do you, should you or should we consider who's saying it when it comes internally or should we keep that? That's one thing we're exploring with our design partners. You know, this is something that I think is also starting to emerge as a theme, this idea of, I think to get an AI product really good, the context in which it is going to work really matters. So you're building for product managers, you're solving product manager use cases and what the LLM might need to know, the elements from a document that might be important, the things that lead to decisions might look different than if you were building for finance. And that, that like layer of synthesis is very, you're not creating a like knowledge base for all companies, for all functions. And it allows you to tackle these really specific use cases that maybe would be way harder in a generic sense. Yeah, I think that's true for almost every single product that the more you specialize, the better you can be at something. But then if you really want to generalize, I think this is an excellent learning for startups in general. If you want a common popular question from some investors, maybe not the more experienced ones, but more junior investors is how are you going to compete and react when Google launches this or OpenAI? They may launch it, but there are lots of other examples, but it's probably if it's too specialized, they're not going to be able to do it because they're a mass market company. If your target demographic is at least 2 billion people, that's going to force certain design decisions. We can afford to be opinionated because we have been very specific about the problem we're solving. So I think that's a very good summary in general. And I think this is going to become more important with time. Like I think as software gets easier to build because of AI, we're going to have smaller, more opinionated products. And I actually think that's good for the world. Sorry, Charlotte, go ahead. I was going to say that it's really fun to build for product managers because maybe you felt the same, but designers have Figma, developers, they have all these exciting tools. They work together in GitHub, seem happy about it, and now they're getting Cloud Code. Maybe it's not only for developers, of course, but they're getting Cursor and everything. But product managers have been, I'm not sure really where we do our cozy work. And I think, I hope we can build a space where you're actually excited to work as a product manager. Yeah, I like that. Also, I can't honestly say that I've been to a company where the quarterly planning, for example, has been working well. And I'm going to tell you why I'm saying that in a second. But just the scenario of 50 to 5,000 people trying to decide in real time together what dependencies do we have, what can we promise our board, what can we promise our customers? So you're forced into this waterfall mindset set, even though your instinct as a PM tells you that I need to be adaptive and listen to feedback and be super open to pivoting. And you have these two competing instincts and demands at the same time while expected to plan everything for the next three months in a week. And some companies, they do it with big planning or they use a giant spreadsheet. I never see, maybe you have Teresa, I've never seen it been done correctly. I can't wait for us, hopefully, but for anyone to solve this with AI and just summarize what everyone is thinking. Stop. Just tell the AI and it will summarize it for you because we don't have the brain capacity for it, I don't think. I'm smiling at this example because as a full time employee, I always worked at really small companies and I really did work with like usually an engineering peer. I almost always was the product manager and the designer and we just tried things. We just built stuff and it was a startup and you shipped what you built and you learned from it and you iterated. And then one of the very first companies that I coached at, I think they had 20 product teams, so already way bigger than anywhere I had ever worked. And I was visiting them on site during their quarterly capacity planning meeting. I didn't even know something like this existed. I sat in a room with 300 people. Where somebody projected a spreadsheet on the wall and they literally all day long, it took a full day, worked through all the dependencies across all the teams and how that would affect their roadmap. I did not know this was a thing. And I was in the room because they were hiring me to teach them how to do continuous discovery. And I was like, how can you commit on day one to what you're going to do for the next 12 weeks if we're going to do continuous discovery? Yeah, we sort of have this challenge of like, how does this actually work at scale? And I don't know. We're getting better answers, but I don't think we have the answer. I don't know. I don't think we know how to reconcile a business's desire to predict the future with the uncertainty that's required to build good products. You helped and definitely helped this a lot with your focus on opportunities because you can focus on an opportunity and you can promise to focus on that opportunity to some degree, more than you can promise to focus on a particular feature or technical solution. So I think that's obviously one way of doing it, but in general, it is a problem. Even there are different ways trying to get around it. And I think AI will help us a lot here just because it can keep more than 20 things in its head at the same time. Or even if you're super smart and can keep 200 features in your head at the same time, it's still not enough at a large company. I do think as a company grows, product coherence is really hard. And I think we see this with with big company products, right? Like you encounter things that just don't make any sense. And it's because it's really hard. I mean, in theory, this happens up the organizational chain, but ultimately it comes down to one or two people that have to keep that coherence in mind. And I don't. The problem is becoming too big. And I think if we build more, it will become even bigger. Yeah, for sure. And everyone is talking about speed, but we have the same brains we had 100,000 years ago. We're at these companies with thousands of employees. And I read somewhere that our brain is primed to handle 150 individuals in our tribe. So we're not really made for it necessarily. And the fog of war is definitely real. And when I took my first step up the corporate ladder and was a head of product at a couple of companies, you realize that, oh, my God, you don't actually know as much as you think. You would think that when you're sitting in the air conditioning. Like we've been thinking for years now, like what's going to happen to product management. And I think it's so interesting now when developers get cloud code and suddenly software is going to move a lot faster. I think there are a lot of people thinking that, okay, we're product managers. We need to get into vibe coding. We need to start prototyping more. That's going to be our role. But, and that's one likely path, but I also think it's even more important that to start working like how do we do discovery as fast as developers are coding, because they're only going to be coding faster in the wrong direction. And as designers and product managers, we always had a little time to plan, okay, what are we going to learn about next? You had time for stakeholder alignment and figure out what, what's like, how, what I want to build, how to step in with a vision and what users say, because development took time. But now if that's going to go faster, it's going to be even more important to actually know what's going on and how your product and your goals, how that fits into the whole picture. So that you can support a really fast development. Yeah. I mean, I, we can have a whole different discussion about how discovery is going to change. I want to get back a little bit to sort of the AI components. You both have mentioned bits and pieces. So I, I have in my head, there's these three underlying tree structures, you've got a bunch of documents, you have an agent that processes documents, and you have a retrieval agent that's supporting the like front end of your product where people can ask questions and things like that. Is the, is the agent that is extracting from the document, are they building those trees? And then the retrieval agent is retrieving from those trees, like, help me connect the dots between those components. That's exactly how it works. Yeah. Okay. Yeah. I tried to, in my head, picture this very curious and outcome driven and emotional agent that is a perfectionist that really wants to build these trees and really wants to find those pieces of information and becomes super frustrated when it doesn't find it and starts looking a little bit more after them and do more searches. And it has a certain budget to spend for each document. It's quite a big budget, but it still is budget conscious to some degree. But if it gets too frustrated, it's just going to keep searching and chunking document into these little pieces and putting them in the trees and then also connect the pieces in, and for example, the product chain we talked about with the signal and signal learning decision and principle, for example. So I can imagine, okay. So I can start to imagine how this document processing agent works. It's got a point of view. It knows it's trying to fill in as much detail on these trees as it can. It's got a pile of documents. You've given it a budget. It's off to the races, working hard, filling in the trees. What happens when it uncovers a conflict? Yeah. So it always tries to resolve the conflict automatically and just give it, it will surface it to the user, but it will be auto resolved. If the conflict seems to be potentially destructive, meaning that if we resolve this conflict, we're actually saying that this old signal that may be connected to loads of product chains is actually invalid. Then that's a serious case that could be really serious for the business. So that's going to be escalated to the user and surfaced with, okay, we have a couple of options here. What do we do? Do we merge them? Do we keep the new one? The old one? What do we do here? So the agent will explain why it's a conflict and why this is important. And you wouldn't believe the examples we've seen. Sometimes we had to look for like minutes and like, why, how is this actually a conflict? But it turns out, yeah, if you think about it like that, it actually, if you move a couple of turns down in the chess game, yeah, it turns out that this actually will collide in the end. And it's very interesting. Yeah. Please go on. Yeah. Okay. So Charlotte, you had mentioned there is a human in the loop. Does your customer get to view these three trees and get feedback or is there a way you're presenting the data to help them kind of understand it? Yes. All of this. And I think it's pretty interesting. I've been reading a lot, everyone's building context layers, but I would say that our product to some degree is a UI on that context layer. So you have, you see the full tree and you can edit, is this an opportunity or is it actually an objective? If it gets it wrong, so you have all the chance to edit and put it stuff yourself. And the same for like when a conflict arises, the AI tries, as Mathias said, like the AI tries to autoresolve it, but ultimately it's up to the human to decide, is this, should we go with the old info, the new info, or should we try to merge them? And I think for a merge, for example, that would be like one customer says, one customer says that they liked this flow, another customer said that they didn't like it. That is a conflict. And the truth is that both can coexist because customers can have different opinions. So then you have a chance to either merge them into, some customers think this, some customers think that, or you keep them as is, and you can add a note and say, let's keep an eye that this is not decided and yet which one it is. I think to raise a pattern among in general, AI development in general is that most companies, they start out with a chat because that's what you experienced in chativity. But the chat really, it demands a lot from the user. You need to know what you're looking for. You need to understand that there is a reason for me to start typing into this chat and ask these questions. And it really takes a lot. So we'd rather have, like Charlotte said, we'd rather have a UI layer that gives you the lay of the land without you having to necessarily know that you should know it. So that's, I think more and more AI products will probably add a UI that's not just the chat on top of things. And then the third wave here in terms of fixed patterns, I think it's going to be that we see lots, lot more proactive agents. As the agents becomes better, why would they have you sit around waiting to ask the question or even log into the product when they could just send you a text message about something? And we realized that when we built our first version of this, the multi-agent system, we started talking about implementing the MCP server for GitHub. And it turned out that there was no project MCP tool. And GitHub had this really excellent JIRA alternative that we wanted to integrate with. And the agents saw this. And when we woke up in the morning, they had been Googling or something. And they found out that yesterday, GitHub actually released the project as an MCP tool. And it messaged me and said, I saw you were building this MCP integration. Why are you not using their new server? And like, wow, this is cool. I would have never thought about asking that question because I had only Googled it a week ago. We will see a lot more of that in the coming months, I think. This is actually one of the most powerful use cases, I think. I moved my task management system to Markdown files. And one of the primary drivers of this is now I have an agent that every day, like on a cron job, queues up Claude to look at my to-do list and to enrich every single one of my tasks. And then I literally look at a task, and sometimes it's already done because Claude knew how to do it. Oh, wow. This feels magical. Like, I have some, or like, oftentimes it's not completely done, but like, it'll have added search results or some research or gone and found stuff from my context files and been like, remember this. And it's early. I'm still experimenting with like, what's the right way to enrich tasks with? But it's super fun. It feels like I have a team. Yeah, no, it's cool. It's very cool. Okay, let's talk a little bit about, we're coming up on time, but let's talk a little bit about how you evaluate quality. I think from what you've described, what goes in your trees seems critically important. And I hear that there's a human in the loop. I'm curious about how you, what you do with that human feedback. Is that a feedback loop for the agent? Are there other evals in the system? Just what are you doing to evaluate quality? Yeah, we're solving an inherently sort of abstract problem with no inherent deterministic right or wrong. It's going to be ultimately at the end of the day, if you, if it's a conflict that the product manager A is focusing on onboarding while another one is focusing on payments, is that a conflict or not? That's going to be very much a human judgment, a judgment call. So it's hard to build an eval around that. Having said that, there are ways, for example, we allow the users to, if they want to leave feedback after one of these little Lego pieces or conflicts have been surfaced, was this relevant to you? Are you happy with the out to resolve answer? And that will be fed back to the agent. And every week, if the agent has enough signals from the users about being really bad at something, being a bit too, raising too many duplicates, for example, it will judge itself, review itself. And it will say, I'm actually doing way, way too many duplicates. And it has the ability to some degree with my overview or our overview to rewrite its own prompt. So you can rewrite this on prompt based on what they've learned during the week, if it has enough data supporting that decision. So that's one way we work with this. Another way is just human feedback. Just looking at what is the agent saying? Is that good? Is it bad? Is it relevant? Is it crazy? Does it seem to understand what it's doing right now? It's just going to be human looking at it. When it comes to conflict detection, there are a number of benchmarks. And also, there are also a lot of benchmarks for retrieval, and we use them a little bit, but they're looking at such particular part of the process that it's hard to apply our systems to that benchmark. Yeah, okay, cool. And then tell me about, I know you mentioned at the very beginning, Charlotte, you have design partners, you're getting ready for a launch. What's next? We're working with several design partners and trying to figure out, okay, how does this fit? We still have things that we need to work on, work on in the UX, make it understandable, make it work. Sometimes it's okay, but if you just have this integration, it would be a game changer. Right now, we're listening for all these pieces that brings us to knowing that, okay, but this product market fit, even though we're starting to feel that there are a lot of customers reaching out to us. It's okay, but can we take that meeting about your product, which is really exciting. So that's where we are right now. And then once we feel that, we're going to go public. Yeah. I find it so inspiring. We both have been PMs for many years, in my case, like 15 years. It's one of the most stressful roles you can have. And I think the data says that as well. Some PMs have very low job satisfaction and it's very unfortunate because it's such an interesting and powerful and impactful role if you're allowed to do your work as a PM and not just sit in meetings that you may or may not want to sit in because they're not relevant. You want to, as a PM, most PMs I know, they want to make a dent in the universe, as Steve Jobs said, and you want to help people, your users, and you have a genuine interest in building great products. That's your passion. And you want to work as a team and have the one plus one is three sort of experience with your team. You don't want to sit and look for data and have these conflicts because you misunderstood something and you don't know who decided what, and there's going to be politics about who said what, then what did we decide? All this boring stuff, just removing the boring stuff, I find it so inspiring. And to be able to be allowed and having the privilege of keep building this product, to fuse AI to do the boring stuff and humans to do creative and fun stuff and help that fuse for those who want it, that merger of intelligence, that is the most exciting thing I can possibly think about doing. So I think we'll keep doing that and we'll launch this to as many as possible, I hope. Amazing. I want to say that we're working with our design partners, but we also have a wait list on MomentalOS.com. So I assume that when we're a bit further with our design partners, we're going to start letting in people from our wait list. Amazing. I will make sure we put a link to that in the show notes. Thank you. You know, Mattias, what you were just saying makes me think of a company that we had on an earlier episode. They're called Perk and they do nothing like what you're doing. They help automate travel expense reporting, but their tagline is about eliminating shadow work. And I love that phrase. It's how do we get rid of all the boring parts of our job that takes up so many hours of our week that really keeps us from doing the parts that are creative and human and fun and what got us into the job in the first place. Exactly. Yeah. So I love that. Yeah. Good term. This has been amazing. I really appreciate both of you sharing your story and I'll be rooting for you. It's fun to see. I think I just recorded another episode where it was also a two-person founding team and it's just fun to see really small teams being able to have big impact. And I think that's one of my favorite parts about what's just now possible. Yeah. All right. Cool. Thank you. Thank you. Thank you. Good to talk to you. If you enjoyed this conversation, please subscribe in your favorite podcast app and give us a rating as it helps others find the show. Thanks. I appreciate it.