Ex-Yahoo CPO Albers Urges Kill Rates Over Speed as AI Code Surges

youtube

Because artificial intelligence makes software creation nearly frictionless, engineering velocity no longer delivers value, leaving upfront product judgment and strict kill rates as the decisive leadership skill.

AI-assisted summary of Agentic Teams and Product Leadership with Michael Albers — original source. Check the original for full context.

Source published: 2026-10-07

Key ideas

Michael Albers outlines a multi-tiered AI architecture where Claude Opus acts as an orchestrating 'chief of staff,' delegating lightweight file and administrative tasks to Haiku and intermediate reasoning to Sonnet. (0:00)
As software generation becomes frictionless, Albers argues that judgment has become the scarcest commodity, requiring product leaders to institute strict kill rates and explicit success metrics before writing code. (19:05)
During Project Dakar at Yahoo Mail, leadership halted all new feature development across scrum teams for several months to resolve cascading stability failures, technical debt, and data loss. (14:01)
Operating Albers Advisory as a 'team of one,' Albers uses an isolated three-node setup across a desktop, laptop, and an Ubuntu server on Hetzner coordinated via Model Context Protocol (MCP) and a Syncbox queue. (30:00)

Detailed notes

## Background Published on YouTube by the @Scale Podcast channel on October 7, 2026, this episode features AI-native product executive Michael Albers. The conversation explores lessons from Albers's two decades leading massive consumer platforms at Yahoo! and AOL, how AI is fundamentally transforming the economics of building software, and why exercising product judgment has become far more critical than shipping velocity.

## TL;DR Former Yahoo Chief Product Officer Michael Albers details his career journey from early technical support at Netscape and leading Yahoo Search off Google to navigating massive scale and hard sunset decisions at Yahoo Mail. He argues that in an era where software creation has become cheap and instantaneous, raw shipping speed is obsolete and product judgment—knowing what not to build—is the primary differentiator. Albers also outlines how he operates Albers Advisory as an independent 'team of one' powered by a multi-agent Claude system across an isolated three-node architecture. Finally, he shares practical strategies for token budgeting, organizational alignment, and preserving screen-free physical disconnection through mountain biking.

## Atmosphere & style Recorded casually on location at Pleasure Pizza in Santa Cruz, the conversation has the relaxed, reflective warmth of two longtime colleagues catching up over a slice of pizza. Michael speaks with pragmatic, veteran clarity, balancing lighthearted humor about rogue agents and legendary 1990s campus pranks with the hard-earned gravity of having halted entire product roadmaps and shut down iconic platforms like Yahoo Groups. It feels grounded, insightful, and refreshingly candid, contrasting high-altitude executive war stories against the gritty technical details of modern local agent orchestration.

## Bulletin - [00:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=0s) Michael Albers outlines a multi-tiered AI architecture where Claude Opus acts as an orchestrating 'chief of staff,' delegating lightweight file and administrative tasks to Haiku and intermediate reasoning to Sonnet. - [19:05](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1145s) As software generation becomes frictionless, Albers argues that judgment has become the scarcest commodity, requiring product leaders to institute strict kill rates and explicit success metrics before writing code. - [14:01](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=841s) During Project Dakar at Yahoo Mail, leadership halted all new feature development across scrum teams for several months to resolve cascading stability failures, technical debt, and data loss. - [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) Operating Albers Advisory as a 'team of one,' Albers uses an isolated three-node setup across a desktop, laptop, and an Ubuntu server on Hetzner coordinated via Model Context Protocol (MCP) and a Syncbox queue.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=0s) A Chief of Staff agent running Claude Opus dynamically orchestrates sub-agents, delegating routine tasks to Haiku and stepped-effort reasoning to Sonnet to manage compute costs. - [00:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=0s) Because weekly model token quotas reset early Saturday, Albers reserves Friday as an intensive 24-hour 'build day' to burn through the remaining ~30% of his budget. - [06:32](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=392s) Early search relevance benchmarks at Yahoo Search Technology (YST) mirrored modern LLM evals through rigorous side-by-side editorial testing against incumbent Google results. - [14:01](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=841s) Project Dakar established organizational alignment at Yahoo Mail by completely freezing feature velocity to eliminate debt, stabilize infrastructure, and resolve customer care backlogs. - [16:54](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1014s) Sunsetting legacy platforms with massive user bases like Yahoo Groups and AIM was not an admission of product failure, but a necessary pruning of maintenance overhead to free strategic capacity. - [19:05](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1145s) When code creation becomes cheap and rapid, shipping velocity ceases to be an advantage, making product judgment and deciding what not to build the core differentiators. - [20:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1200s) The discovery framework created with Felix von Kunhardt relies on setting upfront success definitions, evaluating quantitative performance metrics, and enforcing strict concept kill rates. - [23:49](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1429s) Unifying product and engineering leadership under a single GM or CPTO reporting line eliminates organizational friction and aligns teams against one shared priority stack. - [25:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1542s) Early-stage startups can defer specialized back-office hires like legal and finance by utilizing AI drafts, redirecting saved capital into compute and API token infrastructure. - [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) Operating autonomous agents safely requires a zero-trust architecture with local PII masking, scoped permissions, and a complete ban on data deletion rights. - [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) Cross-machine agent workloads can be orchestrated securely across desktop, laptop, and dedicated remote cloud servers using Model Context Protocol interfaces and queuing pipelines. - [35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) Individual productivity gains from AI agents are easily captured, but restructuring whole organizations around AI-native collaboration remains a difficult leadership challenge. - [37:29](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2249s) Physical disconnection during activities like mountain biking provides dedicated cognitive space for synthetic reasoning, creativity, and long-term product judgment.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=0s) Token Budgeting and the Multi-Agent System

Michael Albers describes how he manages his daily product workflow through an agentic system using Anthropic's Claude models. His primary interface is a "chief of staff" agent running Claude Opus as its default brain. When file operations or trivial administrative actions come up, the chief of staff automatically delegates the task down, explicitly informing him that it is spinning up a sub-agent on Haiku because it is significantly cheaper to operate. For intermediate reasoning tasks, the system steps up to Claude Sonnet, with effort parameters explicitly tuned across low, medium, and high settings.

The chief of staff agent maintains local persistence: all contacts, records, and context are stored locally as Markdown files within a strict folder hierarchy, synchronized seamlessly across three distinct machines. Delegating a task always begins with an explicit check on model selection to balance intelligence versus compute costs. Because token allocations reset every Saturday morning, Michael tracks his burn rate closely; by Friday, he typically finds around 30% of his token capacity unspent. Rather than letting the quota go to waste, he treats Friday as an intensive "build day" with a 24-hour window to burn through the remaining allowance on heavy development tasks.

