Lời khuyên cho technical founder: từ prototype, MVP đến launch

1. Diana Hu và ba giai đoạn của bài giảng

Đây là một bài giảng trong Startup School của Y Combinator, mở đầu bằng tiêu đề "How to Build & Succeed as a Technical Founder". Người trình bày là Diana Hu. Theo mô tả video đăng ngày 21/04/2023, chị là Group Partner tại YC và từng là CTO của startup YC của chị, Escher Reality, công ty đã được Niantic (hãng làm Pokemon Go) mua lại.

Chị tự giới thiệu (video đăng ngày 21/04/2023): chị đang là group partner tại YC. Trước đó, chị là co-founder và CTO của Escher Reality, một startup xây SDK augmented reality cho các nhà phát triển game. Chị và nhóm ở Escher Reality cuối cùng đã có một thương vụ exit, bán công ty cho Niantic, nơi chị làm director of engineering và phụ trách toàn bộ nền tảng AR ở đó.

Vì vậy, chị nói mình biết đôi điều về việc xây một thứ từ một ý tưởng, thành một prototype, rồi launch một MVP (thứ mà chị gọi là hơi "duct tapey"), rồi scale nó, đạt product market fit và scale hệ thống lên hàng triệu user (video đăng ngày 21/04/2023).

Chị nói bài giảng gồm ba phần. Một: vai trò của technical founder là gì, và họ là ai. Hai: build như thế nào ở từng giai đoạn mà các bạn trong Startup School đang ở: ideating, giai đoạn mới chỉ có một ý tưởng và vừa bắt đầu; xây MVP khi đã có chút validation và đưa nó tới launch; và launch, giai đoạn bạn muốn iterate để tiến tới product market fit. Sau đó chị có một phần nhỏ về việc vai trò của technical founder thay đổi thế nào sau product market fit. Chị nói sẽ không nói nhiều về phần này, vì phần lớn các bạn trong Startup School đang ở những giai đoạn sớm hơn (video đăng ngày 21/04/2023).

Chị hào hứng với bài giảng này vì chị tổng hợp nó từ rất nhiều cuộc trò chuyện với các technical founder của YC, chẳng hạn từ Algolia, Segment, Optimizely, WayUp, và chị hào hứng với mọi góp ý và ví dụ của họ trong bài (video đăng ngày 21/04/2023).

2. Technical founder là ai, và khác một lead developer ở đâu

Đôi khi Diana nghe các non-technical founder nói: "tôi cần ai đó build app cho tôi". Theo chị (video đăng ngày 21/04/2023), như vậy là không đủ. Một technical founder là một partner trong suốt hành trình của startup, và việc này đòi hỏi một mức độ cam kết rất cao.

Technical founder làm gì? Theo Diana (video đăng ngày 21/04/2023), họ dẫn dắt phần lớn việc build sản phẩm, tất nhiên, và cả việc nói chuyện với user. Đôi khi chị được hỏi ai là CEO, ai là CTO khi có một technical founder. Chị nói câu trả lời có nhiều sắc thái: nó phụ thuộc vào loại sản phẩm, ngành bạn đang ở, và thành phần kỹ năng của cả đội. Chị đã thấy technical founder làm CEO, làm CTO, hoặc nhiều vai trò khác.

Ở giai đoạn đầu, vai trò của technical founder trông như thế nào? Theo Diana (video đăng ngày 21/04/2023), nó trông rất giống một lead developer. Nếu bạn từng là lead developer ở một công ty, bạn là người phụ trách gom dự án lại, build nó và đưa nó về đích. Hoặc nếu bạn đóng góp cho một dự án open source và là developer chính, bạn đưa ra mọi lựa chọn về tech.

Nhưng có vài khác biệt then chốt so với một lead developer, theo Diana (video đăng ngày 21/04/2023). Bạn phải làm mọi việc liên quan đến tech. Nếu bạn làm phần mềm, bạn sẽ phải làm frontend, backend, DevOps, website, UX, thậm chí cả IT để cấp tài khoản Google, bất cứ thứ gì. Nếu bạn làm hardware và có lẽ chỉ quen phần điện, quen làm việc với EagleCAD, bạn cũng sẽ phải làm quen với cả phần cơ khí. Và trong lúc làm mọi việc tech đó, tất nhiên bạn sẽ phải nói chuyện với user để thật sự lấy được những insight để iterate.

Bạn sẽ thiên về việc build một thứ "đủ tốt" thay vì một kiến trúc hoàn hảo, theo Diana (video đăng ngày 21/04/2023). Nếu bạn từng làm ở một công ty lớn, có thể bạn đã được thưởng vì kiến trúc hoàn hảo, nhưng ở startup thì không. Bạn sẽ thiên về hành động, di chuyển nhanh, và thật sự ra quyết định với rất nhiều thông tin chưa đầy đủ.

