> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 產品思維

> 產品思維是先盯住使用者會懷念的結果，再決定做什麼、不做什麼，並用結果而非功能數量來衡量。了解其起源、Superhuman 案例，以及它何時會失效。

<Info>
  **類別**: 思維<br />
  **類型**: 認知框架<br />
  **來源**: 德魯克，1954 年；萊維特，1960 年；卡根，2008 年；佩里，2018 年<br />
  **別名**: 產品心態、用產品而非專案來思考、以結果為導向的產品工作
</Info>

<Note>
  **快速回答** — **產品思維**（Product Thinking）是一種習慣：先盯住使用者會懷念的改變，並確認這件事對生意和技術也成立，再決定做什麼、砍什麼；做完之後，看行為有沒有變，而不是看功能有沒有上線。德魯克把企業目的說成創造顧客；萊維特指出人們愛鐵路勝過愛出行；卡根和佩里把這套習慣寫成可公開練習的方法。核心啟示很簡單：上線了一個功能，還不等於有了結果。
</Note>

## 什麼是產品思維？

**產品思維**（Product Thinking）是一種技能：把每一次動手都當成一筆賭注——賭的是某個人會懷念的改變，而且市場和組織付得起、還能重複交付；不是路線圖上的一個空位，也不是一張必須兌現的需求單。

> 所謂構建陷阱，就是組織陷入用產出而非結果來衡量成功。

這是梅麗莎·佩里 2018 年《逃離構建陷阱》裡的句子。[設計思維](/zh-hant/thinking/design-thinking)問的是方案對一個人好不好用、好不好受。產品思維多問一層：這是不是值得為一群我們服務得了的人去解的問題？我們交不交得出？上線之後，有沒有任何人的行為真的變了？

日常圖像是一間不斷添置器具的廚房。螺旋切菜器到了，因為看起來聰明。產品思維早一步：哪個週二的晚飯真的有人吃完？這件工具消失了，誰會發現？我們還用得起嗎？一張功能需求、一次「順便加一下」、一個有十二個沒人點的分頁的市政 App，都是帶著贊助方的螺旋切菜器。

[創業思維](/zh-hant/thinking/entrepreneurial-thinking)從手頭已有的手段和虧得起的損失出發。市場還是霧的時候，那是搜尋方法。產品思維是更緊的一步：選定可重複的結果，寫清給誰用，並拒絕把「已經發版」當成證據。[待完成工作法](/zh-hant/methods/jobs-to-be-done)給「人到底雇這個方案來完成哪段進展」起了名字。產品思維決定要不要圍著這份工作做一款產品，還是放手。

### 產品思維的三層理解

* **入門**: 功能不是結果。日常線索是標題裡已經寫好方案的待辦、一句「我們應該加一個」，或家裡那個打開不超過兩次的工具。
* **實踐**: 動手之前先寫四行：給誰、對他們會有什麼改變、我們怎麼知道、以及這次明確不做的。再選一個最小測試，好讓這個賭注有機會被證偽。
* **進階**: 多數想法死在某個沒被點名的風險上。成熟的做法是同時抓住價值、可用性、可行性、商業可行性，並不斷收窄市場，直到真有一個人會因為失去它而失望。

## 起源

產品思維起於如何停止把「你做出來的東西」和「誰會懷念它」混為一談。它不是給一個職位起的別名。

**1954** 年，**彼得·德魯克**在《管理的實踐》裡寫道：對企業目的只有一個站得住的定義——創造顧客。利潤是結果，不是目的。**1960** 年，**西奧多·萊維特**在《哈佛商業評論》發表〈行銷近視症〉，點出企業版的器具之愛。他寫道：鐵路公司把顧客讓給別人，是因為它們認定自己在鐵路業，而不是運輸業——以產品為導向，而不是以顧客為導向。

實踐者用的這個名字更晚。**2008** 年，**馬蒂·卡根**的《啟示錄》（*Inspired*）描述強產品團隊如何把發現（什麼值得做）和交付（如何做好）分開。**2017** 年，他在矽谷產品集團的一篇短文裡把工作拆成四種風險：價值、可用性、可行性、商業可行性。稍後他又把產品寫成 *顧客 × 生意 × 技術*——任一為零，產品就是零。

**2018** 年，佩里出版《逃離構建陷阱》，把「產出 / 結果」這道切口變成公共診斷。同年，**拉胡爾·沃拉**在 *First Round Review* 寫下 Superhuman 的產品—市場契合引擎，把**尚恩·埃利斯**的「非常失望」問卷做成可運轉的迴路。旁邊的方法——[最小可行產品](/zh-hant/methods/mvp)、精益循環、持續發現——是這套習慣可以拿起的工具。它們替代不了習慣本身。

