科技創業週報 #301:四封讓 YouTube 被收購的關鍵 email

| |

Hello 讀者好~

經典科幻電影《駭客任務》要出第四集了(英文正式片名為 The Matrix Resurrections)!提前上線的互動式官方網站很有意思,由你自己來選擇藍色藥丸或紅色藥丸,每次重新點擊都會產出不同的電影剪輯片段,據說共有 18 萬種版本 💊

編輯已經準備好中秋連假複習小時候看得似懂非懂的三集《駭客任務》,12 月上映時無縫接軌。

liz

.
[Podcast] 星箭廣播 EP123 | 一部電影要播一年!電子紙「慢電影播放器」|Titan 幫自己的智慧音響做了一個螢幕

越來越多生活環境裡的廣告看板、公車站牌、速食店菜單都漸漸被螢幕取代,有些甚至換上了電子紙螢幕。本集《星箭廣播》想跟大家聊聊各種跟顯示器相關的有趣專案。前陣子 Julie 發現一個專案「慢電影播放器」,作者將電影《2001 太空漫遊》特殊處理後,以原本三千分之一的速度在自製電子紙螢幕播放,原本兩個多小時的電影變成超過八千小時,要一年才播得完。作者的靈感來源是什麼?除了用上電子紙螢幕,他還用了什麼特殊的技術去處理影像?

Titan 會分享一個他最近按照網路教學完成的小專案:用 Raspberry Pi 搭配一片四吋 LCD 螢幕,為家裡的 Sonos 音響系統做一個顯示器。兩位主持人還會聊到幾個有趣的螢幕相關專案和產品,例如電子紙手寫平板電腦和柔性 AMOLED 螢幕 DIY 套件等等。當然,也歡迎你跟我們分享更多好玩的專案或應用。
[英] 按人頭還是使用量收費?你的 SaaS 新創產品該如何訂價?

你的 SaaS 新創產品該按照人頭(per seat)還是使用量(per use)來收費?前者對客戶來說費用的可預期性較高,常見的是 Salesforce 或 Adobe,後者提供的彈性高,代表則是 Twilio。簡單的做法是可以先用一個 2X2 的矩陣,將客戶的價值(value)與使用量(usage)各自區分為間歇、週期性(Intermittent)和穩定(steady)兩種,如果客戶價值與使用量都是間歇、週期性,那可以採用按照使用量收費。文章會進一步談到選擇訂價策略的多種情境(例如你的成本結構、進入市場策略),甚至混搭的使用方式,有些 SaaS 公司會先收取一定的費用,然後再按使用量計費。

作者提醒,許多人將訂價策略當成「變現」(monetization)在思考,但把它當客戶獲取策略(acquisition strategy)來想也很重要。善用訂價策略還有綁住客戶的效果,例如按人頭計算並以年費計價,其實就是客戶的轉換成本。作者還舉了一個很有意思的案例:米其林有一款輪胎很耐用,若按舊有模式來賣勢必會侵蝕銷售,因此他們改採里程數(使用量)來計價,這讓卡車/貨運公司可以將費用轉嫁到客戶身上。
[英] 設計師必須要很努力,才能讓使用者毫不費力——「預設值」的五個設計原則

你能想像一個沒有「預設值」的世界嗎?操作任何產品都必須自行定義,這肯定會增加許多認知負荷。對多數使用者來說,「預設值」能不動則不動,因此預設值是展現設計是否周到的重要關鍵。

曾在 Air Asia、思科擔任設計師的 Rohith M S,分享了五個預設值的設計原則:以訂機票的流程為例,需要自己手動調整的選項能少則少,另外,盡量使用大家熟悉的設計元素,別讓使用者 在需要自定義時感到困惑。最後一個建議則是,切記保留「恢復預設值」的選項(編輯就有使用新產品時改預設值改到亂掉,想歸零重新來過卻遍尋不著,只好刪掉重新下載的經驗 🥲)。
[英] 四封電子郵件揭露 YouTube 被 Google 收購的 起源

