Insights

The ProductLeadLab PRD: High-Stakes Edition

By Lisa Su — Product Lead for Startups & AI Platforms

1. The "So What?" (Executive Summary)

• The Friction: What is actually broken? Give me one sentence on the user pain point. (e.g., "Our KYC drop-off is at 40% because the manual upload step feels like a black hole.")

• The Business Lever: If we ship this, what’s the ROI? (e.g., "Capturing an extra $250k in monthly volume by moving the needle on completion rates.")

• The North Star: What is the one metric we’re holding ourselves accountable to? If it’s not measurable in Posthog, it doesn't exist.

2. The Moat (Strategic Context)

• The Target: Who are we winning for today? (e.g., "The High-Intent Borrower who needs liquidity in <24 hours.")

• Defensibility: Why this and not the other 50 things on the backlog? How does this make us harder to kill in the market?

• The RICE Logic: Briefly justify why this won the sprint. If the confidence is low but the effort is high, why are we here?

3. The Execution (Journey & Requirements)

• The "Happy Path": The 3-step "Perfect World" flow. Don't overcomplicate it.

• When Things Break: What happens when the API hangs or the user is on 3G? We need graceful failure, not a spinning wheel.

• The MVP Line: What is the "scrappy but not crappy" version? Draw a hard line between "Must Have" and "Nice to Have."

4. The Guardrails (Tech & Compliance)

• PII & Data: What sensitive data are we touching? We’re building for Fintech/HealthTech—don't let a feature launch break our SOC2/HIPAA posture.

• Instrumentation: List the exact events we’re tracking. If we can’t see the user behavior, we can’t iterate.

• Compliance Check: Does Legal/Risk need to sign off on this flow?

5. The Anti-Scope (Protecting the Runway)

• Hard No's: List the 3 things we are explicitly not building.

• The Goal: Prevent scope creep before it starts. If it’s not in the Happy Path, it’s a V2 problem. Let’s protect the engineering runway and ship.

Every startup founder starts with a vision. But by the time you hit your first $1M in funding, that vision often gets buried under a mountain of "nice-to-have" requests, "gut-feel" pivots, and a Jira backlog that looks more like a wish list than a strategy.

In the San Francisco Bay Area, where engineering talent costs upwards of $200k per head, building the wrong feature isn't just a mistake—it’s a fatal drain on your burn rate.

The $500,000 Hallucination

I’ve audited dozens of product roadmaps across Fintech, HealthTech, and E-commerce. The most common "silent killer" I see? The Ghost Feature. A Ghost Feature is a complex tool built because one loud "Potential Enterprise Client" asked for it in a sales call—but they never actually signed the contract. Or, it's a feature the founder "just knew" would be a game-changer, but currently has a 0.5% adoption rate among actual users.

A Ghost Feature is:

• Built for a “potential” enterprise client who never converts

• Driven by intuition rather than validated demand

• Used by less than 5–10% of your actual users

• It often takes 2–3 months to build.

If your team spent three months building that, you didn’t just lose time. You spent $500,000 of your investor’s capital on a hallucination, which it doesn’t move your business forward.Not because your team isn’t talented.But because no one enforced product discipline at the right moment.

Why This Happens (Even to Smart Teams)

Most early teams operate like this:

• Sales pushes for features to close deals

• Founders rely on instinct

• Engineering executes quickly

What’s missing is a system that answers one question: “Will this feature measurably improve our core metrics?” Without that, your roadmap becomes reactive instead of strategic.

The Shift: From Features → Outcomes

At high-performing product organizations, teams don’t build based on belief. They build based on evidence and expected impact.The shift is simple, but powerful. Stop asking “Should we build this?” Start asking “What outcome will this drive—and how do we know?”

The FAANG-Grade Solution: Ruthless Prioritization

At organizations like Google or Meta, we don't build because we "think" it’s a good idea. We build because the data leaves us no choice. To stop the bleed at your startup, you need to shift from "Building Features" to "Validating Outcomes."

Here is the 3-step audit I use to clean a bloated roadmap:

1. The Usage vs. Effort Matrix: If a feature took 4 weeks to build but hasn't been touched by more than 10% of your power users in the last 30 days, it is technical debt. Kill it or hide it.

Evaluate what you’ve already built.

• High effort + low usage = hidden technical debt

• If <10% of active users engage with a feature → question its existence

Action:
Deprecate, simplify, or remove low-impact features.

2. The RICE Score Reset: Reach, Impact, Confidence, and Effort. If you can’t put a hard number on the "Confidence" score (based on real customer interviews, not just "vibes"), the feature doesn't move to the top of the sprint.