Bạn sẽ quen với technical debt, với những quy trình kém hiệu quả, với rất nhiều code xấu, và nói chung là rất nhiều hỗn loạn (theo Diana, video đăng ngày 21/04/2023). Tất cả những điều này để nói rằng technical founder cam kết với thành công của công ty, và điều đó có nghĩa là làm bất cứ điều gì cần thiết để nó chạy được. Chị đôi khi nghe người ta nói kiểu nhân viên ở một công ty: "việc này không thuộc phần việc của tôi". Không, theo chị, như vậy là không được ở đây. Bạn phải làm.

3. Giai đoạn 1, Ideating: prototype trong vài ngày

Phần tiếp theo là cách build. Giai đoạn đầu tiên là ideating, lúc bạn mới chỉ có một ý tưởng về thứ mình muốn build. Theo Diana (video đăng ngày 21/04/2023), mục tiêu ở đây là build một prototype càng sớm càng tốt, với một trọng tâm duy nhất: build thứ gì đó để cho user xem và demo. Nó thậm chí không cần chạy được hoàn toàn. Song song đó, co-founder CEO của bạn sẽ tìm một danh sách user trong vài ngày tới để xếp lịch gặp và cho họ xem prototype khi nó sẵn sàng.

Nguyên tắc ở đây, theo Diana (video đăng ngày 21/04/2023), là build thật nhanh, trong vài ngày. Đôi khi chị nghe: "Diana, một prototype trong một ngày, nghe như không thể. Làm sao được?"

Một cách làm, theo chị (video đăng ngày 21/04/2023), là build trên rất nhiều phần mềm làm prototype, và giữ mọi thứ cực kỳ đơn giản. Ví dụ, nếu bạn là công ty phần mềm, bạn sẽ build một prototype có thể bấm được, có thể dùng thứ như Figma hay InVision. Nếu bạn là công ty DevTools, có thể bạn chỉ cần một script viết trong một buổi chiều và chạy nó trên terminal.

Nếu bạn là công ty hardware hay hard tech, theo Diana (video đăng ngày 21/04/2023), vẫn có thể build prototype. Có thể sẽ lâu hơn một chút, nhưng mấu chốt là các bản dựng 3D (3D rendering) để thật sự cho thấy lời hứa của sản phẩm. Ví dụ chị đưa ra là một công ty tên Remora, đang giúp xe tải thu giữ carbon bằng một bộ phận gắn thêm (theo video đăng ngày 21/04/2023). Bản dựng 3D đó đã đủ để khiến user của họ hào hứng với sản phẩm, dù đó là hard tech.

4. Hai prototype đời đầu: Optimizely và Escher Reality

Diana kể (theo lời kể trong video đăng ngày 21/04/2023): Optimizely đi qua YC ở batch Winter 2010, và họ dựng prototype này đúng nghĩa trong vài ngày. Lý do là họ đã nộp đơn vào YC với một ý tưởng rất khác. Họ bắt đầu với một Twitter referral widget, ý tưởng đó không thành, và họ nhanh chóng hiểu vì sao. Nên họ ghép rất nhanh prototype này.

Theo lời kể của Diana (video đăng ngày 21/04/2023), hai founder là Pete và Dan; Dan thật ra đã phụ trách analytics cho chiến dịch tranh cử của Obama, và anh nhớ lại lần được gọi đến để tối ưu một trang gây quỹ, rồi nghĩ: "hừm, cái này có thể thành một startup". Thế là họ ghép nó lại rất nhanh.

Đó là visual editor đầu tiên, theo Diana (video đăng ngày 21/04/2023): nó tạo một A/B test, chỉ là một file JavaScript nằm trên S3. Chị nói đúng nghĩa là bạn mở Option Command J nếu bạn đang ở Chrome, và các founder chạy A/B test đó thủ công ở đó, và nó chạy được. Tất nhiên không ai dùng được nó ngoài các founder, nhưng nó đủ để cho các marketer, những target user cần tối ưu site, xem và khiến họ hào hứng. Thứ này được build chỉ trong vài ngày.

Ví dụ khác là startup của chính Diana, Escher Reality. Theo chị (video đăng ngày 21/04/2023), vì chị và nhóm build thứ hard tech hơn, chị và nhóm phải đưa các thuật toán computer vision chạy được trên điện thoại, và đã làm xong việc đó trong vài tuần. Như bạn thấy trong video demo, cho người ta xem một demo về AR là gì dễ hơn rất nhiều so với việc giải thích và khua tay, và nó khiến việc bán hàng và giải thích dễ hơn rất nhiều.

5. Những sai lầm thường gặp với prototype

