How do you know if a product idea is actually good?

Most product ideas feel good at midnight and feel confusing by Tuesday morning. Before you spend a dime or an hour of work, make sure the idea has legs: a real problem, a real group of people, and a realistic way to test it.

The thinking phase of product development is ideation and definition. It uses a simple six stage framework, but with fewer buzzwords and more practical checks. Breeze fits well here because you can keep the idea, notes, and decisions on one card inside product management software instead of scattered across docs and chat. When that context is spread out, it is easy to forget why you chose an idea in the first place. That is why documentation fails when it lives somewhere nobody checks, and why simple software tends to get used consistently.

The development stages give the full map. This article stays in the first part of the work: turning a promising idea into something worth testing.

Key takeaways

• Good ideas are specific: a clear user, a clear pain, and a clear outcome.
• Validate demand with small tests instead of internal debates.
• Write the big why in one sentence before you build anything.
• Pick one success metric and keep the idea, evidence, and decisions in one place.

1. How do you brainstorm without collecting 200 random ideas?

You brainstorm better ideas by giving the session a constraint. Start with a customer pain, a workflow that is too slow, or a cost that is too high. Then generate options within that boundary. Otherwise you will end up with a long list that no one wants to defend. A productive brainstorm is usually just a short timer, a clear prompt, and a strict rule that every idea must match the same problem.

If you need structure, use one technique for 15 minutes, then stop. The Interaction Design Foundation's SCAMPER method is a simple prompt-based approach that avoids blank-page brainstorming.

Create one card per idea in Breeze, then add the same three custom fields in the description for each card: who is it for, what problem it solves, and what would change if it worked. This makes ideas comparable, which is the whole point.

2. How do you check if people actually want this?

You check demand by looking for real behavior, not polite opinions. A good sign is when people already pay, hack together workarounds, or complain loudly about the same pain. A weak sign is when friends say, "That is cool."

A simple way to pressure test the idea is to look for market fit signals: repeat usage, pull from customers, and a clear reason they would switch from what they use today.

You can check demand quickly without running a big research project. Start with 5 to 10 interviews with people who actually match your target user and listen for repeated pains, not clever suggestions. Then look at what they already use, including workarounds like spreadsheets and email. If you want a fast signal from strangers, run a simple landing page and measure waitlist sign-ups. And when you want the most honest signal, ask for a small commitment, like a paid pilot, a pre-order, or a calendar booking.

Create a small list called Evidence in Breeze and add one card per signal: interview notes, screenshots of workarounds, competitor links, and sign-up results. Keeping evidence next to the idea helps you avoid arguing from memory.

3. How do you write the big why in one sentence?

You write the big why by combining the user, the pain, and the outcome in a single sentence. If the sentence feels vague, that is useful information. Vagueness is the first warning sign that you do not know what you are building yet.

To draft the sentence, start by naming who it is for (as specifically as you can), then describe what they struggle with today, and finish with the outcome they want in plain language. If it helps, add a short reason why now is the right time. You are aiming for something the team can repeat without reading a document.

To keep it visible, put the one sentence version at the top of the card description in Breeze. Then add a checklist item called "big why agreed" and do not move the card forward until someone disagrees out loud and the team resolves it. A short project scope also helps, because it turns the sentence into clear boundaries.

4. How do you pick success metrics before you build?

You pick success metrics by deciding what behavior proves the idea works. Pick one primary metric that matches the goal, like activation rate, weekly usage, or time saved. Add one guardrail metric so you do not win the metric while losing the customer experience.

Defining early goals and metrics is part of the definition stage, because you need a way to evaluate whether the work was worth it. Put the primary metric in the Breeze card title or the first line of the description so it stays visible. A quick sanity check against success factors helps you avoid measuring something easy but meaningless.

5. How do you decide if it is worth building right now?

You decide it is worth building when you have enough evidence to run a prototype test, and the upside is worth the time you are taking away from other work. If the evidence is weak, the next step is not "build a lot" - it is "test one assumption."

