Pillar 1: Principles

Key Takeaways

‍

• THE OAK'S LAB WAY is built on five principles that serve as decision-making frameworks, not motivational statements. They're the first pillar of our product development methodology for a reason: before we talk about roles, activities, or tools, we align on how the team makes decisions.
• Each principle targets a specific recurring conflict in product teams: user value vs. internal convenience, business outcomes vs. feature velocity, simplicity vs. over-engineering, focus vs. scattered priorities, and structure vs. creative freedom.
• Shared principles let distributed teams make consistent decisions without constant escalation. This matters even more when working with an external partner, because you can't rely on hallway conversations to keep everyone on the same page.
• These principles become most critical when team growth outpaces the capacity to coordinate effectively.

‍

Five Principles That Prevent Expensive Debates

‍

We built THE OAK'S LAB WAY on five principles that influence how our teams work. Each one addresses a specific type of decision product teams face repeatedly and provides clear guidance when trade-offs get real.

‍

1. User Obsession

‍

User Obsession means understanding what users actually need and prioritizing their success over internal convenience. This principle resolves a fundamental tension in product development: between building what we think users need and building what users actually need.

‍

How our teams apply this

‍

We validate assumptions with real user feedback before committing development resources. Success gets measured by user behavior (adoption and retention) rather than by the number of features shipped. When a solution reduces user friction but requires more development effort, this principle tips the scale toward the user every time.

‍

What this delivers

‍

Higher retention rates, fewer costly pivots, and stronger growth, because the products we build solve problems users actually have rather than problems we assumed they had.

‍

2. Outcomes Over Outputs

‍

This principle connects every product development effort to measurable business outcomes and eliminates work that doesn't meaningfully contribute to them. It shifts the team from being busy to creating real value.

‍

How our teams apply this

‍

We establish clear success metrics tied to business objectives before starting development. We track user adoption and revenue impact rather than feature completion. And we regularly audit features to eliminate functionality that isn't contributing to user or business success.

‍

What this delivers

‍

Faster progress toward business objectives and more efficient use of development resources. When you're measuring what matters rather than counting what shipped, priorities get a lot clearer.

‍

3. Stay Lean

‍

Stay Lean means identifying the simplest solution that achieves the desired outcome, then iterating based on real usage data. This is about eliminating waste, not cutting corners.

‍

How our teams apply this

‍

We build the simplest version that validates core assumptions, then expand based on user behavior. We eliminate unused features. We choose approaches that minimize complexity while maintaining quality. And we regularly simplify workflows that have become unnecessarily complicated over time.

‍

What this delivers

‍

Faster time-to-market, lower development costs, and products that remain manageable as they scale. There's a compounding benefit here: every bit of unnecessary complexity you avoid today is complexity you don't have to maintain tomorrow.

‍

4. Relentless Focus

‍

Relentless Focus is the discipline to maintain strategic alignment when every stakeholder has compelling priorities. It's about limiting work in progress and ensuring that every effort supports the same objectives.

‍

How our teams apply this

‍

We maintain clear product roadmaps with explicit rationale for each item. We say no to feature requests that don't align with current priorities. And we protect teams from context-switching by batching similar work and maintaining consistent sprint objectives.

‍

What this delivers

‍

Higher-quality execution on the initiatives that matter most, because teams aren't fragmenting their attention across competing priorities. The discipline to say "not now" to a good idea is often more valuable than the idea itself.

‍

5. Discipline Fosters Innovation

‍

This one sounds counterintuitive, but it holds up across hundreds of projects. Teams that follow consistent processes have more mental bandwidth for creative problem-solving. Discipline handles the routine decisions automatically, freeing cognitive resources for challenges that actually require innovation.

‍

How our teams apply this

‍

We use standardized approaches for common activities (code reviews, deployment, user research) so teams can focus creative energy on product-specific challenges. We maintain quality standards that prevent technical debt from consuming future development capacity. And we establish clear communication patterns that minimize coordination overhead.

‍

What this delivers

‍

Teams dedicate more time to solving genuinely difficult problems because they're not constantly managing process issues or reinventing how to handle routine work.

‍

What This Actually Delivers

‍

Companies operating under these principles consistently outperform those relying on ad hoc decision-making:

‍

Faster decision-making. Clear principles eliminate lengthy debates about common trade-offs. Teams don't relitigate the same questions every sprint.

‍

Better market fit. Products prioritize user value over internal preferences and measure success by business results, not features shipped.

‍

Efficient resource allocation. Development resources flow toward high-impact activities rather than work that feels productive but doesn't move the needle.

‍

Independent teams with strategic consistency. Teams operate autonomously while maintaining alignment because everyone understands and applies the same decision-making frameworks. This is especially important across distributed teams and when working with external partners.

‍

Manageable technical debt. Disciplined approaches to quality and lean development prevent the accumulation of shortcuts that slow down future work.

‍

Why Growing Companies Can't Afford Ad Hoc Decisions

‍

Growing companies face a specific challenge: you've proven product-market fit, raised funding, and now face expectations for significant growth. The constraints pile up quickly:

‍

