我在建造陷阱裡嗎?
想像一下，突然得到一段完全自主的時間——不用接受老闆的要求，可以自己決定如何運用。再配合上現在最流行的 Video Coding、BDD、TDD，專心開發一個產品。這根本就是熱愛開發者的天堂。
開發了幾個工具後，快速丟到社群或問朋友們有沒有人要試用，然後雙手合十祈禱自己也會是下一個百萬 AI 產品的故事。
但有沒有可能，我們正深陷「建造陷阱」裡？心裡先有一個美好的想法，透過自己投入的時間不斷加強這個想法。等到後面發現找不到使用者時，因為捨不得沉沒成本，反而增加了轉向（Pivot）的難度。
我在開發前作的問卷真的有效？
你可能會想：「我是個很科學的創業者，在做這些事情之前我有透過問卷調查。我設計的問卷大家都說有興趣啊！」但問卷往往是從朋友、家人或過去的同事開始收集。相信你平常為人不錯，所以有很多人願意幫忙填問卷。然而，正因為如此，我們收集到的問卷常常會有偏差。
我發現大家在回答問題時，其實會跟著你已經設定好的選項去回答，更深層的需求或痛點往往無法在問卷上表達出來。而且當你問：「如果有試用的話，你會有興趣嗎？」大家普遍都會說有興趣。為什麼？因為沒有人想當壞人，大家都想 be nice。
因此,這種帶有偏差的問卷調查，反而可能讓我們更容易掉進建造陷阱而渾然不覺。
不要打造沒有人想要的產品
Y Combinator 的共同創辦人 Paul Graham 曾說過一句經典的話：「Make something people want」（打造人們想要的東西）。這聽起來很簡單，但實際上卻是最容易被忽略的原則。許多創業者花費數個月甚至數年的時間開發產品，最後才發現市場上根本沒有人需要它。
確認真的有人願意為你的解決方案付費
那麼，我們該如何避免這個陷阱呢？答案就是：在開始大規模開發之前，先確認真的有人願意為你的解決方案付費。這就是為什麼我們需要採用 ”展示→販售→打造” 的策略。
展示→販售→打造
我們團隊也還在學習中，但希望用這樣的心態和方法來快速迭代進行中或未來的想法。
在有任何想法之前，我們會先從團隊內部溝通並收集資料。等到這個想法從各個角度都得到團隊共識後，接下來就要進行潛在使用者的訪談。
這些訪談採取面對面的形式，與每位受訪者深入了解他們在使用現有工具時遇到的問題和需求。訪談方式主要聚焦在了解使用者如何運用現有工具和做法來達成目標，而不會用引導性問題讓受訪者回答我們想聽的需求或痛點。從這些訪談中獲得的洞察，我們再反覆驗證：這個問題是否夠大? 痛點是否足夠強烈? 是否夠急迫值得我們來解決?
確認問題之後，我們再進行解決方案的討論。在這個階段，我們都盡量不作開發程式的工作，其實有很多方式可以讓使用者了解我們能提供的獨特價值和可能的解法。有了解決方案提案後，再來必須直接找使用者來測試問題與解決方案的 Fit，也就是確任我們提供的解決方法提案可以被使用者接受並 ”販售”。
我特別想強調「販售」這個環節：過程中你會遇到很多好人，大家都會禮貌地表示願意嘗試或有興趣。但關鍵是：永遠要看使用者實際「做了什麼」來判斷他們是否真的感興趣，而不是只聽他們「說了什麼」。
問使用者：「如果這個解決方案可以解決你的問題，我們提供早期預購五折優惠，你有興趣嗎 ?」
如果使用者說 ok，就馬上請他們付款。這是一個很強的好訊號。
至於後面打造產品的部分，在 AI 時代大家都是高手，就不在這裡贅述了。
透過不斷迭代學習, 解決問題
持續學習的速度 是新的不公平優勢
與大家共勉，在這個快速變化的時代，唯有保持敏捷的學習態度，才能在競爭中脫穎而出。希望這些經驗分享能幫助大家避開建造陷阱，真正打造出使用者想要的產品。
References
(Translated by AI)
Escaping the Build Trap: Show → Sell → Build
Am I in the Build Trap?
Imagine suddenly having a period of complete autonomy—no need to follow your boss’s demands, you can decide how to spend your time. Combined with today’s most popular Video Coding, BDD, TDD, you can focus on developing a product. This is heaven for development enthusiasts.
After developing a few tools, you quickly throw them to communities or ask friends if anyone wants to try them, then clasp your hands together and pray that you’ll also be the next million-dollar AI product story.
But is it possible that we’re deeply trapped in the “build trap”? We first have a beautiful idea in our hearts, continuously reinforcing this idea through our invested time. When we later discover we can’t find users, because we can’t let go of the sunk costs, it actually increases the difficulty of pivoting.
Are the Surveys I Did Before Development Really Effective?
You might think: “I’m a very scientific entrepreneur, I conducted survey questionnaires before doing these things. Everyone who answered my questionnaire said they were interested!” But surveys often start with collecting from friends, family, or former colleagues. I trust you’re usually nice to people, so many are willing to help fill out surveys. However, precisely because of this, the surveys we collect often have bias.
I’ve found that when people answer questions, they actually follow the options you’ve already set to respond, and deeper needs or pain points often cannot be expressed in surveys. And when you ask: “If there’s a trial, would you be interested?” people generally say they’re interested. Why? Because no one wants to be the bad guy, everyone wants to be nice.
Therefore, this kind of biased survey can actually make us more likely to fall into the build trap without realizing it.
Don’t Build What Nobody Wants
Y Combinator co-founder Paul Graham once said a classic phrase: “Make something people want.” This sounds simple, but it’s actually the most easily overlooked principle. Many entrepreneurs spend months or even years developing products, only to discover that no one in the market needs them.
Confirm that people are really willing to pay for your solution
So how do we avoid this trap? The answer is: before starting large-scale development, first confirm that people are really willing to pay for your solution. This is why we need to adopt the “Show → Sell → Build” strategy.
Show → Sell → Build
Our team is still learning, but we hope to use this mindset and method to rapidly iterate on ongoing or future ideas.
Before having any ideas, we first communicate internally within the team and collect data. Once this idea has gained team consensus from all angles, the next step is to conduct interviews with potential users.
These interviews take a face-to-face format, deeply understanding the problems and needs each interviewee encounters when using existing tools. The interview approach mainly focuses on understanding how users use existing tools and practices to achieve their goals, rather than using leading questions to get interviewees to answer the needs or pain points we want to hear. From the insights gained from these interviews, we repeatedly verify: Is this problem big enough? Is the pain point strong enough? Is it urgent enough to be worth solving?
After confirming the problem, we then discuss solutions. At this stage, we try not to do any programming work, as there are actually many ways to help users understand the unique value we can provide and possible solutions. After having a solution proposal, we must directly find users to test the fit between problem and solution, which means confirming that the solution we provide can be accepted by users and “sold.”
I particularly want to emphasize the “sell” step: during the process you’ll meet many nice people, everyone will politely express willingness to try or show interest. But the key is: always look at what users actually “do” to judge whether they’re truly interested, rather than just listening to what they “say.”
Ask users: “If this solution can solve your problem, we’re offering an early bird 50% discount, are you interested?”
If users say ok, immediately ask them to pay. This is a very strong positive signal.
As for the later product building part, in the AI era everyone is an expert, so I won’t elaborate here.
Solving Problems Through Continuous Iterative Learning
The speed of continuous learning is the new unfair advantage
I encourage everyone: in this rapidly changing era, only by maintaining an agile learning attitude can we stand out in competition. I hope these shared experiences can help everyone avoid the build trap and truly create products that users want.