Pendo

Build an AI-Native Team with a Company OS

This guide explains how product leaders can build an AI-native company by implementing a Company OS: a single GitHub repo mapping every team’s activities to opinionated 'skill' files that are uploaded into Claude’s organization settings so workers encounter the right workflow inside their existing tools. Jiaona Zhang (CPO at Laurel) describes how Laurel uses this structure to let non-engineering roles (even CSMs) ship to production, the creation of a full-time AI Ops role to scale workflows, and a captain model for end-to-end feature ownership with two review tracks (fast vs. full). Practical adoption tactics include company hackathons to break technical assumptions, daily Slack briefings with embedded skills, and a four-level framework for measuring AI maturity across teams.

Why AI agents need usage observability

You shipped an agent. It's live. Users can talk to it.

OpenAI PMs Ship 100K Lines via Harness Engineering

An interview and case study with Ryan Lopopolo (Member of Technical Staff at OpenAI) describes how OpenAI’s 'harness'—a repo-centric environment of docs, tests, lints, CI review agents and observability—lets product managers, designers and engineers produce production code without directly typing in an IDE. Lopopolo says PMs on his frontier team shipped roughly 100K lines of production code by authoring PRDs, tests, docs and harness rules; an internal Codex experiment produced about 1M lines of code and 250K lines of markdown prompts. The harness enforces non-functional requirements via tests (e.g., typography, module boundaries), runs persona-based review agents, and gives agents runtime observability to validate features. The piece frames the harness as the new locus of product work and argues product roles must learn to write machine-executable artifacts so agentic models can reliably build and validate features.