```mermaid flowchart TD accTitle: Model Delegation Flow accDescr: Orchestration workflow showing how the Chief of Staff agent assigns tasks to sub-agents based on complexity and cost.

User["Michael (Prompt / Task)"] --> CoS

subgraph Orchestration ["Agent Architecture"] CoS["Chief of Staff Agent (Claude Opus Default)"] LocalData[("Local Markdown Hierarchy Synced across 3 instances")] CoS <--> LocalData end

- **Chief of Staff Brain:** Runs Claude Opus by default for core orchestration and complex decisions. - **Sub-Agent Delegation:** Delegates simple or file-level chores to Claude Haiku; routes moderately complex tasks to Claude Sonnet. - **Effort Tuning:** Fine-tunes Sonnet runs by configuring explicit reasoning effort tiers (low, medium, high). - **Knowledge Storage:** Context and directory files are stored locally in Markdown across a three-instance setup. - **Weekly Cadence:** Tokens reset early Saturday, turning Friday into a designated "build day" to consume the remaining ~30% token budget.

---

[01:11](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=71s) From Amsterdam to Silicon Valley

The podcast hosts introduce Michael Albers, recording on location at Pleasure Pizza in Santa Cruz, California, during an engineering meetup. Reflecting on their past working relationship, the host highlights Michael's path from high-scale platforms serving over a billion users to operating as an AI-native advisory firm. Michael recounts his upbringing in the Netherlands, where he was born and raised in Amsterdam until age 10 before relocating to the suburbs of Utrecht.

During his university years, Michael studied electrical engineering. At the time, dedicated computer science curricula were virtually non-existent or uncommon in Dutch universities. Drawn to hands-on work with physical hardware and circuit boards, electrical engineering served as his entry point into technology. In 1990, he made the move to Silicon Valley, landing in Santa Clara. His first role was at McAfee Associates, located on the Lawrence Expressway in a modest single-story building with only around 20 employees working under founder John McAfee to build early antivirus software. After subsequent stints at boutique database consulting agencies, he arrived at Netscape in 1995–1996.

- **Early Education:** Born in Amsterdam, moved to Utrecht; earned a degree in electrical engineering due to a lack of formal computer science programs. - **First US Role (1990):** McAfee Associates in Santa Clara, working directly with John McAfee in an office of roughly 20 staff members. - **Consulting to Netscape:** Built foundation experience in enterprise databases before landing at Netscape during the initial browser boom.

---

[03:45](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=225s) Netscape Server Infrastructure and Support Realities

While Netscape gained mass consumer fame for its web browser, Michael worked on the enterprise server division. His role centered on technical support for core backend infrastructure: Netscape Enterprise Server, proxy servers, LDAP directory servers, and secure SSL certificate servers—components that laid the plumbing for early commercial internet transactions.

Providing high-stakes technical support meant carrying a pager, living inside Unix terminals, configuring administrative dashboards, and handling emergency outages for major corporate clients like Wells Fargo, whose online banking operations relied on Netscape's certificate servers. When secure systems crashed or destabilized, Michael took direct calls from furious enterprise clients, an experience he describes as formative for understanding operational uptime, server reliability, and real-world edge cases.

The cultural atmosphere of Netscape in the mid-1990s was electric, bringing together figures who built the foundations of the web: > "Original founders of the Apache server, right? The people that wrote proxy protocols, right, from Switzerland, right? The people that really built the foundation of the Internet, all working in the same place."

This era was also defined by the spirited rivalry with Microsoft. Michael recalls the famous exchange when Netscape staff placed a massive Mozilla dragon statue on Microsoft’s campus lawn in Redmond, prompting Microsoft employees to return the favor by dropping an enormous blue Internet Explorer "e" logo onto the Netscape campus grounds.

- **Netscape Server Suite:** Technical support for Enterprise Server (web), LDAP, proxy systems, and SSL certificate engines. - **Mission-Critical Incidents:** Supported Wells Fargo's secure transaction backends through live outages and pager rotations. - **Browser Wars Lore:** High-profile pranks between Netscape and Microsoft involving the Mozilla dragon mascot and the giant Internet Explorer logo.

---

[06:32](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=392s) Inktomi and the Migration to Yahoo! Search (YST)

Following his tenure at Netscape, Michael moved to Inktomi, an OEM search and content delivery network (CDN) engine powering internet providers behind the scenes. When Yahoo decided to acquire Inktomi's search division, the strategic mandate was clear: Yahoo was currently relying on Google to power its web search results, and executive leadership wanted to bring the core technology in-house, achieve feature parity, and cut ties with the external search provider.

Michael stepped into the lead product manager role to oversee this migration, which coalesced into Yahoo Search Technology (YST). The effort required cross-functional coordination between core algorithmic engineering teams and Yahoo's editorial staff. It provided Michael with his first direct exposure to machine learning, algorithmic ranking, and training dataset curation.

Yahoo’s editorial team acted as the ultimate quality gatekeepers. They ran rigorous side-by-side evaluations comparing candidate search algorithms against incumbent Google results, refusing to approve rollout milestones until the internal engine matched or outperformed the benchmark. Michael highlights the clear parallel between those early search relevance evaluations and modern LLM evals: the tooling and scale have expanded dramatically, but the fundamental practice of curating high-quality datasets and testing against a baseline remains identical.

- **OEM Architecture:** Inktomi operated as an infrastructure engine powering third-party search engines and CDNs prior to the Yahoo acquisition. - **Yahoo Search Technology (YST):** The internal codename and technology initiative to transition Yahoo Search entirely off Google. - **ML & Modern Evals:** Curating relevance datasets and editorial side-by-side evaluations in the early 2000s directly mirrors current LLM benchmarking and eval pipelines. - **Editorial Gatekeepers:** Editorial teams served as human benchmarks, evaluating relevance output side-by-side before greenlighting the Google cutover.

---

[08:38](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=518s) Transitioning from Tech Support to Product Management

Michael reflects on the non-traditional paths that lead people into product management, emphasizing that during this era, there were no direct college degree tracks or formalized playbooks for the role. His trajectory transitioned from low-level systems support to search engineering collaboration, and ultimately into product leadership.

Working directly with relevance researchers and software engineers on YST, Michael realized that product management was about establishing clear definitions of quality: setting the success criteria, outlining what "good" looked like, and driving the organizational machinery to deliver against that standard. The podcast host confirms a similar experience, sharing that he originally entered the technology industry through research coding and speech recognition before finding his way into product roles.

- **Non-Linear Career Path:** Michael points out that product management rarely had a linear feeder program, with most professionals migrating from engineering, design, or technical operations. - **Defining "Good":** Moving from support to PM allowed Michael to transition from resolving downstream system failures to defining upfront specifications and acceptance criteria. - **Early Search PM Experience:** Managing delivery pipelines, algorithm quality standards, and relevance benchmarks established his long-term operating framework as an executive.

[10:17](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=617s) Startup Tour: LiveOps, Xobni, and CardSpring

Reflecting on the early days of engineering and product work, the host and Michael Albers recall how building production systems back then was rarely something taught in school; teams simply had to learn on the job and specialize over time. Following his initial run at Yahoo, Albers embarked on his "second startup era." He first joined LiveOps to work on an initiative called LiveWork—a platform analogous to Amazon Mechanical Turk designed to orchestrate a distributed, work-from-home labor pool for tasks like copyright review, image analysis, and content editing.

From LiveWork, Albers moved to Xobni ("Inbox" spelled backwards), where he and the host worked together. At Xobni, the core mission was constructing a rich "people graph" directly on top of the user's email inbox—mining the untapped goldmine of contacts, documents, files, purchase histories, and communication records. Albers then transitioned to CardSpring, building infrastructure for card-linked offers and coupons tied directly to payment networks, enabling a customer who swiped a credit card at a local pizza shop to immediately trigger relevant rewards.

The host reminisces about meeting Albers sixteen years prior, right as Xobni was navigating a chaotic, high-stakes architectural pivot in San Francisco: transitioning away from client-side Outlook DLLs toward server-side web infrastructure capable of powering mobile apps and a Gmail integration. Albers managed that transition and ran the weekly sprints that helped stabilize the backend engineering efforts before his next career leap.

- **LiveOps / LiveWork**: Crowdsourced workforce platform for distributed microtasks, image analysis, and copyright review. - **Xobni**: Inbox-derived people and relationship graph, transitioning from desktop DLL plugins to scalable server-side systems. - **CardSpring**: Card-linked advertising and coupon infrastructure layered directly on consumer credit card transactions.

---

[12:55](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=775s) Returning to Yahoo Mail at Massive Scale

Albers's startup tour concluded when Jeff Bonforte, then CEO of Xobni, reached out with an offer for him to return to Yahoo as Head of Product for Yahoo Mail. At Yahoo, returning alumni are affectionately dubbed "boomerangs." Returning to the mothership represented an astronomical jump in operating scale compared to the startup world: Yahoo Mail served 225 million active users, representing an order-of-magnitude increase in operational footprint.

Albers stepped into the role during a turbulent phase defined by severe stability challenges, frequent outages, and mounting technical debt. Despite the immediate firefighting, the transition offered a major opportunity to reimagine the communications experience. Albers's product strategy aimed to modernize email while integrating the relationship intelligence and address book technology originally developed at Xobni into Yahoo's core email stack.

```mermaid flowchart TD accTitle: Transition from Startups Back to Yahoo Mail accDescr: Sequence diagram showing Michael Albers moving through LiveOps, Xobni, CardSpring, and boomeranging to Yahoo Mail. subgraph Startups["Startup Journey"] A["LiveOps / LiveWork Crowdsourcing Platform"] --> B["Xobni Inbox People Graph"] B --> C["CardSpring Card-Linked Offers"] end subgraph Yahoo["Yahoo Boomerang Return"] C --> D["Recruited by Jeff Bonforte"] D --> E["Yahoo Mail Head of Product 225M Active Users"] end ```

---

[14:01](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=841s) Project Dakar: Halting the Roadmap for a Reliability Reset

Shortly after Albers's return, Yahoo Mail suffered a catastrophic infrastructure failure. A cluster of critical servers went down for an extended period, rendering entire user inboxes completely inaccessible and leaving some users with data loss that was not detected promptly. The failure laid bare years of neglected stability, deferred maintenance, and inadequate capacity planning. Under General Manager Jeff Bonforte and Albers as Head of Product, leadership made the drastic call to halt all new product development entirely and launch "Project Dakar," named after the grueling off-road endurance rally.

```mermaid flowchart TD accTitle: Project Dakar Operational Structure accDescr: Diagram illustrating how product and engineering halted new features to focus on cross-functional reliability streams. A["Yahoo Mail Critical Outage Inboxes Down & Data Loss"] --> B["Project Dakar Launched Feature Work Halted"] B --> C["Reliability & Core Stability"] B --> D["Customer Care Remediation"] B --> E["Growth & Front-End Performance"] B --> F["Legacy System Migration Completion"] C & D & E & F --> G["Weekly Evening Readouts Named Teams & Clear Accountability"] G --> H["Stable Foundation for Future Growth"] ```

Project Dakar represented complete, ruthless alignment between product and engineering priorities. For several months, every single scrum team stopped building feature requests and focused exclusively on foundational operational health: - Resolving acute customer care backlogs and data retrieval issues. - Completing half-finished migrations from brittle legacy infrastructure to modern server architectures. - Eliminating systemic performance bottlenecks across front-end and back-end systems.

To sustain morale through the grueling reset, leadership created a sense of shared rallying crisis. Work streams were organized into named units with distinct visual identities and custom logos—such as the "Ninja team." The entire organization gathered after hours every single week for intense status readouts tracking progress across each stream. While pausing forward feature velocity felt counterintuitive and heavy in the thick of it, finishing those stalled migrations and securing reliability established the operational baseline that allowed Yahoo Mail to stabilize, retain its user base, and scale cleanly in subsequent years.

---

[16:54](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1014s) Making the Hardest Calls: Sunsetting Iconic Products

As Albers rose to General Manager of Mail and Communication Products and eventually Chief Product Officer (CPO) of Yahoo, his purview expanded over a vast consumer portfolio. With broad oversight came what he describes as the most difficult decisions of his entire career: formally sunsetting and end-of-lifing beloved legacy products that still maintained active user bases. Over his tenure, Albers oversaw the retirement of foundational internet utilities, including AOL Instant Messenger (AIM), Yahoo Messenger, Yahoo Answers (having earlier helped develop "Answerpedia," an internal mashup of Q&A and Wikipedia), and Yahoo Groups.

The most difficult shutdown of all was Yahoo Groups, which hosted over 115 million registered users and 10 million distinct online communities. Albers emphasizes that shutting down these platforms was not an admission that the products had outright failed; rather, it was a cold calculation of operational reality. The ongoing infrastructure, moderation, security, and engineering maintenance costs required to keep legacy services alive directly starved strategic initiatives of attention. For a modern product organization, "saying no" and eliminating cognitive and operational overhead is the prerequisite for organizational focus. Albers explains:

> "It wasn't necessarily that these products failed. The trade-off of continuing to operate them—the cost of running these products—was the challenge versus what was mostly important, which is focus... So from the outside, it seems like it's one call. It's many different things that ultimately allow you to realize that this is the right thing to do: to stop something so you can continue on to something else and focus."

- **AOL Instant Messenger (AIM) & Yahoo Messenger**: Phased out to consolidate communication investments. - **Yahoo Answers**: Sunken moderation and maintenance costs led to its end of life despite massive historical footprints. - **Yahoo Groups**: Terminated despite 115 million users and 10 million communities to free up constrained engineering resources.

---

[19:05](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1145s) Judgment Over Shipping Speed in the Age of Cheap Software

The host draws a direct line between Albers's historical lessons on pruning products and the immediate realities facing tech teams today. In modern engineering organizations—accelerated by AI coding assistants and automation—writing software is faster and cheaper than ever before, producing an unprecedented influx of generated code and rapid deployments. However, shipping velocity alone does not translate to user value or enduring product health.

Albers notes that the explosion of cheap implementation only amplifies the necessity of product discernment. When execution ceases to be the primary bottleneck, deciding what *not* to build becomes the supreme differentiator. As Albers points out, referencing his recent writing on the shift: "building got cheap, judgment became scarce." Navigating an environment saturated with automated feature output demands disciplined product leadership that prioritizes long-term utility, architectural stability, and strategic focus over raw shipping volume.

[20:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1200s) Judgment, Kill Rates, and the Three W's of Product

When building software becomes cheap and blindingly fast, raw shipping velocity stops being an advantage; judgment becomes the scarce commodity. Michael explains that deciding to shutter an iconic service like Yahoo Groups requires heavy executive judgment, but that same muscle must be exercised before writing a single line of code. If a product manager can spin up 100 prototypes in a single week, the most critical question is what *not* to build. To combat aimless production, Michael and his friend Felix von Kunhardt developed a structured discovery framework that forces teams to define their evaluation criteria up front rather than relying on gut feelings later.

This discovery framework hinges on three clear pillars: outlining concrete success metrics, setting a strict "kill rate" (for instance, mandating that out of ten explored ideas, only the top two survive), and establishing an evaluation set covering criteria like real usage demand and technical load times. Michael notes that institutional judgment rarely gets recorded in company documentation—it lives entirely inside people's heads, leaving organizations without a collective memory. By establishing an upfront discovery guide, senior leaders create an invaluable training ground for up-and-coming PMs. Junior product managers build intuition and taste by rapidly iterating through throwaway prototypes, realizing firsthand why certain solutions fail, studying external lessons from internet resources and podcasts, and constantly answering the fundamental "Three W's" of product development.

- **The Discovery Framework (with Felix von Kunhardt):** - **Define Success:** Articulate what constitutes a great product before writing code or building prototypes. - **Enforce a Kill Rate:** Determine upfront how many concepts must be eliminated (e.g., selecting only 2 survivors out of 10 concepts). - **Establish Eval Criteria:** Set measurable standards such as expected user engagement, system performance, and load time. - **The Three W's of Product:** - *Who* is your customer? - *What* problem are you solving? - *Why* is your solution the right approach, or why are you the right team to deliver it?

---

[23:49](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1429s) Moving to GM: Unifying Product and Engineering Priorities

Michael's trajectory at Yahoo eventually expanded from leading communications and mail products into a General Manager role. The transition dramatically shifted his scope: he became responsible for a $3.5 billion P&L and an organization of 750 people encompassing product management, engineering, DevOps, and design under a single reporting line. In typical tech organizations, product and engineering operate with separate leaders and divergent roadmaps, triggering endless friction and negotiation over resource allocation. By unifying both functions under one GM, Michael aligned all 750 people against a single unified priority stack, echoing the operational discipline established during Project Dakar.

Michael sees the broader tech industry shifting back toward this unified model, pointing to the rise of CPTO (Chief Product and Technology Officer) roles and founders actively hunting for engineering leaders who possess sharp product sensibilities. When product and engineering leadership collapse into a single accountable seat, product strategy, technical feasibility, and business outcomes row in the same direction from day one.

```mermaid flowchart TD accTitle: Transition to Unified Leadership accDescr: Diagram showing the contrast between traditional split leadership and the unified CPTO or GM model.

subgraph Traditional["Traditional Split Model"] direction TB PM_Lead["Head of Product"] -->|"Negotiates / Tension"| Eng_Lead["Head of Engineering"] PM_Lead --> PM_Goals["Product Priorities"] Eng_Lead --> Eng_Goals["Technical Priorities"] end

subgraph Unified["Unified GM / CPTO Model"] direction TB Leader["General Manager / CPTO\n(Michael Albers: $3.5B P&L, 750 People)"] Leader --> SingleStack["One Shared Priority Stack"] SingleStack --> Org["Product, DevOps, Engineering, Design"] end ```

---

[25:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1542s) Structuring Early-Stage Startup Teams in the AI Era

When advising founders on team topology, Michael argues against rigid functional silos in favor of fluid collaboration. Thanks to generative AI tooling, early-stage startups can radically defer expensive corporate hires. He points to founders who deliberately hold off on hiring a CFO or a Head of Legal because modern AI models deliver "good enough" drafts and legal assessments, allowing founders to reallocate that payroll capital toward compute infrastructure and API token budgets.

Within the core product team, the traditional linear relay race—where a product manager writes a spec, tosses it to a designer, who throws it to engineering—is completely obsolete. Instead, designers should establish early design systems and style guides so that AI-generated prototypes built by product managers immediately inherit the product's visual language. Simultaneously, engineering must outline infrastructure realities and database constraints upfront. This prevents PMs from falling in love with prototypes that look impressive in isolation but cannot run on the company's production systems. For early startups, having a technical Head of Product oversee engineering avoids wasteful political disputes over priorities and keeps everyone pointed toward identical objectives.

---

[28:04](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1684s) Albers Advisory and the "Team of One" Agent Architecture

In 2021, Michael stepped away from managing hundreds of employees at Yahoo to launch Albers Advisory. Specializing in interim and fractional product leadership, he embeds into companies undergoing executive turnover, organizational restructuring, or urgent product launches. Rather than building a traditional consultancy with junior associates, Michael operates as an independent "team of one powered by a bunch of agents," bringing executive horsepower directly to portfolio companies.

When transitioning from leading large human organizations to building an agent-driven solo practice, Michael sought to recreate the high-leverage support he relied on at Yahoo: a world-class Chief of Staff. He initially experimented with AI tools like Lovable and Bolt before diving deeply into Anthropic's Claude and open-source agent frameworks (such as OpenClaw). He humorously recalls wanting to name his AI Chief of Staff "Anandita" after his former human chief of staff who had kept his executive operations running smoothly, before deciding that would be "a little creepy." The system ended up generating its own name as he began solving the early friction points of permissions, security, and context orchestration.

[30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) Security, Isolation, and the "Team in a Box" Architecture

Michael recounts how early experiments with autonomous agents made him deeply uncomfortable with their security posture. Aside from issues of trust and safety, he had instances where agents went rogue overnight, racking up unexpected bills before he could stop them. Realizing the off-the-shelf setups were not ready, he transitioned to Claude Code and designed an isolated three-node environment:

1. **Local Desktop:** His primary machine, and the only node granted access tokens for his personal email address. 2. **Laptop:** Used on demand while mobile. 3. **Always-On Remote Server:** An Ubuntu instance hosted in Finland via German cloud provider Hetzner. It runs background research tasks, powers a Telegram bot, hosts his build scripts, and manages his custom to-do bot.

```mermaid flowchart TD accTitle: Distributed AI Agent Architecture accDescr: Three computing nodes connected via an MCP interface and Syncbox task queue to external tools.

subgraph Nodes["Compute Nodes"] D["Desktop\n(Personal Email Access)"] L["Laptop\n(On Demand)"] H["Hetzner Ubuntu Server\n(Finland · Always-On)"] end

subgraph Coordination["Inter-Agent Layer"] MCP["Model Context Protocol (MCP) Interface"] SB["Syncbox\n(Task Exchange Queue)"] end

subgraph Execution["Local Data & External Services"] MD["Markdown Files\n(Hierarchical Context)"] GD["Google Drive / Telegram / Surveys"] end

D <--> MCP L <--> MCP H <--> MCP

D <--> SB L <--> SB H <--> SB

