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.
The Death of the Handoff: Why 'Over the Wall' Design Is Failing
The handoff is a ritual that every designer who has worked in a product organization knows intimately. You spend days or weeks creating detailed specifications — annotated wireframes, interaction flow documents, component-level design files with red-lines and spacing notes — and then you hand all of it over the wall to engineering.
Building a Culture of Learning: How Product Leaders Create Psychological Safety for Failure
Lean UX is built on a premise that most organizations find genuinely difficult: that teams should be rewarded for learning, not just for delivering. Learning requires failure — not strategic failure, not execution failure, but the productive failure of a well-designed experiment that produced an unexpected result.
Cross-Functional Team Health: The Signals Every Agile Coach Should Monitor
In agile coaching, team health is both a leading indicator and a lagging one. It is a lagging indicator because the team's current health reflects the cumulative effect of past decisions — about how the team was formed, how work is structured, how leadership behaves under pressure, and whether the organization's stated commitment to agile practice is matched by its actual governance decisions.
The CPO as Chief Experimenter: Modeling a Learning Culture from the Top
Culture follows behavior. This is the most important and most frequently ignored principle in organizational change management. Product leaders who want their organizations to run experiments, embrace failure as learning, and make evidence-based decisions routinely attempt to create this culture through proclamations, process mandates, and values statements.
Coaching Upward: How to Get Executives to Support Agile Transformation
The most common reason agile transformations fail is not that teams cannot learn agile practices. Teams adapt quickly — the ceremonies, the frameworks, the vocabulary are learnable within a few sprints. The reason transformations fail is that the organizational context in which teams operate does not change. Funding models remain project-based, which means teams are measured against delivery schedules rather than outcomes.