Product Discovery: Validating Ideas Before Building

The biggest waste in software development isn't building the wrong thing poorly—it's building the wrong thing really well. After seeing teams spend months building features nobody wanted, we developed a product discovery process that validates ideas before writing production code.

The Problem with "Just Build It"

We've all been there:

An executive has a "great idea"

Engineering spends 3 months building it

Launch day arrives... crickets

Feature is used by <5% of users

Team morale suffers

The issue isn't bad engineering—it's skipping discovery. We were solving problems nobody had or building solutions nobody wanted.

Our Discovery Framework

We now use a structured 4-phase discovery process before committing to major features.

Phase 1: Problem Validation (Week 1)

**Goal:** Confirm the problem is real and worth solving.

Activities:

**User Interviews (5-8):** "Tell me about the last time you struggled with [problem]"

**Data Analysis:** Look for signals in support tickets, analytics, churn reasons

**Competitive Research:** How do competitors handle this? Why might users switch?

**Output:** A problem statement: "Small business owners spend 4+ hours/week on [task] because [reason], leading to [negative outcome]."

Red Flags:

Can't find users who experience the problem

Problem is rare or edge case

Problem severity is low

Existing solutions are "good enough"

If we see these, we stop. No amount of clever engineering can solve a non-problem.

Phase 2: Solution Exploration (Week 2)

**Goal:** Generate and evaluate potential solutions.

Activities:

**Brainstorming:** What are 5+ ways to solve this problem?

**Assumption Mapping:** What must be true for each solution to work?

**Feasibility Check:** Quick technical spike—can we actually build this?

**User Sketches:** Show lo-fi concepts to users, gather reactions

**Output:** 2-3 promising solution directions with trade-offs documented.

Example:

*Problem:* Users struggle to find relevant content in our knowledge base.

*Solutions Explored:*

1. AI-powered search (high impact, medium effort, AI risk)

2. Better tagging/categorization (medium impact, low effort, maintenance burden)

3. Personalized recommendations (high impact, high effort, cold start problem)

Phase 3: Prototype & Test (Weeks 3-4)

**Goal:** Test the solution with real users before building production version.

Activities:

**Build lo-fi prototype:** Figma, HTML mockup, or even a slide deck

**Usability testing (8-10 users):** "Think aloud" sessions

**Measure key behaviors:** Do users understand it? Can they complete the task? Do they see value?

**Output:** Validated (or invalidated) solution with specific improvements identified.

What We Learned:

**Lo-fi is enough:** Users can evaluate value from sketches. Don't waste time on polish.

**Test with strangers:** Your team and friendly customers are biased. Recruit participants who don't know your product.

**Watch, don't ask:** Users are terrible at predicting their behavior. Watch what they do, not what they say they'll do.

**Set success criteria in advance:** "At least 7/10 users must complete the task in <2 minutes" prevents rationalization.

Phase 4: Build vs. Buy vs. Partner (Week 4)

**Goal:** Decide if we should build this in-house.

Activities:

**Build cost estimate:** Realistically, how long to MVP? To mature feature?

**Integration research:** Are there tools/APIs we can integrate instead?

**Opportunity cost:** What else could we build with this time?

**Output:** Go/No-go decision with rationale.

Real Example:

*Feature:* Video conferencing in our app

*Discovery outcome:*

Problem validated: Users want to meet without leaving our platform

Solution tested: Embedded video worked well in prototype

**Decision: Don't build.** Zoom/Google Meet integrations solved the problem at 10% of the cost. We built a deep integration instead.

Case Study: Payment Reminders

Let me share a recent discovery process that saved us from a big mistake.

Initial Idea

"Our invoicing feature should have automated payment reminders to improve collections."

Seemed obvious, right? Every invoicing tool has this.

Phase 1: Problem Validation

Interviews with 8 customers revealed:

6/8 already had their own reminder process (CRM workflows, assistants)

2/8 didn't send reminders at all (didn't want to appear pushy)

0/8 mentioned this as a pain point unprompted

**Red flag.** We were solving a problem most users didn't have or had already solved.

Phase 2: Solution Exploration

We dug deeper. What *related* problems did they have?

Tracking *which* invoices to follow up on (80% mentioned this)

Knowing *what to say* in follow-ups (60%)

Understanding *why* payments were delayed (55%)

Aha. The problem wasn't automation—it was *information*.

Phase 3: Prototype & Test

We built a prototype of a "Follow-up Dashboard" showing:

Overdue invoices prioritized by amount and days late

Suggested follow-up scripts based on customer relationship

Payment delay reasons (requires customer input)

Tested with 10 users. Result: 9/10 said they'd use it, 7/10 said it was more valuable than automated reminders.

Phase 4: Decision

Build time: 2 weeks (vs 6 weeks for full automation)

Value: Higher (users actually wanted this)

**Decision: Build the dashboard, skip automation (for now)**

Outcome

Feature launched, used by 78% of invoicing customers within first month. 4.7/5 feature satisfaction score.

If we'd skipped discovery and "just built" payment reminders, we'd have spent 6 weeks on something few people wanted.

Common Objections

"Discovery slows us down"

Disagree. It prevents wasted development time. 4 weeks of discovery vs. 12 weeks building the wrong thing? Discovery is faster.

"Our customers are telling us what they want"

Customers tell you their problems, not solutions. "I want a faster horse" ≠ "I need a car."

"Competitors have this feature"

Competitors also ship features nobody uses. Be customer-driven, not competitor-driven.

"We need to move fast and iterate"

Iterate on prototypes, not production code. Production iteration is expensive and hurts trust.

Discovery Checklist

Before committing to any major feature:

✅ Have we talked to 5+ customers about the problem?

✅ Can we quantify problem severity with data?

✅ Have we explored 3+ solution directions?

✅ Have we tested a prototype with 8+ users?

✅ Have we considered build vs. buy vs. partner?

✅ Have we set measurable success criteria?

If any answer is "no," do more discovery.

Conclusion

Good product discovery isn't about process for its own sake—it's about building the right thing. The right thing, even if imperfectly built, will beat a perfectly-built wrong thing every time.

Invest in discovery. Your engineers, your users, and your company will thank you.