當確定要開始了解領域需求，建設系統前，就要瞭解到問題是什麼，而這個問題，是不是在這領域中是重要的？是不是為優先問題？
定義問題這一部分，很難用一個在架構或是方法論，就說照著這樣做就可以找到好問題，然後就可以當作是開發要點。
問題本身是不是一個問題，就是一個問題
問題的目的
但問題還是會回到一個根本的需求概念，如果這世界上從來沒有人定義過「書」這個概念，那當你今天要建構一個「書店」或「圖書館」的系統時，要如何從無到有的觀察與探索這些領域中的概念，並且將其建立起明確的運作規則，以符合實際的用途。 軟體產品的開發者，在收到各種面向的問題後，並將各種相對應知識萃取出來，就可以建立出一個範疇框架。
從零到一是最痛苦階段，在那之後的從1到99很多時候，都是持續維護一個主軸去發展，那從0到一最一開始定義問題就是歸納收斂的技巧。
定義問題
產品在做之前要先釐清商業模式的核心價值和問題是什麼？很多產品其實不好用，但還是有可能很多人會下載訂閱，這是因為商業模式是抓住使用者需求核心問題，UIUX介面也就是強化那個核心
在定義問題時，可以從下列幾個面想去進行思考
所以定義問題將會是一個最初的開示的步驟，但是不是說這個問題主軸定義完後，就永遠不可以改，只是不太可能的，而定義問題是為了讓產品可以開始往前邁進的第一步，第一步要選擇踩那一步，就是可以用定義問題的來決定
然後有了第一步之後，就逐步朝著一個方向進行迭代，方向不是說不能改，而是你當有了第二步第三步第四步時候，就會更清楚說如何去走向要朝那一個方向
但是改方向是一件大事，產品如果說常常改變主軸方向，參與的人其實心裡也會很疲累，甚至也會覺得說這個產品這個品牌是沒有一個未來可言，在決定要轉方向的時候，一樣也要了解現在的方向為什麼卡住，會需要調整方向，讓所有團隊可以了解。
定義問題內容，可以多從這些面向開始思考
- 為什麼會需要這個東西或解決方法？
- 為什麼使用者會需要？
- 這是唯一答案或方法嗎？
- 為什麼公司會需要執行這方法？
- 這個方法要如何賺錢？
- 最小顆粒(MVP)是什麼?
產品在做之前要先釐清商業模式的核心價值和問題是什麼？很多產品其實不好用，但還是有可能很多人會下載訂閱，這是因為商業模式是抓住使用者需求核心問題，UIUX介面也就是強化那個核心。
Take away
定義問題時，多自問自答一些「為什麼」，來幫助自己理清問題的範疇
解決方法定下來，當有遇到障礙時，要先理清障礙卡點是什麼，在進行轉向的規劃