The dangerous kind of clever

The ideas I distrust most are the ones that sound elegant before anyone says who is angry enough to use them. "A dashboard for X" is usually too early. "A copilot for Y" is often a costume. A real small product normally begins with a sentence that already has a scene in it: a recruiter has twenty resumes to compare before lunch; a founder has to rewrite the same investor update three times; a support lead has a pile of messy tickets and no good first sort.

My read: the best early clue is not excitement. It is recognition. When the right person hears the problem, they should start correcting your wording because they have lived the annoying details.

A bad idea can still get polite praise

Most validation fails because the question is too comfortable. If you ask "would this be useful?", almost everyone can say yes without committing anything. A better test is to ask for a specific artifact: send me a messy file, let me fix one example, reply with the output you expected, or tell me what you currently do instead.

For example, a resume tool does not become real when people agree that job search is painful. It becomes real when someone lets you judge an actual resume, argues with the feedback, and still asks for the next pass. The argument matters. It means the output entered their real decision loop.

The first proof should be embarrassingly manual

If the first version needs accounts, billing, a settings page, a team dashboard, and a complete onboarding sequence, the product is probably hiding from the real test. The first proof can be a form, a short landing note, a manual review, a script, a spreadsheet, or a tiny demo. The point is not to look serious. The point is to make the next conversation sharper.

• Can the user describe the pain without learning your vocabulary?
• Can you produce one useful result with almost no interface?
• Can the user tell you what would make the result trustworthy?
• Can you reach five more people who have the same problem?

Distribution is part of the product shape

A tiny product with no path to its users is not tiny; it is just invisible. Distribution should be tested while the idea is still cheap. A public note, a before-and-after example, a small manual service, or a focused thread can reveal whether the audience has the words, urgency, and habit needed for the product to travel.

The useful question is not "can this become a SaaS?" It is "where would this naturally show up before someone knows my brand?" If the answer is nowhere, the product needs either a sharper pain or a more native surface.

What I would stop doing earlier

I would stop when every conversation requires education before pain appears. I would stop when users praise the idea but never bring a real artifact. I would stop when the product only works if people change a habit they do not already want to change. Small bets are not about stubbornness. They are about making the cost of being wrong low enough that you can keep your judgment honest.

聰明題目最危險

我最不信任的題目，通常是還沒講出誰真的痛，就已經聽起來很漂亮的題目。「某某 dashboard」常常太早，「某某 copilot」常常只是換皮。真正的小產品，通常一開始就有畫面：招募的人中午前要比二十份履歷；創業者同一份更新要改三個版本；客服主管面前是一堆髒資料，第一輪分類都很痛苦。

我的判斷是：早期最好的訊號不是興奮，而是辨認。對的人聽到問題時，會開始糾正你的說法，因為那些麻煩細節他真的經歷過。

禮貌稱讚通常不算驗證

很多驗證失敗，是因為問題問得太舒服。你問「這有沒有用」，大多數人都能說有用，卻什麼也不用付出。比較好的測試是要一個具體東西：丟我一份很亂的檔案、讓我修一個例子、回我你原本期待的輸出，或告訴我你現在怎麼土法煉鋼。

例如履歷工具不是在大家同意求職很痛苦時變真，而是在有人願意拿真履歷給你看、跟你的建議吵、吵完還想要下一版時變真。那個爭論很重要，代表你的輸出進入了他的真實判斷流程。

第一個證據應該手工到有點丟臉

如果第一版就需要帳號、付費、設定頁、團隊 dashboard 和完整 onboarding，通常代表你在躲真正的測試。第一個證據可以是一張表單、一篇短文、一個人工 review、一支 script、一張 spreadsheet，或一個很小的 demo。重點不是看起來正式，而是讓下一次對話更準。

• 使用者能不能不用學你的詞，就講出自己的痛？
• 你能不能幾乎不做介面，仍然交出一個有用結果？
• 使用者能不能說出什麼會讓結果變可信？
• 你能不能找到五個也有同一個問題的人？

分發不是後面的事

沒有路徑碰到使用者的小產品，不是真的小，只是看不見。題目還便宜的時候，就該測分發。一篇公開筆記、一組 before/after、一個人工服務、一串聚焦討論，都能看出這群人有沒有共同語言、急迫感，以及把東西傳出去的習慣。

有用的問題不是「這能不能變 SaaS」，而是「在別人還不知道我是誰以前，這個東西會自然出現在哪裡」。如果答案是沒有地方，那就不是還沒行銷，而是痛點或場景還不夠準。

我會更早停下來的狀況

如果每次對話都要先教育，痛點才勉強出現，我會停。如果大家一直稱讚，但沒有人願意拿真東西給你處理，我會停。如果產品成立的前提，是使用者要改一個他本來就不想改的習慣，我也會停。小型題目的價值不是硬撐，而是把錯誤成本壓低，讓自己的判斷不要失真。