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 .