How do you evaluate a product idea?

In this order, because the order does the work: (1) who specifically is it for, and what breaks in their week without it — named person, named pain, not a demographic; (2) has anyone paid, or clearly said they would, with money or a signed intent attached; (3) what is actually shipped and running versus what only exists in the deck — I want the URL, not the roadmap; (4) what is the one number that tells you whether it's working, and what is that number today; (5) the verdict. Most people evaluate ideas by asking whether the idea is good. That question has no answer. Whether a specific person will pay a specific price to make a specific pain stop — that question has an answer, and you can usually get it in a week.

What should I ask before hiring product help?

Four things. What have you personally shipped, and can I see it running — not a case study PDF, a live thing. What's your first deliverable and when do I get it, in days. What would make you tell me not to hire you, because anyone who can't answer that is selling hours, not judgment. And what does it cost, flat, before we start. On my side those answers are published: 50+ products shipped over 15 years, the free 30-minute strategy call gives you a concrete written next step, the $2,500 AI Readiness Assessment lands a written roadmap on day 14 and gets credited in full against any build within 90 days. If someone can't answer all four inside one email, the engagement will feel exactly like that email.

How do I know if my MVP is worth continuing?

Ask what would have to be true for this to work, then check whether any of it is true yet. Continue if: someone outside your friend group has paid or is actively trying to, users come back without a reminder from you, and you can name the one workflow that keeps them. Stop or reset if: every user came from your own outreach, retention past week two is effectively zero, and the plan for growth is a feature that isn't built. The reset is usually not a rebuild — it's the same code aimed at a narrower audience. Killing the audience is cheaper than killing the product, and founders almost always try it in the wrong order.

What are the red flags when evaluating an early-stage product?

The five that end an evaluation fast: the target customer is a demographic instead of a person you can name and reach; zero money and zero signed intent after months of building; the demo is a deck and the product is a Figma file; the founder can't state one metric they check weekly; and the roadmap has more items than the product has users. One more from 2026 specifically — the whole thing was generated by an AI coding tool, nobody senior has read it, and it's about to take real customer data. That last one is not a reason to stop building. It's a reason to run a security pass before launch, which is a much cheaper week than the alternative.

How can 30 minutes be enough to evaluate a product?

Because the questions are ordered by how much they can kill. Thirty minutes is not enough to design your product, audit your code, or write your strategy — it's enough to find the load-bearing assumption and check whether it's holding. Nine times out of ten the answer surfaces in the first ten minutes, and the remaining twenty are spent deciding what to do about it. The long version of this work exists too: a two-week paid assessment produces a 15-25 page written roadmap. But you should not buy the long version until the short version has told you which problem you actually have.

What should I have ready before a product strategy call?

Three things, and none of them are slides. A live link to whatever exists, even if it's ugly and half-broken — especially then. The honest revenue number, including zero. And the one question you'd most like answered, written down, because calls without a stated question drift into a pleasant conversation that changes nothing. If you bring those three, thirty minutes is genuinely enough to leave with a decision instead of a vibe.

Justin McKelvey

Fractional CTO · 15 years, 50+ products shipped

Product Leadership • 8 min read • Published Jul 31, 2026

How I Evaluate a Product Project in 30 Minutes

Quick Answer

I evaluate a product project in five passes, in this order: who it's for and what breaks without it (5 minutes), whether anyone has paid (5), what's actually shipped versus deck-ware (10), the one metric that tells the truth (5), and the verdict — kill, focus, or ship this week (5). The order matters more than the questions. Each pass can end the evaluation, so the cheapest answer arrives first. Most product projects don't die of bad ideas; they die of an unnamed customer and an unchecked number.

Reviewed July 2026 · Author: Justin McKelvey — 15 years building products, 50+ shipped, former CTO at an AI startup

TL;DR: This Is the Whole Framework, and I'd Rather You Ran It Yourself

Every couple of weeks now, a founder emails asking if I'll take a look at their product and tell them what to fix. Sometimes it's an app their team has been building for eight months. Sometimes it's a thing they shipped last weekend with an AI coding tool. The ask is always some version of the same sentence: can you give us some product-improvement advice?

