APEX POC Kickoff Meeting

Date: February 11, 2026 Attendees: Bob (CTO), Kartik (CPO), Sabrina (PM)

Summary

Demonstrated APEX proof-of-concept using Cursor IDE with PM workflow skills. Discussed repository architecture, branching strategy, and pilot project selection.

Key Decisions

1. Initiative Directory Structure

Each initiative is a directory (not a single file) containing: - Initiative.md - Main initiative document - meetings/ - Meeting notes, decisions - discovery/ - Research, user interviews, data - experiments/ - Experiment docs (E-2026-NNN.md) - designs/ - Wireframes, mockups, prototypes - tickets/ - JIRA ticket references - release-notes/ - Version history, changelogs - docs/ - Supporting documentation

2. POD as Metadata

POD (team assignment) is stored as frontmatter metadata, not folder structure. This allows initiatives to move between teams without file reorganization.

pod: Revenue-Optimization  # Team assignment as tag

3. Repository Organization

Discussed three approaches: 1. Repo per microservice (too granular - 147 repos) 2. Mono-repo for entire company (too broad) 3. Domain/product surface repos (selected)

Proposed repos: - product-pricing - Revenue pricing - product-forecasting - Demand forecasting - product-reporting - Analytics & reporting

Alternative: Customer-facing product names (e.g., "Game Changer")

4. Branching Strategy

• Start without PRs for simplicity
• Work in branches per initiative
• Merge conflicts handled by Git (different directories = trivial merge)
• Add PR workflow later if needed for design review checkpoints

5. Technology Stack for New Projects

Decision: Project Searchlight will use entirely new stack:

Rationale: Searchlight uses only Lighthouse data, minimal Duetto data needed. Perfect test case for greenfield stack.

6. PRD Auto-Generation

PRDs should be auto-generated from initiative context: - Meeting notes - Discovery artifacts - Experiment results - Designs

Engineers should create tickets from PRD, not PMs.

7. Release Notes Integration

Release notes should be: - Part of initiative directory - Auto-generated from PRD + code changes - Include context ("why") from initiative

Pilot Projects Selected

Action Items

1. Bob: Polish Cursor skills, prepare for Wednesday kickoff
2. Bob: Pull Tour Operator artifacts from Confluence
3. Kartik/Sabrina: Decide on repository naming convention
4. All: Schedule Wednesday 10am ET kickoff with Shiv, Charles

Follow-up Meeting

Wednesday, February 19, 2026 @ 10am ET - Attendees: Bob, Kartik, Sabrina, Shiv, Charles - Focus: Project Searchlight as first APEX project

Tools Demonstrated

• Cursor IDE with PM workflow skills (/pm-initiative, /pm-experiment, etc.)
• Obsidian for markdown preview
• mcp-vector-search for semantic code/document search
• Kuzu Memory for graph-based context retention
• Vercel for frontend deployment
• Clerk for authentication management

Transcript

