從健身到健康,從個人到家庭 -淺談 Apple Watch 的產品定位

產品定位說的簡單,實際執行起來卻很難!
評論
Photo Credit:Apple
評論

本篇投稿同步刊登於 Medium。關於作者 YJ.Porter.Wu ,長年糾結於理性思考與感性情感的交叉口,擁有物理與材料科學背景但內心始終流著設計血液。抱持著遲早要回台灣的心態,瘋狂的往外漂流。在中國工作期間,體會到經濟巨人的震撼,但在英國重返校園後才了解到,擁有自身文化才是最美的意義。努力看清事物存在的目的,卻越看越模糊。

美國時間 9/15,Apple 發表了新的 iPad、Apple Watch,以及全新的服務 Fitness+和Apple One。 

最期待的 iPhone 12 沒發表、iPad Air 越來越像 iPad pro、Fitness+ 進軍家庭健身,直接打擊合作夥伴 Nike 的 NTC 以及其他類似的健身 app 服務,Apple One 的大補帖訂閱制,則預期對 Netflix、Spotify 等訂閱服務產生顯著的挑戰!

不過本文想要討論的是 Apple Watch,這個我認為近年來產品定位最成功的 Apple 產品。

什麼是產品定位?

相較於涵蓋面通常較廣的品牌定位,產品定位就必須更精準明確。一個好的產品定位脫離不了幾個面向:功能、價格、情境,以及最重要的客群。

換句話說,

  • 目標客群知道這個產品是打算賣給他嗎?
  • 你的使用情境中包含你的目標客群嗎?
  • 你的產品功能是配合使用情境打造的嗎?
  • 你的價格,目標群眾負擔的起嗎?

產品定位說的簡單,實際執行起來卻很難。最主要的因素脫離不了情境、功能、客群,歸納成下面兩個挑戰:

挑戰一、產品具有新穎的功能,但使用情境尚未成熟

挑戰二、功能新穎、情境明確,但過於大眾 (競爭產品多),不知道在跟誰溝通

我們從這幾個面向來討論 Apple Watch 近年來的產品定位

功能:什麼是手錶? 什麼是智慧型手錶?

Apple Watch 並非第一家做智慧型手錶的科技品牌,事實上很難想像,第一款 Apple Watch 推出時間才不過 5 年前 (2015)。

從手錶的原始功能面來想,手錶的具體基本功能是「查詢時間」,附加價值則是「身分象徵」。你很難想像還能賦予一個戴在手腕上的小裝置,除了看時間之外的其他功能。或者應該說,原始的手錶功能已經滿足我們期待的功能了,任何其他新增的功能,都是「多餘的」。

在這種條件下,能做的產品定位策略大概只有兩種,一:創造新的使用需求,二:挑戰產品原有的功能。

創造新的使用需求

因此,2015 年的 Apple Watch,嘗試以 Sport 系列創造新的使用需求,只是當時市面已有相對成熟的 Garmin 及 Fitbit 在運動需求面耕耘。Apple Watch 提供的運動功能對專業運動者而言太過陽春、續航不夠,對於一般使用者來說,吸引力不足以掏出 349 美金購買。

那跟 iPhone 搭配呢? 可以讀訊息、導航、呼叫 Siri? 在小螢幕中硬要塞進原本智慧型手機就能做到的事,讓智慧型手錶一直脫離不了「手機附屬品」的印象。這個印象成為了智慧型手錶的硬傷,因為只要是附屬品,就是非必要品,那麼就會大大降低消費者的購買力。

Apple Watch 能做的,iPhone 都能做,如何擺脫手機附屬品的定位曾經是難題。Photo Credit:Apple Special Event 2014
Apple Watch 能做的,iPhone 都能做,如何擺脫手機附屬品的定位曾經是難題。Photo Credit:Apple Special Event 2014

這也是上述提到的挑戰一,產品具有新功能,但使用情境尚未成熟。

挑戰產品原有的功能