Yes. And here's the framework I use, in full, before you book anything — because the calls where the founder has already run it on themselves are worth about triple the ones where they haven't.

I've been building products for 15 years and shipped 50-plus of them. Some worked. Plenty didn't, and the ones that didn't are where this sequence came from. I've run it as a CTO, as a Head of Product, and now on calls with founders I've never met, where I get thirty minutes and no context. It's five passes. Each one can end the evaluation early, which is the entire point — you want the cheapest possible answer first.

Minutes 0–5: Who Is This For, and What Breaks Without It

First question, always: name the person. Not the segment — the person. "Independent event planners running 8 to 20 events a year who currently track vendors in a spreadsheet" is a person. "Small businesses" is a wish.

Then the harder half: what breaks in that person's week if your product disappears tonight? If the honest answer is "nothing, they'd go back to the spreadsheet and be mildly annoyed," you don't have a product problem. You have a pain problem, and no amount of design polish fixes it.

I'm listening for specificity and speed. Founders who've talked to their customers answer both questions in about eleven seconds. Founders who've been building in a room answer with a market-size number, which is not an answer to either question. That tell alone predicts most of what I'll find in the next twenty-five minutes.

Minutes 5–10: The Money Question

Two versions, and I ask them in this order:

Has anyone paid? Real money, from someone who isn't related to you or invested in you. Any amount.
If not — has anyone said they would, in a way you could hold them to? A signed letter of intent, a deposit, a "send me the invoice when it's ready." Enthusiasm doesn't count. Enthusiasm is free, which is exactly what it's worth.

Zero on both, after months of building, isn't fatal — but it relocates the entire conversation. We're no longer evaluating a product. We're evaluating whether you've ever tested the assumption the product is built on. That's a better problem to have at minute eight than at month eighteen.

The founders who hate this question are the ones who most needed it. I've been on the receiving end of it myself, which is roughly how I learned to ask it early — the pre-sell-before-you-build sequence exists because of how many times I did it in the wrong order.

Minutes 10–20: The Build Reality — What's Actually Shipped

This is the longest pass, because it's where the gap lives. I ask for a link, not a walkthrough. Something running, right now, that I could use badly and break.

What I'm separating: what is shipped, what is half-shipped, and what is deck-ware. Deck-ware is the feature that exists in the roadmap slide, the investor update, and the founder's mental model of the product — and nowhere else. Every early-stage product has some. The dangerous amount is when the deck-ware is the part the pitch depends on.

Then the 2026 question I didn't have to ask three years ago: who wrote this, and has anyone senior read it? A large share of what I look at now was generated with Lovable, Cursor, Replit Agent, or Claude Code. That's genuinely fine — I'd start a new product that way too. But AI-built and production-grade are different finish lines, and the gap between them has a name: vibe debt. Auth that works until two people log in. Validation that trusts the client. Secrets in the repo. It demos beautifully and fails with real users, on the day you least want it to.

So I check three things fast: is anything handling money or personal data, is there any auth beyond the happy path, and has a human being with production experience read the parts that touch either. If the answers are yes, barely, and no — that's not a reason to stop. It's a reason to spend one week on a security pass before launch instead of finding out the expensive way. The free 20-point checklist covers most of it; the ones that come to me for a rescue are the ones who found out after.

Minutes 20–25: The One-Metric Test

I ask one question and then shut up: what's the one number you check every week to know whether this is working, and what is it right now?

Three possible outcomes, all informative:

They answer instantly with a number. Rare, and it changes the whole call. We can now talk about what moves it, which is the actual work.
They name a metric but don't know today's value. Common. It means the metric is aspirational — someone chose it in a planning meeting and nobody wired it up. Fixable in an afternoon, and worth doing before anything else.
They list six metrics. Six metrics is zero metrics. It means nobody has decided what this product is for, and every future prioritization argument will be unwinnable because there's no shared definition of better.

