Check out the conversation on Apple, Spotify and YouTube.
Introduction (0:00)
Aakash: The era of monoskilled professionals is dead. So I’m going to demonstrate the future of product builders. Meet Oji Udezue, former CPO at Typeform, Calendly, and Parable, as well as former head of product of creation and innovation at Twitter.
Aakash: How much of this thinking, like viability gates and sharp problem tests, should we really be outsourcing to LLMs? Is the LLM basically the first draft, just to get some thinking going, and then we improve and react?
Oji: You really do need to look through all the output. Make sure that it makes sense for you. We do this all the time, because I think it’s hard to fully trust 100% LLMs.
Aakash: Can you open up that scaffolding skill and we can see what is inside it and how it looks?
Oji: Yes. So it’s multi-skills here. You can see that it has a master SKILL.md and then it has a bunch of subskills where it would do market research.
Oji: I’ve been a product manager for 25 years and I’ve never really felt that coding was worth my time until now.
Aakash: Before we get into today’s show, please take a second to check that you’re subscribed on YouTube and following on Apple and Spotify podcasts. If you want access to all of my favorite AI tools, I’ve gotten them to give you an entire year of their paid plans. Check out bundle.aakashg.com for an entire year of Bolt.new, Airtable, Speechify, Descript, Magic Patterns, Linear, Dovetail, Arise and Mobbin. And now into today’s show.
What you will learn today (1:31)
Aakash: OG, what are people going to learn today if they stay till the end?
Oji: Well, the most important thing they’re going to learn is that we won’t just focus on code skills. Product right now, or coding, or engineering, or the shipyard, whatever you want to call it, is full of repos in GitHub with skills to token max or token minimize or to change costs, all on the coding layer.
Oji: But we know that a tech company, a successful tech company, is really three layers. It’s the software and the hardware. It’s the product, which is about customers and about the business model. And it’s about the business. They’re thinking about allocating resources to the rest of the chain.
Oji: What you’re going to learn is how to take the raw harness, like Claude Code, and apply not only coding skills but product skills, product judgment on tap, and business skills that will help you make the very best decisions about how to build a successful product.
Aakash: So I’m really excited about this. Where should we start?
Why PMs became the bottleneck (2:43)
Oji: So Aakash, where I want to start is something I think is really important. Product Mind consults with lots of companies, big and small. And the things that we get asked to do is, first of all, come in and reconceptualize a product as much more AI native.
Oji: Very quickly what happens to us is that we get pulled into the shipyard. How people are organized, new skills for people in an AI era, how do things work together, how do people work together. And what we’re seeing immediately is the developers are speeding up very quickly, especially if they’re early adopters. And then we see everyone else being a bottleneck.
Oji: And particularly we see PMs who are not speeding up their product judgment, not speeding up their orchestration skills to match the new speed of the engineers.
Oji: So what I’m about to show you is a set of product judgment skills. Not just code skills, but product judgment and business skills that product managers can use to think at the business layer, at the product layer, while not sacrificing code fidelity and things like testing and quality and so on.
Oji: The best instantiation of this is the new project scaffolding skill. There are all kinds of skills here. We have things like finding the aha moment for your new product, whether it’s agentic or not. We have things like figuring out whether it’s a sharp problem.
Oji: But the scaffolding skill is special because it starts with you describing a business problem, and then it really makes decisions, helps you make decisions. It does market research for you, tells you whether it’s a viable problem and how to solve it if it’s not a viable problem. It makes architectural decisions for you based on asking you questions. It figures out how to test the thing based on those architectural decisions. And it even sets up continuous integration and continuous delivery for you.
Scaffolding a new product live in Claude Code (4:46)
Oji: So we’re going to work directly in Claude Code, not in Claude Desktop or anything, just in the same way that developers work. So what I’m going to tell this thing right now is to scaffold a new project.
Oji: One of the things I’m obsessed about is the fact that people won’t read any code. So what I want to build is either a SaaS or an agent that helps vibe coders, people who don’t have a lot of software experience, helps them figure out if their code is any good. Security, robustness, complexity, simplicity. All of that tells them the story of their code, because no one is looking at it, even in a corporate environment.
Oji: And so hopefully, if we tell it to scaffold this, it will run all the processes of the scaffolding for us. I’m going to hit enter. If you pause and read it, you’ll see that it’s just a first idea.
Oji: What this is going to do is it will run a viability gate. It will take a look at some frameworks and try to figure out if this project is even viable at all. And so that first gate is still sort of loading the skill. There you go. It’s an 11-step workflow. That makes sense, because it’s a very powerful skill, and it will skip straight to the viability gate.
Inside the scaffolding skill (6:00)
Aakash: Can you open up that scaffolding skill and we can see what is inside it and how it looks?
Oji: Oh yeah, let’s do that. So if you look at the skills, you’ll see a bunch of the product skills. Sharp problem. So the first one, yes. So it’s multi-skills here. You can see that it has a master SKILL.md and then it has a bunch of subskills where it will do market research.
Oji: It will actually fetch skills for you, new skills for you if you need it for your project type. It will set up testing. And the core skill is to basically do the viability gate.
Oji: So let’s go back to see what it’s doing here. What it’s trying to do is a web search. So I’m going to tell it that it can absolutely do web search in order to find out what’s going on. So it’s conducting market research.
Oji: So I think I interrupted it. I’m going to continue. And it’s going to conduct market research on the idea. And the next thing it’s going to do is to write a product brief. And once it’s done with the product brief, it will start to get to the code level at all.
Oji: Claude takes its time a little bit, but what it’s doing is that it’s spinning up a web search session. Sometimes it would do that through Chrome if you have Chrome tools installed. Sometimes it’ll do that itself with HTTP. And of course, I didn’t give Claude all my permissions.
The viability gate verdict (8:00)
Oji: So the viability gate, this is going to be interesting. It’s going to tell me whether this thing is worth my time, or worth your time very specifically. And you have to understand that what it’s really doing is taking frameworks from product management, from our book, and it’s trying to see, is this thing worth spending time on? Some of the dimensions include things like the frequency of the problem, whether we have a clear customer.
Oji: And there we go. Let’s run that.
Aakash: So what does it tell us with the viability gate?
Oji: Viability gate, pass, proceed. Zero weak, three strong, three moderate. Not a silent pass. Three moderates are flagged as a de-risking agenda. Now step four, market research. And if we go into the repo we will start to see this document show up.
Oji: So if we go away from skills and go to Code Memo, it’ll start to actually write for us what it’s finding out from doing a web search. So right now we know that usually, if there are three weak things, it will kill it. It will recommend you stopping. But according to it, the viability gate is strong.
Oji: So it has six dimensions. Revenue, technical feasibility, differentiation, competitive landscape, target user definition, and problem clarity and urgency.
Market research and the product brief (9:42)
Oji: So if we go back to its work, it’s literally going in and doing deeper market research for you now. It’s scanning competitors, it’s scanning pricing, it’s scanning what people have done in the space.
Oji: And so right here, it’s created it. It’s done your market research package for you. I set it so that it’s not narrating itself in full, but you can see it has a market overview. It has trends shaping the space. It has direct or near competitors and what they’re charging for. It has key takeaways. It has adjacent products. This is really comprehensive, guys, about what it’s doing for you.
Oji: And now it’s writing a product brief. We have tools that help you write a PRD. This is literally your new project brief, where it codifies that into a problem, into target customers, core value proposition, success criteria that will help you know whether you succeed or fail. And then it starts to write goals for you that will help you gauge where it’s going.
Oji: Okay, now it’s done that. It’s done some of the business level skills, and what it’s working on now is trying to find out how to scaffold the rest of the project in code for you. So now to the code layer. You can see that Code Memo’s core is an LLM analyzing repos for Claude, with current, correct model IDs.
The scaffolding skill as an orchestrator (11:30)
Aakash: So the scaffolding skill is basically an orchestrator skill. It seems like it’s calling some of these other skills, creating documents, walking through this 11-step process.
Oji: Yes. So if you look at these skills here, they’re all really dense. They have built-in product frameworks. Some of them we’ve written from our book, Building Rocket Ships. Some of them are well-known product frameworks that we’ve included as part of this. Building Rocket Ships is actually pretty comprehensive and it’s a very good resource.
Oji: But what it does is it combines some of these things. The most important one it combines is actually the sharp problem test. So it’s doing an internal sharp problem test, and it’s orchestrating a few more skills within that in terms of new product scaffolding.
Oji: Well, the thing that’s special about this one is that by the time it’s done, you will have a full repo. So you can see that it’s created a prototypes folder. It’s created your package of thinking. It’s also created your first milestone folder for you to get started. By the time it’s done, architecture is settled. Continuous integration is settled. And if you give it its GitHub repo, it can start the project and make the first push into GitHub for you.
Oji: Why is this important? When you are a PM and when you are a vibe coder, the things that are difficult for you are all the things. It’s doing the right kind of market research, figuring out if it’s the right thing to work on. But then immediately, where you hand off to developers is also a problem. What’s the architecture? I’ve seen a lot of vibe coders who don’t have continuous integration. They don’t know how to test the code, because they don’t know how to do that. So this sets it all up for you so that you have the bones of a really solid product and a really solid code base to start to work on. I think that’s the power of the scaffolding.
[Sponsor break]
Walking through the skill step by step (15:25)
Aakash: Can we scroll through that file a little bit, just to see how it’s put together?
Oji: So which particular file?
Aakash: The scaffolding skill.
Oji: Oh yeah, the skill. So if you go to new project scaffolding, you have the main skill here and then we scroll through that. Okay. So it’s got each step defined.
Aakash: For instance, the sharp test. Is it going to go call that skill?
Oji: Yeah. So for example, the workflow is to gather context. It will ask you questions if you don’t have it. It’ll find a project type. Is this an iOS app? Android? Because of my prompt, it was pretty clear what it was. It will look for reference projects around the internet, some of the best practices, and it will try to understand how to build this.
Oji: Then it will run a viability gate. This is a compressed version of the sharp problem test, where it will go through problem clarity, target user, competitive landscape, differentiation. The sharp problem test is even more specific. The thing that differentiates it is that it tries really hard to focus on the three times value that you create. That’s not in here. This sort of looks at the market space and sees, is there a lane for you? And the sharp problem test will do something even deeper than that. Whether you will make money, that’s really what the sharp problem test is. This is about, is there a lane for you?
Oji: And if there are three dimensions that are weak, it will just recommend that you don’t do this at all. This is very important. LLMs very rarely tell you no. And this skill will tell you absolutely no, don’t do this. I’ll demonstrate that in a second. I’ll tell it to scaffold a new thing that, if we look at it, might look on a boundary, but it will probably say we can’t do this.
Why LLM market research is only a first draft (17:28)
Oji: And then market research is huge. We tell people market research is weird. You probably shouldn’t do market research with only LLMs. But you can do a lot, 60% or 70%, with an LLM before you go find real sources.
Oji: And I want to step back and also tell people, the danger in this kind of workflow is that you take it as gospel. You really do need to look through all the output, make sure that it makes sense for you. We do this all the time, because I think it’s hard to fully trust 100% LLMs.
The CLAUDE.md, folder structure, CI and security (18:06)
Oji: So it will generate a perfect CLAUDE.md for you for this project. People spend a lot of time thinking, okay, how do I author my CLAUDE.md, what’s the thing in the front matter and in the rest of it. This says, for this project, here is a CLAUDE.md that works best for you. It’ll create a CLAUDE.md that does the project well, hunts bugs, follows the patterns of the folders, follows the patterns of the prototypes, and it’s perfect for this project.
Oji: And then it will create a folder structure. So it will say, here’s where you need to put the documents, here’s where all the milestone things go. And by the way, all this is in the CLAUDE.md. So this is basically a self-organizing repo already, if you’re going to use it. Here’s where the prototypes go, and for each folder it tells Claude and it tells you exactly what goes into it.
Oji: It creates a test folder for you, and then crucially it sets up your continuous integration, your quality system. So every time you check in, all your code is tested. And it sets up security. It starts to find things that you shouldn’t, your secrets in particular get ignored. So it knows how to do that, so you don’t have leakage when you push things to GitHub.
Oji: And it starts quality. It keeps all your documents, it does bug classification, it starts to catalog over time bugs that are made and how to learn from those bugs. So there’s a lot that goes into this. And then some of the harder things that it offloads are the CI templates and the CLAUDE.md pattern. So it gets the perfect CLAUDE.md. These are all called within that skill.
Oji: And so if you go back here, what you have is, essentially we started out with a very clean empty folder, but this is all you have now. And so it gets ready for you to commit your first check-in on this project.
Running the gate on a second idea (20:15)
Oji: Okay. So why don’t we try this? Why don’t we try another project? That may or may not, we won’t say anything, may or may not pass the viability gate. Should we do that?
Aakash: Let’s do it.
Oji: Okay. So let’s do this. Run the scaffolding skill on a new problem. Use a new folder for it in this repo.
Oji: And so I am going to try to solve a standup problem. I’m going to try to ask it to build something for a project called Standup Zero that uses Slack comments and creates a daily standup digest, and ask it to run a viability gate first. Let’s see what happens.
Should you outsource this thinking to LLMs (21:29)
Aakash: So while this is running, how much of this thinking, like viability gates and sharp problem tests, should we really be outsourcing to LLMs? Is the LLM basically the first draft, just to get some thinking going, and then we improve and react?
Oji: Yeah. The very specific thing that we are trying to solve is that if you start in chat and start with, hey, I have an idea, unless you prompt really well, and unless you’re sold on adversarial prompting, or you go as far as some people do and check with multiple different kinds of LLMs, what you’re going to see is it will tell you that you have a good idea.
Oji: The thing about this is that it’s built in. It has a built-in sort of responsibility to tell you whether you’re smoking crack or not. And I don’t mean that jokingly. Tell you whether your idea makes any sense. And it doesn’t just ground it in the model sense. It grounds it in a really clear framework that has evals, that goes through very systematically. So I think that’s the main difference.
Oji: Now, should you trust it completely? I’ve already said you shouldn’t. It produces real artifacts that you should go check. So it’ll create a viability gate document. You should look at that viability gate document and see if you agree with it. See if you can do extended research with it. But it’s your first draft. It’s your first thing out of the gate that has the ability to say yes or no, and here’s where you need to go.
Oji: So it doesn’t have enough information. It’s asking me questions. What should Standup Zero be built as? Let’s call it TypeScript and Slack. How far should this scaffold go? Let’s go to the gate first and then pause, because if the gate says no, then what are we doing? Submit our answers. All right, let’s see what it says.
Oji: So it’s gone off and done some crawling, some competitive research as we saw, and it’s trying to figure out if this is worth it. I’ve read some of the stuff it comes up with for the market research and it’s really good. It will do basically as high quality as Perplexity will do to go look for whether there’s a space for you.
Vet a Feature for existing products (24:22)
Aakash: And does this apply only to new products, or what about features for existing products?
Oji: That’s a really good question. Because we realize a lot of vibe coders will say, I could never build before, I need to build. So this is perfect for that. When I started the first demo of Code Memo I used these skills to do it. But really, most PMs don’t start brand new projects. So we have features for them.
Oji: So for example, this is called Vet a Feature. I have a feature idea. Should I even bother building it? I have opportunity cost of other feature ideas. And so this particular skill will take a feature idea and tear it apart. Look for anti-patterns, confidence. So it’s like a scaffolding skill, but very specific for a feature within a product.
Oji: And I think this one is actually even more interesting, because this one focuses very hard not just on the lane, but whether it’s worth building at all amongst other features you have. So the sharp problem test is baked in really hard into this.
Aakash: So the key lesson here for any PM is, create a skill like Vet a Feature. You can grab OG’s, which we’re going to link down below in the description. But fundamentally, you need to work with LLMs to actually figure out, is this a problem worth solving? Is this the right problem space? And before, we used to do that all by ourselves or skip that step entirely. And this is really helping us have a thought partner, make sure we actually do it every single time.
Oji: That is correct. We want you to think about the full stack of the problem. Again, business, product and code together. When you work in triads or quads or whatever that is, because of the people around you, you are, if you’re lucky, thinking about all those things together. And you’re like, is this worth solving as a PM? And the developer is like, oh, here’s how we’re going to do it. And product marketing is like, here’s how we tell the story, I’m going to go off and do research.
Oji: What we’re doing is compressing all that into one really smart orchestrator, and a builder can get started really fast. It doesn’t mean you don’t need specialists, by the way. Big companies always need specialization. That’s a given. But in small startups, in smaller companies, and even as you scale up to big companies, the ability for one person holding a critical skill, say product, to really have agents that help them with the first draft of these things, is incredibly powerful.
Aakash: Quick thought experiment for you. Is there anything in this video you should be trying on your own? If there is, try it. Take a screenshot, post it on LinkedIn or X, and tag me. I’d love to see what you’re learning.
[Sponsor break]
Applying PM judgment to the output (31:18)
Aakash: So maybe we can turn over to the other one that’s run, and you can show us how you apply your PM judgment on top of what it’s written.
Oji: Yeah, that’s a good point. So I’m back in the first one, and let me just make sure that it’s done. I’m going to ask it to continue and share the final results in a table for me, so that we can know that it is done. Done.
Oji: So yeah, here’s the result. Okay, so it’s done market research. It’s decided what’s viable, the structure. So the way to think about this now, once you’re here, is to go back into this and start to take a look.
Oji: I’ve worked with developers in the past who I had to insist that they actually do code review, even if they’re working with AI. And so the place you start first is these two documents. The other ones are sort of boilerplate. So I’m going to create some space here. So this is the market research document. And then I think if we double-click, if you two-finger click on the market research…
Aakash: I think you can open as preview, so it looks a little better.
Oji: Okay, let’s do that. There we go. Perfect. Well, you know a VS Code trick that I don’t. So that’s good on you, Aakash.
Oji: All right. So, market overview. It sits at the intersection of AI code. So look, I don’t want to read through all this. The first thing is to take this for yourself, and for PMs and PM leads in your space, and see if it covers all the ground that you need.
Oji: The things to look out for are, does it mention the kinds of tools you expect it to mention? Well, these are a really good set for this kind of tool, because these are your competitors. Does it mention in each of these categories all the things that you wanted it to mention? You take a sense check of these things. If it mentions tools that are old, tools that are not functional, tools that are sort of decrepit, you shouldn’t trust it. If it mentions tools that are current, adjacent things that you were thinking about as you were thinking about the problem but they didn’t actually solve the problem for you, then you are on the right track.
Oji: Take a look at this differentiation map, for example. Does it seem right?
Aakash: Yes.
Oji: Where does Code Memo sit? Does it seem right for you? And so this is your first scan for credibility. Imagine that you are doing a PRD review in a room full of PMs. This is what you essentially should be doing with this one.
The PRD review (34:31)
Oji: And then it actually writes a PRD for you. And so this is the real PRD review. Is the stuff in the market consistent with what it’s writing for you? So let’s scan this very quickly.
Oji: Code is now produced faster than anyone can read it. AI codegen has split authorship from understanding. The person who wrote an app via prompts often cannot evaluate whether it’s safe, correct, or production ready. This bites two groups hard. Solo founders ship AI slop they cannot audit. Corporate developers onto an unfamiliar codebase.
Oji: So it came up with all this by itself. And if you stare at this and say, I would invest in that, I would spend time on that, it nailed exactly what I want. Or you should be asking yourself, what did it miss? What persona did it miss?
Oji: For example, what I notice here is that it says the primary is a non-technical founder. Makes sense. Small company. Sure. It’s probably not a big company founder though, right? They have more resources, more tools. So I’m glad that it said non-technical founder, but it didn’t qualify it by the size of the company, for example.
Oji: It sort of doesn’t think the corporate developer is the strongest thing. It’s simply out of scope, to protect focus. That makes sense, I guess. But I read the output and it mentioned that it’s a much lower value proposition for the corporate developers, because they have so many more tools to do these things. And so the vibe coder is a real target for this value proposition.
Oji: Paste a GitHub URL, upload a vibe coded folder, and in under a minute get a plain English verdict on whether the code is production safe. So this starts to tell us that the value loop is really good, is really powerful. And so I would scan this and see, is this the kind of high level product brief I would write? What’s missing? What’s missing if I wanted to present it to other people? And that’s how to evaluate this.
Standup Zero fails the gate (36:48)
Aakash: Cool. Let’s go take a look at the other agent and see what it did with our other idea.
Oji: Okay, let’s do that. So let’s step back here. It looks like it is still crunching through the viability gate. So let’s go to that folder. And you can see it’s called Standup Zero here, and it has crunched through the viability assessment. And so, scorecard. So it’s weak.
Aakash: So this is the real alpha from using a skill like this. It’s going to help you separate out which features, or in this case we showed new products, that you should be building and shouldn’t be building.
Oji: Yeah. So here it says there were three moderate scores. So it’s saying, I’m not sure about this, basically. You should proceed with eyes open. And then it goes into the details. Clarity and urgency is moderate. It’s just workflow convenience. It’s not very deep. Target user definition isn’t very strong for what I pasted in. The competitive landscape is very strong. This is actually a bad thing. There’s a lot of competition here. And so it’s calling out all these things for you. Differentiation isn’t very strong.
Oji: So all of this is basically pointing out that it’s going to be very hard for you to enter this market. It’s not defensible for you. Everyone can build exactly what you’re building. So if you really want to continue this, you should maybe pause and think about it.
Oji: Now, I don’t know about you, but I think that’s worth a lot from the start. This is you thinking hard about where you’re going before you start thinking, I can write code. Because what we see today is people just build. People build and then there’s no customer for it. There’s nobody for it. In fact, it’s super puzzling right now, because it feels like GitHub is the only place that people can express themselves when they have Claude Code. They just build anything, put it on GitHub, and just languish with zero stars. If that makes any sense.
Oji: Now, if you are someone who wants to make an impact in the world, this kind of thing will help you conserve your time, attention, and focus on all the right things.
Prototypes and the interaction model (39:32)
Aakash: So where do we go from here? We promised that we’d help people become a builder PM. What’s the next step once you’ve figured out the right idea? In this case, we’re knocking out Standup Zero, but we’re in favor of Code Memo.
Oji: Yes. So let’s go back to Code Memo. And I think we get to tell it to continue. All right, fantastic.
Oji: So the next thing I would do is prototypes. And this is a fun one. What should Code Memo look like? I want to establish the basic interaction model that delivers value. Can you first ask questions about the user interacting with Code Memo, and then we will generate a set of prototypes to evaluate what direction to take this in?
Oji: Now, this is very compressed. You don’t necessarily start with prototypes, but you do start with interaction. And by that I mean specifically, does this have user experience? Is this just a chat interface talking to an agent? What does it look like? How do you instantiate it? And so I’m going to ask it to use its survey skill to help me make the choices.
Oji: So now that it says go, what I’m trying to do next is really to start to build a baseline of a product. If you look at these skills, there are a few directions you can take this in.
The customer discovery plan (41:53)
Oji: For example, the interesting one that I would do right after this is the customer discovery week. I’m going to ask it to use this skill to tell me how to get to better confidence and to answer the unknowns.
Oji: So while it’s doing that, I’ll prep that question. I need you to develop my customer discovery plan by running the customer discovery week skills.
Oji: So on one hand, I’m trying to generate ideas of what the interaction is. On the other hand, I need to ask a bunch of questions. So let’s tackle the questions about the interaction model first.
Oji: So, paste a GitHub URL. I don’t like any of these. So what I’m going to say is, I think it’s both one and two. I needed to paste the GitHub URL, but I’m going to connect it to GitHub because I need to analyze the code that I’m writing, because I’m a vibe coder.
Oji: How’s the verdict delivered on screen? Single verdict card, narrative scroll, conversational chat. So I think that it needs to be a dashboard and drill down. Once the verdict is on screen, what should the user be able to do? Depth of engagement. I needed to do two and three, and four.
Oji: In the first 60 seconds, this is interesting. It’s getting to the aha. What was the core value the user came for? Understanding. Submit those answers.
Oji: I need to develop my customer discovery plan, run the customer discovery skills on the product brief and market research, and do this in parallel while finishing up. It’s going to spin up a thread finishing up the interaction model.
Oji: So I’m basically doing two things now. I’m grounding my sense of what interaction is, and I’m going to launch additional research to really figure out if I fully understand the problem. Now, I would ordinarily do the one before the other, but I just wanted to demonstrate the two different ways. You can go straight to build, or you can start to talk to customers about it.
Oji: So what we’re seeing is it’s summarizing the tension, and it’s going to generate three self-contained HTML and CSS prototypes. The skill itself tells it to do this prototype before you react. So it’s going to go off now and it is going to basically start to write prototypes.
Aakash: So the last set of skills in the diagram we started with was really the business layer. Is there business viability, which we talked about in terms of a new product? For a feature there might be some more nuance there. Then this next layer is really that product layer, where we’re figuring out the prototypes, what actually works, and we’re going to go through and find a prototype that might potentially demonstrate a viable solution so that we can test that. Is that right?
Oji: Yes. That’s exactly right. We start out with the business problem. Is there a lane for us? Are we thinking about the customer correctly? There are other business problems that you get to later. Pricing, access to market, what’s your marketing plan. But what we’re doing now is product. What’s my customer discovery, so I can dig deeper into the problem? What does this even look like?
Oji: As PMs, we usually own why is this a thing that we spend time on as an organization, and what is it, which is how does it instantiate, what does it look like, what does it feel like when it’s solving the problem, how does it generate delight. And of course we share this with designers, and so we’re still early in that process.
Oji: Assuming you’re a vibe coder, what won’t we know? What does it feel like? What does it look like? These are all the things that you take to developers. But what you have now is that, because you’re doing it all in one shot inside Claude Code, you can compress all of that within one Claude Code session. And you notice that we are not in Claude Desktop and Cowork. You can do all this within one session.
Oji: So what we have here is, it’s done some prototypes. While this is running in the background, I am going to show you some of the prototypes it’s made. I really hope to God, because we didn’t install a lot of design skills. Can you see this?
Aakash: Mhm.
Oji: Yeah. So it’s made a few things for us to take a look at. The way you should think about this is prototypes. You should just get a feel. This isn’t real design yet. This is definitely about, where do you start? So here you see it. You paste in the GitHub thing here and it tells you the story of the code very quickly. Here, more of the same but more data, logic up front. And here, sort of a side panel where it does similar things.
Oji: So what I usually do when I start to work on these things is, in practice I’ll have shadcn, I’ll have UI UX Pro Max skills, I’ll have like five or six design skills, and I’ll tell it to use one design skill to make a prototype. So if I have six design skills it will make six prototypes. And I’ll ask it, because you can make hundreds and hundreds of prototypes, I’ll ask it actually to combine two skills each. So it will make like six more but using two design skills at a time to do it, and so I can see what this could look like for us. But all this is baked into the skill directly.
Oji: I’m going to go back to Claude Code and share that screen again, and then we’ll take a look at the other task that we asked it to do. Okay, so by the way, it’s asking me about the interaction model I want. We’re not going to spend time figuring that out yet, so we decline that. So we’re going to instead say, the discovery plan agent finished.
Oji: So it created a customer discovery plan for us. So we’re going to go to docs and we’re going to go to customer discovery plan and we’re going to take a look at it.
Oji: And it says the plan itself is complete and executable. The script, the survey, the synthesis template and the week’s time budget are below. What is missing is the one input the skill will not let a plan proceed without. A confirmed list of recruitable people with real target cohorts, not adjacent contacts from the founder’s network. The skill treats fewer than five real target contacts as its own validation signal. It means you may not have access to the market.
Oji: Again, very important. It says you can’t just wing this. You need actual people to talk to. If you tell me who they are, then I know that you’re ready for this.
Oji: And so what we can see here is the three-step interview process that it wants us to do. It tells you how to recruit, what the gates are, where to go shop for targets, the hypothesis you want to validate, step one, motivation.
Oji: In the book, we talk about this three-step process where the first step is figure out what questions to ask. Open-ended questions, no motivation, no direction, no prototypes whatsoever. So it walks you through that. Tell me about. Walk me through the last time. So it’s walking through people’s workflows.
Oji: And then step two is when you take those things and say, okay, I now think I have the questions I need to answer, and then it will codify those questions. So the first step, you learn what questions to ask. The next one, you use those questions to ask. And then the third, you expand it so it becomes data. So once you really solidify the questions you’re asking, you can start getting a sample of the answers. You turn it into a survey so you can quantify the responses that you get. So it builds all this for you, ready to go.
Oji: In this case, it’s saying, listen, you sound like you’re still winging it. You need very specific people. Go find them and I will help you validate that you have a real customer discovery plan.
The three speed problem (51:31)
Aakash: So what I’m really hearing from these skills is that they’re forcing you to do the PM fundamentals. And what they’re doing is they’re giving you the first draft of those things. And to be a true builder PM, you need to be able to do this at engineering speed. And that’s why we’re relying on these skills. We’re not just doing it by hand, as we did step by step in the past.
Oji: Correct. So there’s something we call the three-speed problem, which is, for the past 40, 50 years, whatever you want to call it, the longest pole has always been development. And it’s long in many ways. It takes time to actually write quality code. It takes time to do quality. It takes time, if you’re in the cloud, to make it robust, not fail, to do DevOps, recover very quickly. All of that is being cut down maybe by 10x, maybe in five years by 20x.
Oji: But really the process of building is not just code. It’s, why should we build this, build it, get it to customers. So if this middle speeds up very quickly, you start to have almost an equation imbalance. And the reason it’s an imbalance is because the why should we build is customer bound. You have to talk to people. You have to talk to the market. And the other side, access to the market, getting it into people’s hands, is also customer bound.
Oji: Because Anthropic has shipped what, maybe like 60 features in 30 days.
Aakash: They’re becoming recursive.
Oji: Correct. By the way, that’s a whole other thing to talk about, which is how to build feedback into the skill. So some of these skills build feedback deeply into the product automatically for you. And we’re trying to refine some of those things. We haven’t shipped that one.
Oji: We were fussing with slash commands just now. I don’t know all their slash commands. So I can’t actually absorb all the features that they make. I’m limited by that.
Oji: I don’t know if our audience knows this, but Claude Cowork was just completely redesigned. They shipped it and it seemed amazing, but there was low adoption, and so they’ve just sort of blended it back into chat a bit, versus having three tabs, Code and Chat, because it didn’t stand alone by itself. So people are having to not just ship very quickly but make sure they have the right thing.
Oji: And by situating this in the same skill set that your developers use, that you can learn very trivially, you see a massive amount of speed up. Because this repo can be your developer’s repo as well. It’s not different. If your founder and your developer are working on this, they can see all the business skills themselves. They can run them themselves, or you can run them.
Oji: So we are seeing people essentially collapse the separation of tasks. PMs live in Notion, designers live in Figma, and collapsing it into one GitHub repo with everything. The coders will live here under source, test, all the security stuff, Playwright, Vitest. You live up here. But it’s joint context in one repo for every member of the team who needs to touch this stuff, and everything is always available to them at all times.
Where to grab the skills (55:31)
Aakash: Amazing. If people want to go grab these skills, can you show us where they can grab them?
Oji: Yes, I can, Aakash. So I am going to share a different screen. One of the fun things we’ve done at Product Mind as we start to build is start to collect these things. Some of them are private. They’re not available yet. But if you go to the labs at productmind.com, don’t just ignore these things. This is not a monetizable site yet, or at all. This is just to show the products that we can actually share from our engagements.
Oji: But everything you’ve seen actually can be accessed more trivially through what we call skills. So you can chat with it without going into Claude Code. So that’s the first thing. The second one, and we have a lot of people who do this now, the second one is a skills library. The skills are open source. So you can come here and you can browse through them, read them.
Oji: Here you have the new project scaffolding, Vet a Feature, Vibe Memo. I’m very excited about this one. Vibe Memo is a simple system, we installed it, that captures your decisions as you build. So right now, when you write code, that’s captured. But Vibe Memo says capture the why. Why are we making these decisions in the code? So it keeps the why with all the decisions in the log for you. I find this very exciting. So every time we have a big code base, we want to take a look at, why did we even make that decision? What were we thinking? Vibe Memo captures it.
Oji: Sharp problem test. There’s so many. Let me just point out a few more favorites. One is roadmap from strategy, to construct a whole strategy for you. Another one is a listening machine. It will turn all the surfaces in your product into feedback tools that constantly collect information. These are things that people spend years and years trying to figure out. We build it into a skill that gets you started immediately.
Oji: Scope cutter. We all do this. We’ve got to cut scope. And scope cutter gives you a very succinct way to reduce how much you do. There’s even a simpler one, which is, once you want to build the first thing, are you going to do an MVP, which is just for learning, or are you going to do an SLC, which is actually to put in front of people for them to be amazed? And how do you even do that, and how do you cut, and so on and so forth. And of course advanced things like pricing. How should you design pricing? All built in.
Oji: So again, business and product level skills that merge with code skills in one place for you to become hyperproductive. We think this is the new frontier. I think code skills alone are becoming cheap. The other day I saw someone remove Superhuman skills from their repo because the models are so good. Some of these skills are breaking. But these business skills, these product skills, these are still the things that give us the ability to build the right thing. So I’m super excited about that.
Aakash: And today we showed the harness as Claude Code in Antigravity. Is there any particular reason you should be using Antigravity, or can you use any harness for Claude Code?
Oji: No, it’s any harness. Antigravity is a fork of VS Code, so it looks a little bit like Cursor. It looks like VS Code. It does. That’s just what I have on my screen. I’m running through a terminal, and so I actually don’t use any features of Antigravity. It’s a nice interface, but nothing special about it.
Rolling this out to a team (59:20)
Aakash: So if you’re a product leader, you go ahead and you download these skills, you make these skills your own, you distribute them to the team, the team is starting to use them. You are one of the few people who has actually helped teams do that. So you’ve gotten to see, what are the mistakes that people make? What are the problems or the pitfalls in rolling out this new way of working that people should know about, so that they can avoid them?
Oji: I think that the most important thing is shared context. I heard Boris from Claude Code talk about the fact that his CLAUDE.md is very thin. It has only a few lines, maybe six lines. And what it’s actually doing is that it’s referencing a shared CLAUDE.md.
Oji: Now, you should think about CLAUDE.md as some kind of base skill, basically. And so centrally they author CLAUDE.md and optimize it. Think about it, once a minute, everything that everyone is learning is being put into that central CLAUDE.md. It’s small, it’s short, it contains essence, it connects people to all the right tools within the organization.
Oji: So I think that the biggest lesson for putting this into an enterprise is, don’t let people fork these things willy-nilly. For example, I was working with an enterprise that had a ways of working document, and then they had a very specific SDLC that was supposed to produce very specific artifacts. What I would do in that situation is to take the relevant skills here, for example the scaffolding skill or the Vet a Feature skill, and I would harmonize it with what they need to come out of it.
Oji: Why would our product brief be different from what the organization wants? It shouldn’t be. Why would a market research document be different from what the product marketing team would produce, or what they believe is right to produce? And so we would essentially centralize this, modify it so that it creates artifacts that our organization needs, and prevent people from forking it themselves.
Oji: Now, to be clear, I like organizations where it’s sort of open source, and if people learn new things, because the CPO doesn’t know everything, you give people the license to innovate. Or if they innovate, they should innovate into a central place so everyone gets the innovation, if that makes any sense.
Oji: So I think that’s the biggest thing, when AI rollouts are completely ungoverned in a way that doesn’t have shared context. Because listen, in science fiction we’re always sort of afraid of the hive mind. We’re afraid of AIs collaborating because then they’ll kill us. But it turns out that we are the original hive mind. The only reason that we’ve survived through the centuries as humans is because we learn from each other. And so this is very imperative when you roll out AI. Try to force it into a structure where one person learning means everyone has learned. That’s one of the big powers of it.
Closing (1:02:52)
Aakash: OG, you’ve generously shared these skill files. You guys can find the link in the description to this GitHub repo. As he said, you can make these your own. That’s really the key. Adding it in to make it your own, and then deploying it as an open source repo for your team to use. This is the playbook. If you’ve been wondering, how do I become a more AI native team, how do I get my PM team to work at engineering speed, we’ve just given all of that away for free. Thank you so much for being here.
Oji: Thank you, Aakash. And I hope people become even more effective product builders and hyper creators with the stuff that we’ve made. Super happy to share.
Aakash: I hope you learned as much from today’s episode as I did. If you can do one thing that’s totally free that would help the show, it would be to check that you’re following on Apple and Spotify podcasts. Check that you’ve left ratings and reviews on those platforms. Check that you’re subscribed on YouTube. Leave a like and a comment on this video, and then share it with your friends. We’re trying to make better and better podcasts. After two years, we think we’ve gotten something pretty good going. So let us know what we can do to make it even better, who else we should interview, and we will put on the best shows we possibly can.
Aakash: Finally, don’t forget my offer for the bundle. You get an entire year of my paid newsletter, plus my favorite AI tools. Bolt.new, Airtable, Speechify, Descript, Magic Patterns, Linear, Dovetail, Arise, and Mobbin. That’s $27,000 worth of value for just $150. So check that out at bundle.aakashg.com if it interests you. And I can’t wait to share our next episode soon.