SLShenoy Labs
HomeProjectsArticlesAboutContactSupport

Shenoy Labs

Hybrid product studio across projects, research, and practical systems.

Think. Learn. Solve.

HomeProjectsArticlesAbout
Privacy PolicyTermsRefund PolicySupportContact

© 2026 Shenoy Labs. All rights reserved.

← All articles
Lean product research cover image with calm card-based layout motif.
Research3 min read · February 22, 2026

Lean product research without a UX team

The minimal toolkit I use to validate ideas before writing a single line of code.

productresearchvalidationlean

Most solo builders skip validation entirely. They code for three months, launch to crickets, and conclude the market does not want it.

The market almost always wants something — you just built the wrong version.

Here is the minimal research process I run before writing any code.

The problem with skipping research

The instinct is: I know this problem, I have it myself.

The trap: the version of the problem you experience is rarely the most common version other people experience.

Your specific context — your tools, your workflow, your existing knowledge — shapes the problem in ways that differ from your target user.

Research does not mean months of user interviews. It means enough signal to distinguish what you assume from what is true.

The four-question framework

Before any build, I try to answer four questions:

  1. Who has this problem acutely? Not "who might benefit" — who is frustrated right now?
  2. What are they currently doing instead? The tool they use today is your real competitor.
  3. What makes the current solution painful? This is your product's reason to exist.
  4. Would they pay, or just use for free? This shapes the whole business model.

You can answer all four with a weekend of structured research.

The toolkit (zero cost)

Reddit threads

Search [problem] site:reddit.com. Sort by top. Read comments, not just posts.

Comments reveal the granular frustrations that posts abstract away.

Product Hunt reviews (one star)

Go to your category on Product Hunt. Sort by one-star reviews on existing tools. These are your design brief.

"Currently using" questions on Indie Hackers

Post one question: "What tool do you use for X? What do you wish it did differently?"

Thirty answers is enough data to find patterns.

Competitor support forums

Every successful tool has a community with a feature-request section. That list is your roadmap.

What counts as validation

You do not need ten paying customers before you build. You need:

  • At least five people who described the problem without you prompting them
  • At least two who said the current solution is painful, not merely imperfect
  • A clear hypothesis about what you will build that you can state in one sentence

That is a validated idea. Now build the smallest possible version and find out if your hypothesis was right.


The goal is not to eliminate risk. The goal is to take the right risks.

Written by Lakshman Shenoy

Published February 22, 2026

Recommended next reads

Why building in public is the best career move you haven't madeNext.js performance patterns that actually move the needle

Newsletter

Occasional notes on projects, research, and useful links.

Get in touch

Send a note, suggest a topic, or support the work.

Send a noteSupport
Suggest a topic