Signups is almost never the number. Signups measures your marketing. The number you want measures whether the product did the thing: repeat usage in week two, jobs completed, invoices sent, whatever your product actually promises. Pick the one that would embarrass you if it stayed flat.

Minutes 25–30: The Verdict — Kill, Focus, or Ship This Week

Every evaluation ends in one of three places. I say which one out loud, because a call that ends in "lots of interesting directions here" has wasted both of our afternoons.

Kill. No named customer, no money, no pain that breaks anything. The product is a solution wearing a problem's clothes. Killing it this month is the highest-return decision available to you, and nobody will ever thank you for it.
Focus. The most common verdict by a wide margin. There's something real in here, and it's buried under four other things. Cut to the one workflow that the paying-est user actually uses, aim it at the narrowest audience you can name, and let the rest sit. This is almost always an audience decision, not a code decision — positioning does more here than a rebuild ever will.
Ship this week. It works, someone's paying, and the thing standing between you and more of them is a launch you've been polishing for a month. The advice is short: stop, ship, and go get customer eleven by hand.

The Red Flags That End an Evaluation Early

Sometimes I know at minute six. These are the ones that get us there:

The customer is a demographic. If you can't name three real people who have this problem and tell me how you'd reach them by Friday, we're not evaluating a product yet.
Months of building, zero conversations. Not zero sales — zero conversations. The plan was to build it and then find out.
The product is a Figma file. Design-complete and build-zero, past month three, means the hard part hasn't started.
The roadmap is longer than the user list. Twenty planned features and eleven users is a confidence problem, not a capacity problem.
Nobody owns the decision. If "we'll have to align on that" answers three questions in a row, the bottleneck isn't the product. It's the org chart, and no framework fixes that from the outside.

Questions to Ask Yourself Before You Book Anyone (Me Included)

Run these before you pay a consultant, an agency, or a fractional anyone:

What decision am I actually trying to make? "Get advice" isn't a decision. "Do we keep building this or narrow it" is.
Have I run the five passes above on my own product, honestly? Most of what a good advisor does in the first hour is ask questions you could have asked yourself for free. Do that part yourself and buy the expensive part.
Am I buying judgment or hands? Different purchases, different people, wildly different prices. Confusing them is how founders end up paying senior rates for execution.
What's the first deliverable, and when do I get it? If nothing lands for weeks, ask why.
Would I know within 30 days whether this was worth it? If not, shrink the engagement until you would.

That last one is why I keep the first call free and 30 minutes. It's also why the paid version has a fixed price and a written deliverable on a stated day rather than an open-ended retainer — the $2,500 AI Readiness Assessment lands a 15–25 page roadmap on day 14, and gets credited in full if we build together within 90 days. Ongoing fractional work ($5K–$15K/month) exists, but I only offer it after we've done one engagement together, because neither of us can judge that fit from a call. If you're wondering whether you need that level of help at all, the honest signs are written down here.

Do this today: open a blank note and write the five answers — the named person, the money, the shipped-versus-deck-ware split, the one number and its current value, and your own verdict. Twenty minutes. If you can't fill in one of them, you just found the thing to work on this week, and you didn't have to hire anyone to find it.

Still want the outside read? Book the free 30-minute strategy call — bring a live link, your honest revenue number including zero, and the one question you want answered, and you'll leave with a verdict instead of a vibe. No pitch: if the answer is "kill it" or "you don't need me yet," that's what you'll hear. Got a single question rather than a whole evaluation? The 15-minute quick call exists for exactly that.

Next step See how we'd work together →

Free Resource

Get the Free AI Content Toolkit

The exact system I use to turn one idea into a month of content — atomization framework, voice template, prompt library, weekly system.

Frequently Asked Questions

