What Makes Customer Obsession Powerful

At its core, the biggest benefit of customer obsession is that it keeps teams grounded in the real needs of their users. It’s easy to get caught up in trends, internal politics, or our own biases about what we think customers want. Customer obsession forces us to step outside those assumptions and truly listen to the people we’re building for.

When building a product, it’s easy to get lost in the weeds of features, bugs, and deadlines. Customer obsession reconnects teams to the “why” behind what they’re building. Teams that understand the problems they’re solving build better products—and do it with urgency and clarity. This mindset must inform prioritization and long-term vision. Knowing what truly moves the needle for customers is how you build a product that lasts.

Customer obsession also prevents over-engineering. Often, when presented with a blank canvas, teams start to overcomplicate. I’ve been in many conversations where we were trying to solve a problem with unnecessary complexity. At one point, we debated building a rules engine to handle a dozen edge cases. But when we stepped back and asked, “What’s the actual problem we’re solving?”—we realized only two of those cases would realistically occur. That insight let us ship a simpler solution in weeks instead of spending months designing for hypotheticals.

Lastly, this mindset ensures teams aren’t building in a vacuum—hoping that customers will eventually show up. It grounds teams in real-world pain points. That’s especially critical in the early stages, when you’re still hunting for product-market fit. By staying close to the customer, teams can iterate faster and pivot more confidently.

Where It Starts to Break Down

Customer obsession is a powerful value—but like any value, taken to the extreme, it can backfire.

From Proactive to Reactive

It starts when teams become reactive. When every decision is driven by the latest piece of feedback or the loudest customer voice, product development turns into a game of whack-a-mole. Instead of building toward a long-term vision, teams chase requests, patch holes, and deliver features that don’t always fit the broader strategy.

Over time, this leads to a fragmented product. The roadmap becomes a mirror of urgency, not insight. It’s essential to balance genuine customer needs with a strong product point of view—one that understands when to say “not yet.”

When Teams Get Left Behind

Customer obsession can also take a toll internally. When “the customer is always right” becomes the default, teams fall into a service posture—dropping everything to respond to asks, skipping tech debt paydown, and deprioritizing their own needs.

Morale suffers. Engineers stop feeling like collaborators and start feeling like a support queue. Burnout sets in, and ironically, the quality of what gets delivered to customers declines.

One of my favorite mental models here is Jocko Willink’s idea of leadership capital. You earn it by building trust and making sound decisions. But when you consistently trade your team’s focus and well-being for short-term customer appeasement, you burn through that capital fast—and lose the trust that makes long-term success possible.

Customer empathy doesn’t mean saying yes to everything. It means understanding your customers well enough to say “not now”—and trusting your team to hold that line.

Loudest ≠ Most Important

Another failure mode: letting urgency override strategy. It’s easy to prioritize the enterprise client pushing for a custom workflow or the user threatening churn. But chasing the loudest voice often means overlooking quieter patterns that represent broader impact.

This can skew your roadmap, introduce one-off features, and erode UX consistency. You might please a few accounts, but the product loses cohesion—and the long-term vision suffers.

Being customer-obsessed doesn’t mean being customer-led. It means being customer-informed, and strategic about what you act on.

When Boundaries Erode

Especially in early-stage startups, customer obsession can blur boundaries. Every customer feels existential. Teams stretch themselves thin—responding to every fire drill, making last-minute changes, or shipping quick fixes that compromise architecture.

It all comes from a good place: wanting to deliver value fast. But it’s not sustainable. Deep work disappears. Strategy is replaced by scramble. And systems begin to crack under the weight of constant urgency.

The irony? Customers might be happy today—but missed deadlines, brittle infrastructure, and team attrition catch up quickly.

True customer obsession means building systems—and a team—that can serve customers not just today, but sustainably over time.

Lessons for Founders and Product Leaders

Customer obsession isn’t inherently bad—it just needs boundaries, clarity, and intentionality. If you want it to be a healthy part of your culture, it helps to define what it actually means inside your org.