Theo Diana (video đăng ngày 21/04/2023), sai lầm thường gặp đầu tiên với prototype là bạn không nên build quá mức ở giai đoạn này. Chị đã thấy người ta có thiên hướng đó và nói với chị: "Diana, nhưng user không thấy được nó, hoặc prototype này chưa đủ tốt, nó không cho thấy toàn bộ tầm nhìn." Theo chị, đây là sai lầm khi founder nghĩ cần một MVP đầy đủ ở giai đoạn này, và thật ra không phải vậy.

Sai lầm khác, theo Diana (video đăng ngày 21/04/2023), hiển nhiên là không nói chuyện hay không lắng nghe user đủ sớm. Bạn sẽ thấy không thoải mái khi đem cho người ta xem thứ prototype chắp vá mà bạn vừa ghép vội, và điều đó không sao cả. Bạn sẽ nhận được feedback.

Sai lầm còn lại ở giai đoạn này, theo Diana (video đăng ngày 21/04/2023), và ví dụ là Optimizely: khi founder quá gắn bó với ý tưởng, khi feedback từ user khá rõ ràng là nó chưa tới, không phải thứ user muốn, mà vẫn không buông bỏ ý tưởng tồi.

6. Giai đoạn 2: xây MVP, và có nên tuyển người lúc này

Phần tiếp theo: hãy hình dung bạn đã có prototype, bạn đã nói chuyện với mọi người, và có đủ sự quan tâm. Khi đó bạn chuyển sang giai đoạn tiếp theo, thật sự xây một MVP chạy được để đưa tới launch. Theo Diana (video đăng ngày 21/04/2023), mục tiêu về cơ bản là build để launch, và việc này cũng nên được làm rất nhanh: có thể trong vài ngày đến vài tuần, đôi khi vài tháng, nhưng lý tưởng là trong khoảng vài tuần với phần lớn công ty phần mềm. Một lần nữa, hardware và deep tech là ngoại lệ.

Mục tiêu ở giai đoạn này, theo Diana (video đăng ngày 21/04/2023), là build thứ gì đó mà bạn nhận được cam kết từ user rằng họ sẽ dùng sản phẩm. Và lý tưởng thì cam kết đó trông như việc họ trả tiền. Lý do bạn có prototype là trong lúc bạn build, co-founder hay CEO của bạn có thể nói chuyện với user, cho họ xem prototype, và thậm chí nhận cam kết rằng họ sẽ dùng nó khi nó sẵn sàng launch.

Diana rẽ sang một chuyện bên lề, vì đôi khi founder quá hào hứng: "Tôi đã cho xem prototype, mọi người hào hứng, và có quá nhiều thứ phải build. Tuyển người có phải ý hay không?" Với một founder lần đầu, cảm giác là: "trời ơi, có fit rồi, người ta muốn nó". Theo chị (video đăng ngày 21/04/2023), có phải ý hay không thì thật sự tùy. Nó thật ra sẽ làm bạn chậm lại trong việc launch nhanh. Vì nếu bạn tuyển từ một nhóm người, những engineer mà bạn không quen, sẽ mất hơn một tháng hoặc lâu hơn để tìm được một người giỏi. Và rất khó tìm người ở giai đoạn này, khi mọi thứ còn rất mơ hồ và hỗn loạn.

Nên nó sẽ khiến bạn di chuyển chậm, theo Diana (video đăng ngày 21/04/2023). Và điều âm thầm nguy hiểm hơn là nó khiến bạn không phát triển được một số insight về sản phẩm, vì sản phẩm của bạn sẽ thay đổi. Nếu một người khác trong team build phần đó chứ không phải các founder, bạn sẽ bỏ lỡ bài học then chốt đó, thứ có thể chứa một hạt vàng, nhưng nó không do bạn build. Chị nói có ngoại lệ: bạn có thể tuyển muộn hơn một chút, khi mọi thứ đã được build ra nhiều hơn, nhưng ở giai đoạn này thì việc đó vẫn khó.

7. Justin.tv và Twitch: các founder tự viết MVP

Diana đưa một ví dụ (theo lời kể trong video đăng ngày 21/04/2023): Justin.tv và Twitch. Lúc đó chỉ có bốn founder, trong đó có ba technical founder rất giỏi. Ở thời điểm đầu, với MVP, chỉ có các founder build phần mềm với tư cách software engineer. Và điều kỳ diệu là Justin, Emmett và Kyle build những phần khác nhau của hệ thống. Kyle trở thành một engineer xuất sắc, không biết sợ, xử lý những bài toán khó của video streaming. Emmett làm toàn bộ phần database, Justin làm phần web. Và chừng đó là đủ để đưa nó tới launch.