A simple go or no go rule for small teams is this: go when you can name the user, name the pain, and name the test you will run in the next 10 days. No go when the idea depends on "viral growth" or "everyone will want it" without evidence. And pause when the idea seems good but the timing is wrong, so you can keep it in the backlog with notes instead of forcing it into a quarter that is already full.

A paused idea is still useful. In Breeze, keep the card, attach the evidence you gathered, and add a note about what would need to change for it to become a priority. This is also one of the easiest ways to prevent scope creep, because you are explicitly separating "not now" from "must build."

When you are ready to test, move into prototype testing. If you are already thinking about release work, the launch checklist is a quick way to catch the tasks that are easy to forget, like docs and support prep.

6. How do you list assumptions without overthinking it?

You list assumptions by writing down what must be true for the idea to work. Keep it short. Three to five assumptions is enough for a first pass. The goal is not to predict the future. It is to pick the one assumption that would ruin the project if it is wrong.

A typical assumption set sounds like this: the target user experiences the problem at least weekly, they will switch from their current workaround, they will trust you with the data needed to solve it, you can deliver a first version without months of integration work, and the outcome is valuable enough to pay for or prioritize. You do not need all of these to be true on day one. You need to know which one is the biggest risk.

Put assumptions on the idea card as a checklist in Breeze. Then create one short test card per assumption. You are not trying to validate everything at once. You are trying to kill the riskiest unknowns early.

Example: imagine you want to build an internal tool that helps a support team respond faster. Your riskiest assumption might be that the current delay is caused by missing context, not by staffing. A quick test could be a one week manual workflow where the team centralizes context on a Breeze card and measures time to resolution. If the metric improves, your idea has legs. If not, your "big why" needs to change.

7. How do you do a quick competitor check?

You do a quick competitor check by looking at what people already use and what they complain about. You do not need a 40-slide analysis. You need enough clarity to answer: why would someone switch, and what do we do differently?

A lightweight competitor check is usually enough: list 3 to 5 alternatives, including workarounds like spreadsheets and email, then write one thing each option does well and one thing users hate about it. From there, write one sentence about the gap you can realistically own. This keeps the conversation grounded without turning it into a research project.

Keep this on a single competitor card in Breeze. Add links, screenshots, and notes as attachments and comments so the team can reference it later. The point is to ground your idea in reality, not to win an argument.

8. How do you test willingness to pay?

You test willingness to pay by asking for a real commitment. That can be a paid pilot, a pre-order, or a signed letter of intent. If you are building an internal tool or a new workflow, the commitment might be time: a team agrees to run the pilot and give feedback on a fixed schedule.

Simple pricing and commitment tests include a paid pilot with a clear scope and metric, a deposit or pre-order for a specific outcome, a choice test where people pick between pricing options, or an internal commitment where a stakeholder allocates hours and agrees to a deadline. The theme is the same: you are looking for something real, not polite encouragement.

If you want a quick way to run a choice test, try asking people to pick between three options: basic, standard, and premium. The point is not to lock pricing on day one. It is to learn what level of outcome they value. In Breeze, keep a card for each conversation and write the option they chose plus one sentence explaining why. After five to ten conversations, patterns show up quickly.

Add a checklist item called "commitment test" in Breeze and do not move the idea into build until that box is checked. It saves you from building a product that people like in theory but will not pay for or prioritize.

9. What should an idea board include?

An idea board should make it easy to move from "interesting" to "worth building now." The simplest version is a small funnel: ideas come in messy, and you narrow them down based on evidence. You do not need a complicated scoring system. You need a visible way to separate "interesting" from "ready to prototype." If your team is new to designing work as a flow, workflow basics can help you think in steps instead of random tasks.

In Breeze, a simple board for the thinking phase can follow that same funnel. Start with lists like inbox, short list, evidence, ready to prototype, and not now. Then use a few labels for user type, problem area, and idea source. On each idea card, keep a short checklist covering the big why, the evidence, the metric, and the next assumption to test so ideas stay comparable.

Once a card is in "ready to prototype," the next step is prototype testing. When you start lining up release work, the launch checklist helps you cover the non-obvious tasks. And when you are ready to move from decision to execution, an action plan keeps the next steps specific.

Questions and answers