Your team is growing. You're hiring fast, but new team members need time to be productive and find their place in the team.

‍

Your priorities are multiplying. Multiple stakeholders have urgent priorities competing for the same resources and time.

‍

Your capacity is finite. The team lacks bandwidth for everything leadership wants to accomplish.

‍

These are exactly the moments when principle-based product development becomes critical. You can't add more approval layers because that kills velocity. But you also can't let every team make independent decisions without guardrails, or chaos ensues. Shared principles give teams the framework to make consistent decisions without constant escalation.

‍

These principles are one pillar of our broader product development methodology, which also covers roles, activities, and tools for building products as a mature organization.

‍

What This Means in Practice

‍

Here's how principles actually show up in our day-to-day work:

‍

1. Principles as tiebreakers in sprint planning

‍

When competing priorities surface during sprint planning or backlog refinement, our teams reference these principles by name. A stakeholder pushes for a feature that would require significant engineering effort? The team uses Outcomes Over Outputs to evaluate whether the feature actually moves the metrics that matter, or if there's a leaner path to the same business result. This turns what could be a 30-minute debate into a structured conversation with a shared vocabulary.

‍

Validate by observing how trade-off decisions get resolved. If principles are working, team members can articulate why they chose one path over another, rooted in these frameworks rather than in who pushed the hardest.

‍

Red flag: Decisions regularly come down to who has the strongest opinion or the most seniority, rather than an evaluation against shared principles.

‍

2. User Obsession as a check on assumptions

‍

Before committing engineering resources to a feature, our Product Leads validate assumptions through user research, prototype testing, or data analysis. User Obsession isn't a vague commitment to "caring about users." In practice, it means the team has a specific process for catching the gap between what we think users need and what they actually need, and that process runs before development starts, not after launch.

‍

Validate by checking whether recent features went through some form of user validation before development began. If validation is happening consistently, User Obsession is functioning as a principle. If it's skipped when timelines get tight, it's decorative.

‍

Red flag: The team ships features based on stakeholder requests or internal assumptions without validating demand. Discovery feels like a nice-to-have rather than a prerequisite.

‍

3. Stay Lean as a guard against over-engineering

‍

Our Tech Leads use Stay Lean to evaluate technology choices and architectural decisions. The question isn't "what's the best possible solution?" but "what's the simplest solution that gets us to the desired outcome?" This prevents the kind of premature complexity that slows teams down: building for theoretical scale before you've validated the product, or introducing a new framework when the existing one works fine.

‍

Validate by reviewing recent technology decisions. If the justification centers on solving a current, concrete problem, the principle is working. If justifications lean on "best practices," "future-proofing," or "industry standard" without connecting to a specific constraint, the decision wasn't lean.

‍

Red flag: The team has recently introduced new technologies that have added complexity without addressing a concrete, current limitation.

‍

Common Questions About Our Principles

‍

Q: How are these different from the company values we already have on our website?

‍

A: Company values tend to be broader cultural statements like "customer first" or "bias for action." They're fine for recruiting or marketing, but they don't resolve the argument between your CTO and CPO about whether to refactor the authentication system or ship a new dashboard feature. Our product development principles are specific enough to address real trade-offs. "Validate with users before committing engineering resources" provides clear guidance in that discussion. "Customer first" does not. If your principles can't change a decision, they're not functioning as principles.

‍

Q: We already run Scrum. Why do you need principles on top of that?

‍

A: Most frameworks focus primarily on delivery: sprint cadence, ceremonies, and velocity tracking. What they don't cover is how to decide what goes into the sprint in the first place, or how to resolve competing priorities when the backlog is larger than the team can handle. Principles like Outcomes Over Outputs and Relentless Focus sit above delivery work. They determine what gets built and why, while Scrum determines how and when. The most common gap we see is teams running solid Scrum execution but treating prioritization and discovery as entirely ad hoc.

‍

Q: What happens when two principles conflict with each other?

‍

A: This happens regularly, and it's actually a sign the principles are working. Stay Lean might suggest shipping a quick solution, while User Obsession demands more polish because testing showed users struggle with the minimal version. The principles aren't meant to eliminate judgment. They narrow the decision space. Instead of debating from scratch, the team discusses which principle is most relevant to the current context. That conversation takes minutes instead of consuming a full planning session.

‍

Q: How do these principles work when our team is collaborating with OAK'S LAB?

‍

A: This is exactly why principles are the first pillar of THE OAK'S LAB WAY. Before we discuss roles, activities, or tools with a new client, we align on how the team makes decisions. When your internal product team and ours both operate under the same frameworks, decisions remain consistent whether they're made in your office or ours. Shared principles are arguably more important with an external partner because you can't rely on hallway conversations to keep everyone aligned.

‍

Q: How long before principles actually change team behavior?

‍

A: Expect a few months of intentional reinforcement before they become habitual. The key is to reference them in real decisions, not just post them on a wiki page and move on. Teams that explicitly cite a principle when resolving a trade-off in sprint planning internalize it much faster. You'll know they're working when someone says, "We should stay lean and cut feature X from this release" without being prompted.