Diana cũng đưa ra một ngoại lệ (theo lời kể trong video đăng ngày 21/04/2023): sau khi launch, họ đã tuyển những engineer giỏi. Nhưng điều then chốt là họ rất giỏi ở chỗ không quan tâm đến CV. Họ thật sự cố tìm những người "lạc loài", những engineer mà Google bỏ qua, và những người đó hoá ra rất xuất sắc. Chị kể hai engineer như vậy rất thoải mái trong công việc và rất giỏi, và họ đã đảm nhận phần lớn phần video web chỉ trong ba tháng kể từ khi vào. Theo chị, bạn muốn những người như vậy, những người có thể tự cất cánh và chạy.

8. Nguyên tắc 1: Do things that don't scale, và ví dụ Stripe

Quay lại các nguyên tắc để build tới MVP. Nguyên tắc thứ nhất, theo Diana (video đăng ngày 21/04/2023), là essay kinh điển của Paul Graham, "Do Things That Don't Scale". Về cơ bản, hãy tìm những mẹo khéo léo để launch nhanh, theo tinh thần làm những việc không scale.

Và trong phiên bản meme Drake của ý này, theo Diana (video đăng ngày 21/04/2023): tránh những thứ như self-onboarding tự động, vì nó đòi hỏi rất nhiều engineering; tránh build một backend scalable, tránh các script tự động. Những thứ đó nghe hay vào một lúc nào đó, nhưng không phải ở giai đoạn này. Mẹo thay thế có thể là onboarding thủ công: bạn đúng nghĩa là sửa database và tự thêm user, các bản ghi và dữ liệu vào. Và một điều ngược trực giác nữa là hỗ trợ khách hàng một cách "điên rồ": chỉ có bạn, các founder, ở tuyến đầu làm việc, làm những việc không scale.

Một ví dụ kinh điển là Stripe (theo lời kể trong video đăng ngày 21/04/2023). Diana cho xem trang web lúc họ launch: rất đơn giản. Họ có API để developer gửi thanh toán. Nhưng ở backend, thứ không scale là đúng nghĩa các founder tự xử lý từng yêu cầu thủ công và điền các mẫu đơn ngân hàng để xử lý thanh toán lúc ban đầu. Và như vậy là đủ tốt để giúp họ launch sớm hơn.

9. Nguyên tắc 2: giải pháp 90/10

Nguyên tắc thứ hai, theo Diana (video đăng ngày 21/04/2023), là "giải pháp 90/10" nổi tiếng, một khái niệm do Paul Buchheit đặt ra; chị giới thiệu ông là một trong các group partner ở YC và là người tạo ra Gmail ban đầu.

Hãy nhớ, theo Diana (video đăng ngày 21/04/2023), phiên bản đầu tiên sẽ không phải phiên bản cuối, và rất có thể nhiều phần code sẽ bị viết lại, và điều đó không sao. Hãy đẩy càng nhiều tính năng càng tốt sang sau launch. Và khi nói launch nhanh bằng một giải pháp 90/10, chị không có ý là tạo ra bug. Bạn vẫn muốn nó đủ tốt, nhưng bạn muốn giới hạn sản phẩm để nó chạy trên một số chiều hạn chế: có thể là tình huống, loại dữ liệu bạn xử lý, chức năng, loại user bạn hỗ trợ, số lượng thiết bị, hoặc vùng địa lý.

Hãy tìm cách cắt bài toán ra để đơn giản hoá nó, theo Diana (video đăng ngày 21/04/2023). Và đây có thể là siêu năng lực bí mật của bạn với tư cách một startup lúc ban đầu, vì bạn có thể di chuyển nhanh hơn rất nhiều. Các công ty lớn không thể làm vậy. Hoặc ngay cả khi startup của bạn đã lớn, bạn có luật sư, đội tài chính, đội sales, những thứ khiến bạn di chuyển chậm lại. Dòng chữ hiện lên lúc chị nói ý này ghi "Start off with limited features".

10. DoorDash: Palo Alto Delivery dựng trong một buổi chiều

Diana đưa ví dụ DoorDash (theo lời kể trong video đăng ngày 21/04/2023). Lúc đầu, họ ghép nó trong một buổi chiều, và họ thật ra có tên là Palo Alto Delivery. Họ lấy các file PDF thực đơn, và đúng nghĩa là để số điện thoại của mình lên đó; số điện thoại đó là của một trong các founder. Và site không dynamic mà là static.

Theo lời kể của Diana (video đăng ngày 21/04/2023), frontend của họ đúng nghĩa chỉ là HTML, CSS thuần và PDF. Họ không buồn build backend. Cái "backend", trong ngoặc kép, đúng nghĩa chỉ là Google Forms và Google Docs, nơi họ điều phối mọi đơn hàng. Và họ thậm chí không build thứ gì để theo dõi tài xế hay ETA. Họ làm việc đó bằng Find My Friends trên iPhone để theo dõi từng đơn giao đang ở đâu. Như vậy là đủ.