Most teams use RICE incorrectly—especially “Confidence.”

• Reach → how many users are affected

• Impact → how much it moves key metrics

• Confidence → must come from real user signals

• Effort → actual engineering cost

If your confidence is based on “gut feel,” it’s not a high-priority feature.

Action:Require evidence (interviews, usage data, experiments) before prioritizing.

3. The "Moat" Test: Ask one critical question:Does this feature create a competitive advantage—or just catch you up?If it’s just parity, it should not dominate your roadmap.

Action:
Prioritize features that:

• differentiate your product

• improve retention or revenue

• compound over time

What Strong Product Leadership Looks Like

Your role as a founder is not to approve features. It’s to ensure:

• every sprint ties to a measurable outcome

• every feature has a clear reason to exist

• every engineering hour increases company value

If your team is shipping consistently—but your metrics aren’t improving—
that’s not an execution problem.It’s a product strategy gap.

From Busy Work → Real Traction

When you remove Ghost Features, three things happen quickly:

• Engineering velocity becomes focused

• Roadmaps become aligned with business goals

• Product decisions become faster and more confident

This is how startups move from:building features → building leverage

Stop Building, Start Scaling

Your job as a CEO isn't to be the "Chief Feature Officer." Your job is to ensure that every hour of engineering time is an investment in your company's valuation.

If your developers are busy but your metrics are flat, you don't have an engineering problem. You have a Product Leadership gap.

Is your engineering team shipping "noise" instead of "signals"?

I help founders move from "idea" to "defensible moat" by professionalizing their product culture in 30 days. Let’s stop the burn and start building what actually moves the needle.

[Book a 25-Minute Product Health Audit] → No pitch, just a roadmap "gut-check."

From Idea → Launch (Step-by-Step Guide for Founders)

By Lisa Su — Product Lead for Startups & AI Platforms

PHASE 1: IDEA VALIDATION

Before building anything, make sure your idea solves a real problem.

☐ Define your target user (who are they?)
☐ Clearly state the problem you are solving
☐ Write your value proposition (1–2 sentences)
☐ Talk to 10–30 potential users
☐ Validate demand (at least 30–50% show interest)
☐ Identify existing alternatives (competitors or manual solutions)

Goal: Confirm people actually want this before building.

 PHASE 2: MVP DEFINITION

Focus on the minimum features needed to deliver value.Your MVP should solve ONE problem extremely well.

☐ Define your core user journey
☐ List all features → cut 70% (keep only essentials)
☐ Identify your #1 core feature
☐ Create simple user flow (step-by-step experience)
☐ Decide success metric (e.g., signups, usage, matches)

PHASE 3: DESIGN (NO CODE REQUIRED)

☐ Sketch your product (paper or digital)
☐ Create wireframes (Figma or similar tools)
☐ Design 3–5 key screens only:

• Homepage

• User onboarding

• Core feature page

• Dashboard (optional)

Don’t overdesign — clarity > perfection.

PHASE 4: BUILD MVP (FAST)

Choose no-code tools to launch quickly: Timeline: 2–4 weeks max.

☐ Build frontend (Bubble / Framer / Webflow)
☐ Set up database (Airtable or built-in)
☐ Enable login/signup
☐ Build core feature only
☐ Set up basic analytics (user tracking)

PHASE 5: TEST WITH REAL USERS

Your users will tell you what to fix.

☐ Recruit 10–20 early users
☐ Watch how they use your product
☐ Ask:

• What confused you?

• What did you expect?

• Would you use this again?

Track:

• Drop-off points

• Engagement

• Feedback patterns

PHASE 6: ITERATE & IMPROVE

☐ Fix biggest usability issues first
☐ Improve onboarding experience
☐ Add only HIGH-impact features
☐ Refine value proposition
☐ Retest with users

Iteration > perfection.

PHASE 7: EARLY TRACTION

☐ Get first 50–100 users
☐ Build simple landing page
☐ Share on:

• LinkedIn

• Related user groups

• User communities

☐ Collect testimonials
☐ Track key metrics (usage, retention)

Traction is more important than features.

BONUS: MARKETPLACE (YOUR CASE)

If you’re building a marketplace (like Internship platform):

☐ Define BOTH sides:

• Supply (companies)

• Demand (students)
  ☐ Solve for ONE side first
  ☐ Manually match users at the beginning
  ☐ Focus on liquidity (active users on both sides)

Marketplaces succeed when both sides get value quickly.

FINAL CHECK

Before launch, ask yourself:

☐ Does this solve a real problem?
☐ Can users understand it in 10 seconds?
☐ Does it deliver value immediately?

If YES → 🚀 Launch it.