How do you evaluate a product idea?: In this order, because the order does the work: (1) who specifically is it for, and what breaks in their week without it — named person, named pain, not a demographic; (2) has anyone paid, or clearly said they would, with money or a signed intent attached; (3) what is actually shipped and running versus what only exists in the deck — I want the URL, not the roadmap; (4) what is the one number that tells you whether it's working, and what is that number today; (5) the verdict. Most people evaluate ideas by asking whether the idea is good. That question has no answer. Whether a specific person will pay a specific price to make a specific pain stop — that question has an answer, and you can usually get it in a week.
What should I ask before hiring product help?: Four things. What have you personally shipped, and can I see it running — not a case study PDF, a live thing. What's your first deliverable and when do I get it, in days. What would make you tell me not to hire you, because anyone who can't answer that is selling hours, not judgment. And what does it cost, flat, before we start. On my side those answers are published: 50+ products shipped over 15 years, the free 30-minute strategy call gives you a concrete written next step, the $2,500 AI Readiness Assessment lands a written roadmap on day 14 and gets credited in full against any build within 90 days. If someone can't answer all four inside one email, the engagement will feel exactly like that email.
How do I know if my MVP is worth continuing?: Ask what would have to be true for this to work, then check whether any of it is true yet. Continue if: someone outside your friend group has paid or is actively trying to, users come back without a reminder from you, and you can name the one workflow that keeps them. Stop or reset if: every user came from your own outreach, retention past week two is effectively zero, and the plan for growth is a feature that isn't built. The reset is usually not a rebuild — it's the same code aimed at a narrower audience. Killing the audience is cheaper than killing the product, and founders almost always try it in the wrong order.
What are the red flags when evaluating an early-stage product?: The five that end an evaluation fast: the target customer is a demographic instead of a person you can name and reach; zero money and zero signed intent after months of building; the demo is a deck and the product is a Figma file; the founder can't state one metric they check weekly; and the roadmap has more items than the product has users. One more from 2026 specifically — the whole thing was generated by an AI coding tool, nobody senior has read it, and it's about to take real customer data. That last one is not a reason to stop building. It's a reason to run a security pass before launch, which is a much cheaper week than the alternative.
How can 30 minutes be enough to evaluate a product?: Because the questions are ordered by how much they can kill. Thirty minutes is not enough to design your product, audit your code, or write your strategy — it's enough to find the load-bearing assumption and check whether it's holding. Nine times out of ten the answer surfaces in the first ten minutes, and the remaining twenty are spent deciding what to do about it. The long version of this work exists too: a two-week paid assessment produces a 15-25 page written roadmap. But you should not buy the long version until the short version has told you which problem you actually have.
What should I have ready before a product strategy call?: Three things, and none of them are slides. A live link to whatever exists, even if it's ugly and half-broken — especially then. The honest revenue number, including zero. And the one question you'd most like answered, written down, because calls without a stated question drift into a pleasant conversation that changes nothing. If you bring those three, thirty minutes is genuinely enough to leave with a decision instead of a vibe.

More on Product Leadership

The Prioritization Formula: A Product Prioritization Framework for Solo Founders

RICE, ICE, Kano, MoSCoW, Lean Prioritization — every prioritization framework was built for product teams, not solo founders. Here's a 5-input formula that synthesizes the best of all five for the 1-person company.

9 min

The Clarity Filter: How to Beat Feature Creep and Know What to Stop Building

Feature creep is a clarity problem, not a discipline problem. Here's the 4-question filter I run when a roadmap is bloated and the founder can't tell what to cut.

8 min

Founder's Cut: A Founder Coaching Framework for Builders Past the Build Stage

Founder coaching for the awkward stage between shipping something real and scaling. Founder's Cut is a 90-day framework — Clarity, Systems, Velocity — for founders and builders who already proved they can build but don't yet know what to build next.

8 min

How to Build an MVP in 2026: The 6-Week Framework

Most MVPs fail because founders build too much. Here's the 6-week framework I use with clients to go from idea to paying customers — with real examples from products I've shipped.

9 min

Written by

Justin McKelvey

Fractional CTO & AI consultant in Austin, TX. 15 years building software, 50+ products shipped, $53M+ in client revenue generated. I help $1M–$50M founders ship production software and automate operations with AI — without hiring a full-time executive team.

Work with me

If this was useful, here are two ways I can help:

1) Get the free toolkit 2) Book a strategy call