Thứ này được ghép lại đúng nghĩa trong một buổi chiều, và họ đã launch được (theo lời kể trong video đăng ngày 21/04/2023). Điều rất thiên tài họ làm, theo Diana, là vì họ là sinh viên Stanford, họ giới hạn để nó chỉ chạy ở Palo Alto. Và ngược trực giác, việc tập trung vào Palo Alto và làm cho đúng ở đó trong lúc lớn lên đã giúp họ tập trung và làm đúng việc giao hàng và unit economics ở vùng ngoại ô ngay từ đầu, để họ có thể scale điều đó và làm đúng, so với đối thủ, vốn tập trung vào các thành phố lớn. Chị nói bạn đã thấy câu chuyện diễn ra thế nào: với đối thủ, unit economics và vận hành khó hơn nhiều, và họ đã không làm đúng được.

Theo Diana (video đăng ngày 21/04/2023), điều thú vị là việc tập trung ngay từ đầu và làm đúng những thứ đó có thể giúp bạn tập trung và làm đúng những việc mà về sau sẽ phục vụ bạn tốt.

11. Chọn tech stack theo tốc độ iterate

Ở giai đoạn này, chọn tech stack thế nào? Theo Diana (video đăng ngày 21/04/2023), một điều là cân bằng giữa thứ hợp lý cho sản phẩm của bạn và chuyên môn cá nhân của bạn, để ship nhanh nhất có thể. Hãy giữ nó đơn giản. Đừng chọn một ngôn ngữ lập trình mới, hay ho chỉ để học nó cho startup của bạn. Hãy chọn thứ mà bạn đủ "nguy hiểm" và đủ thoải mái để launch nhanh.

Điều đó dẫn tới nguyên tắc tiếp theo, theo Diana (video đăng ngày 21/04/2023): chọn tech vì tốc độ iterate. Và một điều nữa: rất dễ build MVP thật nhanh bằng các framework và công cụ API bên thứ ba, và bạn không cần tự làm nhiều phần việc đó. Ví dụ: authentication thì có những thứ như Auth0; thanh toán thì có Stripe; hỗ trợ đa nền tảng và rendering thì có những thứ như React Native; cloud infrastructure thì có AWS, GCP; landing page thì có Webflow; backend, serverless thì có Lambda, Firebase hay database dạng hosted.

Theo Diana (video đăng ngày 21/04/2023), trong quá khứ các startup hết tiền trước cả khi launch, vì họ phải build mọi thứ từ đầu. Đừng cố làm kiểu engineer "ngầu", cứ build mọi thứ từ đầu. Không, hãy dùng tất cả những framework này. Nhưng chị biết có những CTO nói với chị: "dùng API bên thứ ba này đắt quá", hoặc "dùng XYZ thì chậm quá".

Với điều này, chị nói (video đăng ngày 21/04/2023) chuyện dùng bên thứ ba có hai mặt. Ý chị là dùng để di chuyển nhanh, nhưng không có nghĩa là thế này, và chị đưa ra một meme mà chị gọi là rất hay, do head of developer experience của Airbyte đăng.

12. Noob, mid và Jedi master: chuyện PHP của Facebook

Diana giải thích meme (video đăng ngày 21/04/2023). Điều buồn cười là ở phần đầu đường phân phối, bạn có kiểu "noob", người vừa học PHP hay chỉ JavaScript và dùng nó để build chiếc xe đồ chơi. Có những engineer chế giễu người mới vì "PHP không scale", hay JavaScript, đủ thứ: "PHP không phải ngôn ngữ tốt, blah blah blah".

Rồi ở giữa là engineer trung bình, theo cách Diana tả (video đăng ngày 21/04/2023): người nói "được rồi, tôi sẽ mặc quần engineer người lớn vào và làm như Google sẽ làm", build một thứ tối ưu và scalable, dùng cho backend những thứ như Kafka, Rust, Prometheus, Kubernetes, Envoy, hay hàng trăm microservice. Đó là technical founder trung bình. Và startup trung bình thì chết. Nên đó không phải kết cục tốt.

Điều buồn cười là, theo Diana (video đăng ngày 21/04/2023), bạn có Jedi master. Và khi nheo mắt nhìn, giải pháp của họ trông giống hệt của người mới. Họ cũng chọn PHP và JavaScript, nhưng chọn vì lý do khác: không phải vì họ vừa học nó, mà vì họ nhận ra như vậy họ có thể di chuyển nhanh hơn rất nhiều. Điều chị muốn nhấn mạnh là nếu bạn build một công ty và nó chạy được, bạn có đủ user, thì các lựa chọn tech không còn quan trọng đến thế. Bạn có thể giải quyết để thoát ra.

