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.
Estimating in Uncertainty: How to Give Honest Estimates Without Losing Stakeholder Trust
Software estimation is one of the most persistently dysfunctional practices in engineering. The dysfunction has a familiar shape: stakeholders request a date, engineers provide a best guess, the best guess becomes a commitment, the commitment becomes a deadline, and the deadline is missed for reasons that were foreseeable but not incorporated into the original estimate.
Saying No to a Bad Requirement: An Engineering Lead's Framework for Constructive Pushback
Engineering leads occupy an unusual position in the product organization. They are the last line of defense against requirements that are technically impossible, technically inadvisable, or technically correct but product-counterproductive.
Getting Developers to Care About Users: The Power of 'Exposure Hours'
The empathy gap between designers and engineers is one of the most consistent sources of product quality problems in software teams. Designers who regularly talk to users develop intuitions about user behavior, pain points, and mental models that shape every decision they make — from information architecture to error message wording to the sequencing of multi-step workflows.
Design Systems as Products: Treating Your Internal Tools Like External Software
Design systems have become one of the most significant investments in modern product organizations. A well-maintained design system — a shared library of components, patterns, tokens, and guidelines that product teams draw on to build consistent user interfaces — reduces design and engineering duplication, speeds up feature development, and creates a coherent user experience across a complex product surface.
Facilitating a 'Design Studio': Getting Your Whole Team to Sketch Solutions
Design is not the exclusive domain of people with 'Designer' in their title. This is one of the most important and least internalized principles in Lean UX. When a product team treats design as something that happens in a separate room, by a separate person, before being handed to the team for execution, two things go wrong: the team loses the diversity of perspective that produces genuinely creative solutions, and the people who ultimately build the product develop no ownership over the design decisions they are executing.
Coaching the 'Definition of Done': Why Output Completion Is Not Enough
In most agile teams, 'done' means the same thing: the code is written, the tests pass, the pull request is reviewed and merged, and the feature is deployed to the staging environment. This is a reasonable definition of technical completion. It is not a sufficient definition of value delivery.