samarv/complex-first-product-design

Complex-First Product Design

This framework challenges the traditional MVP (Minimum Viable Product) approach by prioritizing the architecture of the most difficult use cases during the initial design phase. By solving for the "mission-critical" or "global" end-state first, you avoid the technical debt and architectural dead-ends created by optimizing solely for speed and simple use cases.

Core Principles

1. Reject the "Speed-Only" MVP

Traditional MVPs optimize for the shortest path to launch. In complex domains (FinTech, HR, Infrastructure), this leads to building the "wrong thing" technically. When you only design for simple cases, you make architectural assumptions that are nearly impossible to unwind when you eventually need to support enterprise-grade complexity.

2. Identify the "Ridiculously Hard" Use Case

Before writing code, identify the most complex version of the problem you will eventually need to solve.

• The Global Scale Case: Instead of one country, consider six countries with conflicting laws.
• The High-Stakes Case: Instead of a simple user, consider a hospital administrator where the software is mission-critical.
• The Scale Case: Instead of 10 users, consider 10,000 employees across a distributed organization.

3. "Go and See" (The Deep Dive)

Do not delegate domain expertise to specialists (legal, compliance, or tax) without first becoming a "world expert" in the details yourself.

• Spend 50% of your time in the "trenches" of the domain.
• Read the raw textbooks, tax laws, or technical specifications.
• Understand how data is communicated and changed at the source.

4. Design for the End-State, Ship the Subset

Designing for complexity does not mean building everything at once.

• Create a technical architecture that accommodates the most complex case.
• Once the foundation is solid, choose a subset of features to build and ship first.
• Ensure the 80% of the system is a shared platform, and the 20% of specificity is handled via configuration rather than custom code.

The Execution Workflow

1. Form a "Founding Team": Assign one entrepreneurial lead (usually an engineer capable of product thinking) and one design partner.
2. Cultural Immersion: The lead should spend 2–3 months working within the existing platform/org to understand the "system of record" and how other products integrate.
3. Pressure-Test Assumptions: Present the initial design to senior leadership. Ask: "What happens if we have 10,000 global users with this specific, difficult requirement?"
4. Iterative Pressure-Testing: Meet every two weeks with the DRI (Directly Responsible Individual) to review designs specifically for "interaction friction" for both small and large company admins.
5. Dogfooding: Use the product internally for at least 3 months before a public launch to identify where the "complex case" architecture fails in practice.

Examples

Example 1: Global Payroll System

• Context: A US-based company needs to expand payroll to the UK.
• The MVP Trap: Cloning the US payroll codebase and changing currency/tax fields for the UK.
• Complex-First Application: Designing a system that simultaneously considers the requirements of the UK, Germany, India, and Canada.
• Output: A global payroll platform where 80% of the logic is shared, and 20% is "country-specific configuration" managed by compliance teams rather than engineers.

Example 2: Time and Attendance Product

• Context: Building a tool to track employee hours.
• The MVP Trap: Building a simple "clock-in/clock-out" button for a 5-person office.
• Complex-First Application: Researching the requirements for hospital shift management, including mission-critical compliance and complex overtime laws across different states (e.g., California vs. Pennsylvania).
• Output: An architecture that handles life-critical shift scheduling and city-level tax variations, even if the first version only supports simple office workers.

Common Pitfalls

• Delegating the Deep Dive: Relying on a "tax expert" or "legal expert" to tell you what the product should do. You must understand the weeds yourself to make the right product trade-offs.
• Equating Design with Scope: Thinking you have to build the most complex feature on Day 1. The goal is to build an architecture that doesn't prevent that feature later.
• Horizontal Communication Bloat: Having too many people involved in the "founding" stage. Keep the team small (under 5 people) to maintain high decision-making tempo.
• Ignoring the Platform: Building a standalone vertical product that doesn't utilize the shared "system of record." This forces users to sync data manually, destroying the value of a compound startup.