We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Atlassian: lots of people building, no one steering
Atlassian's product leader shared lessons from shipping AI across 20 apps. The biggest one is about people. Atlassian started about 10 projects staffed by "AI builders": PMs, designers and engineers who code with AI. They moved fast at first, then "slowed down terribly" after a few weeks or months. In the speaker's words, "everyone was rowing but no one was steering," and PMs and designers slipped back into their old roles to unblock decisions . Atlassian is adding an AI-builder role, but doesn't expect most PMs and designers to take it. The PM-and-design to engineering ratio is about 1:10, yet with AI it "feels like" 1:30 or 1:40, so steering matters more .
Other lessons from the talk:
- Use chat for discovery. What users typed into whiteboard chat became features, such as grouping sticky notes into themes, and new workflows, such as turning brainstorm cards into Jira tickets . Features built for humans are then exposed as tools agents can use, including through MCP or a CLI .
- Adding AI to existing products is fine. Atlassian says adding AI to existing workflows was "probably one of the best things we did." Its rule: reimagine workflows for new products, evolve them for existing ones . Agents should get the same primitives as humans: tools, context, goals, accountability, and awareness of what the team is doing .
- More junior hiring. Atlassian now hires more juniors and seniors and fewer mid-level people. It pairs juniors' willingness to experiment with seniors' eye for spotting slop, through a four-day "AI builder week" .
A r/ProductManagement post argues nearly the opposite. Teams that struggle "add AI to the workflow they already had" and end up with "a faster version of the broken process" . Atlassian's distinction between new and existing products may settle the disagreement.
Collison: agents could reward better products
Patrick Collison argues that personal agents will act as "a kind of structural subsidy for product quality." His thought experiment: imagine every buyer spent 10 hours researching each purchase. In that world, making the product better becomes a more effective strategy than winning on distribution . The other side of that change: coupons and other price discrimination work less well, and so does the cross-subsidy in which people who forget to cancel subscriptions pay for everyone else . Collison expects potentially "pretty big" changes for businesses that monetize demand routing, meaning placement fees and ranking algorithms . He also says it's open whether agents will concentrate demand on a few top products or spread it out, and that all of this assumes agents work for the consumer .
AI PM listings: no ML degree required, few entry-level roles
Aakash Gupta used AI to scan 8,354 open roles at 36 companies and found 651 unique product roles . Of the AI PM roles, 151 don't require hands-on ML experience and 15 do. Where pay was listed, the no-ML AI PM roles had a median of $262K, compared with $216K for non-AI PM roles. Only 8 of the 651 were entry-level . Anthropic and OpenAI listings asked for a grasp of model capabilities and for pairing offline evaluation with online experimentation . Gupta's caveat: these are listings, not hires .
Surge's new sudo L7 benchmark makes a related point. It has 60 tasks, mostly from private production repos, and grades architectural judgment and "should we even be doing this?" The best agents succeed on only about 45% of tasks . Lenny Rachitsky called that "half-way" to staff level .
New roles on AI-heavy teams
Sachin Rekhi sees three roles emerging on teams at the AI frontier :
- AI platform engineers, who run shared skill marketplaces, make company context machine-readable, and manage MCP connections.
- AI operations leads, who are embedded in marketing, sales and legal teams to automate their workflows.
- Forward-deployed engineers, who work inside customer organizations.
Agent safety is a product decision
Gupta retells the PocketOS incident. An agent working in staging found a domain-management token that, unknown to the team, could also delete production volumes. One API call wiped the database and the backups stored with it. The newest recoverable backup was three months old . The rules were in the agent's instructions, and it broke them anyway. The fixes all sit in the harness: narrowly scoped tokens, backups the agent can't reach, confirmation before irreversible actions, and complete separation of staging and production . His starting step: list everything your agent can destroy and put a guard in code on each item .
From the community
- Claude Code as a PM knowledge base. One two-founder team runs its whole company from a markdown git repo. They advise starting small with decision records (question, options, decision, rationale, review date) and saving nothing without a human saying yes .
- The domain-experience filter. A laid-off PM landed 4 interviews from 70 applications, and second rounds came only from companies in their own industry . A hiring-side reply defended the filter: when a role gets 300 applications in four days, domain experience is the only thing you can check in thirty seconds . Another reply countered that domain experience really matters only for infrastructure, hardware, deep ML, and compliance-heavy roles .