Guiding Principles
Four principles that form the foundation of effective product management
These four principles form the foundation of effective product management. They are not abstract ideals—they are practical orientations that I have found consistently separate high-performing product teams from those that struggle. When teams internalize these principles, decisions become clearer, conflicts resolve faster, and products improve measurably.
- Customer Obsession Drives Every Decision
- Business Outcomes Define Success
- Fast, Iterative Delivery Creates Advantage
- Collaborative Ownership Removes Barriers
1. Customer Obsession Drives Every Decision
Product teams perform best when they recognize a fundamental asymmetry: business goals are visible and constantly reinforced, but customer needs require deliberate work to uncover.
Every company has revenue targets, growth metrics, and strategic priorities that are discussed in all-hands meetings, written into OKRs, and referenced in executive reviews. These business objectives are important—they keep the lights on and fund the work. But their visibility creates a gravitational pull that can distort product decisions if left unchecked.
Customer needs, by contrast, are hidden. They exist in the messy reality of how people actually work, the workarounds they’ve developed, the frustrations they’ve normalized, and the goals they’re trying to achieve. Understanding these needs requires active investigation. It requires getting out of the building, watching users struggle, and asking the right questions.
The true path forward lies in alignment. The best product decisions don’t sacrifice business viability for customer happiness or vice versa. They find the intersection where solving customer problems is the business strategy. This alignment isn’t always immediate—sometimes you invest in customer value that pays off over quarters, not days—but it must be the north star.
Customers Are Not Product Designers
A critical distinction: customers can articulate their needs, but they are not inventors. Users will suggest features constantly—“add a button here,” “make it work like this other tool,” “why can’t I just…”—but these suggestions are symptoms, not diagnoses.
I have found that the most effective teams dig beneath feature requests to understand the underlying story. What was the customer trying to accomplish? What step in their workflow broke down? What would success look like from their perspective?
This is where journey mapping becomes essential. Rather than treating customer feedback as isolated data points, effective teams roll up all feedback through the lens of specific customer journeys. These journeys might be:
- A workflow within your software (onboarding, completing a core task, troubleshooting an error)
- A workflow spanning multiple tools (your product as one step in a larger process)
- A real-world activity that your software supports (a field technician completing a service call, a marketer launching a campaign)
There is enormous noise in customer feedback—feature requests, complaints, suggestions, support tickets, NPS comments, sales call notes. Journey mapping transforms this noise into signal by asking: “Where does this feedback fit in the customer’s story? What step is breaking down? How important is that step to the customer’s ultimate goal?”
Unmapped problems become noise without journey context
When you map feedback to journeys, patterns emerge. You might discover that five seemingly unrelated complaints all trace back to the same moment of friction. You might realize that a loudly-requested feature would only help customers who are already succeeding, while a different investment would unblock customers who are failing silently.
The Hierarchy of Customer Evidence
Not all customer input carries equal weight. Product teams perform best when they maintain a clear hierarchy:
- Behavioral data — What customers actually do (most reliable)
- Contextual observation — Watching customers work in their environment
- Story-based interviews — Customers recounting specific past experiences
- Stated preferences — What customers say they want (least reliable alone)
This hierarchy doesn’t mean ignoring what customers tell you. It means triangulating. When stated preferences align with observed behavior and fit coherently into journey context, you have strong signal. When they conflict, dig deeper.
The Hot Take Worth Considering
Teresa Torres, whose Continuous Discovery Habits has shaped modern product practice, offers a candid admission: “There’s truth to criticism that thought leaders write about an ideal world that most product people don’t live in.” (Source)
This honesty matters. Customer obsession is the goal, but most teams operate with constrained research budgets, limited user access, and pressure to ship. The principle isn’t about perfection—it’s about orientation. Even with constraints, teams that try to understand customers outperform teams that assume they already know.
2. Business Outcomes Define Success
Product teams perform best when they measure success by the changes they create in customer behavior, not merely by the features they ship.
This distinction—outcomes over outputs—has become a mantra in product management circles. But I have found that many teams misunderstand what it actually demands.
What an Outcome Actually Is
An outcome is a measurable change in human behavior that drives business results. This definition, articulated by Josh Seiden, is more demanding than it appears. It requires teams to answer: “What will customers do differently if we succeed?”
Not “customers will have access to a new feature.” Not “customers will rate us higher in surveys.” But: “Customers will complete their first project within 24 hours instead of 72.” Or: “Customers will invite a teammate within the first week.” Or: “Customers will reduce their time spent on manual data entry by 40%.”
These behavioral outcomes are leading indicators of the business results you care about (retention, expansion, efficiency). They are also actionable—you can observe them, measure them, and design specifically to influence them.
The Trap of Output Obsession
When teams focus primarily on outputs—features shipped, story points completed, releases deployed—they optimize for activity rather than impact. A team can ship consistently for six months and move no meaningful metric because they were building the wrong things, or building the right things poorly.
Output metrics feel safe because they’re controllable. You can always ship something. Outcome metrics feel risky because they depend on customer response, which you can’t fully control.
But this discomfort is the point. Product management is fundamentally about placing bets on what will change customer behavior. Avoiding outcome measurement doesn’t eliminate the risk—it just hides it until the quarterly business review.
The Nuance: Outputs Still Matter
Here’s where I diverge slightly from the purist position. The LogRocket team makes a fair point: “Don’t fall into the trap of ignoring outputs altogether… Most innovations don’t come from careful planning but from learning on the go.” (Source)
I have found that the resolution is this: every output should be framed as a learning opportunity about an outcome.
You don’t wait until you’ve perfectly defined your outcome before shipping. You ship because shipping is how you learn. But each shipment should have a hypothesis attached: “We believe that by building X, we will see behavior Y change, which will indicate progress toward outcome Z.”
The goal isn’t to achieve the outcome with your first shipment. The goal is to learn whether your assumptions about the outcome are correct, then adjust.
Who Owns the Outcome?
The PM’s job is to articulate the proposed outcome based on deep understanding of user needs. This is non-delegable. If the PM can’t clearly state what behavioral change the team is pursuing, the team is navigating without a compass.
But articulation isn’t enough. The entire trio—PM, Lead Designer, Lead Developer—must agree to aim for this outcome. It becomes the team’s shared definition of “done.”
This matters because “done” should never mean “we shipped our original plan.” Done means one of two things:
- We achieved the outcome (or made measurable progress toward it), or
- We learned that our assumptions were wrong and deliberately pivoted to a different outcome
Teams that define done as “shipped the spec” will ship the spec even when evidence suggests it isn’t working. Teams that define done as “reached the outcome or learned” stay responsive to reality.
Definition of Done — outcome achieved or assumption invalidated
3. Fast, Iterative Delivery Creates Advantage
Product teams perform best when they ship something tangible every two weeks—not because speed is inherently virtuous, but because shipping is learning.
Why Two Weeks?
The two-week cadence isn’t arbitrary. It’s short enough to maintain urgency and prevent scope creep, but long enough to produce meaningful work. More importantly, it forces a discipline that improves planning quality.
When you commit to shipping every two weeks, you can’t avoid the question: “What can we actually learn or de-risk in this cycle?” This question transforms planning conversations. Instead of debating the ideal feature set for a quarterly release, teams ask: “What’s our riskiest assumption right now? What’s the smallest thing we could build to test it?”
This doesn’t mean every two-week cycle produces a customer-facing release. Some cycles produce prototypes, internal tools, technical foundations, or research synthesis. But something tangible ships—something that can be reviewed, critiqued, and learned from.
The Connection to Outcomes
Fast iteration and outcome-focus reinforce each other. When you’re clear on the behavioral outcome you’re pursuing, you can design small experiments to test whether you’re making progress. When you ship frequently, you get faster feedback on whether your outcome hypothesis is correct.
The opposite pattern—slow, large releases—couples tightly with output thinking. When you only ship quarterly, the pressure to include everything intensifies. Features get added to justify the wait. The release becomes a bet-the-quarter moment rather than one step in an ongoing learning process.
When Two Weeks Feels Impossible
Some work genuinely can’t ship in two weeks. Infrastructure migrations, platform rebuilds, and complex integrations have longer critical paths. In these cases, the principle adapts: what can we validate about our approach in the next two weeks?
Maybe you can’t ship the migration, but you can ship a proof-of-concept for the trickiest component. Maybe you can’t launch the integration, but you can test the authentication flow with a partner. The goal is always to maintain the learning cadence even when the delivery cadence must extend.
Quality and Speed Are Not Opposites
A common objection: “If we ship every two weeks, quality will suffer.” I have found the opposite is true when the scope adjusts appropriately.
Quality suffers when teams commit to large scopes with tight timelines. The two-week discipline prevents this by forcing scope negotiation upfront. “We can’t build the full feature in two weeks” becomes “What subset delivers the most learning?” This constraint actually protects quality because it prevents the last-minute corner-cutting that happens when ambitious plans meet immovable deadlines.
Two-week learning cycle
4. Collaborative Ownership Removes Barriers
Product teams perform best when the core decision-making group has strong, balanced voices—and when accountability is embraced rather than diffused.
The Core Trio Structure
I recommend a core decision-making team of:
- 1 Product Manager — owns the problem definition and outcome articulation
- 1 Lead Developer — owns technical approach and feasibility assessment
- 1 Lead Designer — owns user experience and usability validation
This trio is the product’s brain trust. They should be in constant communication, jointly own discovery activities, and make decisions together.
Supporting roles—UX researchers, QA engineers, additional developers, data analysts—contribute expertise to this core group but don’t dilute the decision-making structure. This isn’t about excluding people; it’s about ensuring clear accountability and preventing design-by-committee paralysis.
Each person in the trio must have a strong voice. When engineers feel unheard, they disengage from product thinking and become ticket-takers. When designers feel overruled, they produce work they don’t believe in. When PMs feel undermined, they lose the authority to make hard calls. The trio model works because it gives each discipline genuine influence, which earns genuine commitment.
Scaling the Trio
At scale, strict trios become harder to maintain. Teams grow. Specialization increases. Multiple workstreams run in parallel.
The adaptation I’ve found effective: the trio becomes your “lead” representatives from each function, with teammates supporting them. A squad might have 1 PM, 1 Lead Designer (with 1-2 supporting designers), and 1 Lead Developer (with 3-4 supporting engineers). The leads participate in trio decisions; the supporting team members execute within that direction.
This preserves the benefits of small-group decision-making while allowing teams to scale.
The Accountability Question
Here’s the sticky reality: in many organizations, the PM is held accountable for team performance regardless of decision-making structure. When the product fails, the PM takes the heat. When it succeeds, credit disperses.
This asymmetry is often unfair, but it’s also often true. The question is how to navigate it.
I have found that effective PMs embrace accountability while facilitating genuine shared decision-making. This means:
- Solicit real input — Not performative consultation, but genuine incorporation of engineering and design perspectives into product direction
- Use the customer voice as authority — When decisions are grounded in customer evidence (journey maps, behavioral data, interview insights), they become less about opinion warfare and more about interpreting shared reality
- Own the outcome publicly — When decisions prove wrong, the PM shouldn’t hide behind “the team decided.” Take responsibility, then course-correct together
The paradox: the more willing you are to own failures, the more your team will share ownership of decisions. Blame-deflection fractures teams; accountability-embracing unifies them.
The Cultural Variable
I want to acknowledge that organizational culture shapes how these principles apply. In some companies, PMs have significant authority—they can make calls and expect execution. In others, PMs can only lead through influence, navigating complex stakeholder dynamics and earning buy-in for every decision.
Neither model is inherently right. What matters is clarity. Know what authority you actually have, design your processes accordingly, and don’t pretend to have authority you lack (it destroys credibility) or fail to exercise authority you possess (it creates confusion).
In influence-driven environments, the trio model becomes even more important. When you can’t mandate, you must align. A united trio—PM, Lead Dev, Lead Designer speaking with one voice—carries far more influence than a PM advocating alone.
Culture shift — from siloed functions to collaborative ownership
Summary: The Four Principles in Practice
| Principle | Core Belief | Practical Implication |
|---|---|---|
| Customer Obsession | Business goals are visible; customer needs require work to uncover | Map all feedback to customer journeys to separate signal from noise |
| Outcome Focus | Success is behavioral change, not features shipped | Define “done” as outcome achieved or assumption invalidated |
| Fast Iteration | Shipping is learning | Ask “what can we de-risk in two weeks?” not “what can we build?” |
| Collaborative Ownership | Strong voices prevent blind spots | Core trio (PM + Lead Dev + Lead Designer) makes decisions; PM embraces accountability |
These principles reinforce each other. Customer obsession surfaces the right problems. Outcome focus ensures you’re solving them meaningfully. Fast iteration accelerates learning. Collaborative ownership brings diverse expertise to bear.
When all four are operating, product work feels coherent. When any is missing, dysfunction emerges—building the wrong things, shipping without learning, or fragmenting into siloed functions that optimize locally while failing globally.