Speaker A: Navy one, like this big. Speaker B: Oh, in London, he also got these, like, real big unicorn horses. Speaker C: Nice. Speaker B: And, yeah, Andy was playing with it the entire two days. It was so bad. Speaker C: All right, so now we are. Yeah, right now we are talking about the APEX proof of concept. Kind of our first step to figuring out the tool, tooling workflows and stuff like that. So what I've done is I've created a set of. Cursor rules and skills, and I actually think we'll want to probably just include them in every project. It's easy enough to sync them, we can actually distribute them. But maybe we'll do is a. Actually, I don't. We'll do. Don't get fancy. We'll do a sub project, but we'll include that in the projects themselves. So it'll all be from one place. And if we update or whatever new rules come along, we can just add them. So as far as the PMs go, anybody using this, they just type slash commands. It should be just automatic. Okay. So the idea is that we have these. Now, these pm, they're all called pm. We may want to call it apex, PM or something just to make it easy. But they're all the things that you might want to do. So, like, what does a PM do? I don't know. Let me ask a thing. Help. I'm stuck. What do I do? And so it will tell you all the things that you need to do as part of the thing. And I think this will be getting people going. But as people start to use this, they may not need AI for some of the things they may want to copy, paste, whatever. There'll be validators and formatters, and I've even created like an NPM doctor so that if they have questions, they can just check their files. Speaker B: And so I think they will start. So would we have one project for every. Let's say each initiative is a different project. Speaker C: So I think that's going to be based on the working relationship. So if the team and the code base. Honestly, I think it's based on the code base. The code base is. If it's a project within a code base, then it should be initiatives within a single project. We just don't create. We just create initiatives. Speaker B: Initiatives. Speaker C: Each initiative has a subdirectory and whatever. So let's just say. Speaker B: Let's say we create an initiative. Speaker C: So there's a PM initiative and we just hit return. All right, so it's going to say these things now. Don't, don't. Like this is all flexible. We can do whatever we want to. So, Sabrina, what is the title of this initiative? Speaker A: Let's do Usage Dashboard. Speaker C: Okay. And you can, by the way, hide the thinking stuff. Speaker B: All right. Speaker C: Metric target. Speaker A: User logins. Speaker C: Okay. And actually, I don't think we need GPT2 for this. A very simple model. It's just text processing. But since I just wrote this from scratch like an hour ago, when I figured out how it works, I just picked the most expensive one. All right, Hypothesis. Speaker B: It should be, we believe doing X will increase the logins by this much. Speaker C: So give me a hype. I mean, I can just copy this, but you have anything else you want, any sort of. You're the domain expert. Speaker A: It's fine. Speaker C: Okay. It's fine. Speaker B: Well, it actually created the example. Speaker C: Yes, yes. Speaker B: Very good. Speaker C: Let me hide all this stuff here. We don't need it. Okay, so it's got. It's got. Everything's gonna be. A lot of things are gonna be conventions. So we have a convention where it will create in here an initiative. Yeah, it's actually creating a new initiative because I already did it. So the. The convention it picked, we can change. This is I for initiative. The year and the number, it's a serial number. There's also a convention for commits and PR and stuff like that just kind of follows what we do. Again, we don't have to. I mean, it will be handled automatically just by these workflows. So, yeah, the MDs are sense of. Markdown. Speaker B: Yeah, markdown. My point is, in an ideal world would be every team will have initiatives. So there's a pod, right. And POD has a bunch of initiatives that they are working on, and there's a different POD that's working on other initiatives. Sometimes initiatives depend on each other. Speaker C: Right. Speaker B: But mostly the idea is that they should be independent and the pod. Speaker C: So POD is required. A pod. Speaker B: Yeah, POD is required. So I don't know if POD should be in the name. If it makes it easier to identify it or should fold. We should have folders for each. POD is another way change. Speaker A: That's the thing. I don't want to, like, marry us to, like, if we decide we don't want a strategy team anymore, now it's combined with the other team, then like, that's true. Speaker B: So maybe POD just becomes metadata of. Speaker C: The initiative, like attack on it. Speaker B: Yeah, but. Yeah, but this convention limits us to 999 initiatives, which is already a good upper limit of how much. Speaker C: Well, that's per project. That's per project. Speaker B: I don't know. Speaker C: So I mean, we could have a thousand. Are we going to have a thousand initiatives per project? Speaker B: I would start with one initiative, one project for the entire company, which is 2026, is the project. And they're just wonderful. Speaker C: Well, so. Okay. I think. Speaker B: I don't think. Speaker C: Because. So that's. You're thinking about the monorepo. I don't think we can put. Do a monorepo for everything. We have too many, too much legacy stuff. So I think the initiatives have to sit with the code that's going to execute. Speaker A: If we did, apps versus it can. Speaker C: Be front end versus back end and we could have hybrids. So the rule of thumb I actually propose is that. Speaker B: So a project for every microservice. Speaker C: It's whatever our structure is for the code, all the code needed to run the project, run the initiative. Well, let's say all the code needs to run the project. The initiatives should be a subset of the code that's going to run it. So let's say it's a UX or UI project. It would sit within the code project where that is. Ah, okay. Speaker A: Well, what happens if it spans multiple. Speaker C: So then we just pick. We pick. It's okay, I get it. I thought about that. We just pick the one, the dominant one. Or if it's equal, we just pick one. There's no great way to do it. Speaker B: But can you show us the projects today? I mean the code. Speaker C: Sure. Speaker B: So in. Speaker C: Yeah. Speaker B: How do you. Speaker C: Now, here's one. Sorry, let me take a step back. Here's another way to do it. We don't have to align them at all. We just have to put pointers in the code repository, where all that goes. Now, if you think that we can do everything in a single monorepo for all the projects. Yeah. Speaker B: The point is how much. Initiative. Initiative. What is common versus what is shared. Speaker C: Yeah, I hear you. Speaker B: So that's what I'm thinking more about than aligning it to the code, but. Speaker C: More so actually, the more I think about it, it's easy enough to pull projects into code, so we just do a clean design where it's just a repo for the project metadata. Speaker B: And metadata, for starters, we can have three, which is apps, analytics and platform. Speaker C: So these are the repositories that you have today? That we have today. And they're kind of a mess. Speaker A: How many do we have? Speaker C: 147. Speaker B: Yeah, I think PMs will be just stuck figuring out where to add it itself will be confusing enough for them, that mapping. I don't. Yeah. Speaker C: It's fine, it's fine. Speaker B: Cognitive burden on the PM to know where the code is. Speaker C: It doesn't matter. You're right. So what we can do is. Speaker B: Three repos, one for. Speaker C: Yes. And then what I was going to say is initiatives will get pulled into the code projects and they'll be available, but they won't be dependent. That makes sense. Yeah. And they'll still synchronize. So when you pull code for, let's say, the ML pricing engine, you'll have a link to a sub, what's called a sub module, which will pull from the initiative. Speaker B: Yeah, I still think, I mean, not teams, but I still think we should divide by product surface. Because if you think these are going to power release notes, power customer documentation and saying that, look, game, maybe Game Changer is the name of the repo and all the PRV's of game changer are there, then release notes are also there. So the context is there and you continue to keep doing it. Yes, of course. Game Changer means code change in this repo and that repo and that repo, that engineering still has to be. So maybe making it more customer facing. Speaker A: What if we do then we follow kind of the menu structure we do, like pricing, forecasting, reporting. Speaker B: Yeah, yeah. And then, and then platform can. Product platform is. Onboarding, integrations and data platform. We just leave it at that. And then we can create more if required. But I would do, I would add a little bit more structure to it. Speaker C: Yeah. So here's my suggestion. I've got all the notes. Think about this, because this is actually a pretty big decision. Speaker B: Yeah. Speaker A: Because I was gonna say, once we do this, it's gonna be really hard to unwind. Speaker C: I mean, it's doable, but it'll be messy. And I also think the biggest issue is it's like story points. Just so you know, I want to actually create a uniform story point system for the entire company. That never works. I'm gonna try it. But the reason why it's hard is that it's a cognitive framework and everybody just. It takes a while to sort of get over, oh, yeah, this is how we should do it. And it's kind of a test on how elastic your mind is. But my concern is that if we change it, it's just that it just creates so much chaos, mental chaos. Speaker B: And all the historic data will not match. Speaker C: Exactly. Exactly. Speaker B: Anyway, so coming back to this. Okay, so let's think through it now. Let's keep going. So imagine this is user or Game changer project in which now we have two initiatives. The second one is about usage Dashboard. Speaker C: Yeah. So let me actually just give you. Just to give you some tactical. This would be the view that you would see inside of if you were working inside of Cursor. And again, I think cursor is perfectly fine for people who like cursor. Speaker B: You can view this as regular page also. Speaker C: Right. So that's. If you have Obsidian or any other markdown editor. I would just recommend Obsidian because it's open source. This is what it looks like. Speaker B: It's syncing it. Speaker C: Yeah. Well, it's just. It's actually pointing to the exact same place. Speaker B: Okay, can you go back to cursor? Can you right click on the top? Is there a way? I mean, maybe. Speaker C: So I. So I have. Speaker B: Yeah, you can see it as markdown. Can you click here somewhere? Speaker C: Sorry, right here? Speaker B: Yeah, there's three dots. What is that somewhere here? I have seen it in the past. Where. Speaker C: So maybe there is. I'm not a cursor expert. Yeah. So it may be that there's a way to do this. What we want. How. How we want to do it. Yeah. But I don't think we should, you know, get too. Speaker A: Do we have Obsidian in our library of tools? Speaker C: Not yet, but we'll all like. We also don't have cursor in our. Speaker A: I know, I know. It came up on one of the calls. So you handled it well. Speaker C: Okay, so not cursor was for something else. Right. So I think the. So leaving aside the sort of the repo design which you guys will come up with, and the sort of the technical linking between initiatives and code, the other big challenge. Well, there'll be others. But another big challenge is how do you handle sort of the commit workflow? And in my mind, I think the general principle should be a single. Well, so you'll have. And you tell me. Speaker B: So commit workflow. Do you know what that is? Speaker C: Okay, so let's even take a step back. Even before you have an initiative, I typically recommend doing like even a lighter like a one pager. I call them one pagers. Where just somebody writes down here's what I want to do gets buying in. And then you convert that into here. Yeah. Okay, so now this is here. Yeah. Speaker B: Comment is just pushing it to get right. Just saving it in git. Speaker C: Right. So. Speaker B: But wouldn't there be a folder for customer reference data for this initiative? So. Speaker C: Right. So that's the question is if we want to automatically create folders because not every initiative will have the same folder. Sort of Supporting folder structures. Right. So what we should do is define a. I mean, we can either leave it open, like we could just say this is. We'll create every initiative becomes a directory and then. Okay, so that's a change. We'll create every initiative as a directory and then we can be not didactic about what's in the directory, but we just say everything in there. I mean, we should have some conventions because it's easier to find, but it's. Speaker B: I think every initiative should have a directory, right? Which has. In the root of that should have this md. And then there should be folders, one saying designs UI designs, and the other folder being customer transcripts or conversations. Speaker C: I'll just say all just create meetings directory because it's going to be internal teams too, as well. Speaker B: Yeah, meetings. And I think those are the two kind of inputs, Design conversation and the. Speaker A: Meetings and all the discovery documents. Speaker C: Yeah, whatever, Discovery. Right. Speaker B: And then experiments is another folder within which there should be experiment 1, 2, 3, which is. I've tried this and each experiment we discussed about the format in which it should be. Speaker C: So. Speaker B: So that would be the higher structure. So can we create it here? Speaker C: So as we said, we said four things, right? Speaker A: We said. Speaker C: Okay, so let me see how quickly we can do it. Sorry, let me actually just talk to. Instead of a single file for an initiative, let's create a directory for each initiative. And within that directory should be a Meetings. No initiative, the actual initiative document, which maybe we'll just call it Initiative md. Maybe it doesn't need a name because the directory will have the project name and the year, the sort of conventions. But within that directory should be subdirectories for meetings, discovery, experiments, PRDs, designs. And then within experiments should be also subfolders for different experiments. So every time you create an experiment, you create a subdirectory within the experiments directory that will contain the data for that experiment. So this is claude code, or my version of Claude code that does a lot of the heavy lifting behind the things. You're watching this sausage being made. So the. The other thing to figure out is. And this is actually just like software development as you. When you build it initially. So actually, sorry, We will have to work in branches because. Okay, so that's. Here's the thing, here's the downside about working, not necessarily downside. If we do model repos, which we're talking about, which is one repo for multiple things, everybody has to work in a branch. So the idea will be when you create an initiative, you actually Branch, the repo, the entire repo and all your work. And you can share a branch. People can, you know, you can have multiple branch, all your work goes in that branch and then you then have to merge. At some point there's going to be a merge sync back to master, which you do at some checkpoint, and, and that's kind of coordinated, so it makes it a little bit more complicated, but I think it's fine. I mean, people do that with like all of Google's on single water repo. Speaker B: Yeah. Speaker C: Which is crazy. Speaker B: What I really like about that is, I mean, if we just at least for now, we do 1pm as one, once we break it down, it goes to that level, that 1pm has one repo. Speaker C: Well, they'll have one branch. Speaker B: They'll have one and then they'll work on that branch where they continue to do discovery. But the developer knows that they have to take the PRD from the previous and they can keep developing while you're. Speaker C: Experimenting and they can actually pull from that branch. So it should work. Speaker B: And then when a new PRD is created for that same initiative, it will get version controlled. I guess not. Speaker C: Well, at some point there are natural checkpoints when you want to reconcile all the different branches. But Git is designed for very lightweight branches and easy merging, and the content is not code and generally it will be in separate directories. So I think the merging will actually be pretty straightforward. Yeah, yeah, So we actually add that as well. So we want to refine the branching strategy a little bit more. Speaker B: So. Speaker C: So when a PM creates an initiative, they're also creating, not only are they creating an initiative directory within the initiatives directory of the project, they're creating a initiative branch and they will work in that branch. So multiple. Because we are doing a monorepo design for this, each PM should be able to work in their own branch for their initiative without stepping on the other people working on their initiatives. Speaker B: But typically, at least for now, it is the same PM who's working on all those initiatives. Speaker C: Oh. Speaker B: If we divide, unless we start putting multiple PMs on the same part of the product surface. But there are designers working there too. There are tech leads working there too. Speaker C: But they won't be working on it at the same time. So if we ask them, for example, to work in a branch, I mean, sorry, so I would think it would. Speaker A: Be the exception, not the rule. Like most people are not going to be overlapping. Speaker B: I mean, the team itself is working on three initiatives at a given point in time. I see what you're saying they're experimenting on this initiative, they're delivering on this initiative, and they all belong to the same project. So a given team is on one project, but they might be working on three different initiatives. That's why I was always thinking initiative is a project, but that will create thousands of projects. Speaker C: Yeah, no, no, I think initiative is right. So, I mean, the thing is that as long as you're working in different directories, you don't actually have to be in different branches. Yeah. I mean, the branch is only if you want to make a change and you're working on one document and somebody. Speaker B: Else may be working on the same one, that is when you need to worry about branching. Speaker C: Yeah. Speaker B: In general, isn't it a good idea to just branch the whole project, work on an initiative, and then commit it? Speaker C: So here's the thing. Yes and no. You could just do a merging strategy where everybody works on the same branch, and then you just figure out merging. And if the work is on different folders, merging is trivial. The only reason I would say a PR is good. I mean, a branch is good, is that when you're ready for review, you create a pr, which is like, hey, take a look at this thing. Let's get everybody on board with the changes I make. So the question we have to ask ourselves is. How much, let's not call bureaucracy, but how much process do we want to add to making changes to these, or do we want to just try? I mean, the other approach we could take is a lighter touch where just people work on their own stuff by convention and we just handle. Git. Can handle merging fine. And it's only when they are ready for like a presentation that, like, to a broader audience that they create a pr and then they share, hey, this is a pr. Take a look. We. What do you think? Okay, so let's do this. Let's keep the strategy the same that everybody. You work in a branch, a branch per initiative, and when you're ready to turn that into, okay, maybe this is a natural thing. When it's ready to go to the engineers or other people, then you do a pull request and then it gets put in. Another thing you might want to consider is maybe when the designers are ready for their board, they're done, they're done, and they want to show it. Then the designers do a PR for their branch with their. Speaker B: And that will force a conversation because of pr. So designers can't just simply drop the designs. Speaker A: I feel like it's just so much more fluid than that, though. Like Design is usually iterating in engineering's in there because, oh, they found this issue or we can't actually do this thing the way you designed it. So how do you account for all that? Speaker C: Right, but I mean, if they're kept in. Well, if they're kept in a separate repos, it's not going to hurt the engineers to have the designers continue to iterate. Speaker A: But at what point does it become like you're just maintaining to maintain? Speaker C: Well, I mean the work in general, once you check out a branch and you work on it and you commit it, any sort of conflicts are generally handled by git and it's not code. So I think it's. And the rare cases where somebody, two people change the same thing at the same time, then you have a thing that you have to resolve. But what I'm hearing is that's not going to happen that often. Speaker A: I don't think so. Speaker C: The issue is if a spec gets changed by two different people, then that might be an issue. Speaker B: Yeah, it's possible that a spec can change by two different people and when they try to merge, they need to have a conversation and do the merge. That's exactly what we want to stop people overwriting each other's work because engineering needs. Speaker C: So let me, let me. So here's my suggestion. Why don't we start with. Without the PRs for now? Because this is a lot and we run it with. We talked about three different, potentially three different projects. Right. The Vision360, the Lighthouse and as the tour operators. And we just try just doing things in git with the tools and just merging, committing and merging. And then if we find that we run to problems that it would solve better with a PR, we can get to a PR model. Yeah. Speaker A: Okay. Anything Demand360 or Lighthouse API? Speaker B: Demand360. This is the pressing one. And the Project Searchlight. Yes, it has Lighthouse API inside it. Speaker C: Yes. Speaker B: But can we just take Project Lighthouse and deliver on it in a completely different stack? Speaker A: I like it. Speaker B: Because the same problem, the data source is the same, so we have to solve one to get the other done. The other one is a UI only. Speaker C: Top of yes. Speaker A: Yep. Yeah, I think those are three great projects. Speaker B: And Tour Operator is already being wipe coded. There's a lot of customer conversations, designs and all happening. Speaker A: Yep. Yeah, that one's nicely contained. Speaker B: So in an ideal world, those two Lighthouse, Searchlight and Tour Operator, completely different stack with Vercel. Vercel, what is it? Speaker C: Vercel? Speaker B: Yeah, Vercel. Speaker C: So Vercel is A dx. It's one of the fastest growing sort of DX friendly. It's probably called Composable Stack DX is developer experience. Yes. Actually I'll show you what Marcel is. Speaker B: I have to. Speaker C: I have to translate. Speaker A: No thank you. Speaker B: Yeah, There you go. All right, I'll see you guys later. Speaker C: Thank you. Yeah, yeah, yeah. Okay.

[Transcript continues with technical demonstrations of Vercel, Clerk authentication, vector search, and other tooling...]