## 核心要點

產品思維在某件事即將被加上、被撥款、或被宣布「做完了」時才值錢。把第一張點名了方案的需求單當成工作本身，它就失效。

<Steps>
  <Step title="先寫結果，再寫功能">
    一張已經含著方案的需求——「加一個儀表板」「我們需要一個 App」——是猜疑穿著工單。先改寫成改變：誰卡住了，做成了會有什麼不同，我們怎麼看見。Intercom 的公開規則是同一刀：從問題開始。如果你離開控件的名字就說不清問題，你還沒有產品賭注，只有一張購物清單。
  </Step>

  <Step title="同時解使用者、生意和技術">
    卡根的四種風險是防止單相思的清單。價值：他們會選它嗎？可用性：他們搞得懂嗎？可行性：以現有時間和技能，我們做得出來嗎？商業可行性：銷售、成本、法律、品牌還認不認？[設計思維](/zh-hant/thinking/design-thinking)在前兩問上很強。後兩問是零，產品思維就不會把一個討人喜歡的原型叫做「產品」。
  </Step>

  <Step title="衡量改變，而不是衡量發版">
    故事點、發版列車、「我們上線了」，都是產出。結果是人們做什麼、付什麼、會不會回來，發生了改變。佩里說的構建陷阱，就是因為從未定義過真正的價值，於是改用好數的代理指標——交出了多少功能。把它和[德魯克有效性原則](/zh-hant/principles/drucker-effectiveness)放在一起：把事情做對，不等於做了該做的事。
  </Step>

  <Step title="先收窄給誰用，再拓寬做什麼">
    一款想討好每一種人設的產品，通常誰都不會想念。萊維特的問題——「你到底在做什麼生意？」——是市場切割，不是口號。Superhuman 契合度的第一段上升，來自砍掉人設，而不是加功能。[經濟思維](/zh-hant/thinking/economic-thinking)給同一批工程師的另一種用法標了價。說不，就是產品。
  </Step>
</Steps>

## 應用場景

某次動手即將被當成進度時，再用產品思維。已經有清楚規格和死線的一次性任務，不要拿它當剎車。

<CardGroup cols={2}>
  <Card title="把需求改寫成看得見的改變" icon="graduation-cap">
    一門課、一份教學、一段新手引導，常常是一堆模組。問哪一課消失了學習者會想念，以及學完之後他們能做成什麼以前做不成的事。其餘砍掉。如果工作標題已經是一種形式——「加一段影片」「寫一本手冊」——你還在買器具。
  </Card>

  <Card title="砍掉沒有結果的路線圖條目" icon="briefcase">
    評審時，拒絕只點名控件的工單。一頁紙寫清使用者、改變、信號、四種風險。如果開著的風險是價值，就不要從可行性探針開工。用最小的[最小可行產品](/zh-hant/methods/mvp)去證偽這筆賭注，然後讓工程師盯著結果，而不是盯著最初那張草圖。
  </Card>

  <Card title="問誰會想念家裡的那個工具" icon="house">
    共享日曆、一週食譜、十七個群的家庭聊天：每一樣加上去時都「聽起來有用」。寫清給誰、哪個週二會因此變好、消失了誰會失望。如果誰都不會發現，就封存。你不是在辦新創公司。你是在拒絕一抽屜沒人用的器具。
  </Card>

  <Card title="用使用而不是用啟動日給公共工具撥款" icon="landmark">
    城市入口網站、家長會專案、志工 App，都能上線十二個分頁然後失敗。選一件人們已經在試著做的事——交罰款、約時段、登記一次——衡量重複使用，而不是剪綵。如果唯一的成功指標是「我們上線了」，那就是帶著新聞稿的構建陷阱。
  </Card>
</CardGroup>

## 經典案例

產品思維可核對的公共窗口，不是某個著名發布日。而是 **Superhuman** 在 2017–2018 年，試圖停止猜測：一款漂亮的郵件客戶端，到底算不算有人會想念的產品。

到 **2017 年夏**，團隊已經有一款很快的測試版客戶端，卻沒有共同語言來說「我們準備好了」。**尚恩·埃利斯**比較了近 **100** 家新創公司後，給出一道乾脆的問卷：如果不能再用這個產品，你會怎樣？後來長得起來的公司，活躍使用者裡通常有超過 **40%** 回答「會非常失望」。掙扎的公司通常在這條線下面。Superhuman 問的是過去兩週至少用過兩次的人。第一個數字是 **22%**。