First: it’s not heroics. It’s not about dropping everything, skipping lunch, or jumping on Slack at 9pm to fix something that wasn’t scoped properly. Healthy customer obsession is strategic, not reactive.

Obsess over the right signals. Anecdotes are useful—but they’re not the whole story. Look for patterns in customer behavior, common threads across feedback, and needs that align with your product vision. One urgent email shouldn’t derail months of intentional work.

Balance advocacy with sustainability. Yes, we’re here to serve customers. But we can’t do that well if we burn out our teams or build systems too fragile to scale. Advocate for the customer, but protect the team.

And finally: empower your ICs. Engineers, designers, and PMs should feel confident saying, “This isn’t the right time,” or “Let’s solve this in a way that scales.” If customer obsession becomes a top-down directive, it stops being empathy—and starts being pressure.

Done right, customer obsession aligns teams around purpose. Done poorly, it erodes the very systems that serve your customers. Choose wisely. If you’re seeing signs of imbalance, you’re not alone. Let’s build better cultures — together.

For every Rails class we shipped, we had to trace requirements, detail business logic and interfaces, and map out risk controls — all in a format that is audit-ready for FDA review.

This post kicks off a series called ‘AI Prompts I Wish I Had’, sharing prompts that could’ve made our engineering workflows smoother while building regulated software.

The goal of this series is to offer practical, high-context AI prompts that help teams move faster toward an FDA submission — without compromising quality, traceability, or compliance.

🧠 The Prompt

# SDS Documentation Prompt

You are a SaMD software engineer generating regulatory documentation.
I will provide you with one or more Ruby/Rails classes used in a regulated
Software as a Medical Device (SaMD) product.

Based on the code I provide, generate a **Software Design Specification (SDS)** entry suitable
for inclusion in a Design History File (DHF).

Your output should include:

1. **Component Name**  
2. **Purpose / Role in the System**  
3. **Description of Logic / Behavior** – Provide detailed explanations including:
   - Specific business rules with exact criteria and thresholds  
   - All possible status values/enums with definitions of what each represents  
   - Step-by-step process flows with decision points  
   - Data validation rules and constraints  
   - Error handling and edge cases  

4. **External Interfaces** – Include:
   - Specific API endpoints and GraphQL mutations/queries  
   - Database table names and key fields  
   - Session storage keys and data structures  
   - Third-party service integrations  

5. **How It Satisfies Specific SRS Requirements** – Expand on:
   - Security controls with implementation details  
   - Audit logging mechanisms and what data is captured  
   - Regulatory compliance features  
   - Data integrity safeguards  

6. **Design Considerations** – Detail:
   - Security flags and their enforcement mechanisms  
   - Session state management and validation logic  
   - Performance optimizations and their rationale  
   - Safety mechanisms and fail-safes  

7. **Traceability Notes** – Include:
   - Specific risk control implementations  
   - Audit trail mechanisms (PaperTrail, analytics events, etc.)  
   - Logging infrastructure for regulatory compliance  
   - Known technical limitations with business impact  

**Additional Requirements:**
- **No abbreviations or “etc.”** – List all status values, rules, and conditions explicitly  
- **Implementation details** – Show actual code snippets for critical security or compliance logic  
- **Business rule explanations** – Explain the medical/regulatory rationale behind complex rules  
- **Security deep-dive** – Cover authentication, authorization, session management, and data protection  
- **Audit compliance** – Document all logging, tracking, and audit trail mechanisms required for regulatory review

Format the output in Markdown with headers for each section. Be comprehensive, technical, and audit-ready.

Example usage:

The system we are documenting is located within `packs/authentication`.

I want documentation covering the login and session management flow for users.  

How does the system validate credentials?
How is the session established and managed?
What audit trails are recorded for access attempts?

Like anything generated with AI it requires a careful review, but this prompt can help you quickly generate a starting point for a comprehensive SDS entry that meets FDA requirements. It ensures that you cover all necessary aspects of the system’s design and behavior, making it easier to compile your Design History File.

Let me know if this is helpful — and if you want me to share the next prompt in this series.

If you’re building a SaMD or working in a regulated domain and want help tuning your dev workflows with AI, let’s talk.