Ví dụ Diana đưa (theo lời kể trong video đăng ngày 21/04/2023): Facebook nổi tiếng là được build trên PHP vì Mark rất quen với nó. Và tất nhiên PHP không hẳn scale hay không hiệu năng lắm. Nhưng nếu bạn là Facebook và đạt tới quy mô số user như vậy, bạn có thể giải quyết để thoát ra. Đó là lúc họ build một transpiler riêng tên HipHop để biên dịch PHP sang C++ cho tối ưu. Chị gọi đó là một nước đi Jedi. Và ngay cả với JavaScript, theo chị, có V8 engine khiến nó khá hiệu năng, nên chị nghĩ như vậy là ổn.

13. WayUp, và lựa chọn tech gắn với lời hứa với khách hàng

Diana kể về WayUp (theo lời kể trong video đăng ngày 21/04/2023): một công ty YC năm 2015, giúp các công ty tuyển dụng và là một job board cho sinh viên đại học. JJ, CTO, dù không học chính quy khoa học máy tính hay kỹ thuật ở UPenn, đã tự học lập trình và làm freelance vài năm trước khi bắt đầu WayUp.

Và JJ, một lần nữa như một Jedi master, đã chọn công nghệ vì tốc độ iterate, theo Diana (video đăng ngày 21/04/2023). Anh chọn Django và Python, dù nhiều người cùng thời bảo anh nên dùng Ruby on Rails. Diana nghĩ vào năm 2015, Ruby on Rails phổ biến gấp 10 lần theo Google Trends. Và điều đó vẫn ổn, nó hoàn toàn không giết công ty. Theo chị, đó là lựa chọn đúng với họ vì có thể di chuyển nhanh và đưa sản phẩm ra cửa rất nhanh. Backend được giữ đơn giản: Postgres, Python, Heroku, và nó đã chạy tốt với họ.

Diana tóm lại (video đăng ngày 21/04/2023): những lựa chọn tech duy nhất quan trọng là những lựa chọn gắn với lời hứa với khách hàng của bạn. Ví dụ, ở Escher, chị và nhóm thật ra đã viết lại và vứt bỏ rất nhiều code, nhiều lần, khi scale qua các giai đoạn khác nhau của công nghệ. Nhưng lời hứa mà chị và nhóm giữ với khách hàng nằm ở tầng API trong Unity và các game engine. Đó là thứ không thể vứt bỏ. Còn mọi thứ khác, chị và nhóm viết lại, và điều đó không sao.

14. Giai đoạn 3, Launch: iterate với hard data và soft data

Phần ba: bạn đã có MVP, bạn đã build và launch nó. Ở giai đoạn này điều gì xảy ra? Theo Diana (video đăng ngày 21/04/2023), mục tiêu ở giai đoạn launch là iterate để tiến tới product market fit. Nguyên tắc thứ nhất là iterate nhanh với hard data và soft data.

Với hard data, theo Diana (video đăng ngày 21/04/2023), là technical founder, bạn hãy đảm bảo đã dựng một dashboard với analytics theo dõi KPI chính. Và một lần nữa, hãy chọn công nghệ cho analytics stack theo tốc độ. Giữ nó cực kỳ đơn giản: những thứ như Google Analytics, Amplitude, Mixpanel. Đừng làm quá với những thứ cực kỳ phức tạp như Logstash, Prometheus. Theo chị, những thứ đó rất tốt cho công ty lớn, nhưng không phải ở giai đoạn của bạn; bạn chưa có tải đó.

Còn soft data, theo Diana (video đăng ngày 21/04/2023): hãy tiếp tục nói chuyện với user sau khi launch, và kết hợp hai loại dữ liệu này để biết vì sao user ở lại hay rời đi, và hỏi để tìm ra những vấn đề mới mà user có, để iterate và build.

Diana kể về WePay (theo lời kể trong video đăng ngày 21/04/2023), một công ty YC khác. Khi launch, họ là một sản phẩm thanh toán B2C, hơi giống Venmo. Nhưng nó không bao giờ thật sự cất cánh. Họ đã iterate. Về analytics, họ thấy một số tính năng đã launch, như nhắn tin, không ai quan tâm, không ai dùng. Và họ phát hiện ra rằng, xét về lượng thanh toán, user lớn nhất của họ khi đó là GoFundMe.

Họ cũng nói chuyện với user, theo lời kể của Diana (video đăng ngày 21/04/2023). Họ nói chuyện với GoFundMe, bên không quan tâm gì đến phần giao diện B2C này; GoFundMe chỉ quan tâm đến việc nhận được thanh toán. Và rồi WePay phát hiện ra một cơ hội tốt hơn là trở thành một API, và về cơ bản đã pivot sang đó. Họ làm phiên bản đầu tiên, một lần nữa áp dụng nguyên tắc làm những việc không scale: họ thậm chí không có tài liệu kỹ thuật, và họ làm việc với GoFundMe để có phiên bản này. Và phiên bản API này mới là thứ thật sự cất cánh và đưa họ tới product market fit.