2006 年 Google 以 16.5 億美金收購了 YouTube,創下科技史的經典收購案例。Google 當時是怎麼看待這間剛展露頭腳的公司的?Internal Tech Email 揭露了四封由 Google 高層 Jeff Huber、Peter Chane 針對 YouTube 交換意見的信件,YouTube 創辦人來自 PayPal 幫的背景,以及近在咫尺的創業地點,商業化的潛力、方式也與 Google 的長處不謀而合,這些都讓 Huber 興致高昂,Chane 的態度則較為保守 🧐 最後,他們把整串信件呈交給 Google 共同創辦人 Larry Page,他的態度是什麼呢?(此外,寄件副本欄也有玄機——後來成為 YouTube CEO 的 Susan Wojcicki 也在寄件對象裡面。)
[英] 反向面試問題集

「你有沒有什麼問題?」面試時主動提問,是了解公司、團隊,降低期望落差的機會。GitHub 上一份集結眾人心力的「反向面試」(Reverse interview)問題集,列出了許多在面試時可以反問面試者的問題,從職責範圍、技術層面、團隊文化、辦公環境、福利到遠端政策,還包含了公司對公共議題的態度與立場。你可以從這份清單中找到自己最好奇的問題,先做做功課後如果無法找到答案,就可以在面試中提問了。

本文也有中文版本(簡體),有需要的讀者可以參考~
[英] Notion 用 Next.js 重構了官網,自家工程師現身說法

隨著 Notion 使用者快速成長,團隊也頻繁發表部落格文章和使用指南,並新增各種登入頁面,但同時網站的效能也成了未爆彈。(你可能也聽過的抱怨是速度越來越慢了)於是他們出動三位工程師、花了兩個月重構官網搬到 Next.js——結果網站 Lighthouse 分數從原本的 50 分變成 97,SEO 成效也提升了,而且開發時不用再擔心弄壞官網和 app。

因為初期團隊規模小,Notion 官網和 app 共用一套程式碼是利大於弊,但兩年過去,開發者和使用者體驗都開始受影響,而在優化現有用戶端 codebase 和搬到靜態網站產生器從頭開始之間,他們最終採用了後者。至於過程中的決策和執行細節,包括為什麼選擇 Next.js;在版本控制、託管、部署等方面要特別注意的事,也很值得參考。
[中] Phil Huang/雲端原生人才看得到,找不到?

雲端原生(Cloud Native)領域中,為什麼會出現「人找事」或「事找人」的種種問題?作者黃秉鈞以地端 IT 基礎架構師角度拋出討論,首先點出他觀察到台灣甲乙方的現況,像是多數政府單位及金融、製造業仍重視地端+離線的基礎平台建設; app 開發只想用服務而不想管服務等等;而老闆對 DevOps、SRE 和雲端工程師這類員工又有著變身超級賽亞人的期待。

人才端的部分,除了釐清考取證照與否的意義,作者也點出幾個常見誤解和相對應的組織文化挑戰,包括會容器使用 VS. 會容器平台管理、CI/CD 持續交付整合、IT 自動化。最後還有關於 DevOps 和 SRE 的差異,以及他分享給人才和企業方的一些建議。雖然這是線上討論的簡報檔,不過仍能對此議題有更進一步的了解。
[中] Huli/來談談工程師的知識焦慮

前端工程師 Huli 常看到有人問自己下一步該往哪去,是要學 A 還是 B 或回去學重要的基礎 C?他曾經也是這樣,發現時不時有新的框架或函式庫出現,也每天汲取新的知識,但還是有這種「學不完」的知識焦慮。而他的解方是選擇放棄——他反思自己真的需要這些知識嗎?少看了真的有影響嗎? 

他剖析知識焦慮產生的最大原因之一是沒有方向,所以他分享給已經在工作、還在找工作的人不同建議,包括他對學習順序的看法(先學習工具跟框架,抑或是原理跟基礎?),幫助擺脫這種知識焦慮,專注眼前目標,並忽略其他雜訊。
.
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出

(文章代表圖:Photo by Liam Truong on Unsplash

Previous

《星箭廣播》124 集——你的耳機都開多大聲?用 iPhone 與 AirPods「測」聽力(ft. Jedi)

《星箭廣播》125 集——命運總是會考驗你有沒有備份電腦資料

Next

發佈留言

Share via
Copy link
Powered by Social Snap