We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Moats: a test for them, and advice not to worry about them
Lenny's Newsletter published a three-step test for whether a startup has a moat. First, identify a compounding advantage. Second, judge how strong it could become. Third, measure whether it is working . Only four advantages count: switching costs, network effects, scale economies and data effects. If you can't see the potential for any of them, "that's a red flag" . Speed, distribution and brand are treated as "fuel," not moats. Distribution matters more than ever because building has become easier while reaching customers hasn't, but it only "helps create the raw ingredients" for a moat . The test is to judge a company by what it actually does, not by its stated strategy: what the team works on every day, what is on the roadmap, and which teams are large and influential .
That same evening, Paul Graham said nearly all standard startup advice still applies in the age of AI . On moats specifically: "don't stress about moats... Just grow." In his view, passing on growth because it lacks a moat is far worse than not having one, and "moats often emerge later anyway" . He added that AI can do much of a cofounder's work, but a cofounder's main job is helping bear the stress . If you're evaluating a company to join, use Lenny's test. If you're deciding whether to chase a growth opportunity, Graham's warning applies.
What building expert AI skills teaches
The previous brief covered Hiten Shah's Linear-vs-Jira example. His full article adds lessons from testing. A feed held several observations of one ClickUp pricing change. Counted separately, they could suggest a competitor kept changing prices. Experts check where information came from, because "plenty of retrieved material can still amount to one source" . Live use exposed failures the evaluations missed. One skill asked users for information the system already had. Another created a file the user couldn't get to. Shah's fix was to follow each request all the way to a usable result . Expert corrections that keep recurring can become reusable rules or tests, but test them on several cases, because "a rule that fixes one example might make another worse" .
Sachin Rekhi now scores every employee on seven AI-maturity levels: Abstain, Search, Assist, Judge, Automate, Compound, Transform. Assist means producing real deliverables. Judge means critiquing and iterating on output, which he calls critical "in an age of AI slop" . He named each level with a verb so behavior is easy to observe .
Teresa Torres on engineers, discovery and training
Torres says the common mistake is that engineers first see the work at sprint planning, after requirements and design are done. That is the most expensive and disruptive point to get their feedback . She wants at least one engineer involved while the team learns from customers and explores solutions . On AI blurring roles, she treats one- or two-person teams using coding agents as "an interim step," not the end state. PMs who submit PRs need to learn about scalability and maintainability. Engineers who build without customer context run into the same wall from the other side .
In a separate episode with Petra Wille, Torres argues that a one-hour talk can't create a habit-driven team. Know-how transfers fast, but skills need practice over time . Talks work best as part of a longer coaching program .
When agents become the users
- Agent shopping. Shah suggests that Shopify sellers ask an agent using Tobi's new Shop skill to shop for their product category without naming their brand, then see whether it recommends them .
- MCPs over UIs. One B2B team says it does nearly all its work through Claude and uses outside software through MCPs. Its time in software UIs has "decreased by a great margin," and it expects customers to follow .
- Google Labs hiring. Josh Woodward, head of Google Labs, the Gemini app and AI Studio, says he is hiring for "unlearning" rate and explosive endurance .
From Reddit
In one org, weak product leadership has turned PM into project management. UX, engineering and BAs fill the requirements gaps . Suggested fixes: track the cost in clarification hours, rework and bounced tickets , and don't start work without a problem statement, success metrics and acceptance criteria . A thread on PM frustrations in 2026 offered a prioritization tactic. Rank the backlog against named strategic goals, make each new request say what it would displace, and record who overrode the order so you can review those calls at quarter's end . One commenter described an executive who compared a two-week vibe-coded build with a six-month estimate, even though the quick version broke legal and contractual obligations .
- Bring an engineer into customer learning, problem selection, and solution exploration before sprint planning; waiting until requirements and designs are fixed makes feedback more disruptive and can miss better technology-informed solutions. Engineers should first get curious about customer needs, business goals, and discovery, then offer suggestions grounded in their expertise rather than projecting their own preferences onto customers.
- For customer discovery, interview people who experience the problem even if they are not current customers, and ask them to recount a specific experience from beginning to end. Following up on skipped steps reveals what people actually did; direct questions about tools or habits can elicit less reliable answers. Compare the story with the product to identify unmet needs and gaps.
- AI coding agents make it easier for people to work across roles, but do not replace the trio’s complementary expertise: engineering on feasibility, design on usability, and product management on business viability. Torres sees one- or two-person agent-assisted work as an empowering interim step, not a scalable substitute as products grow; teams can enable one another with engineering patterns and codebase documentation, plus documented customer and business context.
- The essay identifies social life as an underserved consumer-agent opportunity: beyond one-off tasks, agents could coordinate gatherings, help people maintain closer relationships, and facilitate new connections. For matchmaking, it distinguishes personal agents that represent one user’s preferences from mediator agents seeking a good fit for multiple people.
- In the author’s reunion example, agents found attendees and contact information, published the event and reminders, reviewed itineraries, mapped locations, handled permission approvals, and produced a to-do list. She also points to early-access group chats that work for friends without accounts as a way for agents to coordinate through existing communication patterns, and envisions agents coordinating across users’ calendars and preferences.
- For relationship-building, the proposed product role is to notice timely opportunities—such as sharing photos, discussing a book, or meeting someone while traveling—and prompt the user, rather than automatically generating every message. The essay cautions that AI-suggested replies may make recipients evaluate a partner more negatively when they suspect AI use, while personal messages from close friends are associated with greater well-being than broadcasts or likes.
- Continuous discovery cannot be taught in a single hour: it involves multiple skills, habits, and mindsets built through repeated practice. This creates a service–outcome mismatch when teams expect a talk or workshop to produce a capable, habit-driven team.
- Know-how can transfer quickly, but skills and mindset shifts require practice; talks are better suited to inspiring a team and depicting a different future, and deliver most when embedded in longer coaching or training. Open Q&A can surface organizational barriers that need addressing before training can work.
- PMs can face an accountability mismatch: one commenter says most work is making initiatives decided without their input function, while evaluations still emphasize strategic decision-making; another describes revenue KPIs tied to flows owned by other teams.
- A practical prioritization tactic is to order the backlog against named strategic goals, require new requests to identify what they displace, document who made overrides, and revisit those decisions later. Commenters caution that executives may be weighing broader objectives or context that PMs do not have.
- One commenter describes an executive comparing a two-week vibe-coded solution—which reportedly broke legal and contractual obligations—with a six-month estimate, a warning against treating prototype speed as equivalent to delivery. Another argues AI implementation still needs causal validation against user experience or business metrics.
- The post criticizes PM hiring criteria as difficult to satisfy: newer tech firms may ask for more years of experience than the sector has existed, while older firms may require highly specific domain and subdomain experience.
- Treat a moat as a self-reinforcing advantage, not just a temporary edge: the framework is to identify a potential compounding advantage, gauge its possible strength, and measure whether it is working; the four proposed types are switching costs, network effects, scale economies, and data effects. No plausible path to one is a red flag. Assess the company through its core customer-value loop and what teams actually work on—the roadmap and influential teams—rather than its stated strategy.
- Look for product and operating choices that fit the proposed moat: deepen workflow embedment and expand use cases or integrations for switching costs; grow both sides of a marketplace and improve discovery or reduce transaction risk for network effects; and expand operations or utilization to lower unit costs for scale economies.
- Data effects are becoming more common with AI: product usage can generate data that improves the product, with Cursor cited as learning from users’ code accept/reject signals. The article distinguishes speed, distribution, and brand as growth “fuel,” not usually compounding advantages in themselves, though distribution can help create one and brand may become one over time.
- Eyal’s “experience loop”—believe, anticipate, feel, confirm—frames marketing and branding as part of the product experience, not just a way to raise awareness: expectations can shape how customers experience an offering. He illustrates this with identical cars carrying Toyota and Geo Prizm logos that customers rated differently.
- Product teams should address customer perception alongside product quality and make sure the experience delivers on expectations. Positioning can also emphasize the emotional outcome rather than only the function: Eyal describes evocative language as turning an ordinary offering into an anticipated experience, citing Netflix’s “see what’s next.”
Product teams should think and operate like labs, experimenting at the frontier because what is possible changes every few months . Google Labs’ head says great ideas rarely come from design sprints, brainstorms, or scheduled ideation; “you can’t microwave good ideas” .
- Julie Zhuo proposes three jobs for social AI: make gathering logistics easier, help people maintain existing relationships through context-aware prompts, and help people meet through agents that represent individuals or mediate between both sides.
- Product examples include Instinct’s early-access group chats, which can include people without Instinct accounts and support trip, carpool, and ticket coordination; Meta’s Muse can remember dietary restrictions, suggest menus, and turn recipes into grocery lists. Zhuo says agents cut planning her mini-reunion from at least 5–10 hours to 30–60 minutes.
- A key interaction guardrail: help users act on sincere intent rather than automate personal communication; Zhuo notes that people evaluated partners more negatively when they suspected AI-suggested replies were used.
Lenny shared a plug-and-play Claude moat-check skill for evaluating a company one is considering joining; it guides users to identify a compounding advantage, assess its strength, and measure whether it is working.
Google has personal-context data across Chrome, Android/Gmail, Calendar, Maps, Photos, YouTube, and Docs, but the quoted post says it still lacks a clear, simple unifying personal-AI product—and argues that Google is consequently powering other personal-AI products, including Meta. Lenny shared Google executive Josh Woodward’s response: “Watch this space. We hear you loud and clear.”
- Product teams should operate like labs teams: as what is possible changes every few months, staying ahead requires experimentation at the frontier.
- The Head of Google Labs, Gemini app, and AI Studio says the two skills he is hiring for are a high rate of “unlearning” and “explosive endurance.”
For product and company strategy, treat a compounding advantage—not distribution, execution, or early-stage brand alone—as the basis of durable defensibility. Distribution helps create the ingredients for a moat, execution gives a company more chances to find one, and brand can become a moat over time but often takes too long to matter for startups. The four proposed compounding advantages are switching costs (deeper workflow integration supports retention and reinvestment), network effects (more users improve the product and attract others), scale economies (higher volume lowers unit costs), and data effects (more usage generates data that can improve the product). When evaluating a startup, identify its potential compounding advantage, gauge how strong it could become, and measure whether it is working; seeing no plausible advantage is a red flag.
Distribution, execution speed, and brand can help startups grow, but the post argues they are not usually durable moats on their own; lasting defensibility comes from compounding advantages . It identifies four such advantages: switching costs, network effects, scale economies, and data effects, each strengthening as the product or business grows . A startup-assessment framework is to identify its compounding advantage, gauge how strong it could become, and measure whether it is working .
Tobi’s new Shop skill lets users connect their Shop account to an agent for shopping . For Shopify sellers, Hiten Shah suggests testing agent-mediated product discovery by asking the agent to shop for the category they sell without naming their brand, then checking whether it recommends them; he frames this as a new question alongside understanding why customers buy .
When testing early prototypes for product-market fit, look for people’s eyes lighting up or their leaning in; the speaker contrasts these reactions with relying on DAU or DAU/MAU as the signal at this stage.
A durable startup moat is a self-reinforcing compounding advantage; distribution and execution can help a company but are not durable moats by themselves, and brand may take too long to become one for most startups. The four mechanisms are switching costs, network effects, scale economies, and data effects, each of which can strengthen as the company grows. To evaluate a startup, identify its potential compounding advantage, gauge how strong it could become, and measure whether it is working; seeing no potential advantage is a red flag when considering joining.
A useful framework for assessing product ideas is to look for four compounding advantages: switching costs deepen retention and revenue per customer; network effects make the product more valuable as users join; scale economies lower unit costs, enabling lower prices or a better product at the same price; and data effects use growing usage data to improve the product and drive further usage.
Hiten Shah says Q3 brought more AI-agent capabilities he had been running on his own machines into products anyone can use, changing how he thinks about the size of tasks to give AI and what it can be trusted to handle.
- AI workflows for research should not infer why deals were lost without buyer interviews or deal records; they should state what evidence is needed, since plausible unsupported explanations can influence decisions.
- Product teams can turn expert corrections into reusable methods or tests for recurring errors, while keeping temporary, task-specific corrections in context. Test rules on different cases because a fix for one example may make another worse.
- Evaluate the full user journey through a usable result, not just whether an individual step succeeds: the system may lack required information, ask for information it already has, or create a file the user cannot access.
- In competitive analysis, distinguish separate market events from duplicate observations or articles repeating one source; provenance affects how many events or sources the analysis can credibly claim.
For a PM with one year in the role after growth marketing, moving from client-led B2B feature delivery toward B2C, the thread recommends presenting complex cross-team delivery under regulatory deadlines and, where possible, linking it to client revenue maintained or grown when direct user metrics are unavailable. B2C applications should demonstrate experience with data, A/B testing, analytics, scale, and customer satisfaction; shipping a small B2C product independently is another way to create concrete portfolio and interview evidence. One commenter cautions that moving from B2B to B2C can be harder than changing domains, and that a year of PM experience may be a disadvantage in a difficult market.
It Takes an Expert to Build an AI Expert
As a test, we asked Claude to explain why Linear was losing deals to Jira. It gave us eight plausible explanations, even though we hadn’t provided any evidence about those deals.
There were no buyer interviews or deal records to draw from. Still, the answer sounded like something a sales team could use. A few of those explanations could easily have made their way into a meeting and shaped a decision.
We tried the same question with a win/loss skill we’d built for competitive intelligence and product marketing. This time, Claude said it couldn’t establish why the deals were lost. It explained what we’d need to learn from buyers before reaching a conclusion.
Someone experienced in win/loss research would recognize the problem immediately. They know how quickly a reasonable-sounding explanation can become accepted as fact. They also know that understanding why a buyer made a decision requires evidence from that buyer.
We’ve been building 16 AI skills around knowledge like this. The work has taught me how much expertise becomes visible when someone explains why an answer isn’t good enough. Those explanations can help us build systems that recognize the same problems before anyone acts on the result.
What Experienced People Notice
A salesperson preparing for a competitive call needs claims they can defend when a buyer asks a difficult question. A model can produce a polished battlecard in seconds, but someone who’s done this work for years may spot a comparison based on old information or a recommendation that assumes too much about the buyer.
We talked with product marketers and design partners while developing the skills. Their feedback was especially useful when they challenged answers that initially looked fine. Asking why they wouldn’t use an answer often revealed a requirement we hadn’t thought to write down. The explanation could become a rule the system would need to follow.
Another example came from a feed containing several observations of a ClickUp pricing change. The records referred to one underlying event. If the system counted each observation as a new change, it could tell a convincing story about a competitor repeatedly adjusting its prices.
An experienced analyst would check whether those records described separate decisions or repeated visits to the same page. A similar problem arises when several articles repeat a single press release. Plenty of retrieved material can still amount to one source. Understanding where information originated changes what the analysis can reasonably claim.
We wanted the skills to make those distinctions consistently. That meant learning from the mistakes experienced people could spot and testing whether the resulting rules held up in new situations. During development, though, we encountered a failure that no amount of domain expertise could resolve on its own.
The Whole System Has to Work
One skill had been written around a market briefing described in our documentation. When the team checked the running system, the briefing capability wasn’t there. We caught the mismatch before running the model as part of that audit.
The instructions could have been followed exactly and the job still wouldn’t have worked as designed. Fixing the wording would have done nothing to make the missing information available. We needed to check what the software could actually deliver.
Our evaluations tested whether the skills followed their methods and handled missing evidence appropriately. Those checks helped, but later live-use testing uncovered problems outside their scope.
One skill asked someone to identify their company even though the system had already returned that information. Another generated a file on disk without making it available to the person who requested it.
In the second case, the file existed. The person asking for it still couldn’t use it. A test focused on file creation might pass even though the job remained unfinished.
These failures changed what we looked for when testing. We needed to follow a request all the way through to a usable result. When something went wrong, we had to find where the process broke before deciding what to fix.
The Most Valuable Corrections Should Last
People who know their work well make corrections that can teach us a great deal. They catch unsupported claims and recognize when an answer doesn’t fit the situation. Yet the reasoning behind those corrections often disappears when the conversation ends.
Some of that knowledge can become part of a reusable method. A mistake that keeps happening may deserve a test of its own. Other corrections depend on temporary information and should remain part of the context for that particular task.
Making those decisions takes care. A rule that fixes one example might make another worse. We need to try it on different cases and see whether it holds up.
The methods will also need to evolve as models improve. Some instructions may become unnecessary. The responsibility we’re asking the system to handle still determines whether its output is good enough.
This is where I see the long-term value of a skill library. It can preserve lessons from people who understand the work and make those lessons available the next time someone needs them.
The Convincing Wrong Answer Test
Try this with an AI workflow your team already uses.
Find an answer that sounds reasonable but contains a mistake an experienced person would catch. Ask them to explain why they wouldn’t use it. What would they need to know before trusting the conclusion?
Their explanation should help you decide what needs to change. If the answer lacks evidence, make the source requirement clearer. If the system makes a claim it can’t support, define where it should stop. A missing tool needs an integration fix. A result that never reaches the user needs an end-to-end test.
Then run the workflow on a different example. You want to find out whether the change improves how the system handles the job or simply fixes the original answer. If the mistake returns, you have another case to learn from.
When I first wrote about skill libraries, I was thinking about how companies could preserve the methods their best people had developed. Building these 16 skills helped me see how much of that knowledge only surfaces when someone encounters a problem.
An experienced person can recognize why an apparently good answer shouldn’t be trusted. When they explain what they noticed, we have a chance to make that judgment useful beyond a single conversation.
The mistakes experts catch are often the skills AI still needs to learn.
The Skills
We’ve open-sourced the 16 skills for competitive intelligence and product marketing so you can inspect their methods and try them on your own work.
- AI workflows for research should not infer why deals were lost without buyer interviews or deal records; they should state what evidence is needed, since plausible unsupported explanations can influence decisions.
- Product teams can turn expert corrections into reusable methods or tests for recurring errors, while keeping temporary, task-specific corrections in context. Test rules on different cases because a fix for one example may make another worse.
- Evaluate the full user journey through a usable result, not just whether an individual step succeeds: the system may lack required information, ask for information it already has, or create a file the user cannot access.
- In competitive analysis, distinguish separate market events from duplicate observations or articles repeating one source; provenance affects how many events or sources the analysis can credibly claim.