MCP --> MD H --> GD ```

To coordinate these nodes without compromising security, Michael built a custom Model Context Protocol (MCP) interface and a shared queuing mechanism he calls **Syncbox**. The different Claude instances drop tasks into each other's queues to run workloads based on their varying privilege levels.

His core philosophy was zero-trust from the outset: "I do not trust you. You have to earn your right to trust." Privileges were expanded incrementally under a strict internal trust and safety policy: - **Data sanitization:** Strict PII filtering and token masking are applied locally so raw sensitive data is never transmitted to LLM providers. - **Restricted permissions:** Inboxes allow draft creation, archiving, and reading, but *no deletion rights* exist anywhere in the pipeline ("No deletion. And so I manage permissions through scope depending on the task"). - **Agent delegation:** What Michael dubs his "team in a box" enables him as a solo operator to execute fractional CPO responsibilities alongside personal side projects. The server can ingest a software spec, conduct competitor research, analyze trends, manage Google Drive surveys, and email participants. He can orchestrate entire client engagements directly from his phone while autonomous tasks hum in the background.

---

[33:23](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2003s) Token Budgeting and the Friday Build Hack

Managing token consumption is essential when operating as a solo enterprise. Michael subscribes to Anthropic's Claude Pro/Max tier ($100 per month), but in the beginning, he burned through his entire quota by Tuesday, leaving him locked out unless he purchased more credits. To solve this, he instituted a dynamic routing framework managed by an AI "Chief of Staff":

- **Opus:** Serves as the high-context "Chief of Staff" coordinating the workday. It possesses Michael's hierarchical Markdown notes, context files, and local knowledge bases. - **Sonnet:** Brought in for intermediate cognitive tasks, modulated with explicit low, medium, or high effort parameters. - **Haiku:** Delegated simpler workloads like file manipulation, routine parsing, and formatting. The Chief of Staff explicitly flags: *"I'm about to assign a subagent. I suggest we use Haiku."*

This tiered orchestration changed his burn rate. Instead of exhausting his limit midweek, he typically reaches Friday with roughly 30% of his tokens intact. Because Anthropic's quotas reset on Saturday morning, he turned Friday into a dedicated "build day": > "My tokens reset Saturday morning and so I have 24 hours to blow 30% of my tokens and I go build... Why not, right? I mean, I'm not gonna waste my tokens."

Friday functions as a personal hackathon where remaining tokens are channeled into rapid prototyping, building apps, or engineering automations and infrastructure.

---

[35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) Leadership, Adaptability, and Team Dynamics

Having navigated successive technology waves—the dawn of the consumer web, search engines, web media, and the transition to mobile—Michael views the rise of AI as "an inflection point like no other."

He addresses the widespread FOMO experienced by product managers who juggle daily operational demands while watching rapid technological shifts from the sidelines. Michael emphasizes curiosity over fear. Adopting AI is not about working oneself out of a job, but about gaining "superpowers" to execute at a higher caliber.

However, he highlights a stark divergence between individual productivity and organizational throughput: - **Individual vs. Team leverage:** Mastering personal agent workflows is straightforward compared to reshaping how an entire organization collaborates around AI systems. - **The judgment imperative:** Because generating prototypes is nearly frictionless, teams can build anything imaginable on a whim. The product leader's primary responsibility shifts from driving shipping velocity to asserting rigorous product judgment: knowing what *not* to build and deciding what truly deserves to ship.

---

[37:17](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2237s) Lightning Round: AI Tools and Physical Disconnection

The conversation moves to a rapid-fire tool review and personal habits:

- **Favorite recent AI tool:** Beyond Claude, Michael highlights **Manus**. Originally incubated inside Meta before being spun back out, the tool impressed him with structured execution flows, seamless third-party SDK integrations, and image generation capabilities (leveraging GPT-based pipelines) without exhausting back-and-forth prompts. - **Everyday physical-world use cases:** When the derailleur snapped on his ten-year-old bicycle, Michael snapped a photo with **Google Gemini**. The multimodal engine accurately identified the obsolete derailleur model, found the appropriate replacement part to order, and provided guidance on mechanical adjustments during installation. - **Disconnecting during exercise:** Michael intentionally avoids audio assistants or AI interruptions while out mountain biking: > "That is alone time for me, where I get to think about everything. I'd say that's where I build my judgment. It's where my creativity kicks in. And so I don't need AI there necessarily because it's me and my brain."

---

[38:29](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2309s) Mountain Biking, Strava AI, and Event Outro

Michael regularly rides in Truckee, California, alternating between an analog mountain bike and an e-mountain bike: - **Analog rides:** Provide rigorous physical climbs at high elevation. - **E-bikes:** Allow him to tackle longer distances and steeper terrain for exploration. He dismisses mountain biking purists who reject e-bikes, noting that they miss out on exploring backcountry trails that are inaccessible on purely human power.

After rides, however, he embraces analytics. He relies heavily on **Strava's** integrated machine-learning features to evaluate his performance. Once back at the house, he reviews metrics like heart-rate zones, elevation gain, and power output, praising Strava's contextual ride summaries (e.g., highlighting his longest rides or aerobic zone distributions).

The host closes by thanking Michael and inviting listeners to register for the upcoming **Product @Scale** conference in Menlo Park on October 28, featuring speakers from Meta, Nvidia, Microsoft, Intel, and Pindrop.

## Notable quotes > [03:45](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=225s) Original founders of the Apache server, right? The people that wrote proxy protocols, right, from Switzerland, right? The people that really built the foundation of the Internet, all working in the same place. — Michael Albers

> [16:54](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1014s) It wasn't necessarily that these products failed. The trade-off of continuing to operate them—the cost of running these products—was the challenge versus what was mostly important, which is focus... So from the outside, it seems like it's one call. It's many different things that ultimately allow you to realize that this is the right thing to do: to stop something so you can continue on to something else and focus. — Michael Albers

> [19:05](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1145s) building got cheap, judgment became scarce — Michael Albers

> [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) I do not trust you. You have to earn your right to trust. — Michael Albers

> [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) No deletion. And so I manage permissions through scope depending on the task — Michael Albers

> [33:23](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2003s) I'm about to assign a subagent. I suggest we use Haiku. — Chief of Staff Agent

> [33:23](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2003s) My tokens reset Saturday morning and so I have 24 hours to blow 30% of my tokens and I go build... Why not, right? I mean, I'm not gonna waste my tokens. — Michael Albers

> [35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) an inflection point like no other — Michael Albers

> [37:17](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2237s) That is alone time for me, where I get to think about everything. I'd say that's where I build my judgment. It's where my creativity kicks in. And so I don't need AI there necessarily because it's me and my brain. — Michael Albers

## Mentioned Michael Albers, John McAfee, Jeff Bonforte, Felix von Kunhardt, Yahoo!, Yahoo Search Technology (YST), Yahoo Mail, Yahoo Messenger, Yahoo Answers, Yahoo Groups, AOL, AOL Instant Messenger (AIM), Netscape, Netscape Enterprise Server, Inktomi, Google, Google Gemini, McAfee Associates, Wells Fargo, Microsoft, LiveOps, LiveWork, Xobni, CardSpring, Albers Advisory, Anthropic, Claude Opus, Claude Sonnet, Claude Haiku, Claude Code, Lovable, Bolt, OpenClaw, Hetzner, Telegram, Manus, Strava, Meta, Nvidia, Intel, Pindrop, Syncbox, Model Context Protocol (MCP)

## Video description What happens when building gets cheap?

In this episode of the @Scale Podcast, AI-native product executive Michael Albers shares lessons from more than two decades building consumer products at scale and explores why judgment may be one of the most valuable skills in the age of AI.

Michael spent much of his career at Yahoo! and AOL, ultimately serving as Yahoo!’s SVP and Chief Product Officer over a $7.5B+ portfolio serving more than a billion users. Earlier in his career, he was the primary product lead in moving Yahoo! Search off Google and onto its own search engine, and later served as VP of Product at Xobni.

Today, Michael runs Albers Advisory, where he takes on fractional and interim product leadership roles. Since 2024, he has also been building his own AI systems hands-on, developing an AI-native approach to product work.

In this conversation, Michael explores: • Why “building got cheap, judgment became scarce” • How AI is changing the economics of building products • Why deciding what NOT to build may become more important • Lessons from leading products at Yahoo! and AOL • Moving Yahoo! Search off Google and onto its own search engine • Making difficult product and portfolio decisions • The importance of defining success before building • How to evaluate ideas and determine what deserves to survive • Building an AI-native “team of one” • Using AI agents and custom systems to augment product leadership • What product leaders need to prioritize as AI accelerates the pace of building

Michael Albers is based in Menlo Park and runs Albers Advisory, where he works with companies in fractional and interim product leadership roles.

🎙️ Subscribe to the @Scale Podcast for more conversations with the engineers, product leaders, and technology experts shaping what comes next.

Learn more about Albers Advisory here: https://www.albersadvisory.biz/?utm_id=h8p91

Want to join conversations like this in person? Register for @Scale: Product 2026 happening on October 28 in Menlo Park - https://atscaleconference.com/events/product-2026/

00:00 Token Smart Model Picks 01:11 Intro 01:51 Reconnecting And Background 02:38 Amsterdam To Silicon Valley 03:45 Netscape Support Lessons 06:32 Inktomi To Yahoo Search 08:38 Tech Support To Product 10:17 Startup Tour Xobni Cardspring 12:55 Back To Yahoo Mail Scale 14:01 Project Dakar Reliability Reset 16:54 Hard Calls Killing Products 19:05 Judgment Over Shipping Speed 21:54 How PMs Build Judgment 22:45 Learning From Others 23:25 Three Ws Of Product 23:49 Becoming A GM 24:41 Unifying Product And Engineering 25:42 Structuring Startup Teams 28:04 Leaving Yahoo For Advisory 28:55 Building A Team Of Agents 29:55 Security And Permissions 33:23 Token Budgeting Hacks 35:42 Leadership Through AI Shifts 37:17 Lightning Round AI Tools 38:29 Biking And AI Balance 40:08 Ride Analytics With Strava 41:02 Closing And Event Invite

[Source](https://www.youtube.com/watch?v=Kvo-dCXNDXw)

中文简报

前雅虎CPO Albers：AI代码激增下，项目淘汰率重于开发速度由于人工智能让软件开发几乎毫无阻力，工程交付速度已不再创造核心价值，前期的产品判断力与严格的项目淘汰率已成为决定性的领导能力。前雅虎首席产品官Michael Albers回顾了自己的职业生涯，从早期在Netscape提供技术支持、带领Yahoo Search摆脱对Google的依赖，到应对Yahoo Mail的庞大规模与艰难的项目关停决策。他指出，在软件构建变得廉价且即时的时代，单纯的交付速度已经过时，产品判断力——即明确什么不该做——才是核心壁垒。Albers还介绍了自己如何借助跨隔离三节点架构的多智能体Claude系统，将Albers Advisory作为独立的“一人团队”运转。最后，他还分享了关于Token预算管理、组织协同以及通过山地骑行远离屏幕实现物理断联的实用策略。 Michael Albers介绍了一种多层AI架构：Claude Opus充当统筹协调的“参谋长”，将轻量级文件和管理任务分配给Haiku，将中等复杂度的推理交由Sonnet处理。 (0:00) 随着软件生成变得毫无门槛，Albers认为判断力已成为最稀缺的资源，这要求产品领导者在编写代码前必须设定严格的项目淘汰率和明确的成功指标。 (19:05) 在Yahoo Mail推进Dakar项目期间，领导层暂停了各Scrum团队数月的所有新功能开发，以彻底解决连锁稳定性故障、技术债务和数据丢失问题。 (14:01) 在以“一人团队”运营Albers Advisory时，Albers使用了一套由台式机、笔记本电脑和部署在Hetzner上的Ubuntu服务器组成的隔离三节点架构，并通过模型上下文协议（MCP）和Syncbox队列进行协同。 (30:00)

Reading summary

Former Yahoo Chief Product Officer Michael Albers argues that because software generation has become cheap and fast through AI, executive discernment and knowing what not to build have replaced shipping velocity as the primary bottleneck in product leadership. Product Discernment and Upfront Kill Rates (20:00) Albers contends that when engineers and product managers can produce dozens of prototypes in days, unguided execution leads to organizational bloat. To address this, he and collaborator Felix von Kunhardt implemented a structured discovery framework requiring teams to establish explicit evaluation metrics, assess core questions regarding user needs and technical viability, and enforce an upfront 'kill rate'—such as discarding eight out of ten concepts before writing production code. In Albers's view, institutional judgment rarely survives in corporate documentation, making structured prototyping filters necessary for training younger product managers to recognize failure patterns early. Operational Trade-offs and the Cost of Focus (14:01) Drawing on his operating background at Netscape, Inktomi, and Yahoo, Albers emphasizes that organizational focus often demands halting product roadmaps or terminating active systems. After returning to Yahoo Mail to oversee 225 million users, he halted all feature delivery under 'Project Dakar' to dedicate every engineering team to infrastructure stability, data recovery, and legacy migration following catastrophic outages. Later, as Yahoo General Manager and CPO, he directed the shutdown of high-volume services including AOL Instant Messenger, Yahoo Messenger, Yahoo Answers, and Yahoo Groups—which had 115 million users and 10 million communities. He notes these decisions were not admissions of product failure, but calculations to eliminate maintenance and moderation overhead that starved core strategic efforts. Unifying Product and Engineering Governance (23:49) Albers argues that traditional enterprise friction stems from bifurcated reporting lines between product management and engineering leadership. Managing a $3.5 billion P&L and 750 personnel across product, DevOps, engineering, and design under a single general management seat allowed Yahoo to align around a single priority stack. He observes this model re-emerging in early-stage startups and CPTO structures, where functional silos are abandoned. Under this setup, designers establish upfront design systems and engineers define backend database constraints before product managers generate AI-assisted prototypes, preventing teams from pursuing unviable software architectures. Solo Advisory via Multi-Agent Systems (30:00) Operating his solo consultancy, Albers Advisory, Albers relies on an isolated three-node multi-agent architecture across a primary desktop, a laptop, and an always-on Hetzner Ubuntu server in Finland. Inter-agent coordination runs through a Model Context Protocol interface and a shared queuing mechanism dubbed 'Syncbox,' accompanied by zero-trust security restrictions such as local PII masking and zero email deletion privileges. To manage Anthropic's subscription quotas, his system employs a dynamic routing strategy: Claude Opus acts as the high-context orchestrator, Claude Sonnet tackles intermediate reasoning tasks, and Claude Haiku handles basic file operations. By pacing consumption, he reserves roughly 30% of his weekly token allowance for an intensive Friday build cycle before allocations reset. While Albers demonstrates that individual operators can gain significant leverage by orchestrating specialized AI agent topologies, he cautions that scaling these productivity gains across entire organizations remains an unsolved challenge, requiring executive restraint rather than sheer shipping speed.

Detailed notes — zh

## Background 本期节目由播客《@Scale Podcast》于 2026 年 10 月 7 日发布在 YouTube 平台。视频围绕前雅虎首席产品官（CPO）Michael Albers 展开，探讨了在 AI 让软件构建成本变得极其廉价的时代，产品领导力与决策判断力为何变得愈发关键，并分享了其管理海量规模产品以及如今搭建 AI-native“一人团队”的实战经验。 ## TL;DR 前雅虎 CPO Michael Albers 回顾了自己从网景技术支持、雅虎搜索自研重构（YST），到执掌雅虎邮箱并主导关停 AIM、Yahoo Groups 等经典产品的三十年产品生涯。他尖锐地指出，在 AI 使得代码与原型构建极度廉价的当下，“构建能力泛滥，判断力却变得极度稀缺”，决定“不做什么”与设置淘汰率（Kill Rate）成为产品经理的核心壁垒。此外，他详细拆解了自己转型独立顾问后，如何通过三台设备、零信任权限控制与 Claude 多模型动态路由打造高效自治的“一人智能体团队”，并分享了在周六配额重置前借由剩余 Token 开启周五专属“构建日”的管理技巧。 ## Atmosphere & style 对谈在加州圣克鲁斯的一家披萨店现场录制，背景中带着轻松随性的工程聚会气息，两位相识十六载的老同事如同围炉叙旧般娓娓道来。对话既有回望互联网黄金岁月与生死宕机战役的深厚历史沉淀，又有面对全新 AI 生产力浪潮时的极客兴奋感。整体语调平实、透彻且极具反思性，在严谨的技术架构剖析与林间骑行、修车趣事的快问快答之间切换自然，给人一种历经技术周期起伏后的从容与睿智感。 ## Bulletin - [20:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1200s) 前 Yahoo CPO Michael Albers 指出，随着 AI 使得代码与原型构建成本大幅降低，产品领导力中最稀缺的能力已从“能否造出”转变为决定“不做什么”的判断力与预设淘汰率。 - [00:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=0s) 通过多模型动态分级路由（Opus 负责幕僚长战略决策、Sonnet 处理中等推理、Haiku 执行基础文件读写），可以在保证生产力的同时精准控制 Token 预算，并利用周重置机制形成固定的“周五构建日”。 - [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) 在独立顾问模式下搭建“一人团队”自主 Agent 体系时，必须坚守物理隔离与零信任原则：剥离敏感凭证、禁用全局删除权限，仅赋予起草与只读操作以防 Agent 失控。 - [14:01](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=841s) 面对历史技术债务与系统频繁宕机危机，团队需要果断叫停全部新功能交付（如雅虎达喀尔项目），将全员目标高度对齐至系统可靠性与底层根基治理。 ## Key takeaways - [19:05](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1145s) AI 时代软件构建成本趋近于零，团队面临原型泛滥与交付噪音，高维度的产品判断力（Product Judgment）成为最核心的溢价资产。 - [20:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1200s) 在启动产品发现（Product Discovery）流程前，必须预先定义成功的标准、淘汰指标（Kill Rate）以及可文档化的评估基准集（Eval Set）。 - [23:25](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1405s) 底层产品构思始终需要回归三个经典核心问题：谁是用户（Who）、解决什么痛点（What），以及为何该方案或团队能胜出（Why）。 - [16:54](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1014s) 关停拥有海量用户的遗产产品（如拥有 1.15 亿用户的 Yahoo Groups 及 AIM）并不意味着业务彻底失败，而是为了收敛机会成本并夺回组织专注度。 - [33:23](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2003s) 采用分级模型路由策略可极大优化 Token 预算：常驻最高智力模型作为幕僚长，将文件读写与子任务降级至低成本模型，中等推理则根据难度调节 Effort 参数。 - [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) 在运行多环境常开 Agent 架构时，坚持零信任权限隔离至关重要，包括个人敏感凭证死守本地、实施 PII 脱敏掩码，且绝不赋予 Agent 删除权限。 - [06:32](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=392s) 早年雅虎摆脱 Google 依赖并构建自有搜索引擎技术（YST）的经历表明，严密的人工对照评测（Side-by-side Evals）是验证算法模型与推进大规模系统重构的根基。 - [14:01](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=841s) 面对恶性可用性危机的“达喀尔项目”（Project Dakar）证明，暂停所有新功能、将产研目标深度统一到可靠性攻坚上，是清理遗留技术债的有效战术。 - [24:41](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1481s) 现代科技企业正在打破传统产研壁垒，向 CPTO 或权责合一的总经理（GM）模式演进，以消除产品与工程部门之间的拉锯与分裂内耗。 - [25:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1542s) 初创团队可以借助 AI 工具重塑协作流：设计端前置输出设计规范，工程端预设数据与架构边界，避免 PM 自主生成的原型脱离真实工程底座。 - [35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) 在经历多次技术周期的变革中，领导者的核心挑战是保持极致好奇心并将个人生产力放大转化为组织整体的协同能力，抵制盲目发布一切原型的冲动。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=0s) Token 预算管理与分级模型调用 Michael Albers 分享了他如今作为“一人团队”日常管理 AI Agent 系统的实战心得。他的核心工作流由一个扮演“幕僚长”（Chief of Staff）角色的智能体主导，其默认驱动模型选用推理能力更强的 Claude 3 Opus。幕僚长掌握着他的所有联系人脉与知识库，这些数据全部以结构化的 Markdown 文件形式存储在本地，并在他的三台设备实例之间实时同步。在处理具体任务时，系统具备智能路由机制： - 对于文件读写或基础常规操作，幕僚长会建议下发给子 Agent，并选用性价比极高、调用成本极低的 Haiku 模型； - 当遇到需要较强分析能力的任务时，系统则会切入 Sonnet 模型，并支持根据具体场景配置低、中、高不同的思考深度（Effort 级别）； - 每当有任务派发，Michael 都会与幕僚长动态协商本次任务最适合使用的模型档位。 ```mermaid flowchart TD accTitle: AI Agent 任务分发与模型路由机制 accDescr: 展示幕僚长 Agent 根据任务复杂度分发给不同底层大语言模型并管理 Token 预算的流程 User["Michael Albers"] -->|"分配任务"| CoS["幕僚长 Agent (Opus)\n本地 Markdown 知识库同步"] subgraph Router ["模型动态路由决策"] CoS -->|"简单任务 / 文件读写"| SubHaiku["Sub-Agent (Haiku)\n极低成本"] CoS -->|"中等/复杂推理"| SubSonnet["Sub-Agent (Sonnet)\n支持调节 Effort 级别"] CoS -->|"高难度战略决策"| MainOpus["主智能体 (Opus)\n最高智能水平"] end subgraph Budget ["Token 预算闭环"] SubHaiku --> WeeklyToken["周五盘点剩余 Token (~30%)"] SubSonnet --> WeeklyToken MainOpus --> WeeklyToken WeeklyToken -->|"周六额度重置前"| BuildDay["周五全天火力全开：Build Day"] end ``` 这种根据任务轻重精准调度 Token 的做法，直接塑造了他的工作节奏。通常到每周五时，他发现自己的 Token 额度还会剩下大约 30%。由于平台的调用配额会在周六早晨重置，这最后的 24 小时便顺理成章地被他定为专属的“构建日”（Build Day），全力消耗掉剩余配额来开发、验证新想法。 ### [01:11](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=71s) 播客开场与硅谷早期生涯本期节目是在加州圣克鲁斯（Santa Cruz）的知名披萨店 Pleasure Pizza 录制的特别现场，正值一场工程技术聚会期间。主持人与 Michael 曾是共事多年的老同事，话题随即转向 Michael 跨越三十余年的技术生涯起点。 Michael 出生并成长于荷兰阿姆斯特丹，10 岁时举家搬迁至乌得勒支（Utrecht）郊区。在大学阶段，他攻读的是电气工程（Electrical Engineering）专业，原先的志向是工业技术与工业工程。当时在荷兰，计算机科学教育远未普及，但热爱亲自动手实践、焊接电路板的 Michael 凭着对底层硬件的热情完成了学业。 1990 年，Michael 毅然决定前往美国，直奔技术创新中心硅谷。他的第一份工作是在位于圣克拉拉劳伦斯快速路（Lawrence Expressway）旁的 McAfee Associates。彼时公司规模极小，整栋小楼里包括传奇创始人 John McAfee 本人在内仅有约 20 名员工，主营业务是早期的杀毒软件。此后，他又辗转任职于几家小型数据库咨询公司，积累了扎实的底层技术功底。 ### [03:45](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=225s) 网景技术支持与互联网基础设施风云大约在 1995 至 1996 年间，Michael 加入了当时正如日中天的 Netscape（网景）。虽然外界熟知网景是因为其开创性的浏览器产品，但 Michael 选择在服务器端（Server side）部门担任技术支持工程师。他所负责的体系涵盖了网景的旗舰企业级套件： - Enterprise Server（Web 服务器） - Proxy Server（代理服务器） - LDAP Server（轻量目录访问协议服务器） - SSL Certificate Server（安全证书服务器）这段工作让他深入接触到了现代互联网的基石级技术，尤其是安全 Web 通信协议与企业级架构。由于需要为富国银行（Wells Fargo）等正在探索安全在线交易与网银业务的大型金融机构提供支持，Michael 常年处于严阵以待的“值班（On-call）”状态。面对系统突发宕机、生产环境不稳定的紧急状况，以及电话另一头处于暴怒边缘的企业客户，他整日泡在 Unix 终端与管理后台排查故障。这段高压经历不仅锤炼了他对系统可用性（Uptime）与健壮架构的直觉，更让他深刻体会到“如何从客户痛点出发打造真正可靠的系统”。那段岁月的行业氛围同样令人难忘。当时的网景吸纳了全球最顶尖的底层网络先驱，包括 Apache 服务器的初创元老、来自瑞士的代理协议制定者等。网景与微软之间针锋相对的浏览器大战更是火药味十足——网景员工曾把代表 Mozilla 的绿色巨龙雕塑推到微软园区，而微软则悄悄运来巨大的 Internet Explorer “e” 标立在网景总部门口。这种充满激情与挑战的技术交锋给初入硅谷的 Michael 留下了极深的历史印记。 ### [06:32](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=392s) Inktomi、雅虎搜索重构与早期机器学习实战离开网景后，Michael 加入了知名 OEM 搜索引擎与内容分发网络（CDN）服务商 Inktomi。随后，雅虎整体收购了 Inktomi 的搜索业务线。当时的雅虎虽然是互联网的绝对入口，其底层搜索技术却一直外包给 Google。这次战略收购的核心目标，就是将 Inktomi 的技术体系整合进雅虎内部，打造一套能够与 Google 并驾齐驱、乃至全面替代它的自有搜索引擎——这一庞大项目后来被称为 **YST**（Yahoo Search Technology，雅虎搜索技术）。将底层引擎从 Google 平稳切换到自研系统是一个动用了“千军万马”的浩大工程。作为牵头的核心产品经理，Michael 深度参与了与搜索相关性（Relevance）工程团队及雅虎知名人工编辑团队的紧密协作。这构成了他在机器学习（ML）与算法领域的关键启蒙： - 深入接触早期搜索排序算法、训练集（Training sets）构建与调优； - 领会了与当今 AI 领域评估体系（Evals）底层逻辑完全相通的评测闭环； - 依靠专业编辑团队作为质量守门人，对不同算法模型与 Google 搜索结果展开持续的“并排对照评测”（Side-by-side comparison）。团队定下了极其严格的上线门槛：自研模型的效果若不能在各项对比中持平甚至超越既有方案，就绝对不予放行。历经反复迭代验证，自研引擎终于达成既定指标，雅虎随之平稳切断了对 Google 的依赖，YST 时代正式开启。 ### [08:38](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=518s) 从技术支持转型为产品经理谈及个人职业路径的转变，Michael 坦言产品经理（PM）是一个极为特殊的岗位，并没有传统意义上的线性晋升路径，大部分高校在当时甚至完全没有相关的课程体系。通过在 Inktomi 和雅虎期间从技术支持逐步深入到核心算法与相关性团队，他发现自己天然具备连接业务目标与底层代码的能力： - 开始负责定义“什么是好的搜索结果”，拟定客观评测标准； - 主导工程研发与交付流程的排期与落地； - 最终顺理成章地转型为全职搜索产品经理，完成向产品领导力的跃迁。他指出，硅谷优秀的产品经理往往并非科班出身，有人来自工程一线，有人深耕用户体验设计，而他本人从系统排障、技术支持一线摸爬滚打出来的经历，使他在产品定义中始终对系统极限、架构容错与用户真实的受挫体验抱有高度的敬畏之心。 ### [10:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=600s) 初创企业巡礼：LiveOps、Xobni 与 CardSpring 迈克尔·阿尔伯斯（Michael Albers）回顾了早期技术人员的成长轨迹。在那个年代，很多工程规范并没有现成的课程传授，大家只能在实践中“边做边学”（learn on the job），随着时间推移逐步走向专业化。在离开雅虎（Yahoo）后，迈克尔开启了他的“第二段初创企业时期”（second startup era）。他首先加入了 LiveOps，参与打造一项名为 LiveWork 的服务。该产品在概念上类似于亚马逊的 Mechanical Turk，旨在调度居家办公的远程劳动力，完成版权审查、图像分析和内容校对等任务。随后，迈克尔转投 Xobni（名称即“Inbox”倒写）。正是在这里，他和主持人结下了工作交情。Xobni 的核心愿景是在用户的收件箱之上构建一个强大的“人际关系图谱”（people graph）——收件箱本身是一座金矿，沉淀着联系人、文档、交易记录与历史通信。此后，他又加入 CardSpring，专注于研发与信用卡挂钩的优惠券与广告投放平台（card-linked offers），实现消费者刷卡消费即触发特定商家优惠（例如比萨店返利）的联动体验。 ```mermaid flowchart LR accTitle: 迈克尔的早期初创企业职业轨迹 accDescr: 展示迈克尔从离开雅虎到重返雅虎之间历经的三家初创企业演进路线。 A["离开 Yahoo"] --> B["LiveOps / LiveWork (众包劳动力平台)"] B --> C["Xobni (收件箱人际图谱)"] C --> D["CardSpring (信用卡绑定优惠)"] D --> E["重返 Yahoo (担任回流员工 Boomerang)"] ``` 主持人深有感触地回忆起 16 年前两人在 Xobni 初识的场景：当时旧金山团队处于一片混沌的架构转型期，需要将产品从 Outlook 插件（依赖 Windows DLL 动态链接库）全面改造为能够支撑 Gmail 和移动客户端的服务端/后端架构，而迈克尔正是掌舵该技术条线、推行每周敏捷迭代（sprints）的关键负责人。不久后，Xobni 前 CEO 杰夫·邦福特（Jeff Bonforte）向迈克尔抛出橄榄枝，力邀他重返雅虎执掌 Yahoo Mail 产品线。迈克尔欣然接受，成为了硅谷圈内常称的“回流员工”（boomerang）。 --- ### [12:55](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=775s) 雅虎邮箱的规模冲击与达喀尔项目（Project Dakar）重返雅虎后，迈克尔面临的业务规模发生了量级跃迁。与初创公司几千或几万的用户体量截然不同，Yahoo Mail 当时拥有高达 2.25 亿月活跃用户。伴随巨大规模而来的是严峻的技术危机：系统频繁停机、可用性堪忧。迈克尔作为产品负责人，既要思考如何将 Xobni 的关系图谱技术融入邮箱以重塑通讯录体验，更要迫切解决底层稳定性。一次灾难性的大型宕机事件彻底引爆了危机：部分服务器故障后，大量用户的完整收件箱直接不可用，且持续了相当长的时间，暴露出团队长期对容量规划和稳定性的严重忽视。面对这一局面，时任总经理杰夫·邦福特与迈克尔果断决定：“全面叫停所有新功能开发，启动达喀尔项目（Project Dakar）”。 - **以拉力赛命名**：“达喀尔”（Dakar）取自艰苦卓越的达喀尔拉力赛，象征着全员聚焦、攻克险阻的战役式决心。 - **产研目标高度对齐**：产品与工程团队打破隔阂，统一优先级，所有 Scrum 敏捷小组重新编组，分流攻坚可靠性、客服工单、系统容灾、增长瓶颈及前端性能。 - **战时文化与凝聚力**：每个攻坚小组均设立了代号与团队 Logo（如“忍者队” Ninja Team），每周下班后定期召开全员进度通报会（readout），营造出强烈的使命感。 - **清理遗留系统技术债**：为期数月的停工整顿不仅彻底根除了恶性故障，还顺势完成了原本久拖不决的旧系统向新系统的迁移。迈克尔强调，处于危机旋涡中时，全员背负着高强度的汇报与停滞新特性的压力，难免会心生疑问“我们为什么要付出这么大代价做这事”；然而，如果不彻底夯实底层根基，在摇摇欲坠的架构上迭代新业务只会寸步难行。这场战役彻底重塑了 Yahoo Mail，为其后续的规模化扩张铺平了道路。 --- ### [16:54](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1014s) 艰难抉择：亲手关停经典产品的取舍之道随着迈克尔从邮箱产品负责人晋升为雅虎通讯业务总经理，并最终出任雅虎首席产品官（CPO），他迎来了职业生涯中最艰难的抉择时刻：为庞大的老旧产品线执行“生命周期终结”（End of Life, EOL）操作，亲手关停仍在服务海量用户的明星产品。迈克尔主导关闭的产品名单中包含了多款互联网时代的奠基之作： - **AOL Instant Messenger (AIM)**：PC 互联网时代最具代表性的即时通讯先驱之一。 - **Yahoo Messenger**：雅虎旗下的全球主力通信软件。 - **Yahoo Answers（雅虎知识堂）**：全球最早的大型问答社区之一（迈克尔早期曾参与打造其衍生项目 Answerpedia）。 - **Yahoo Groups**：最沉重的一次关停决策。该产品退役时仍坐拥 **1.15 亿用户**与 **1,000 万个活跃社群**。迈克尔指出，决定关停它们并不意味着这些产品在商业或功能上彻底失败，其核心逻辑在于**机会成本与团队专注度**（trade-off and focus）。长期维护庞大遗留系统所吞噬的工程资源、运维成本与管理精力极其昂贵。面对新的商业战略诉求，产品管理者最重要的修养是具备“说不”（say no）的勇气： > “在当下这个时代，学会说不、决定‘不做什么’至关重要。……从外部看来，关停可能只是某一瞬间的单一指令；但在内部，这是与工程团队海量沟通、捕捉跨部门信号、研判各种现实瓶颈后，最终达成共识的艰难抉择。” --- ### [19:05](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1145s) 代码廉价时代的判断力溢价对话随后延伸至当下 AI 驱动的软件开发新常态。主持人指出，如今在 Meta 等前沿科技企业中，AI 辅助使得编写代码的成本大幅降低、交付速度空前加快，工程团队能够输出海量的代码。然而，这也带来了前所未有的噪音：既然什么都能快速做出来，那么究竟什么才真正对用户有价值？迈克尔结合自己过往在雅虎大刀阔斧裁撤项目的经历对此作出了回应。他提到自己最近撰写的一篇文章中的核心观点：在软件构建能力高度廉价化的今天，**决策判断力（judgment）已成为整个产品体系中最稀缺、最宝贵的资产**。当生产代码不再是阻碍，团队如何抵制盲目堆砌功能的冲动，通过精准的判断力去伪存真，决定了现代科技产品的生死。 ### [20:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1200s) 构建门槛降低时代的“产品判断力”与击杀率（Kill Rate）当软件开发与原型构建的成本变得极其低廉、速度变得极快时，最稀缺的能力便从“能不能造出来”变成了“产品判断力（Product Judgment）”。Michael Albers 指出，正是领导者的判断力决定了何时彻底停掉像 Yahoo Groups 这样的产品；如今一周可以轻松产出 100 个原型，因此更严峻的挑战是**决定“不做什么”**。为了在海量构想中做出取舍，Michael 强调在进入产品发现（Product Discovery）流程之前，就必须在前端明确定义三件事： 1. **成功的样貌**：清晰界定什么才算真正优秀的产品； 2. **击杀率（Kill Rate）**：预先设定淘汰规则，例如“在考察的 10 个概念中，哪 2 个能够活下来，为什么能够活下来”； 3. **评估基准集（Eval Criteria / Eval Set）**：制定严格的技术与体验门槛，涵盖活跃使用度、加载时间等关键指标。 Michael 与好友 Felix von Kunhardt 共同编写了一份指南，专门规范如何在启动前通过对话把这套评估机制文档化。他直言，许多组织最大的痛点在于“没有记忆”——判断力往往只停留在资深人员的大脑中，从未被沉淀为文字，导致新晋产品经理无法传承。对于初级 PM 而言，参与这种前端的发现与筛选流程是培养直觉的最佳训练场；而通过快速迭代原型、吸纳播客与公开信息中的实战经验，年轻团队能够更迅速地理解“为何放弃”比“盲目开工”更为关键。产品的底层思考最终仍然回归到经典的“3 个 W”： - **Who**：你的客户是谁？ - **What**：你正在解决什么痛点？ - **Why**：为什么你的方案是正确解法，或者为什么该由你们来做？ --- ### [24:41](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1481s) 从产品主管到总经理：产研团队权责合一（CPTO 趋势）从主导 Yahoo 通信与邮箱产品进一步晋升为总经理（GM）后，Michael 的管理职责发生了质的飞跃。他需要统管全组织 750 人以及高达 35 亿美元的损益表（P&L），涵盖产品、工程（Engineering）、DevOps 和设计等所有职能。在传统大厂中，产品与工程往往各自设立目标，两边经常陷入漫长拉锯与资源谈判。而总经理模式将产品优先级与技术优先级直接压实在同一个人身上，全员统一在一个目标体系下执行，与早年“Project Dakar”可靠性战役的打法如出一辙。Michael 观察到当前科技行业正在发生重要结构性转变： - **组织角色融合**：越来越多的公司设立首席产品与技术官（CPTO），或者招募具备深厚产品直觉（product chops）的工程负责人； - **破除职能壁垒**：高层管理者的核心任务变成了确保战略一致、成功标准一致，避免不同条线各自为政。对于初期初创企业，Michael 建议创始人打破传统的“PM 提需求 -> 设计做 UI -> 交付工程开发”这一瀑布式线性链条，转向更为流动（fluid）的协作。如今许多创业者借助 AI 工具，甚至可以延缓雇佣全职 CFO 或法务总监，将节省下来的预算直接投入算力基础设施与 Token 支出中。在团队架构上，设计人员应提前输出设计规范（Style Guide），让 PM 借助 AI 工具直接生成的原型就具备统一的视觉风格；工程则需要预先设定好数据库与技术边界，避免 PM 自主尝试的原型在真实系统上根本无法跑通。如果拥有一位懂技术的 Head of Product，将产品与工程汇报链收敛到单一负责人名下，能最大程度避免小团队内部的分裂内耗。 --- ### [28:04](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1684s) 转型独奏：依托 AI Agent 打造“一人团队” 2021 年离开 Yahoo 后，Michael 创立了顾问咨询机构 Albers Advisory，转型为自由职业的独立贡献者（IC）。他主要承担各家企业的阶段性（interim）或部分工时（fractional）产品高管工作，在客户团队面临高管离职、组织架构重组或重大交付瓶颈时进场把关。虽然组织架构上只有他一人，但他通过一系列自主调优的 AI Agent 搭建了一套强大的后盾系统，实现了真正的“一人团队（team of one）”。在尝试了 Lovable、v0（bold）等应用后，他转向基于 Claude 与 OpenClaw 构建深度自动化的工作流。 ```mermaid flowchart TD accTitle: AI Native Solo Team Architecture accDescr: Michael Albers solo advisory workflow supported by custom AI agent suite subgraph User["个人咨询角色"] MA["Michael Albers (顾问 / IC)"] end subgraph AgentSystem["Agent 体系"] COS["AI 幕僚长 (Chief of Staff) 协调各业务条线与日程跟踪"] ToolStack["底层工具链 Lovable / v0 / Claude / OpenClaw"] end subgraph Client["客户交付与支撑"] Projects["产品战略诊断"] Delivery["临时产品领导力 (Interim CPO)"] end MA <--> COS COS --- ToolStack MA --> Projects MA --> Delivery ``` - **数字“幕僚长”（Chief of Staff）**：Michael 职业生涯最出色的时期，往往有一位顶级的幕僚长协助他把控全局。他在搭建系统时的首要目标，便是打造一个虚拟幕僚长来追踪所有工作条线。 - **趣味插曲**：他原本打算用自己过去的优秀幕僚长“Anandita”的名字来给系统命名，但后来意识到这样“有点怪异（a little creepy）”，最终这套 Agent 系统自行为自己取了名字。 ### [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) 构建 Agent 系统：安全权限隔离与“一人团队” Michael Albers 坦言，在早期探索自主 Agent 时曾遭遇过严重翻车：因为安全机制不成熟，部分 Agent 出现了失控行为（"went rogue"），导致一觉醒来账单爆炸，消耗了大量未经授权的费用。吸取这次深刻教训后，他彻底重构了自己的架构，转向使用 Claude Code，并在三个不同节点上部署了 Claude 实例：一台主力台式机（Desktop）、一台随身笔记本（Laptop），以及一台部署在芬兰、托管于德国服务商 Hetzner 的常开（always-on）Ubuntu 云服务器。这台远程服务器承担着不间断的研究任务、待办事项机器人（to-do bot），并通过一套自建的 MCP（Model Context Protocol）接口与所有实例交互。为了让不同环境的 Agent 安全协作，Michael 设计了一个名为“Syncbox”的任务投递中转机制。在权限控制上，他坚持“零信任”原则（"I do not trust you, you have to earn your right to trust"），必须通过任务表现逐步开放权限。更关键的是实行严格的物理与网络隔离：个人邮箱的访问 Token 仅保留在本地台式机上，常开服务器完全无权访问；系统内部部署了本地 PII（个人身份信息）脱敏与 Token 掩码处理，杜绝敏感数据回传给大模型厂商。此外，他的系统遵循极其克制的权限原则——只赋予起草、归档和只读权限，绝不赋予任何“删除（deletion）”权限。依靠这套机制，Michael 将自己打造成了一个高度自主的“一人团队”（Team of One）。他在远程服务器上构建了所谓的“盒中团队”（Team in a box），Agent 之间相互派发任务，不仅能通过 Telegram 机器人随时受控，还能自动完成调研、竞品趋势对比、创建并阅读 Google 表单问卷、向参与者发送邮件等全套工作。他笑着表示，现在哪怕只靠一部手机远程操作，也能井井有条地为客户提供咨询与交付服务。 ```mermaid flowchart TD accTitle: Multi-Instance Agent Architecture and Permission Boundary accDescr: Three Claude instances coordinated via MCP and Syncbox with strict local boundaries. subgraph Local["本地安全环境 (Local Devices)"] Desk["台式机 (Desktop)\n• 拥有个人邮箱 Token\n• 本地 PII / 掩码过滤"] Lap["随身笔记本 (Laptop)\n• 移动办公与临时调遣"] end subgraph Hub["协同与控制中枢 (Syncbox & MCP)"] MCP["MCP 协议接口"] Sync["Syncbox 任务交换箱\n(跨实例派发任务)"] end subgraph Remote["芬兰 Hetzner 常开服务器 (Ubuntu)"] Server["常开 Agent (Team in a Box)\n• 零个人敏感权限 / 无删除权\n• Telegram 机器人 / 代码构建\n• 竞品调研 / 问卷分析"] end Desk <--> MCP Lap <--> MCP Server <--> MCP Desk <--> Sync Server <--> Sync ``` - **权限范围与安全策略**：Agent 永远不具备任何删除权限（No deletion rights），邮件客户端仅开放阅读、归档和起草权限。 - **物理隔离**：个人隐私信息（PII）与个人邮箱凭证死守本地台式机，远程云服务器完全被隔离在外。 - **硬件与托管服务商**：常开服务器运行于芬兰的 Hetzner 机房，兼具稳定性和极高性价比。 --- ### [33:23](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2003s) Token 预算管理技巧与周五“黑客日” 随着 Agent 调用深度增加，Token 账单的管理变得极其关键。Michael 分享了他应对额度消耗的精细化“阶梯调度法”。他订阅了 Anthropic 的 Max 订阅方案（每月 100 美元），但在最开始，由于频繁调用高阶模型，往往周二就耗尽了当周额度，不得不自掏腰包购买额外 Token。为了解决这一痛点，他将架构设计为多模型协同： 1. **幕僚长（Chief of Staff）**：默认常驻最高智力的 Claude Opus 模型。它掌握完整的上下文，包含在本地 Markdown 层次目录中同步的所有知识库。 2. **常规子任务与文件读写**：当需要派发具体任务时，“幕僚长”会自动判断并建议降级至更廉价的 Claude Haiku 模型执行。 3. **中度复杂推理**：若任务具备一定难度，则引入 Claude Sonnet，并进一步将推理努力程度（effort）微调为低、中、高三档。这种精细调度让 Token 消耗发生了戏剧性的反转：通常到了周五，系统里还能剩下 30% 左右的 Token 配额。而 Anthropic 的每周额度恰好在周六早晨重置。于是，Michael 顺理成章地将周五变成了他的专属“构建日”（Build Day / Hack Day）。既然“绝不能浪费 Token”，他就会在周五的 24 小时内尽情挥霍剩下的 30% 算力，集中精力搓新应用、重构自动化脚本或搭建新基础设施。 --- ### [35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) 穿越技术周期：从好奇心到团队协同的领导力作为在科技行业摸爬滚打数十年的老兵，Michael 回顾了自己亲历的技术转折点：从早期的 Web 互联网爆发，到搜索引擎成熟、数字媒体崛起，再到移动互联网大潮，直至当下的 AI 革命。他直言，虽然当下的变革让人眼花缭乱，但这绝对是一次“前所未有的超级拐点”（"an inflection point like no other"）。面对很多产品经理和工程师因本职工作忙碌而产生的落后焦虑（FOMO），Michael 给出的建议是： - **保持极致的好奇心**：不要把 AI 视作淘汰自己的对手，而应将其看作赋能自己的“超级外挂（superpowers）”。 - **先个体，后组织**：提升个人生产力相对简单，但领导者真正面临的巨大挑战是“如何让团队整体以协同的方式工作得更好”。 - **克制交付冲动**：AI 极大地降低了原型开发的边际成本，但“你能造出任何原型，绝不意味着你应该把它们全部发布上线”。在人人皆可构建的时代，裁撤不必要功能的判断力比以往任何时候都更加稀缺。 --- ### [37:17](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2237s) 快问快答：心头好 AI 工具、修车趣事与林间骑行在节目的闪电问答环节，Michael 分享了他日常生活中生动、接地气的一面： - **近期最惊艳的工作流工具**：除了高频使用的 Claude 之外，他特别提到了最近从 Meta 拆分出来的 Manus。他对其输出结果的高度结构化、极高的外部 SDK 集成与调用完成度赞不绝口，认为其在引导用户完成端到端任务方面做得非常丝滑，几乎不需要多轮来回纠偏。 - **日常生活中的 AI 应用**：前段时间他的老款山地车（已有近 10 年车龄）后拨链器（derailleur）损坏，他随手用 Google Gemini 拍了一张后拨链器的照片，AI 准确识别出停产车型的适配型号；网购到货后，他又依靠拍照交互一步步完成了新拨链器的安装与变速微调。 - **坚决拒绝 AI 的私人时刻**：在户外骑车锻炼时，Michael 坚决不使用任何 AI 辅助，甚至连耳机都不戴。他视这段林间时光为神圣的独处时刻：“这是我磨炼判断力、迸发创造力的地方，那里只需要我和我的大脑。” - **电助力山地车（e-bike）之争**：常年在特拉基（Truckee）高海拔山区骑行的他同时拥有普通山地车和电助力山地车。他会交替使用它们：一天用普通车硬核爬坡挑战体能，另一天骑电助力车去探索更远更险峻的林道。他直言那些完全鄙视电助力的死忠骑友“彻底错过了许多探索未知风景的乐趣”。 - **运动后数据复盘**：回到家后，他会立刻坐下来翻看 Strava 的骑行数据，研究心率区间与功率输出。他非常认可 Strava 最近引入的 AI 分析总结功能，能智能指引出“这是你近期最长的一次骑行”以及各心率区间的具体表现。节目最后，主持人预告了将于 10 月 28 日在门洛帕克（Menlo Park）举行的 Product @Scale 线下峰会，届时将汇聚来自 Meta、英伟达（NVIDIA）、微软（Microsoft）、英特尔（Intel）和 Pindrop 等公司的顶尖专家，共同探讨 AI 与产品架构的未来。 ## Notable quotes > building got cheap, judgment became scarce — Michael Albers > [16:54](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1014s) 在当下这个时代，学会说不、决定‘不做什么’至关重要。……从外部看来，关停可能只是某一瞬间的单一指令；但在内部，这是与工程团队海量沟通、捕捉跨部门信号、研判各种现实瓶颈后，最终达成共识的艰难抉择。 — Michael Albers > [30:00](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=1800s) I do not trust you, you have to earn your right to trust — Michael Albers > [35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) 你能造出任何原型，绝不意味着你应该把它们全部发布上线 — Michael Albers > [35:42](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2142s) an inflection point like no other — Michael Albers > [37:17](https://www.youtube.com/watch?v=Kvo-dCXNDXw&t=2237s) 这是我磨炼判断力、迸发创造力的地方，那里只需要我和我的大脑。 — Michael Albers ## Mentioned Michael Albers, John McAfee, Jeff Bonforte, Felix von Kunhardt, Yahoo!, AOL, Netscape, Inktomi, McAfee Associates, LiveOps, Xobni, CardSpring, Google, Microsoft, Meta, NVIDIA, Intel, Pindrop, Wells Fargo, Hetzner, Claude 3 Opus, Claude Sonnet, Claude Haiku, Claude Code, OpenClaw, Lovable, v0, Manus, Google Gemini, Strava, Telegram, YST (Yahoo Search Technology), Project Dakar, Yahoo Mail, AOL Instant Messenger (AIM), Yahoo Messenger, Yahoo Answers, Yahoo Groups, Model Context Protocol (MCP), Albers Advisory ## Video description What happens when building gets cheap? In this episode of the @Scale Podcast, AI-native product executive Michael Albers shares lessons from more than two decades building consumer products at scale and explores why judgment may be one of the most valuable skills in the age of AI. Michael spent much of his career at Yahoo! and AOL, ultimately serving as Yahoo!’s SVP and Chief Product Officer over a $7.5B+ portfolio serving more than a billion users. Earlier in his career, he was the primary product lead in moving Yahoo! Search off Google and onto its own search engine, and later served as VP of Product at Xobni. Today, Michael runs Albers Advisory, where he takes on fractional and interim product leadership roles. Since 2024, he has also been building his own AI systems hands-on, developing an AI-native approach to product work. In this conversation, Michael explores: • Why “building got cheap, judgment became scarce” • How AI is changing the economics of building products • Why deciding what NOT to build may become more important • Lessons from leading products at Yahoo! and AOL • Moving Yahoo! Search off Google and onto its own search engine • Making difficult product and portfolio decisions • The importance of defining success before building • How to evaluate ideas and determine what deserves to survive • Building an AI-native “team of one” • Using AI agents and custom systems to augment product leadership • What product leaders need to prioritize as AI accelerates the pace of building Michael Albers is based in Menlo Park and runs Albers Advisory, where he works with companies in fractional and interim product leadership roles. 🎙️ Subscribe to the @Scale Podcast for more conversations with the engineers, product leaders, and technology experts shaping what comes next. Learn more about Albers Advisory here: https://www.albersadvisory.biz/?utm_id=h8p91 Want to join conversations like this in person? Register for @Scale: Product 2026 happening on October 28 in Menlo Park - https://atscaleconference.com/events/product-2026/ 00:00 Token Smart Model Picks 01:11 Intro 01:51 Reconnecting And Background 02:38 Amsterdam To Silicon Valley 03:45 Netscape Support Lessons 06:32 Inktomi To Yahoo Search 08:38 Tech Support To Product 10:17 Startup Tour Xobni Cardspring 12:55 Back To Yahoo Mail Scale 14:01 Project Dakar Reliability Reset 16:54 Hard Calls Killing Products 19:05 Judgment Over Shipping Speed 21:54 How PMs Build Judgment 22:45 Learning From Others 23:25 Three Ws Of Product 23:49 Becoming A GM 24:41 Unifying Product And Engineering 25:42 Structuring Startup Teams 28:04 Leaving Yahoo For Advisory 28:55 Building A Team Of Agents 29:55 Security And Permissions 33:23 Token Budgeting Hacks 35:42 Leadership Through AI Shifts 37:17 Lightning Round AI Tools 38:29 Biking And AI Balance 40:08 Ride Analytics With Strava 41:02 Closing And Event Invite [Source](https://www.youtube.com/watch?v=Kvo-dCXNDXw)

Source quotes

Michael Albers: building got cheap, judgment became scarce [16:54] Michael Albers: 在当下这个时代，学会说不、决定‘不做什么’至关重要。……从外部看来，关停可能只是某一瞬间的单一指令；但在内部，这是与工程团队海量沟通、捕捉跨部门信号、研判各种现实瓶颈后，最终达成共识的艰难抉择。 [30:00] Michael Albers: I do not trust you, you have to earn your right to trust [35:42] Michael Albers: 你能造出任何原型，绝不意味着你应该把它们全部发布上线 [35:42] Michael Albers: an inflection point like no other [37:17] Michael Albers: 这是我磨炼判断力、迸发创造力的地方，那里只需要我和我的大脑。

Source quotes

[3:45] Michael Albers: Original founders of the Apache server, right? The people that wrote proxy protocols, right, from Switzerland, right? The people that really built the foundation of the Internet, all working in the same place. [16:54] Michael Albers: It wasn't necessarily that these products failed. The trade-off of continuing to operate them—the cost of running these products—was the challenge versus what was mostly important, which is focus... So from the outside, it seems like it's one call. It's many different things that ultimately allow you to realize that this is the right thing to do: to stop something so you can continue on to something else and focus. [19:05] Michael Albers: building got cheap, judgment became scarce [30:00] Michael Albers: I do not trust you. You have to earn your right to trust. [30:00] Michael Albers: No deletion. And so I manage permissions through scope depending on the task [33:23] Chief of Staff Agent: I'm about to assign a subagent. I suggest we use Haiku. [33:23] Michael Albers: My tokens reset Saturday morning and so I have 24 hours to blow 30% of my tokens and I go build... Why not, right? I mean, I'm not gonna waste my tokens. [35:42] Michael Albers: an inflection point like no other [37:17] Michael Albers: That is alone time for me, where I get to think about everything. I'd say that's where I build my judgment. It's where my creativity kicks in. And so I don't need AI there necessarily because it's me and my brain.

Original transcript

[0:00] My default today is Opus. You know, it's a little smarter. And so my chief of staff's reign is Opus as a model. But then when I need to do file operation or simple things, I have a conversation. It actually knows. It tells me I'm about to assign a sub-agent I suggest we use haiku. Cheaper model, way cheaper to use. And it does that then. If I need something slightly more smarter, it's it introduces the sonnet model, right? And there I even said effort, right? You can say, you know, low, medium, high effort, right? And so we adjust that. So every time, I talk to, you know, we dish out a task of my agent, right? I talk to my chief of staff, which has all my contacts, all my knowledge stored locally, in markdown files in a hierarchy synced across my three instances, Every time something is delegated, then we talk about What model to use? Yep. And this is how I actually manage my workday. And what then actually happens is usually by Friday, I'm like, oh, I got 30% tokens left. which is pretty good. And then I've turned Friday into my build day. Because my tokens reset Saturday morning. And so I have 24 hours to blow up 30% of my tokens. Welcome back to the AdScale podcast, where we share stories of technical innovation from top industry leaders. You just heard a clip from a special episode we recorded at Pleasure Pizza in Santa Cruz, California, during an engineering meetup with Michael Albers. a billion users, and now he advises tech companies with a full team of AI agents. Let's dive into our conversation about the latest agent tech product trends, leadership lessons, and tips for product leaders to actually manage teams and tokens. So, It's been a long time that we haven't seen each other. For quite a few years. For the audience, I want to make sure we know each other. We've worked. to get her in the past. And... Knowing you, I thought it would be like super interesting for you to come on this podcast. Thank you. And to actually share your experience. Because for the many years, you've worked your way into many iterations of technology, up to this point where you're kind of doing a one-man show, but before that, you had a variety of experience. Yep. So... Let's start! And let's talk about, you know, you come from the Netherlands, you come from Amsterdam. Let's start there. What's your background? Where did you go to school? Yeah, like you said, I was born and raised in Amsterdam, the Netherlands. I lived there until I was 10 years old. And then we moved to the Burbs, where I went to school in a city called Utrecht. I studied electrical engineering. I wanted to go into industrial technology or industrial engineering. And tell me, at that time... Like I also went to electrical engineering. But I wanted really to work in computers, but the program was just not available. Was it the same for you? Yeah, it was. And I actually think the Netherlands was not really a space where computer science, at least at the time, was. was very popular. And I, you know, I like to be hands on. And so that's why I went with electrical engineering, right? I get to build circuit boards and do that. And then, you know, after that, in 1990, I decided to come to the US and, you know, worked actually right in Silicon Valley. I came to Santa Clara and my first job was at McAfee Associates. Wow. We were on the side of Lawrence Expressway in a very small building, you know, probably 20 employees with John McAfee. And that was really how I got started. You know, antivirus software, that's mostly what we did. From there, I then worked at some other smaller companies, database consulting firms, etc., and then I ended up at Netscape. And so, and of course, that's around 95, 96. And at Netscape, there was the browser side that most people know, I actually worked on the server side. And so I did technical support for Enterprise Server, which was the Netscape web server, proxy server, LDAP server, SSL certificate server, etc. And really exposed me to a lot of what is now the foundation of the internet, secure web server communication, all of that. And then I believe at that time you're dealing with large account from a support perspective. And then... Do you remember like some, like a lot of people, who kind of have this similar type of role where they have to deal with large accounts? Do you remember some learning from that time? Yeah, I mean, I remember being on call, right? I think you know all about this. And supporting customers like Wells Fargo, right, that were using our secure certificate server [5:00] to be able to do banking and transactions securely, things not working out, and so things going down, things not being stable, right? And then, you know, that was part of my role, right, to help them out and make sure that the site was back up and doing that. And I think as a product, I-- That really, you know, A, exposed me to a lot of things. I lived inside of Unix terminals a lot. I dealt with these admin interfaces. I understood what upside really meant. And I think, you know, dealing with somebody angry on the other side of the phone. really exposed me to what it takes to build strong servers and helping customers with their problems. - Do you remember a little bit the energy of the era? 'Cause I kind of like, I vaguely remember it. Like back then was working at Nortel. was like a new grad and then tried to help on adopting some of these technology, and the energy was high. It was great, actually. And what to me was amazing is the kinds of people in Netscape were able to pull in, right? Yeah. Original founders of the Apache server, right? The people that wrote proxy protocols, right, from Switzerland, right? Yeah. The people that really built the foundation of the Internet, all working in the same place. And then there was this fun little battle back and forth between Netscape and Microsoft, right, Mozilla Dragon on the Microsoft campus and they in turn dropped a big E for the Internet Explorer on ours. And there was a really great vibe. And so that was really exciting. Yeah. Great. Let's talk about career progression. Yep. At some point... You do the startup, you do Netscape, and then there's a point where you end up at Yahoo. How did that kind of transition work out? Yeah, when I left Netscape, I actually joined a company called InktoMe. And InktoMe was an OEM search provider. We powered a variety of companies with our search technology, and Yahoo acquired InktoMe. InktoMe did two things, actually, search and CDNs. And I worked on the search side, and that ultimately is what Yahoo ended up buying. Yahoo was at the time running on Google Search, and essentially the acquisition was to bring InkedMe into Yahoo and be on par and eventually switch over. And, you know, we dubbed this collective technology at one point YST or Yahoo Search Technology. Yep. Yeah, yeah. Which I'm sure you're aware of. Yeah, I remember. Yeah. And so I was, you know, the PM lead to help with the transition. This took an army, right? Certainly not me alone. This is many, many people to switch over. But I work closely with the search relevance team, editorial staff, and actually for me, actually first exposure to machine learning, right? Search algorithms, training sets, right? Training sets, yeah. Et cetera. So really interesting. And now when I think about evals and I think about, you know, what it takes to train models, it's very similar. Very similar. The same, I would call it like job infrastructure is bigger with AI these days, but it's kind of like the same thing. all over. Yeah, it is. And so, you know, I think Yahoo had an amazing editorial staff and They were the gatekeepers at the end of the day. They did side-by-side comparison to different models that we had, different algorithms, how we compared against the incumbent provider, and they held the bar. If it wasn't good enough, then it wouldn't go out. And eventually, we succeeded or were better as good as, and that was the moment we switched over. And long story short, that became YSEO Search Technology. Yeah, yeah. Oh, that's great. And then... Part of that overall career transition, you transitioned from tech support to product. Yeah, I think product management is a unique career, actually, in that there's no linear path to become a PM. In fact, many universities don't even teach product management. Some are starting to, and I'm actually very excited about that. So, yeah, I switched from tech support to product. and search. And so I started working with the relevance team, with the engineering team, and realize that, oh, now I actually get the shape, you know, the criteria, the definition of what is good and how you go about that. And ended up essentially managing the delivery of that eventually and doing so. And that was essentially my entry into product. And so that's how I became a search PM. And, you know, that carried me throughout and. Yeah, so the rest is kind of history. That's where I started my product career. And, you know, sometimes you go from engineering, sometimes you come from the design side. Yes, yes. Yes, it is very interesting because I had something similar. I started more as, let's call it like a coding assistant for a researcher. I started my career in speech recognition and over time, I gravitated more. [10:00] And how do we put these things in production? And how do we maintain them? And like all the code that goes around. And yeah, back then also it was something similar where, oh, you're not being taught. You kind of have to learn. on the job and it's something that you specialize over time. Yep. So tell me more about like, so you had Yahoo and at some point you decide to leave. And then you have like another, I would call it like your second startup era. That's right. And this is where we actually met when both of us were at Zobby. Can you tell us a bit about your transition in this era? Yeah, so I left Yahoo and joined a company called LiveOps. They did remote workforce, you know, call centers and they were developing something called live work Mechanical Turk equivalent, you know, where remote people working from home Would do things remotely and you know make edits and things like that. And And so that's what they did, copyright review, image analysis, et cetera. From LiveOps or LiveWork, the Mechanical Turk platform we were building, I then left and joined Zavni. And Zavni is Inbox Backwards. You and I worked there together, and we were building essentially a people graph. on top of your inbox. And if you think about the goldmine that is your inbox, right, people, contact information, documents, files, history, orders, etc. That actually is what we were focusing on. And then from there, I then left and joined a company called Card Spring, where we're essentially building card linked offers, coupons and ads on top of your credit card. So you use your card and you get an offer in a pizza store, for example. At that point, I got a call from the CEO of Zobny, Jeff Bonford, to ask me if I wanted to run Yahoo Mail as head of product for Yahoo Mail. That's how I actually came full circle. Yahoo has a name for it. They call them boomerangs. Yeah, boomerangs. A lot of places are boomerangs. I still do remember the first day we met. I joined Zobni in order to help scale and stabilize what used to be called a backend or server team. Because at that point in time, the team was making a big transition from being inside Outlook to being a mobile app to be able to support Zobni inside of Gmail and all of that. I still remember joining a little bit, the chaos in SF around that. seeing that you were like managing that area and building the weekly sprint and that type of stuff. And I do. Yeah, that's kind of going from DLLs to server side. Yes. That was actually the real big transition. So, yeah, that's good. And, you know, I can't believe it's been basically 16 years. It's been 16 years. Yes. Yes. Now you're back at Yahoo. And now with... more responsibility. And with more decision, more stuff that you have to do, a larger team, and some level of momentum. So tell us a bit more about that transition. Yeah, I mean, that was obviously a much larger scale. You know, even at the very startups I worked at, you know, we had fewer customers and the scale was much smaller. You know, Yahoo Mail had 225 million active users. And, you know, that's an order of magnitude more. When I joined at the time as head of product, a lot of that was also during a time of transformation, you know, at stability challenges, outages, you name it. were not great, but also an opportunity to kind of transform all of that. And so that product is really kind of thinking through what should mail become? How do we do that? And actually, how do we weave in our old Zavni technology, right, to make, you know, contact address books better, the people graph, those kind of things. Talking of outage, I remember this big outage when we were born part of Yahoo Mail, where, you know, a portion of users lost their data not detect properly. And that spun off what we call Bordeaux called the Project Dakar. Can you tell us what it was and what it brought? This is interesting, right? So, yes, we actually, there were a few servers that went down, and not just for a small period of time. People's entire inboxes were not available for a period of time at that moment. And that showed that, you know, we had ignored stability, right? We, you know, capacity planning issues and things like that. I was head of product, but really under Jeff Bonford, who was a GM at the time, we basically decided to stop everything. And start Project Dakar. And for those that don't know, Dakar is a rally. Yep. [15:00] So this is a rally. Everything stopped. And I think it's an indicator of aligning product and engineering priorities at the same time. And so this is for once where everybody works off a common set of priorities, and we then allocated teams, scrum teams, to work on reliability, customer care problems, stability issues, growth issues, front-end issues. But we actually did not end up doing new development. It was all about stability. And this was a multi-month effort where we essentially decided to stop everything we do to get everything to become stable again. everything around Yahoo Mail, because from there on out, We were able to kind of grow and stop. And if you continue to have these issues, it actually makes it really challenging to evolve a product, right, to build new product on top of that. What was interesting is that. We attacked a lot of like, you know, there was partial migration from older system to newer system that. It gave us the opportunity to complete them and then to continue. So it put us in a way better space to actually move forward, move the product forward after the fact. Yeah, absolutely right. Yeah. I do remember like, you know, it was intense. I think we have to report, I believe, every week, and it was after work, we had to report status on all our work stream. Yeah, so it was intense, but it was worth it. And every work stream, we had code names. The ninja team delivered something else. And so to give people an identity, they even had logos, the team, all the readouts and the progress we made. There's a little bit of a creation of a crisis, and I think everybody rallied, but we came out for the biller. it was only a couple of months right and when you're in the thick of it it that's really it seems like why are we doing this this is this is a lot of commitment um and i think you know like i said it transformed jahoo mail from from where we were right coming back to product management it's a bit in this era where you probably had to make the most efficient difficult decision of your career yes can you walk us through the scenario and just give us a little bit of the story and I became the GM of mail and communication products and then chief product officer at Yahoo. And there, you know, we had a lot of products under our purview and under our skies and what we were doing. And so one of the hardest decisions I have to make is end of life in products and the flying products that had users on it. Right. And it started with, you know, killing essentially, you know, AOL Instant Messenger, AIM, one of the most commonly used messaging apps on the platform at one point in time. - Yep, yep. - Not then. Yahoo Messenger, same for Yahoo Answers. I actually worked with the Yahoo Answers team, my first thing to do Yahoo, worked on a product called Answerpedia, which is Q&A answers and meets Wikipedia. And then, you know, one of the hardest ones was actually shutting down Yahoo groups. And I bring this up because I think it's really important in this day and time to say no to things, right? Decide what not to do. And it wasn't necessarily that these products failed, The trade-off of continue to operate them, the cost of running these products, was the challenge versus what was mostly important, which is focus. And so ultimately, the team had to focus on the right priorities, the right business needs, the right product strategy. And so shutting down something like Yahoo Groups, which had 115 million users, 10 million groups, was not easy. But that was a decision I had to make. And that's something you do as a product manager, product leader. You have a lot of conversation with engineering teams. You pick up on signals from different people. You see the challenges. You talk to different groups that interact with it. And eventually you conclude that this is the right call. So from the outside, it seems like it's one call. It's many different things that ultimately allow you to realize that this is the right thing to do. To stop something so you can continue on to something else and focus. And that's why. And if you layer that... with the world we're living today. Like, if I look at, like, you know, from my experience, like, you know, I met a Lots of the coding seems to be not free, but it happens a lot faster than it was before. And there seems to be a tremendous amount of code that gets shipped. And now the question becomes like, you know, What should we focus on? What's going to move the needle for users and for our products? Give me a little bit more around like from the product management about like, how do we manage this influx of energy and things so that we can still get quality systems or quality products? I mean, the stopping or saying no to things is part of that. Right. And so, you know, I wrote a guide or an article recently where I said, you know building got cheap judgment [20:00] became scarce and judgment is what product is all about, product management, right? And so I judgment as a leader to decide to stop something like Yahoo Groups. And I think there has to be judgment that you implement when you decide to be able to build anything because building does get cheap, building does get fast. And so when you can build 100 prototypes a week, yeah, I think the harder thing becomes what do you decide not to build, right? And so I believe strongly that, you know, you need to, before you even do anything in the product discovery cycle up front, you know, Start thinking about what does success look like, what makes for a great product. And then two is define a kill rate, actually, where I'd say of the 10 things that we look at, which are the two that survive and why would they survive? And then from that, you also develop an eval criteria. And so that says this is the reason why they make it through. You have to keep it up. There's usage, there's load time, there's things like that. I believe you have to sit down and actually develop a guide that does that up front. A good friend of mine, Felix von Kunhardt and I wrote this guide together to say, this is a product discovery piece where you have to define what does success look like, what is the kill rate, and then what's the eval set. You do that all up front through conversations. It's also where you actually build judgment. I actually believe most organizations don't write down judgment in documents. It lives in people's heads, right? Why is there no memory? Yeah, it doesn't have memory. And I think, you know, for PMs that are up and coming or junior PMs. That is part of it as well. I think they learn to build judgment in this kind of upfront discovery process. And so I think it's a great training ground to do that as well. How do they build this judgment? Is it just by using the ham more, their product more, but there's also a question of understanding what the user wants, usage patterns? So how do somebody build that judgment? Yeah, I think, of course, using software products, tools, systems, I think develops that, first and foremost. I think you can learn through iteration very quickly. reiterate on that, I think these days that you can do much faster, right? Because you can build faster, you can prototype faster, you can learn quicker. So, I actually think you can accelerate building judgment by building all these prototypes and realize, oh, this doesn't work. That doesn't work. Oh, this one seemed to work good. Right. And doing that. And so I think that's one piece. And then there's a tremendous amount of. information available, you know, obviously on the internet and YouTube podcasts like this, right? So listen to others that have experience, right? Pick up on that. And so I think they can very quickly build and learn. And I think if, if. you know, things are documented up front, right, before you even start building, because you can build pretty much anything nowadays. That is an opportunity for young PMs to actually participate, right, and learn how people decide, learn how to decide not to build something, learn how they decide why something is good. And I think in the world of product, right, there's kind of The three W's I think about, right? Who is your customer? What problem are you solving? And why is your approach the right one? Or, you know, why are you, why are you the right person to build it? Or why is your solution the right answer to that? And so just think about that, right? It's, you know, who's your customer? And what's the problem you're solving? Very basic, but very basic about that. Yeah. Going back to career progression. Yeah. So you were adding products at some point in Yahoo and Yahoo comms and mail. But at some point, You became GM also. So meaning a lot more responsibility, overseeing both product team, engineering team, and all the support function teams and so on. What was that transition like? A unique transition where obviously I went from male uh to broader responsibilities you know with comms etc but what was unique about that role is as you said it wasn't just product it was product it was devops it was engineering it was design uh etc and what's unique about that is i technically owned the full pnl three and a half billion dollar pnl um 750 people total in organization but everything under one person. And so for me as a product person that basically said product and engineering priorities are one set of priorities. And I think it's very similar to what we did with the car, right, where Everybody's executing off the same set of priorities. And I think that is somewhat rare. Typically there's a negotiation that happens between a product team and an engineering team. Yeah, yeah, yeah. [25:00] their own priorities and there's some back and forth around that. And I'm actually starting to see a trend now where that is kind of reversing. I'm hearing CPTO roles, Chief Product and Technology Officers, where these are becoming one. And I actually think that is probably a direction you're moving into. I've heard folks looking for engineering leaders with product chops. And so, you know, that is, I think, where these roles are starting to collapse, essentially, because of Are we building the right thing, right? Is product judgment part of decision making? Are we all rowing in the same direction? Is product strategy aligned? Are our outcomes aligned? Are our success criteria correct, right? And I think it's much more where these roles start collapsing, mostly at a leadership level, I believe. If... You had to give advice to young startup founders and then... Let's go about how to structure these teams to avoid that clash between product and engineering function. How would you structure a small org? I think it used to be that you know, these functions, you know, work very independently and work with each other. I think it should be much more fluid than that. And so now I think for a small startup, A, I think there are things you can do that you wouldn't be able to do before. You know, I've talked to some founders where, you know, they're basically not hiring their CFO just yet. They're not hiring their head of legal just yet because they're able to get good enough responses out of AI tools to be able to do that. And so they delay hiring and they actually spend it on, guess what, tokens, infrastructure and those kind of things, right? And I think that is the right way to go about it. What I think is important is with these tools that are available, you have to change the ways of working, right? It's no longer just, a product manager hands it off to a designer that gets handed off to engineering. These teams need to work together. I think a designer can actually provide you a style guide or information of what look and feel so that the prototype that's output by, say, a product manager looks familiar. they do decide to pursue something, a feature or a product, it can actually run on the infrastructure that already exists. Versus an engineer saying, well, that's great, we don't have this. Or no, we can't do that because of our database limitations. Things like that. Coming back to the structure of the team, would you like... Advise the younger founder like a I want you want your engineering function to report directly to you or like I go to a single head. Yeah, I think a small team is obviously more fluid. Yeah. I do believe that I think, you know, if you have a product, head of product that is technical, some of that can actually collapse into that person because then I think you're avoiding this kind of conversation around, you know, these are engineering priorities. These are product priorities. And certainly when you're small, you want to make sure everybody's focused on the right thing. Everybody goes into the same direction. Yeah. There's a point then you manage... 3.5 billion PNL and so on. And you say, Hey, I'm going to leave all that behind and I'm going to move forward and start my own thing. Yes. Tell us a little bit about this. Yeah. So I left Yahoo in 2021 and then started my own advisory firm. I basically take on interim and fractional product roles. I'm a team of one powered by a bunch of agents. And so I went from running a large organization to being an individual contributor. I help companies when there's a gap or there's a product need. Somebody leaves. There's a restructuring. And I come in to help them from the outside in, essentially, get the product done. team on track or get a product out. And then, you know, I go on to my next client. And so essentially independence right now. So you mentioned a team of one. That's super interesting because like, you know, there's a bit of utopia, but there's also like, you know, I do love control and team of one is great for that. Tell us about your setup. Like, like, like, how do you manage? Like, you know, I've read some article that you publish on LinkedIn talking about your chief of staff and tell us a bit about, you know, the orchestration, how do you manage agents, what's kind of like your setup? I started small, right? So what a couple years ago started with just Lovable. I then started using bold. And then obviously as Claude came about, I wanted to play with that. I actually started an open Claude. So my first idea was I'm going to build a chief of staff because I was at my best with a great chief of staff. And, you know, she kept me on. She kept me on track, made sure all my tracks were going. I even wanted to call my system after her name, Anandita, and decided, "Yeah, that's a little creepy." So I won't do that. Interestingly, it named itself. So I'll talk about that as well. When I started with OpenClaw, there were a couple of things I ran into. One is, [30:00] uncomfortable with the security posture. And so just safety, security, the trust, those kind of things. And then secondly, I had some agents go rogue. And so overnight, I spent a lot of money that I didn't want to spend. And so at the time, it just wasn't ready. But I learned from that. And so then I switched to cloud code. Okay. And so I now run... three instances of Claude. I have one on my desktop. I have Claude running on my laptop as I need to. - Desktop, yes. - And then I have an always on Ubuntu server that sits in Finland at a German ISP called Hetzner. And they run instances there. The reason why the server is always on is because it runs research. It manages my to-do bot. I have an MCP interface that I've built. - Yep, yep. - So all of my instances talk to that MCP interface. And thinking about inboxes, I built something I called syncbox. And so my instances drop each other's tasks to each other to perform different things because I have different access. And so when I first started with Claude, I basically-- - So you manage access by kind of like location of desktop versus your VM running remotely. - That's right. So you have some level of isolation. It's some level of isolation. And a good example of that is my desktop is the only one that has token to my personal email address. Okay. My server does not from a security posture perspective. And so when I first started, I actually said... I do not trust you. you have to earn your right to trust. And I would slowly give you access and slowly give you permissions. And so I developed a trust and safety policy within my own system so that I could be careful about what is shared and what's not. And so including things like PII filtering, token masking, I did not want these to go to the LLM providers. And so that's how I managed that. And so they still remain locally today. And even to this day, nothing has deletion rights. If I think about my email inbox, right, for example, you know, it has draft rights. It has archive rights. It can read everything. No deletion. No deletion. And so I manage permissions through scope depending on the task that I want them to do. And so there's always on server. It's always available to me. You know, it runs a Telegram bot. It does things like that. And often is where I do my builds. So I drop my spec in there. And also there, I've defined what I call team in a box because I am a team of one, but I use agents as a team. And they then help me go build solutions and software that I'm interested in, right, from apps to different services. And that helps you in your current job as fractional, CPO type of thing? It does. Some of them are site projects, things that I'm personally interested in to build. Others are truly performing tasks. So an example of that is doing research, doing analysis, a comparison of trends in the space. It has access to certain documents, so there's access to my Google Drive accounts. And so that's where it creates surveys, it reads survey results, it emails participants and things like that. And you and I were talking earlier, I can fully remotely on my phone, manage a client if I wanted to do that, because a lot of these tasks are happening in the background. You talk about the business. indirectly about token management. This is becoming a hot topic these days because a lot of people have been surprised by the overall cost of these things, token. So you kind of manage it by scope. Do you have limits in some area? Because look, I'm a team of one. So I try to manage my costs in token usage. And so I'm on the Anthropic Max plan. It's a hundred bucks a month. By Tuesday, everything was done. And so now I got to spend money to be able to use more. And so what I started doing is my default today is Opus. It's a little smarter. And so my chief of staff's reign is Opus as a model. But then when I need to do file operation or simple things, I have a conversation. It actually knows. It tells me I'm about to assign a subagent. I suggest we use haiku. Cheaper model, way cheaper to use. And it does that then. If I need something slightly more smarter, it introduces the sonnet model. And there I even said effort. You can say low, medium, high effort. And so we adjust that. I talk to, we dish out a task of my agent. I talk to my chief of staff, which has all my contacts, all my knowledge stored locally, in markdown files in a hierarchy, synced across my three instances, Every time something is delegated, then we talk about what model to use. And this is how I actually manage my workday. And what then actually happens is you [35:00] Actually, by Friday? I'm like, oh, I got 30% tokens left. which is pretty good and then i've turned friday into my build day because my tokens reset saturday morning and so i have 24 hours to blow to 30 of my tokens and i go build oh you go and maximize yes right why not right i mean i'm not gonna waste my tokens yeah so you you kind of find them point like my reset is saturday morning yeah yeah so friday morning i'm like oh i got 30 left there was a slow week or whatever that's interesting at all So I blow it in something fun, right? I end up building an app or whatever that may be. And so that's my hack day. My build day is Friday. Oh, that's awesome. Whatever that could be automation, could be infrastructure. That's how I use it. Oh, that's super awesome. Yep. You've gone to many many transitions, and the more recent one. Could you share some kind of leadership wisdom that you learn along the way about, like, hey, What's the best way? as... a tech person, engineer, product manager, to handle this transition. People talk about adaptability, but I'm like, I mean, I think it is some of that adaptability. I've seen a lot of inflection points in my career, right? Having started with the internet, essentially going to search, going to media, the shift to mobile, then the shift to AI – this is another inflection point. I actually think this is probably an inflection point like no other. And I know many product people are having FOMO, right? Because they're working their day jobs, but they're very curious about it. And so I had the luxury to spend my time on learning these tools. And I decided to do that because I was obviously very curious and realized that I can only do my job better. It's not to actually work myself out of a job. I am actually having superpowers. I can do things more than I could do before. And so I'd say be curious. Start thinking about how you might use these tools in your workflow. And I think actually the hardest part is An individual being better and working better is one thing. The team collectively working better is a very different story. And so I think that's where I think leaders should start thinking about how do we do this, right? If you can build anything you want to in any prototype, that doesn't mean you should ship everything. Let us move to some lightning question. They're fast, but they're lighter. All right. So if I was to ask you today, Like, you know, even in the latest in last week or so. What's your currently favorite AI tool? Um, Of course, I use Claude a lot. The one I actually ended up using quite a bit recently that I'm quite impressed with, just as far as output workflows, is Manus. There's something about how that's been wired and how I work with it that I really enjoyed. Actually, it was part of Meta and recently spun back out. I had to reset my account and all this stuff, but a pretty neat tool. I think I've done some things really the right way. And in this case, you like the output and the fact that it was almost like it was structured in a way? Yeah, well structured. I think the hand-holding of getting something done, the ability to pull in external SDKs and things to get something to be performed. I thought the image generation was quite good. It actually used GPT-2, I believe, for some of that. But it was seamless. And so it didn't feel like there was a lot of back and forth. And so I really enjoyed using that myself recently. - I was rather impressed with it. - Any AI tool in your non-work life? - Actually recently I had a problem with my bike. And so, you know, my derailleur broke. I had to buy a new derailleur and so I actually used Gemini, took a picture of my derailleur, found the right model, it's an older bike, almost 10 years old now, ordered it, got it back, I installed the derailleur and then you had to make some adjustments and so same thing, took a picture and do that. On the flip side... The one place I don't need AI is when I'm exercising, when I'm on my bike. I don't need it in my ear. And the reason why is because that is alone time for me, where I get to think about everything. I'd say that's where I build my judgment. It's where my creativity kicks in. And so I don't need AI there necessarily because it's me and my brain. And that's what I need. Quickly, if you had to pick today, let's say you talk about biking, mountain biking. If you had to pick e-bike or non-e-bike? I have both. So, uh, and, uh, I, so I do both. I say I alternate. So, uh, One day I'll use my regular mountain bike and grind up the mountain. I have a place in Truckee, so that's where I do my mountain biking. And it is hard, right? You're at altitude. You're climbing a lot of mountains and doing that. And then the next day I feel like doing a ride. And then I go back to e-mountain biking. And, you know, so I kind of alternate. I have some friends that are hardcore, no e-mountain bike whatsoever. And I think they're entirely missing out because you can go. [40:00] Yeah, you can discover harder. And so for exploration, it's absolutely fantastic. So I recommend both. That's what I do. Great. Final quick question. Um, If you again, I'll go again in the mountain bike or like, do you do any analysis at the at the end after of your rides? And like, you know, people go like perform like some amazing analysis of their ride. Yeah, I do. I use Strava actually quite a bit. So actually Strava has recently integrated some some intelligence where it tells you. how you did, some things you noticed. I think they've done it very well. I'm one of those guys that once I get back to the house, I sit down, look at my stats. How was my heart rate? Did I climb? Did I have my output correctly? Those kind of things. And so, yeah, I do spend a lot of time with that. And I really like the Strava AI because it says, this was your longest ride in a while. You really were in this zone and that zone. I think it works pretty well. So I do like it after my ride. Awesome. So great. Well, thank you. Thank you for your generosity. That's awesome. You're welcome. Thank you. Thanks for listening. And I hope you enjoyed the conversation as much as I did. If you're interested in connecting with more infrastructure and product engineer in person, join us at our next AtScale event, Product AtScale, in Menlo Park on October 28th. We'll hear about the latest AI innovation. From expert at meta, Nvidia, Microsoft, Intel, Pindrop and more. Go to the AdScale website to register and I hope to see you there.