沃拉沒有把 22 當成「再加功能」的判決。他又加了三問：這款產品最適合誰、核心好處是什麼、怎樣改進。按已經愛上它的人切分之後，這一組的分數是 **33%**——這是市場切割，不是新控件。團隊接著盯住那些已經說出核心好處、但仍「有些失望」的人，用三個季度朝那條失望線去做。等到沃拉在 *First Round Review*（**2018 年 11 月 13 日**）寫下方法時，分數是 **58%**。

邊界說明：早期使用者問卷不是完整生意；「非常失望」也不是倫理、成本或留存。Superhuman 選的是窄的、付費的使用者。可遷移的教訓是第一步。把產品做大之前，先寫清誰會想念它。然後衡量這個，而不是衡量發版列車。

## 邊界與失效場景

產品思維在工作是一次性、規格已知、日期不能動時會失效：一場婚禮、一份合規申報、一座必須週二通車的橋。那是專案思維，對封閉任務是對的工具。把「結果」當壁紙貼在固定交付物上，只會多開會。

還沒有使用者、也看不見任何改變時，它同樣失效。那時需要的是[創業思維](/zh-hant/thinking/entrepreneurial-thinking)和一次便宜的測試，不是對著空房間做產品—市場契合調查。永遠不發版的「發現」是另一種拖延：「我們還要再研究」可以是在逃避一個小而可見的賭注。

常見誤用是口號。團隊把待辦改名為「以結果為導向」，照樣數故事點，把上線叫做結果。另一種誤用是「顧客永遠是對的」：照單全收每張需求，只是多聽了幾句的功能工廠。第三種是設計思維表演：做出生意賣不掉、技術棧跑不動的討喜原型。卡根的產品只有在三個因子都不是零時，才叫產品。

## 常見誤區

這個中文名容易撞上職位名稱、準時發版，以及「使用者說什麼就做什麼」。

<AccordionGroup>
  <Accordion title="產品思維就是當產品經理，或會一堆框架">
    職位可以幫忙。它不是習慣本身。工程師、設計師、教師，以及在家裡選工具的父母，都可以練。待完成工作法、最小可行產品、卡諾、故事地圖，都是可選儀器。習慣是：在控件出現之前，先寫清結果、使用者、以及殺掉它的標準。
  </Accordion>

  <Accordion title="按時把路線圖做完就是產品思維">
    那是專案思維：範圍、日期、一張做完清單。規格已經對的時候，它有用。產品思維把規格當成假說。如果誰的行為都沒變，列車照樣開過了。產品沒有。
  </Accordion>

  <Accordion title="聽每一條使用者需求就是產品思維">
    需求是以方案的形式上門的。工作是把問題撈回來，再決定誰的問題才是你的。Superhuman 的第一段上升來自砍掉人設，而不是為測試版裡的每一種人去造。沒有市場切割的共情，只是更長的購物清單。
  </Accordion>
</AccordionGroup>

## 相關概念

這些頁面挨著同一個問題：如何決定什麼值得做，而不把發版誤認成價值。

<CardGroup cols={3}>
  <Card title="設計思維" icon="pen-nib" href="/zh-hant/thinking/design-thinking">
    用共情和迭代做出對人好用的方案。產品思維再問：有沒有一個市場會想念它，生意能不能重複交付。
  </Card>

  <Card title="創業思維" icon="rocket" href="/zh-hant/thinking/entrepreneurial-thinking">
    從手段和虧得起的損失出發，在不確定裡搜尋。一旦可重複的結果出現，產品思維是更緊的那一刀。
  </Card>

  <Card title="待完成工作法" icon="briefcase" href="/zh-hant/methods/jobs-to-be-done">
    給「人雇這個方案來完成哪段進展」起名字。產品思維決定要不要圍著這份工作做產品。
  </Card>

  <Card title="最小可行產品" icon="rocket" href="/zh-hant/methods/mvp">
    是對產品賭注的最小測試。產品思維是決定這場測試到底在測什麼的習慣。
  </Card>

  <Card title="德魯克有效性原則" icon="bullseye" href="/zh-hant/principles/drucker-effectiveness">
    把「把事情做對」和「做該做的事」分開。產品思維把這刀用在做什麼上。
  </Card>

  <Card title="經濟思維" icon="scale-balanced" href="/zh-hant/thinking/economic-thinking">
    用你放棄的東西給選擇標價。對一個功能說不，就是用工程師和注意力付的那筆價。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  加一個功能之前，先寫清：它消失了誰會失望——以及誰根本不會發現。
</Tip>
