Feature Flags as Learning Infrastructure: How Engineering Enables Lean Experimentation
Feature flags — also called feature toggles or feature switches — are a deployment pattern that separates code deployment from feature activation. Code that implements a new feature is deployed to production but kept inactive behind a flag; the flag is then turned on selectively for specific users, user segments, or percentage rollouts without any additional deployment.
The Portfolio View: How CPOs Balance Explore vs. Exploit Across Product Lines
The explore-exploit tradeoff is one of the foundational challenges in any adaptive system, from individual product teams to entire product portfolios. Explore too heavily and you generate learning without building on it; exploit too heavily and you optimize an existing capability past the point of relevance while missing the next wave of value creation.
Proto-Personas: How to Create User Alignments in Under an Hour
Traditional user personas are valuable tools when they are done well: research-grounded representations of real user segments, built from interview data, behavioral analytics, and observational research, that help teams make design and product decisions from a shared user model. They are also expensive, time-consuming, and frequently wrong in ways that are not apparent until late in the product development cycle.
Writing Better User Stories: Why You Need 'Hypothesis Statements' Instead
The 'As a user, I want [feature], so that [benefit]' format has been the default template for user stories in agile teams for over two decades. It has real virtues: it keeps stories focused on user needs rather than technical implementation, it creates a common language across design and engineering, and it makes stories small enough to fit within a sprint.
Instrumentation as a Feature: Why Measurement Must Be Built, Not Bolted On
In most product organizations, instrumentation is an afterthought. A feature is specified, designed, built, and shipped — and then someone realizes that there is no way to know whether it is working. A tracking request is filed, an analytics implementation is added in a subsequent sprint, and by the time the measurement infrastructure is in place, the feature has been live for three weeks and the baseline data needed to assess its impact is gone.
From Story Points to Outcomes: Coaching Teams to Measure What Matters
If you have been coaching agile teams for more than a few years, you have had this conversation: a team proudly reports that their velocity has climbed from 32 to 58 story points per sprint. Everyone in the room nods approvingly. But when you ask which user behaviors changed as a result of what the team shipped in those high-velocity sprints, the room goes quiet.
Measuring What AI Actually Changes: Behavioral Outcomes in AI-Augmented Products
AI features present a measurement challenge that most product teams are not prepared for. Traditional feature measurement is relatively straightforward: ship a feature, measure whether users engage with it, measure whether engagement correlates with the behavioral outcome the feature was designed to drive.
Managing the 'Shiny Object': How to Say No to Executives Using Data
Every product manager eventually faces the same scenario. You are mid-sprint, the team is executing on a validated roadmap, and an executive walks in — or sends a Slack message — with a new feature idea. It is urgent. It is strategic. It came from a customer meeting, or a competitor analysis, or an intuition from someone who has been in the industry for twenty years.
Facilitating Remote Design Sprints: Tools and Tactics for Distributed Teams
The conventional wisdom about Design Sprints and collaborative design sessions is that they work best in person. There is truth in this. The energy of a physical room — the ease of pointing at someone else's sketch, the ambient awareness of the group's energy, the informal conversations in the coffee queue between exercises — creates conditions for creative collaboration that are genuinely difficult to replicate digitally.
The Sense & Respond Organization: What It Looks Like When Lean UX Wins
Jeff Gothelf and Josh Seiden wrote the book Sense and Respond with a specific vision in mind: organizations that continuously observe the behavior of their users, form hypotheses about how to create more value for those users, test those hypotheses with the smallest possible experiments, measure the behavioral results, and update their products and strategies based on what they learn.
Why 'Velocity' Is a Vanity Metric (And What to Measure Instead)
Velocity is the most popular performance metric in agile product organizations and one of the least informative. Measuring velocity — the number of story points a team completes per sprint — tells you exactly one thing: how much work the team is producing.
The Truth Curve: How to Choose the Right MVP Fidelity for Your Idea
The term MVP — Minimum Viable Product — has been so thoroughly overused in product development conversations that it has nearly lost its meaning. In Eric Ries's original formulation in the Lean Startup, an MVP was the smallest possible experiment that would generate learning about the most critical assumption underlying a business idea.
The Two-Week Learning Cycle: Running Discovery and Delivery in Parallel
Dual-track agile is one of the most frequently misunderstood frameworks in modern product development. In theory, it runs discovery and delivery as parallel tracks — the team is simultaneously learning about what to build next while building what they already understand well enough to deliver.
Moving from Dates to Deliverables: How to Build an Outcome-Based Roadmap
The traditional product roadmap is a confidence trick. Not an intentional one — product managers and their stakeholders construct these documents in good faith, filling in quarter labels and feature names and deadline commitments with the sincere belief that they represent a plan. But they do not.
Organizational Design for Product Teams: When to Split, When to Combine
Organizational design decisions — how product teams are structured, what each team owns, how teams relate to each other — are among the most consequential decisions a CPO makes. They are also among the most difficult to evaluate and reverse: team restructuring is expensive in organizational energy and human disruption, which means most product leaders make these decisions too rarely, keep structures in place too long, and underestimate how much the current structure is shaping the product's evolution.
Dual-Track Agile: Managing Discovery and Delivery in a Single Sprint
In most product organizations, discovery and delivery operate as sequential phases: the team does research, then they design, then they build, then they ship. The problem with this model is that it is fundamentally at odds with the reality of how good software gets made. By the time engineering has finished building a solution that was designed six weeks ago, the user insights that informed that design are already stale.
Engineering Empathy: How 'Exposure Hours' With Users Change How Engineers Build
There is a reliable pattern in engineering teams that have watched a real user struggle with something they built: the engineers remember it. Not in the abstract way they remember a bug report or an analytics alert, but with the specificity and emotional resonance of having watched a person — a real person, not a persona — sit in front of their work and not understand it, or misinterpret it, or give up on it.
The Engineering Lead's Guide to Running Effective Sprint Reviews
The sprint review has an identity problem. In the Scrum framework, it is designed as an 'inspect and adapt' event: the team presents the increment of work completed in the sprint, stakeholders engage with it, and the team incorporates feedback into the product backlog for future work.
Why Engineers Should Co-Design: The Business Case for Technical Participation in UX
The traditional model for engineering's relationship to design is clear and comfortable: designers design, engineers implement. Designers produce specifications. Engineers receive specifications. The gap between the two is bridged by documentation — increasingly detailed, increasingly annotated, increasingly comprehensive documentation that attempts to capture every design decision so that nothing is lost in translation
Escaping the 'Build Trap': How Designers Can Lead via Outcomes
Melissa Perri's concept of the 'build trap' — the organizational condition in which teams measure success by features shipped rather than value created — is usually discussed as a product management problem. But designers are equally susceptible to it, and often more so. A designer whose primary deliverables are screens, flows, and specifications is in the build trap by definition.