15. Liên tục launch: câu chuyện Segment

Nguyên tắc thứ hai trong giai đoạn launch, theo Diana (video đăng ngày 21/04/2023), là liên tục launch. Ví dụ hoàn hảo là Segment, công ty khởi đầu với một sản phẩm rất khác: analytics cho lớp học. Câu chuyện tương tự: họ vật lộn với ý tưởng đầu tiên này, và nó không thật sự thành công cho tới khi họ launch một phiên bản rút gọn chỉ gồm phần backend, thứ chính là Segment.

Theo lời kể của Diana (video đăng ngày 21/04/2023), hãy nhìn số lần launch ấn tượng của họ. Lần launch đầu tiên là từ tháng 12/2012, bài đăng đầu tiên của họ, và bạn thấy mức tương tác trên Hacker News rất cao. Theo chị, đó là một chút dấu hiệu của product market fit. Họ hào hứng, pivot sang hướng này, và tiếp tục launch hằng tuần.

Theo Diana (video đăng ngày 21/04/2023), họ có tổng cộng năm lần launch trong khoảng một tháng. Và họ tiếp tục thêm tính năng và iterate, thêm hỗ trợ cho nhiều thứ hơn. Khi launch, nó chỉ hỗ trợ Google Analytics, Mixpanel và Intercom. Và nhờ lắng nghe user, họ thêm hỗ trợ Node, PHP, WordPress, và cứ thế tiếp tục. Điều đó đưa họ thành một unicorn, rồi cuối cùng exit bằng việc bán cho Twilio với giá hơn 3 tỷ đô (theo lời kể trong video đăng ngày 21/04/2023). Chị gọi đó là khá ấn tượng.

16. Cân bằng giữa build và fix: Pokemon Go

Nguyên tắc cuối cùng khi bạn launch, theo Diana (video đăng ngày 21/04/2023): có một trạng thái buồn cười khi bạn vừa build tech. Bạn muốn cân bằng giữa build và fix. Bạn muốn đưa ra những lựa chọn có cân nhắc giữa sửa bug, thêm tính năng mới hay xử lý technical debt. Và điều chị muốn nói là tech debt hoàn toàn ổn.

Bạn sẽ quen một chút với cái nóng của tech đang cháy, theo Diana (video đăng ngày 21/04/2023). Hoàn toàn ổn. Bạn sẽ sợ đúng những thứ cần sợ, và đó là những thứ đưa bạn tới product market fit. Đôi khi một bug nhỏ về rendering có lẽ không quan trọng để sửa ở thời điểm này. Thật ra, rất nhiều sản phẩm đời đầu hỏng rất nặng.

Diana kể (theo lời kể trong video đăng ngày 21/04/2023): có lẽ bạn rất quen với Pokemon Go khi nó launch năm 2016. Không ai đăng nhập vào game được. Và đoán xem? Điều đó hoàn toàn không giết công ty. Thật ra, chị nghĩ cho đến nay, năm ngoái (tính từ video đăng ngày 21/04/2023) Pokemon đã làm ra hơn một tỷ đô doanh thu. Điều đó không giết họ.

Chị giải thích một chút bối cảnh về chuyện đã xảy ra với tech (theo lời kể trong video đăng ngày 21/04/2023). Nó khá đơn giản. Họ có một load balancer trên Google Cloud, một backend, và việc TCP termination cùng các HTTP request được làm bằng Nginx để route tới các server khác nhau, tức các AFE, application frontend, để quản lý mọi request.

Vấn đề ở đó, theo Diana (video đăng ngày 21/04/2023), là khi user kết nối, các kết nối không bị terminate cho tới khi tới được Nginx. Và hệ quả là client cũng retry. Đó là điều xảy ra khi có tải khổng lồ như vậy. Thật ra, chị nghĩ Pokemon Go, chỉ trong tháng đầu tiên sau launch, đã có số người dùng hoạt động ngang Twitter, thứ mà Twitter mất 10 năm để đạt được, còn họ đạt được trong một tháng (theo lời chị trong video đăng ngày 21/04/2023).

Tất nhiên mọi thứ sẽ hỏng, theo Diana (video đăng ngày 21/04/2023). Về cơ bản là rất nhiều user cố đăng nhập, và nó tạo ra một kiểu tấn công DDoS.

17. Sai lầm sau launch, và vai trò thay đổi sau product market fit