另一方面,初代 Apple Watch 則是嘗試挑戰高階手錶賦予配戴者「身分象徵」的功能,推出要價 10,000 美金 (起) 的 Apple Watch Edition 版本。然而 3C 產品高速汰換的本質,想要搭配精品的永恆價值,怎麼想都覺得奇怪。到了 2020 的 Apple Watch Series 6,雖然持續與 Hermès 有著合作,但被提及的份量已經下降很多了。

Apple Watch Series 6 持續與 Hermès 合作,推出高精品線。Photo Credit:Apple

初代 Apple Watch 所面臨的產品定位兩大難題:

  1. 如何突破「手錶=時間」的既定印象,創造出消費者對於手錶的新需求,而不淪為手機附屬品?
  2. 挑戰高端精品手錶賦予身分地位的功能,是正確的方向嗎?

事實上,一直到 Series 4,Apple Watch 的產品定位才慢慢明朗化。

運動、健身?不,是健康,且是家人的健康!

Apple Watch Series 2 的宣傳影片中,運動、運動、運動,在影片最後強調防水 50 M、在 Series 3 中搭配 4G 網路,讓 Apple Watch 能脫離手機獨立使用。目前為止,Apple Watch 都在逐步讓自己的功能達到「智慧型手錶應該有的基本功能」。

這就是上述提到的挑戰二,功能新穎、情境明確,但過於大眾 (競爭產品多)。Apple Watch 滿足一般對於智慧型手錶的期待,但除了信仰,幾乎沒有購買的理由。

Apple Watch Series 4 開始,目標客群及產品訴求逐漸明確,強調的不是運動、健身,而是「健康、安全、安心」。

Series 4 開始,Apple Watch 開始能偵測跌倒、自動撥打緊急電話、醫療級 ECG (心電圖),Series 6 加入血氧偵測,這些新功能的加入都不再單單只是追蹤運動表現,而是更精準地進一步追蹤「健康數據」。

許多智慧型手錶都有跌倒偵測,但只有Apple Watch從「健康」的角度一直強調。Photo Credit:Apple

至此,Apple Watch 的產品定位才慢慢的與市面上其他的智慧型手錶明確的做出區別,Series 6 的官方標語,直接打上「健康的未來,現在戴上」、「為健康生活設計的終極裝置」。

此外,watchOS7 的家人共享設定,更進一步將使用範圍從個人健康延伸到家人健康,讓使用者能安心掌握沒有 iPhone 的小孩或是長輩的健康狀況。這一步,突破了許多使用上的盲點,像是「買 Apple Watch 給長輩,但長輩卻不會使用或看不懂數據」。

大概沒有任何一款產品像 Apple Watch 一樣,能讓消費者迸出這麼強烈「我蠻想買給我家人使用」的購買動機。

從運動到健康,再到家人健康,「為他人而買」儼然成為了 Apple Watch 獨特的產品定位之一。

放眼我們身上每天會配戴的用品,手錶大概是最貼近我們 (身體皮膚) 的品項之一,因此不難理解科技品牌為什麼想要進軍手錶這個產品領域。

但是手錶本質上就具有一些有趣的限制,比方說,手錶大小大約落在 38mm~44mm,沒辦法像手機一樣無限擴大螢幕,如何在有限的畫面中,「無感」提供更多的資訊本身就是巨大的挑戰。

刻意將 Apple Watch 的產品變化拿出來討論,就是因為看到 Apple 如何在這項本身就很難進攻的產品領域中,短短幾年就成功在市場上做出區隔,這非常有趣。當然,除了 Apple Watch、Garmin 在專業領域如:航海、航空、戶外、潛水的深度耕耘也是很成功的產品定位案例。

產品定位本身就是很複雜的課題,很多時候我們會歸咎於行銷沒做好、產品功能不夠好、產品設計不夠美、市場飽和,但更多時候,根本原因很有可能出在本身的產品定位不夠明確。
我們常說品牌定位首先要搞清楚 TA (目標客群) 是誰,但是不是更多時候,我們反而忽略了每個產品線更細緻的產品定位呢?

責任編輯:Anny
核稿編輯:Mia

延伸閱讀:




開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!