Key Operating Values
How we actually work: Design Thinking, validation, and team expectations
These operating values translate the guiding principles into daily practice. They answer the question: “How do we actually work?” I have found that teams who internalize these values make better decisions faster, with less friction and fewer costly mistakes.
- Design Thinking
- Expectations for Engineers and Designers
- Validation
- Product Discovery with Opportunity Solution Trees
- Customer-Centric Approach
- Customer Models
- Market Speed
1. Design Thinking
Product teams perform best when they approach problems through a human-centered, iterative lens—cycling through discovery, ideation, prototyping, and validation rather than marching linearly from requirements to release.
For Humans at Its Roots
At the root of every business problem is a human problem needing to be understood. Business is the exchange of value to humans—get to the human factor and you can understand and shape solutions to your problems.
Consider the tree metaphor in the diagram:
| Business Problem (Branches) | Human Root |
|---|---|
| ”How can we lower support calls?" | "How can we keep our product from frustrating users?" |
| "How can we increase conversion?" | "What’s the easiest way to help users figure out if our product fits their needs?" |
| "How can we improve SEO numbers?" | "In what circumstances do our users search for our services?” |
The beauty of taking a design approach is that everything starts with the human factor. You base your entire discovery process on a real need about real people. If you try to build a business that’s not grounded on that, you’re building the business on sand.
When you start with understanding the people who will use (or purchase) your offering, it’s a lot easier to build and test the right prototypes that can maximize desirability, feasibility, and viability.
Business problems are visible branches, human problems are roots
This is why Design Thinking isn’t just a process—it’s a philosophical commitment to solving human problems first, trusting that business outcomes will follow.
The Five Steps as a Thinking Framework
Design Thinking is often presented as a sequential process: Discover → Define → Ideate → Prototype → Validate. But I have found that treating it as a rigid phase-gate model misses the point.
The five steps are better understood as modes of thinking that you cycle through continuously:
| Step | Mode of Thinking | Key Question |
|---|---|---|
| Discover | Research and observation | What’s actually happening for customers? |
| Point of View | Synthesis and framing | What’s the core problem we’re solving, for whom? |
| Ideate | Divergent exploration | What are all the ways we might solve this? |
| Prototype | Tangible expression | How can we make this idea real enough to test? |
| Validate & Test | Learning from feedback | Does this actually work for customers? |
On any given iteration—even a two-week cycle—you should be touching elements of each step. You’re discovering new information from the last release. You’re refining your point of view based on what you learned. You’re ideating on solutions. You’re building something. You’re testing it.
Design Thinking as a continuous cycle with POV at center
The framework’s value isn’t in telling you what phase you’re in. It’s in prompting you to ask: “What are we neglecting?”
If you’re deep in building but haven’t talked to a customer in weeks, you’re neglecting discovery. If you’re drowning in research but haven’t prototyped anything, you’re neglecting tangible expression. If you’re shipping but not measuring, you’re neglecting validation.
Point of View as the Anchor
Notice that in the framework, Point of View sits at the center. This is deliberate. Your POV—a clear articulation of the problem, the goal, and the users—anchors everything else.
Without a defined POV, discovery becomes aimless wandering. Ideation produces solutions to the wrong problems. Prototypes lack focus. Validation measures the wrong things.
The POV should be:
- Specific: “Field technicians waste 15 minutes per install on WiFi connectivity troubleshooting” not “Users have connectivity problems”
- Human-centered: Framed around the person’s experience, not your system’s behavior
- Stable enough to guide work, flexible enough to evolve: As you learn, refine your POV—but don’t abandon it every week
Divergent and Convergent Thinking
Design Thinking involves two distinct modes that must both have room to breathe:
Divergent thinking expands possibilities. It’s brainstorming, exploring, generating options. The goal is quantity and variety—no idea rejected too early.
Convergent thinking narrows toward decisions. It’s evaluating, prioritizing, choosing. The goal is clarity and commitment.
I have found that teams must budget for both explicitly. Without protected space for divergence, you converge too early on mediocre solutions. Without structured convergence, you explore forever and never ship.
In practice:
- Budget divergent time in ideation sessions, design reviews, and early research
- Budget convergent time in planning, prioritization, and go/no-go decisions
- Signal which mode you’re in: “We’re brainstorming right now—no critiques yet” vs. “We need to decide by end of meeting”
Divergent and convergent thinking
If your product feels derivative or incremental, you probably aren’t giving divergent thinking enough room. If your team feels chaotic or unfocused, you probably aren’t converging decisively enough.
2. Expectations for Engineers and Designers
Product teams perform best when engineers and designers aren’t just executors of PM specifications—they’re co-owners of the problem who bring their own ideas to the table.
Bringing E+D to Discovery
In an ideal world, every member of the trio participates directly in customer research. The engineer who watches a user struggle with a workflow understands the problem differently than the engineer who reads a summary. The designer who hears a customer’s frustration firsthand designs with more empathy than one working from secondhand descriptions.
I have found that direct exposure to customers softens team members to the user’s experience in ways that abstracted problem statements cannot.
But here’s the practical reality: this is hard to pull off. Developers, in particular, often struggle to get deep work done when their day is fragmented by meetings and calls. Forcing engineers into every interview can hurt productivity without proportional benefit.
The practical minimum:
- Lead engineers and designers should attend live customer sessions when possible—especially during early discovery for a major initiative
- All team members should watch recordings or review summaries of key interviews
- Feedback and pain points should be shared in accessible formats (documented in Dovetail, summarized in team channels)
The goal isn’t perfect attendance at every session. It’s ensuring that the people building the product have some direct connection to the people using it.
Providing Context for Better Decisions
Participation in discovery isn’t just about listening—it’s about enabling better decisions during execution.
When engineers understand the problem deeply:
- They make better trade-off decisions without needing PM involvement
- They spot edge cases the PM might have missed
- They suggest simpler technical approaches that still solve the core problem
When designers understand the problem deeply:
- They make UX decisions aligned with user mental models
- They push back on requirements that don’t actually serve user needs
- They identify opportunities the PM hadn’t considered
Context compounds. The more E+D understand about users and business, the less the PM needs to specify, and the better the product becomes.
Contributing Beyond Hard Skills
The highest-performing teams I’ve worked with share a characteristic: engineers and designers don’t just execute well within their domains—they contribute to product direction.
This happens when:
- E+D are immersed enough in customer problems and business objectives that they generate their own ideas
- The PM creates space for E+D contributions during planning and review
- Good ideas are adopted regardless of who suggested them
When it’s working well, you see designers proposing business model tweaks based on what they learned in research. You see engineers suggesting feature simplifications because they understand what users actually need. You see the trio functioning as a brain trust, not a relay race.
When it’s not working, you see designers waiting for specs, engineers waiting for designs, and PMs doing all the product thinking alone.
3. Validation
Product teams perform best when they validate ideas with real customer feedback before committing significant resources—and recognize that not all validation is equally trustworthy.
The Hierarchy of Validation
Not all evidence carries equal weight. I have found that this hierarchy reflects the reliability of different validation sources:
| Level | Validation Source | Reliability | Use When |
|---|---|---|---|
| 1 | Customer behavior (built and measured) | Highest | Post-launch learning |
| 2 | Customer feedback on working prototype | High | Pre-launch validation |
| 3 | Customer feedback on mockups/concepts | Medium | Early design validation |
| 4 | Stakeholder opinion (proxy for customers) | Low | When direct access unavailable |
| 5 | Team gut instinct | Lowest | Emergency decisions only |
The goal is to operate as high on this hierarchy as time and resources permit.
When Proxies and Gut Are Acceptable
Sometimes you can’t get direct customer feedback in time. A decision needs to be made. The prototype isn’t ready. The users are unavailable.
In these moments, stakeholder opinion and gut instinct can bridge the gap—but they’re not substitutes for real validation. They’re temporary scaffolding.
I have found that the danger is when proxy feedback becomes the only feedback. Teams start believing that stakeholder enthusiasm equals customer enthusiasm. They ship based on internal consensus rather than external validation. The gap between what the team thinks users want and what users actually need widens.
The rule: Proxy and gut can bridge short gaps. But maintain the habit of regular, direct customer feedback so the gaps stay short.
Keep User Feedback Regular and Habitual
Validation isn’t a phase you complete—it’s a habit you maintain.
I have found that the best cadence is at least one customer interaction per week for each PM. This keeps you in contact with reality. It prevents the drift that happens when you’re heads-down building for months.
This doesn’t mean formal usability tests every week. Customer interaction can be:
- Quick prototype reviews
- Support call listening
- In-app survey responses
- Conference conversations
- Advisory board check-ins
The format matters less than the consistency. Weekly touchpoints keep customer understanding fresh and prevent the dangerous confidence that comes from isolation.
4. Product Discovery with Opportunity Solution Trees
Product teams perform best when they use a structured framework to connect business outcomes to customer opportunities to solution ideas to testable experiments. The Opportunity Solution Tree (OST), developed by Teresa Torres, provides this structure.
The OST Framework
An Opportunity Solution Tree visualizes the path from business outcomes to validated solutions:
| Level | What It Contains | Key Question |
|---|---|---|
| Outcome | Business result you’re pursuing (SMAC: Specific, Measurable, Achievable, Customer-connected) | What change do we want to see? |
| Opportunities | Customer needs, pain points, desires that connect to the outcome | What customer problems, if solved, would drive this outcome? |
| Solutions | Concrete ideas for addressing opportunities | How might we solve these customer problems? |
| Experiments | Tests to validate assumptions about solutions | How do we know if this solution will work? |
The tree structure forces you to make explicit the connections between what the business wants and what customers need. A solution that doesn’t connect to a real opportunity, which doesn’t connect to a real outcome, probably isn’t worth building.
Opportunity Solution Tree connects outcomes to experiments
How We Use OSTs in Practice
I have found that OSTs work best as collaborative workshop artifacts, not documents created by PMs in isolation.
The process:
- Collect feedback: Roll up customer feedback that’s been placed on different user journeys
- Plot on OST: In a Miro board (or similar), map opportunities from the journey feedback onto the tree
- Connect to business outcomes: Ensure each opportunity branch connects to a clear outcome
- Generate solutions: Brainstorm solution ideas under relevant opportunities
- Identify experiments: For promising solutions, define assumption tests
This workshopping happens quarterly for major planning cycles, or ad-hoc when aligning stakeholders on which problems to solve.
The visual nature of the OST makes alignment tangible. Stakeholders can see why you’re prioritizing certain opportunities—they connect to the outcomes everyone cares about.
Real OST showing 120% NRR outcome through retention drivers
Prioritizing Opportunities
When the tree has multiple opportunities, how do you choose?
I have found that a combination of pain intensity and business viability drives good prioritization:
- Pain intensity: How acute is this problem for customers? How frequently do they encounter it? How much do they care?
- Business viability: If we solve this, does it actually drive the outcome we need? Is it aligned with our strategy?
In practice, we vote as a team on opportunities that score high on both dimensions. This isn’t a mechanical scoring exercise—it’s a structured conversation that surfaces different perspectives and builds alignment.
Outcomes vs. Outputs on the OST
Here’s where the OST enforces outcome thinking. Look at the example tree:
- Output framing: “Build self-signup feature” ← This is a solution
- Outcome framing: “30% would download App // 75% would finish onboard” ← This is a measurable experiment result
The output tells you what to build. The outcome tells you what success looks like.
When you frame experiments as outcomes, something powerful happens: if the outcome isn’t reached, you keep experimenting—even if it means moving beyond the original solution idea. The goal isn’t to ship “Members Can Self SignUp.” The goal is to achieve the adoption metrics that drive the business outcome.
This is how OSTs prevent teams from celebrating shipped features that don’t actually work.
5. Customer-Centric Approach
Product teams perform best when they define success through the customer’s lens—measuring whether customers can accomplish their goals, not just whether features were delivered.
Milestones Framed Through Customer Lens
The language teams use reveals their orientation. Compare:
| Output-Focused Milestone | Customer-Focused Milestone |
|---|---|
| ”Launch self-signup feature" | "30% of target users complete self-signup within first week" |
| "Ship new onboarding flow" | "Time-to-first-value reduced from 3 days to 1 day" |
| "Release mobile app v2.0" | "Field technicians complete installs 20% faster using new app" |
| "Deploy dashboard redesign" | "Users find key metrics without support requests” |
The output framing lets the team declare victory when code ships. The customer framing holds the team accountable for whether the code actually helped.
I have found that this language shift changes how teams plan. When you know you’ll be measured on “install time reduced by 20%,” you make different design decisions than when you’re measured on “shipped install redesign.”
Reducing Friction vs. Improving Metrics
A subtle trap: teams often optimize for engagement metrics (MAU, session length, feature usage) rather than customer success.
Engagement metrics can be gamed or inflated without actually helping users. A confusing interface might increase time-on-task. A notification-heavy app might boost opens without delivering value.
I have found that the better question is: “What friction are we removing from the customer’s journey?”
Friction-focused goals:
- Reduce steps to complete core workflow
- Decrease time to value for new users
- Eliminate errors that require support intervention
- Remove confusion that causes abandonment
These goals align customer success with business success. Users who experience less friction are more satisfied, more likely to expand usage, and more likely to recommend your product.
Frequent Customer Access
Customer-centricity isn’t a mindset—it’s a practice. And practices require frequency.
I have found that the ideal is at least one customer interaction per week per team. This might be:
- User interview
- Usability test
- Support call listening
- Prototype review
- Advisory board session
- Conference or event conversation
The format varies. The frequency doesn’t.
When customer contact is sporadic—once a quarter, or only during “research phases”—teams drift. They start building for imagined users instead of real ones. Assumptions calcify into beliefs. By the time they validate, they’ve invested too much to pivot.
Weekly contact keeps assumptions soft and pivots cheap.
6. Customer Models
Product teams perform best when they maintain a shared, documented understanding of their customers—a “customer model” that gives the entire organization context about who they’re serving.
What a Customer Model Is
A customer model is a summary of current pain points and needs for a customer segment at a moment in time. It’s a generalization of specific journey research, distilled into a format that team members and stakeholders can quickly absorb.
Think of it as the answer to: “If I’m joining this team or this project, what do I need to understand about our customers?”
A customer model typically includes:
- Segment definition: Who is this customer? What characterizes them?
- Key journeys: What are they trying to accomplish?
- Major pain points: Where do they struggle?
- Unmet needs: What would make their experience dramatically better?
- Context and constraints: What shapes their behavior that we might not assume?
Keeping Models Fresh
Customer models decay. Markets evolve. Needs shift. What was true 18 months ago may be misleading today.
I have found that updating customer models 1-2 times per year for major segments maintains relevance without creating excessive overhead. Good triggers for updates:
- Annual planning cycles
- Major market shifts
- Significant product changes that alter customer journeys
- Persistent mismatch between model and observed behavior
From Noise to Signal: Building Customer Understanding
Customer feedback comes from everywhere—support tickets, sales calls, NPS surveys, user interviews, social media, stakeholder opinions. Most of it is noise. The job of continuous discovery is to transform this noise into signal.
The system I’ve found effective:
- Collect feedback across channels: Support, sales, interviews, surveys, analytics
- Map to user journeys: Place feedback within the context of what customers were trying to do
- Synthesize periodically: Build reports on biggest issues per audience segment
- Update journey maps and opportunity trees: Let patterns inform where you focus
- Refresh customer models: Periodically distill journey learnings into updated models
This flow ensures that individual data points don’t get lost, but also don’t drive decisions in isolation. Signal emerges from patterns across multiple sources.
Customer feedback from multiple audiences flows through pipeline
7. Market Speed
Product teams perform best when they recognize that speed isn’t just about efficiency—it’s about staying aligned with a constantly moving target.
Product-Market Fit Degrades Over Time
Product-market fit isn’t a destination you reach and then maintain. Markets evolve. Customer needs shift. Competitors adapt. New technologies create new expectations.
A product that perfectly fit the market two years ago may be drifting out of fit today—not because it got worse, but because everything around it changed.
I have found that the only way to detect drift is to stay continuously close to customers. Your product becomes part of their journeys. You watch whether it’s meeting their needs or creating new pain points. You notice when expectations shift because you’re in regular conversation.
Teams that do customer research only during “discovery phases” miss the drift. They ship, go heads-down on the next project, and emerge months later to find the market has moved.
Speed Creates Learning Opportunities
Speed isn’t valuable for its own sake. Speed is valuable because it creates more opportunities to learn and adjust.
Consider two teams building the same feature:
- Team A spends 6 months building a comprehensive solution, launches, discovers major assumptions were wrong
- Team B spends 2 weeks building a minimal version, tests at a conference, discovers wrong assumptions, adjusts, iterates three more times in the same 6 months
Team B learns faster because they ship faster. Each shipment—even incomplete ones—generates feedback that shapes the next iteration.
When Speed Prevented Waste
I’ll share a concrete example. We were building a new app flow and had assumptions about what users needed. We tested a quick version with a customer at a conference before the flow was complete.
The immediate feedback changed our goal for the next sprint. We learned that certain flows we’d planned to build weren’t needed—and that something we hadn’t prioritized was actually critical.
If we’d waited until the “complete” version to validate, we’d have wasted cycles building the wrong things. The early, incomplete test saved us significant time.
This is why input as you go—even if you aren’t fully done—is paramount. The cost of testing early is a bit of awkwardness showing incomplete work. The cost of testing late is building the wrong thing.
Speed and Innovation Correlation
Across companies I’ve worked with, I’ve observed a consistent pattern: the teams that ship most frequently are also the teams that innovate most effectively.
This isn’t because fast teams are inherently smarter. It’s because the fast feedback loops enable them to discover what works through iteration rather than prediction. They try more things, learn what resonates, and double down on winners.
Slow teams have to bet bigger because they learn less often. Big bets occasionally pay off—but more often, they miss, and the slow cycle time means recovery takes forever.
The math favors speed. More iterations = more learning = better products.
Summary: Operating Values in Practice
| Value | Core Principle | Daily Application |
|---|---|---|
| Design Thinking | Cycle through all modes on every iteration | Ask “what are we neglecting?” regularly |
| E+D Involvement | Bring builders close to customers | Minimum: recordings and summaries; ideal: live participation |
| Validation Hierarchy | Direct customer feedback beats proxy opinion | Maintain weekly customer touchpoints |
| Opportunity Solution Trees | Connect outcomes → opportunities → solutions → experiments | Quarterly OST workshops; vote on pain + viability |
| Customer-Centric Framing | Define success through customer lens | Milestones as customer outcomes, not shipped features |
| Customer Models | Maintain shared understanding of customers | Update 1-2x/year; synthesize from journey research |
| Market Speed | Fast iteration enables learning | Ship incomplete work to validate early; weekly customer contact |
These values reinforce each other. Design Thinking provides the framework for how to approach problems. E+D involvement ensures the whole team internalizes customer context. Validation hierarchies guide how to test assumptions. OSTs structure the connection between business goals and customer needs. Customer-centric framing ensures you’re measuring what matters. Customer models keep everyone aligned. And speed ensures you’re learning fast enough to stay relevant.