We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI leverage is becoming an organizational design problem. Sachin Rekhi argues that the highest-leverage way to improve a team’s AI productivity is a team-wide “Compounding OS”—a company brain—not chasing the latest model releases. His three building blocks are an organization-wide agentic platform, a shared skill library, and machine-legible company context. For PMs, the implication is to treat reusable skills and accessible context as shared product infrastructure, not isolated individual hacks.
Prompts are a new discovery surface. Hiten Shah’s “empty box” thesis is that not knowing what users will ask is the point: every unexpected prompt is product research. Clicks reveal how people use what you built; prompts reveal what product they wish existed. Instrument prompt themes alongside funnel metrics, then turn recurring, high-value surprises into roadmap hypotheses.
Agentic UX needs a trust layer. Scott Belsky argues that the products that win will combine trust and inspectability with unusually strong hospitality and personalization. For PMs, inspectability is a core experience requirement alongside delight—not a late compliance add-on.
Tactical Playbook
Diagnose adoption in two passes. First, instrument behavior before interviewing: analytics shows where, when, and for whom adoption breaks; conversations explain why. Then split users at the first completed run: dropping before it points to discoverability, onboarding, or friction; completing once and not returning points toward value or workflow mismatch. Ask what they did instead. In B2B, look for the shadow workflow—an old screen, spreadsheet, or email—and compare its step count, fit, and value. Also ask Customer Success which accounts received a rollout versus merely logged in.
Treat enterprise pilots as evidence, not demos. Jen Abel’s enterprise-sales playbook argues that the familiar five-stage view hides a process closer to 15 steps, and that buyers are highly sensitive to the sales motion. Adapt the sequence as follows:
- Make the intro call a 30-minute, one-to-one conversation with no demo or slides; let the buyer speak first, then ask what needs to change, why now, and how success would be measured.
- Before a group demo, work with the champion to choose attendees and build the storyline; avoid becoming an unprepared checkbox presentation.
- Run a two- or three-day pilot with three or four power users, three explicit tasks, and co-authored success criteria. Work backward from signature and involve procurement, security, and legal early.
Case Studies & Lessons
A 20-user beta exposed an activation problem, not a feature gap. A PM’s Claude Code-built language-learning app drew 20 immediate users from a relevant subreddit, but most left because they did not know what to do or find the product compelling. The next move was an immediate exercise to diagnose skill level and orient users. The lesson: after acquisition, make the first action both useful and diagnostic before expanding scope.
Career Corner
Make the job search operate like a targeted funnel. A current profile of Basia Kubicka reports five inbound PM offers a week—including from PlayStation, Comcast, and Dialpad—and growth from zero to 70K followers in 18 months. She treats LinkedIn as a landing page, uses Claude Code to compare five target job descriptions and requires at least 75% keyword overlap before rewriting her profile, maintains a story bank of real accomplishments and numbers, and adapts structures from posts that outperform a creator’s 30-day average by 10×. Apply the same PM discipline: choose five target roles, test focus before positioning yourself, maintain an evidence bank, and iterate from observed response rather than generic AI output.
Tools & Resources
Use Claude Code for evidence hygiene, not PM judgment. One PM points it at exported CS notes, call summaries, and backlog items to cluster repeated needs, flag duplicates, and identify items thin on evidence; the PM still makes the prioritization calls. It stuck because incorrect outputs could be corrected in five minutes or less. This is a useful boundary: automate reconciliation and synthesis, retain human ownership of framing and trade-offs.
Enterprise sales playbook (15 steps) — Enterprise sales leader Jen Ael (co-founder of Jellyfish, GM of enterprise sales at State Affairs) walks through the full enterprise sales cycle, using a ~$100K deal targeting SpaceX's legal function as the case . Most people treat selling as 5 steps; it's closer to 15 . The standard 5 stages (intro, demo, proposal, contracting, closed win/loss) are only CRM forecast-weighting buckets — not the sequence you take a buyer through — and ~90% of founders/salespeople run it wrong; enterprise sales means mirroring and controlling the buyer's process, not dropping buyers into yours . The playbook is ~80% process, ~20% relational art; the same process works for $100K and $1M deals, and enterprise buyers are more sensitive to the sales motion than to the demo .
First meeting. Target only the top executive (e.g., chief legal officer) or their N-minus-one; going deeper creates a game of telephone and surfaces user value instead of executive value — but a $100K deal needs an executive sponsor to allocate budget . Pitch in 2-3 sentences max, selling the "alpha" — what the executive unlocks by bringing in a net-new tool — not just problem-solving or an AI mandate; the litmus test is what they'd tell the board the product lets them do . Use the pincher model: founder reaches the C-level, an AE reaches the N-minus-one, and whichever responds brings in the other . Everyone targets the same names, so the message must feel different; without executive-level value, don't run top-down enterprise . Cold calling works with non-technical buyers; email, LinkedIn, and Twitter plus enrichment tools are the channels .
Intro call (most important step). Super informal: 30-minute one-on-one dialogue, no demo, no slides, always let them speak first, then frame the pitch live around what they shared — never a scripted pitch . Open with "What are you looking for going into 2027? Does anything need to change? Why now? How would you measure success?" to surface top-down priorities without anchoring to your product . Never record the call — buyers won't be vulnerable . Qualify hard: ~1 in 4 calls ends in "revisit in a year" on maturity grounds, and fast disqualification is the seller's job . Never run BANT scripts — the best enterprise sellers are untrained; they pull information and get people excited by vision . The whole game is slowing down to go fast — the full cycle should fit in ~90 days based on buyer maturity .
Demo discipline. Never go straight from intro to demo — the demo is the carrot. Run a 15-30 minute prep call with the champion (the person who wants the deal to happen, usually N-minus-one) to map the storyline, pick attendees, and let the champion put fingerprints on it so it feels like a group effort . Decline straight unprepared group demos and due-diligence "show 4-5 people your product" slots — you become a checkbox or lose the information edge . At the demo, show only the ~20% of the product delivering 80% of the value; demoing everything unravels the narrative and invites "we wouldn't use half the tool"; enterprise sales is tight project management and narrative ownership, and demos look different every time . Immediately after, debrief with the champion before they talk to anyone — there's always someone who can kill the deal, and a champion going quiet is the clearest danger signal .
Pilot. Before the pilot, work backwards from the signing date and engage procurement, security, and legal leads early . Prefer a 2-3 day pilot (users find value in half a day; 2-week pilots waste time) with 3-4 power users — never the executive — given three specific tasks and co-authored success metrics; the seller's job is taking ~99% of the work off the buyer's plate . If integration is required, run a 30-60 day pilot, charge for it, and credit the fee on signature — willingness to pay is the strongest signal, and expect the cycle to run a month longer . Forward-deployed engineers help only when they remove work for the buyer; if they're needed because the product is too hard to use, that's a bad sign, and FDE economics break on $100K deals .
Pricing. Hold pricing discussions until post-demo (or post-pilot) when everyone is excited; if pushed, give a ballpark and co-build the ROI case and defense slide with the champion . Never volunteer discounts or negotiate with yourself; preserve value with step-up year-two or two-year deals . Price should scale with the sales cycle: ~$100K if it closes in 90 days; $250-300K if it takes 9 months .
Papering, procurement, signature. Put agreed terms (price contingent on signing by a date plus a kicker for hitting it) in an email the champion forwards to procurement; always send a Word doc, never a PDF, since they will redline, and offer to use their paper . Procurement is a ~30-day process that isn't trying to kill the deal — but it's the only path to payment, so start no implementation before papers are signed . On redlines, accept easy items and get legal on a live call; expect the kitchen sink in their paper and pick battles — at this stage the deal rarely falls apart . Identify the actual signatory (sometimes the CFO, not the sponsor) before routing .
Benchmarks. Healthy enterprise win rate from qualified lead to signed contract: 25-35%; above that, price is too low . About half of qualified leads are lost by the demo stage; ~80% of deals at the pilot stage succeed post-pilot; ~25% of lost deals return within a year; and the market talks, so don't price inconsistently across customers .
Expansion. A real enterprise motion requires growing $100-250K deals to $350-500K the following year; for your first ~10 enterprise customers, involve the founder post-close to learn what's custom versus buildable . Services is the largest budget line item in enterprises and what they know how to buy — offer it as part of the motion .
PM relevance. The host frames the playbook as deeply product-like — understanding pain points, step-by-step project management, staying on top of details — making it a useful map for PMs partnering with sales and understanding how enterprise buyers decide .
- A senior PM at a large multinational describes his new team as chaotic — no capacity planning, functioning sprints, or effective ceremonies — with PMs doing all the Scrum Master work, and asks why the community has soured on the role; the top-voted reply (96 pts) reports universal product/engineering skepticism about a dedicated scrum master .
- Dominant critique: most SMs are ex-project managers who took a weekend Safe/Scrum certification, lack understanding of product or development work, and behave as if they work for upper management rather than the team ; they end up "glorified meeting schedulers" who run standups without challenging people on blockers or needs .
- Why the dedicated role is questioned: working iteratively doesn't require all agile ceremonies, team members can easily pick up SM duties, and the focus should be customer/business value, not a process framework ; with proper tooling and a well-set-up Jira board there isn't enough work for a full-time SM (better to hire a product owner who also does the role) ; tools like Jira/ADO already force "scrumfall" outcomes and do much of the SM's work .
- Where SMs do add value, it follows background and behavior, not title: engineering-minded SMs improve efficiency, spot blockers early, find technical process improvements, and grow skills; product-focused ones keep goals aligned, protect scope, and ensure shared understanding of requirements; admin/project-management backgrounds mostly run meetings . Strong scrum/delivery managers add real value — but often not through ceremonies ; effective ones do follow-ups, coach ticket hygiene, and leverage their network, making "a proper scrum master a proper luxury" . The rare great SM is typically a former dev/PO/designer with executive confidence; the next-best setup is a genuine coach floating between teams .
- Empirical counter-signal: one firm eliminated the SM role and cut sprint length from 3 weeks to 2 — nothing changed except delivery velocity increased with better quality; when Product, Dev, and QA trust each other, the team runs as a self-sustaining unit without an SM .
- Market and structural drivers: SMs and POs are effectively gone in Silicon Valley, surviving mostly in non-tech companies like banks ; the SM role usually reports into engineering, so engineering downsizing/offshoring hits non-producers first, and some orgs simply laid off SMs with the workload shifted to PMs/POs . One PM describes the "agile industrial complex" as collapsed — certifications and trainings down — with SMs now finding work mostly in government or banks while market-oriented industries move on to SAFe or back to traditional hierarchies .
- Ceremonies are falling out of style: a PM reports not hearing "scrum/kanban/waterfall" in a professional setting for 5+ years; post-AI-layoff engineers are more self-motivated and tooling has become eng-native (engineers manage Linear tickets in terminal), making a process layer negative EV. The same PM no longer writes PRDs, instead building prototypes to sell vision to leaders and engineers in technical scoping discussions .
- Practical implications: some firms replace SMs with "delivery managers" who run ceremonies but also get things shipped ; experienced PMs can cover the role — "I don't care much about what methodology a team uses. I do inspect & adapt, I align & focus the team" ; before adding an SM, frame it as solving a specific team problem — pick one approach and iterate rather than imposing "the way" .
- Estimation caveat: story points are seen as "pointless complexity" — a bucket of time measured in non-time units — with velocity predictably misused by leadership judging dev teams on it instead of business value delivered; and story points aren't actually part of Scrum .
User-owned AI infrastructure is an emerging category: personal devices people already own, with power and networking, can serve AI inference once software makes that capacity discoverable, trustworthy, economically useful, and easy to operate . Agents add the missing operational layer, turning personal compute into programmable infrastructure .
Darkbloom is a working implementation: Apple Silicon owners connect machines, developers send requests through an OpenAI-compatible API, and work is routed to providers . Trust relies on confidential compute, Secure Enclave-backed identity, hardware attestation, encrypted requests, and in-process MLX inference; the software is an unaudited public alpha . Running a six-Mac fleet (four 512GB M3 Ultras, one 256GB M3 Ultra, one 64GB M2 Max) surfaced operational lessons: a technically healthy machine can be economically useless — utilization, not health, is the market's feedback ; model choice drives demand (Gemma was the dependable paid workload, others attracted almost none) ; and hosts progress through states (installed, reachable, compatible, trusted, warm, eligible, routed, earning) with silent dropouts at any stage .
Operations matured into "boring" stability best left alone , supported by an income collector, append-only ledger, health monitoring, watchdogs, and recovery tooling . A Hermes Agent now operates the fleet, watching state, reasoning, using tools, and making changes — an autonomous control plane for personal compute . The likely architecture: workloads move across local, nearby, and hyperscale compute based on privacy, latency, and cost, with idle capacity joining outside networks overnight .
Lenny Rachitsky released an 84-minute podcast episode with Jen Abel walking through the full enterprise sales cycle . The core framework: the cycle has 15 stages, not the 5 most people assume, and skipping a step kills the deal .
The episode covers:
- The "pincer model" for landing the first meeting
- Crafting a winning 2-3 sentence cold outreach pitch
- Running an intro call that extracts maximum intelligence
- The correct 2-3 day pilot structure
- Tips for navigating pricing and procurement
Episode title: "How to Close $100k Enterprise Deals, Step by Step" .
The "research more" loop is fear of rejection, not an information need. Founders over-study regulations, pricing, and contracts instead of reaching out because outreach is scary and "a pdf can't reject you"; research feels productive but avoids the real challenge of acquiring users .
Force outreach before further research. Book five short client conversations before allowing another research session , or cap desk research at one day and talk to at least three potential users; book conversations first so they set the deadline, because research expands to fill available time .
Make outreach low-rejection by changing the ask and the metric. Instead of pitching with a yes/no outcome, ask "how do you handle this today?" — worst case you're ignored. Measure sends (e.g., ten messages per week), not replies, because sends are within your control .
Set an explicit stop rule for research. Five customer conversations, a written list of repeated objections, and one small offer to test is enough for a first pass; any further useful information must come from a real conversation, not another document . Reopen research documents only when a prospect asks something you can't answer, turning research into a response to demand instead of a substitute for it .
Nail non-negotiables first, defer everything else. Payment terms and who owns what gets built should be settled before outreach — skipping those shows up mid-negotiation. Pricing model and general regulatory posture can flex after real client conversations .
Lower the bar and send one bad message now. The first outreach is the only hard one ; five minutes on a call surfaces holes you'd never find in a week of reading . Fear doesn't fade first — cadence makes it smaller . Talking to a client is research too, just with the risk of "no" .
Claude Code, run as a product tool rather than a coding tool, was adopted for feedback consolidation: point it at exported CS notes, call summaries, and backlog items; it clusters them, flags duplicates against the existing backlog, and flags items thin on evidence. The PM still makes the calls; it stuck because prompts could be corrected in five minutes or less .
Custom Python CLI tools on top of Jira automate: (1) a daily report of 'blocked' tickets whose blocker is resolved — a safety net against 600+ daily notifications; (2) a weekly ticket-status report compiled into an email from a template (manual 30 min → 5 min); (3) dev-time data pulled into Excel for cost reports (90 min → 3 min). Selection rules: automate scheduled work that takes >30 min and is annoying/error-prone; prefer products with APIs or plugin extensibility and avoid closed-source no-API tools. ~80 such tools are run from a server and local machine .
A self-built meeting transcriber (a local Chrome extension with speaker identification) frees attention from note-taking; transcripts are fed to Gemini to list decisions. It was chosen over WhisperFlow and Gemini because of privacy uncertainty and to avoid installing software on a company laptop that IT might flag . A similar workflow transforms Granola meeting notes into summaries, stored in Confluence and distributed to Slack .
tiinkr.com is used to vibe-code only to the prototype stage, generating PRD, user stories, tech doc, testing scenarios, and prototype under one roof .
Pylon was adopted for customer support: it automatically ingests company knowledge, docs, and call transcripts; another commenter dismissed it as unlikely to survive, without specifics .
Lenny Rachitsky's podcast episode with @jjen_abel breaks down the enterprise sales cycle into 15 stages (not 5), covering the 'pincer model' for landing the first meeting, crafting a 2-3 sentence cold outreach pitch, running intro calls to extract maximum intelligence, a 2-3 day pilot structure, and tips for pricing and procurement . In a clip from the episode, Abel advises that "If your win rate is higher than 35% your price is too low" — i.e., losing the majority of deals can signal the price is set too low .
Two practical tactics for finding the real buyer surface from an r/startups thread on nailing an ICP (ideal customer profile ). A commenter describes their team's working process: find a problem that is highly relevant to a narrow group of people, quantify the problem, do the math to confirm that solving it is profitable enough to build for, then build and market directly to that narrow group . The post author's heuristic for separating talkers from buyers: the people most enthusiastic in conversations often aren't the ones who convert; the stronger signal is whether a prospect already has a janky workaround for the problem — a spreadsheet, manual process, or an intern — because that means they've already decided the problem is worth money .
- Revolut's Product Skills round for a technical Product Owner role centers on an open-ended ATM network design case — "Design a network of ATMs for customers to top up or withdraw cash"; Glassdoor tips say to treat it like a PRD and include operations (support, machine servicing) in scope .
- A commenter who sat the case received minimal input — "you are leading a project to launch 30K ATMs, how would you do it" — and every clarifying question (purpose, objectives, deficits vs. profits, metrics) was deflected with "what do you think"; after ~35 minutes they picked one subproblem, cash management, mapped a diagram spanning client/backend/user/external data, handled a festival-day scenario with proactive stacking and manual supply planning, then ML demand forecasting in later years; they were rejected .
- Rejection feedback: show clearer ownership by structuring the discussion and setting direction; define system components before execution details; drive the conversation proactively, prioritizing what's essential for a small initial rollout and explaining how the system scales; don't frame the problem as too large — narrow scope and focus on the highest-impact elements .
- The interviewer was an extremely early Revolut employee (< #10); ex-Revolut sources said interviewers were paid extra (busy "110% of the time") and had KPIs on whether their approved hires succeeded .
- The commenter found the case format unengaging (unlike the interactive problem-solving interview) but still recommends attempting it; the round was taken more than a year ago and likely unchanged .
- A PM used Claude Code to "vibe code" a language-learning app, released it to beta via a Reddit post, drew ~20 immediate users; most bailed, and feedback showed they landed without knowing what to do — the next step was an immediate call-to-action exercise that diagnoses skill level and orients users .
- On customer research: ask what customers currently do and where they hurt, not what they want; a "shit PM" simply does what customers ask. Avoid the "Steve Jobs" shortcut — most people aren't him and his decisions only look obvious in retrospect; one exec's "bold statements" have repeatedly been wrong .
- A PM ran customer interviews that showed users only needed more product guidance, escalated it to upper management, and nothing was addressed — framing "disregard for customer feedback" as a core frustration .
- The thread illustrates "product management theatre" (Cagan's phrase): PMs no longer talk to users, spend time on slide decks and fighting execs worried about optics, and features ship "cos the CEO asked"; stakeholder alignment becomes the job and an exec-led "Steve Jobs" mentality ignores user needs .
- Career-side contrast: after ~2 years building his own apps, one became a big success and others medium, rekindling passion vs. work where every feature is second-guessed; he now depends on AI for solo development/maintenance and worries about an AI-bubble financial collapse .
- A commenter attributes rising PM workplace politics to tech-driven layoff fear: leaders align on scope/dates, then change scope at the last minute for months, wasting money .
- To plan a launch video that connects with your ICP, run discovery interviews asking what users need to see to make a decision or change behavior; most product videos fail because they are instruction manuals that assume the customer already wants the product, while great videos focus on conversion first — emotional before technical .
- Low-production recordings of real usage can outperform polished videos: the author's YouTube videos of repetitive technical issues his beta users faced got the most views and eliminated repetitive support tickets ; another commenter advises recording yourself actually using the product and talking through the problem it solves, testing it with someone in the target market — "the video people actually share is the one where they go 'oh, I need that'" .
- For video structure, keep to "one job, one feature, one payoff": open with the pain in three seconds, show one result, then one sentence of how; two features is already a tour, so cut the multi-stage solution and show a before/after transformation rather than a walkthrough .
- Validate the ICP before building: an Ideal Customer Profile without research data is "The Founder's Imaginary Friend"; launch is not the time to start customer discovery .
- A launch alone doesn't create demand; develop the audience first by (1) figuring out who influences and buys your product, (2) determining where you can efficiently reach them — video is just a medium — and (3) doing that frequently, in varied, compelling ways without spamming .
Hiten Shah argues that in AI product development, the "empty box"—having no idea what users will ask an AI product to do—is the point, not a gap: every unexpected prompt is product research. Clicks show how people use the product you built, while prompts show the product they wish existed .
- In a B2B SaaS thread, a buyer found an external competitive intelligence agency useful for a one-off product launch — the agency interviewed actual customers of competitors, which the internal team never had time to do — but called the pricing structure nonsensical for ongoing use; their advice: one-off projects yes, monthly retainer only with a big budget .
- Someone who sells CI services acknowledged you can do it in-house but says most startups don't; a one-time project that leaves the team capable afterward is likely a positive investment, and startups should be obsessed with competitive differentiation .
- Secret-shopper CI can reveal competitor pitching and pricing, attend competitor events for early details, and run loss/churn interviews with customers who defected to competitors — the latter being the most helpful because internal teams can't get those insights; always follow local competition laws .
- A cybersecurity company used an agency in 2023 (per-competitor pricing, affordable then, at the 'CI boom' peak): it gathered feedback from competitors' current customers, secret-shopped the company's own customers, and the resulting base made future CI updates easier and informed sales talk tracks — but after leadership changes, the company no longer wants to pay for CI .
Results: Basia Kubicka gets 5 inbound PM offers/week from PlayStation, Comcast, Dialpad without applying; grew 0→70K followers in 18 months after nearly quitting at 12 likes/post and spammy feedback .
System: Treat LinkedIn profile as a landing page; hiring managers arrive via feed, comments, or Recruiter boolean search, all landing on tagline + profile . She engineered both with Claude Code: a skill that ingests 5 target job descriptions, mines keywords, and requires ≥75% overlap before rewriting headline/about/experience; low overlap halts and says targets are unfocused .
Content engine: Maintains a story bank of real accomplishments/numbers (Claude interviews her to build) so posts use actual experience . Before writing, she scrapes top-performing posts from other creators, filters those beating the creator's 30-day average by ≥10x, templates their structure, and swaps in her own expertise .
Why it works for PMs: Content creation is product management in disguise — ICP, pain points, user research, iteration; PMs already have the skills . Fastest-hired PMs made hiring managers come to them rather than sending 50 applications .
To diagnose low adoption when the buyer and daily user differ, use analytics to find behavioral patterns before talking to users: analytics shows where/when/for whom adoption breaks; conversations explain why — otherwise you're just picking a favorite hypothesis.
A practical split: whether users drop before their first completed run of the flow (points to discoverability/onboarding/friction) or after it (points to value or workflow mismatch); ask what they did instead to separate those. In ERP-like products, look for a shadow workflow (old screen, spreadsheet, email) and compare why it wins: fewer steps, better fit, or not enough value in the new flow.
Check with customer success which accounts actually got a rollout versus a login — that difference has explained more adoption curves than anything in the product.
In B2B, UX is critical but not defining (assuming a decent baseline UX); the answer often lies in value prop or incentives, so define a research agenda and interview well — fixing UX without understanding the core problem is busy work.
- A founder documents a product discovery case in email: search fails because users remember meaning, not exact keywords (e.g., searching "invoice project X" returns hundreds of results, and finding a past invoice requires guessing keywords and scanning threads) . Core UX problems identified: keyword search lacks semantic understanding, and threads hide context (collapsed messages, buried attachments) .
- The founder reframes from "build a better Gmail" to designing email from first principles around information and context: search that understands meaning, files as first-class objects, threads that preserve context, and no chronological inbox at the center .
- Validation feedback was "Email is solved," citing competition with Google/Microsoft and switching costs; the founder acknowledges these warning signs but argues "email works" is not "email is good" — people adapt to tolerated problems until they seem normal .
- A commenter challenges the idea as a long route to a vague proposition and questions the founder's fit to execute . They offer a validation ladder: a problem is not a business; a solution is not a business; a solution people will pay for is not necessarily a business; only a solution people will pay for and you can execute on is potentially a business . They demand specifics: user, purchase, differentiation from Gmail/Outlook, and trust .
Software teams' daily workflow pain points reported in a /r/startups thread: manually updating task status, repeatedly reporting progress, daily/weekly standups, keeping timesheets updated, chasing people for updates, and keeping info synced across tools . A veteran data PM (agile transformations, e.g., 25k-engineer mergers) says the core issue is lack of standardization: Jira's flexibility means teams either use it inconsistently or fall back to Excel, and getting an org to agree on one framework—plus change management—is the hardest part . Another PM's top time-waster is post-work status updates: standup, Slack recap, ticket move, weekly slide—if one tool updated the others automatically, they'd keep it . One team connected Jira to Claude Code via MCP, so the AI assistant updates ticket descriptions/comments automatically, removing the long-running PM–dev battle over ticket upkeep .
Scott Belsky (@scottbelsky) argues that in the consumer agentic era, products that invest in trust and inspectability while also delivering "magical" hospitality and personalization will win, drawing an analogy to Coinbase's success as effectively a security company in an era of ubiquitous crypto startups where risks favored the most secure player.
Sachin Rekhi argues the highest-leverage move for increasing a team's AI productivity is building a team-wide "Compounding OS" (a company brain), rather than chasing the latest AI models and releases . His guide covers three components: standardizing the team on an agentic platform, building a robust shared skill library across the org, and making all company context machine legible . The full video and essay are available via Substack link .