Diana tóm lại một chút về lúc launch, với một số sai lầm thường gặp sau khi launch, và chị nói chính chị cũng từng mắc, từng làm "CTO Doge" buồn (video đăng ngày 21/04/2023). Rất dễ bị cám dỗ build và hỏi "Google sẽ làm gì?". Theo chị, đó gần như chắc chắn là một cái bẫy: cố build như một công ty lớn, hoặc tuyển người để cố di chuyển nhanh; chị nói câu hỏi tuyển người này có nhiều sắc thái hơn, nó có thể là một sai lầm.

Sai lầm khác, theo Diana (video đăng ngày 21/04/2023), là tập trung quá nhiều vào việc sửa, refactor mà không build tính năng để iterate tới product market fit, không khám phá insight từ user. Đôi khi chị thấy CTO nói "được rồi, mình launch rồi, giờ tôi được cắm đầu vào build". Chị nói hoàn toàn không. Một lần nữa, vai trò technical founder của bạn rất khác. Bạn sẽ tham gia vào hành trình và thật sự hiểu insight về lý do user ở lại hay rời bỏ sản phẩm. Bạn phải tiếp tục nói chuyện với họ.

Và sai lầm khác chị thấy, theo Diana (video đăng ngày 21/04/2023), là kiểu "chúng tôi chỉ build tính năng cho sản phẩm". Nhưng bạn cũng cần build tech để tăng trưởng. Thật ra, theo chị, một số growth hack hay nhất là do engineer kết hợp với những người làm sales và growth không có nền tảng kỹ thuật.

Phần cuối là vai trò thay đổi thế nào. Giả sử bạn đã đạt product market fit, điều gì xảy ra? Theo Diana (video đăng ngày 21/04/2023), đây là thời điểm bạn thật sự có thể mặc quần engineer người lớn vào và tìm ra những phần tech cần được build để scale. Tech sẽ hỏng, và đó thật ra là chuyện tốt, hỏng vì quá nhiều nhu cầu. Hoàn toàn ổn; đó là ví dụ Pokemon Go của chị. Bạn sẽ tìm ra những phần cần làm lại, refactor. Đây là lúc làm việc đó, chứ không phải trước product market fit.

Bạn cũng sẽ quyết định engineering culture trông như thế nào, theo Diana (video đăng ngày 21/04/2023). Và đây là giai đoạn bạn thật sự tuyển người nhiều hơn. Có lẽ bạn sẽ chuyển từ dẫn dắt một team engineer nhỏ sang tuyển dụng. Những người đầu tiên bạn tuyển sẽ là những người bạn quen. Và ở điểm này vai trò của bạn thật sự thay đổi, vì bạn bắt đầu có chi phí giao tiếp (communication overhead).

Đây là lúc bạn nhận ra vai trò của mình biến đổi, theo Diana (video đăng ngày 21/04/2023). Với 2 đến 5 engineer, bạn vẫn có khoảng 70% thời gian để code. Khi lên 5 đến 10, bạn chỉ còn dưới 50%. Và trên 10, có lẽ bạn sẽ không thật sự còn thời gian để code, và phải quyết định cách tổ chức mọi thứ, và bạn muốn tiếp tục ở vai trò kiểu kiến trúc sư hay muốn thiên về vai trò con người hơn.

18. Tóm tắt: startup di chuyển nhanh

Diana tóm tắt bài giảng (video đăng ngày 21/04/2023). Giai đoạn một, ideating: mục tiêu là build một prototype càng sớm càng tốt, và nguyên tắc là build rất nhanh, trong vài ngày.

Giai đoạn hai, theo Diana (video đăng ngày 21/04/2023), là quá trình xây MVP, giai đoạn mà chị nghĩ nhiều bạn đang ở, hoặc ở giai đoạn trước đó. Mục tiêu là build thật nhanh để launch trong vài tuần. Các nguyên tắc là làm những việc không scale, tạo một giải pháp 90/10, và chọn tech vì tốc độ iterate.

Và giai đoạn cuối, khi bạn đã launch, theo Diana (video đăng ngày 21/04/2023): mọi ý trước đó về giải pháp 90/10 và làm những việc không scale vẫn áp dụng, và bạn thêm những điều này vào. Mục tiêu là iterate để tới product market fit. Bạn sẽ iterate nhanh với hard data và soft data, bằng analytics và phỏng vấn user. Bạn sẽ liên tục launch. Và bạn sẽ tìm sự cân bằng tinh tế giữa build và fix, nơi tech debt hoàn toàn ổn. Cảm nhận cái nóng của tech debt đó, hoàn toàn ổn.

Và nếu chỉ có một điều rút ra từ cả bài giảng, theo Diana (video đăng ngày 21/04/2023), thì đó là: startup di chuyển nhanh. Chị cảm ơn mọi người.