# Michael Seibel: cách lên kế hoạch cho một MVP

[Michael Seibel](https://homus.dev/speakers/michael-seibel) · [Y Combinator](https://homus.dev/orgs/y-combinator)

> Bài giảng Startup School 2019: MVP là gì, launch nhanh, lean và heavy MVP qua Airbnb, Twitch, Stripe, và mẹo timebox, viết, cắt spec.

Topics: MVP, Startups

Canonical: https://homus.dev/talks/michael-seibel-how-to-plan-an-mvp

## 1. MVP là một thứ cực kỳ đơn giản

Đây là một bài giảng trong Startup School của Y Combinator, do Michael Seibel trình bày; mô tả video ghi anh là "YC CEO and Partner" (theo mô tả video đăng ngày 01/08/2019). Michael tự giới thiệu: anh làm việc ở Y Combinator và giúp điều hành chương trình accelerator. Trước đó, anh đã làm hai startup qua YC, một vào năm 2007 và một vào năm 2012 (theo lời anh trong video đăng ngày 01/08/2019).

![Michael Seibel cầm micro đứng sau bục trong suốt, phía sau là tường gạch và màn chiếu slide](https://homus.dev/photos/1hHMwLxN6EM-0103.jpg)

Michael Seibel đứng giảng trước tường gạch, trong video đăng ngày 01/08/2019; trên màn chiếu phía sau là slide về việc nói chuyện với user trước khi viết code.

Hôm nay anh nói về minimum viable product, gọi tắt là MVP. Anh nói: anh và các đồng nghiệp ở YC lúc nào cũng la founder đừng dùng jargon, vậy mà lại có cả một bộ jargon startup ngớ ngẩn, và MVP là một trong số đó (video đăng ngày 01/08/2019).

Theo Michael (video đăng ngày 01/08/2019), khi nghĩ về một MVP, bạn nên nghĩ tới một thứ đơn giản tới mức buồn cười. Đó là thứ đầu tiên bạn có thể đưa cho nhóm user đầu tiên mà bạn muốn nhắm tới, để xem bạn có mang lại được chút giá trị nào cho họ hay không. Chỉ có vậy thôi. Nó cực kỳ đơn giản.

![Slide tiêu đề: Startup School 2019, MVP (Minimum Viable Product)](https://homus.dev/photos/1hHMwLxN6EM-0011.jpg)

Slide mở đầu trong video đăng ngày 01/08/2019: "Startup School 2019" và dòng phụ "MVP (Minimum Viable Product)", góc dưới có logo Y màu cam.

## 2. Nói chuyện với user trước khi viết code

Điều Michael muốn nói là việc nói chuyện với một vài user trước khi quyết định build MVP là có ích (theo Michael, video đăng ngày 01/08/2019). Điều đó không có nghĩa là bạn phải lao vào một cuộc nghiên cứu kéo dài ba năm, hay phải làm trong ngành mười năm. Nhưng vài cuộc trò chuyện thì có ích. Còn có ích hơn nữa nếu chính bạn là user của mình, vì khi đó bạn tự biết sản phẩm có đang hiệu quả với bạn hay không.

![Slide chữ đen trên nền trắng về việc hiểu vấn đề và nói chuyện với user](https://homus.dev/photos/1hHMwLxN6EM-0042.jpg)

Slide trong video đăng ngày 01/08/2019: "Some understanding of the problem is very helpful when building an MVP so please talk to your users before writing code."

Michael kể anh hay gặp một câu hỏi lạ: "làm sao để có những user đầu tiên?". Câu hỏi đó luôn làm anh hơi khó hiểu, vì về lý thuyết bạn quyết định giải một vấn đề mà bạn biết là có người đang gặp. Vậy nên cách để có user đầu tiên là nói chuyện với chính người mà bạn biết đang có vấn đề đó. Và nếu người đó là bạn thì còn dễ hơn (theo Michael, video đăng ngày 01/08/2019).

Theo anh (video đăng ngày 01/08/2019), nếu bạn đang build sản phẩm cho một nhóm user bí ẩn mà bạn không hề biết họ là ai, thì hãy tự đặt câu hỏi về điều đó một chút, rất nhẹ thôi.

## 3. Mục tiêu của một startup chưa launch

Theo Michael (video đăng ngày 01/08/2019), mục tiêu của một startup chưa launch cực kỳ đơn giản. Bước một: launch nhanh. Đây là điều đã nằm trong tinh thần của YC ngay từ đầu; anh nói đó là lời khuyên tuyệt vời suốt mười năm và vẫn tiếp tục là lời khuyên tuyệt vời.

Nếu chỉ mang về được một điều từ bài trình bày này, thì theo Michael đó là: launch một thứ còn tệ, thật nhanh. Vậy thôi. Anh nói phần còn lại anh sắp trình bày về cơ bản chỉ là những phiên bản tóm lại khác nhau của chính điều đó (video đăng ngày 01/08/2019).

![Slide Goal of a pre-launch startup với bốn gạch đầu dòng](https://homus.dev/photos/1hHMwLxN6EM-0336.jpg)

Slide trong video đăng ngày 01/08/2019, "Goal of a pre-launch startup:", với bốn ý: "Launch quickly (MVP)", "Get initial customers", "Talk to customers and get feedback", "Iterate (improve the product)".

Việc thứ hai một startup giai đoạn đầu cần làm là có vài khách hàng ban đầu (theo Michael, video đăng ngày 01/08/2019). Có được bất kỳ ai dùng sản phẩm của bạn. Bạn không cần có tầm nhìn về cách để mọi người cùng dùng nó, chỉ cần có ai đó tương tác với sản phẩm và xem họ có lấy được giá trị từ nó hay không.

Theo Michael (video đăng ngày 01/08/2019), bạn sẽ ngạc nhiên khi thấy hành trình của rất nhiều founder kết thúc trước cả khi có một user nào thật sự tương tác với sản phẩm họ tạo ra. Chuyện này rất, rất phổ biến. Vì vậy anh nhờ mọi người hãy vượt qua bước này, vì nó cực kỳ quan trọng.

## 4. Feedback và iterate: giữ người thợ, sửa cái tua vít

Việc tiếp theo, theo Michael (video đăng ngày 01/08/2019), là nói chuyện với user của bạn, bất kỳ ai trong số họ, sau khi đã launch MVP, và lấy feedback. Đây cũng là một sai lầm cực kỳ phổ biến.

Lý do anh đưa ra (video đăng ngày 01/08/2019): phần lớn founder có sẵn trong đầu ý tưởng về thứ họ muốn build. Thế nên họ có một cảm giác kỳ lạ rằng nếu chưa build xong toàn bộ thì lấy feedback về cái bản đầu tiên tồi tàn cũng vô ích. Dĩ nhiên là nó sẽ không chạy, nó đâu phải là bản đầy đủ. Bản đầy đủ sẽ cần ba năm, 10 triệu đô và cả một đội. Vậy nên feedback về cái bản nhỏ là vô ích.

Thực tế, theo Michael (video đăng ngày 01/08/2019), ở một mức nào đó bản đầy đủ là một ý tưởng thật tuyệt trong đầu bạn mà bạn nên giữ trong đầu, nhưng nó phải rất, rất linh hoạt, vì có thể hoá ra thứ đầy đủ bạn muốn build hoàn toàn không phải là thứ khách hàng muốn. Anh có một câu: hãy giữ chặt vấn đề bạn đang giải, giữ chặt khách hàng, và giữ lỏng giải pháp bạn đang build.

Và cuối cùng, quan trọng nhất theo anh: iterate (video đăng ngày 01/08/2019). Michael thích phân biệt giữa iterate và pivot. Nhiều founder, khi đã tìm ra cách build một thứ gì đó, liền yêu nó. Thế nên nếu nó không hiệu quả với một nhóm user nào đó, họ bắt đầu nghĩ: không biết thứ này còn giải được vấn đề nào khác.

Michael lấy ví dụ cái tua vít (video đăng ngày 01/08/2019): cái tua vít thật ra vặn vít chẳng tốt chút nào, nhưng không biết nó còn giải được vấn đề gì khác. Rồi họ nghĩ: có khi dùng nó để nấu ăn. Có khi dùng nó để lau dọn. Anh nói: không, vấn đề là "tôi cần vặn một con vít". User là một người thợ máy. Và nếu cái tua vít của bạn không giúp người thợ máy giải được vấn đề đó, thì hãy giữ người thợ, giữ vấn đề "tôi cần vặn một con vít", và sửa cái tua vít chết tiệt đó đi.

Theo Michael (video đăng ngày 01/08/2019), đó mới là thứ bị hỏng. Thứ bị hỏng không phải người thợ máy, cũng không phải việc họ cần vặn một con vít. Vậy nên hãy iterate: tiếp tục cải thiện giải pháp của bạn cho tới khi nó thật sự giải được vấn đề.

Câu Michael nói và ví dụ cái tua vít trong video đăng ngày 01/08/2019: giữ chặt khách hàng và vấn đề, giữ lỏng giải pháp; khi tua vít không giúp được người thợ máy thì sửa tua vít, không đổi người thợ hay vấn đề.

## 5. Lean MVP, trong phần lớn trường hợp

Theo Michael (video đăng ngày 01/08/2019), trong phần lớn trường hợp, hầu hết mọi người nên build một MVP rất lean. Ý của anh và các đồng nghiệp ở YC là bạn phải build được nó nhanh, tính bằng tuần chứ không phải bằng tháng. Nó có thể là phần mềm, hoặc, nói thật, anh và các đồng nghiệp ở YC thấy có startup bắt đầu chỉ với một landing page và một spreadsheet. Phần lớn startup có thể bắt đầu rất, rất nhanh.

Thứ hai, chức năng cực kỳ hạn chế (theo Michael, video đăng ngày 01/08/2019). Bạn cần cô đọng những gì user cần, những gì user ban đầu của bạn cần, thành một tập rất đơn giản. Nhiều khi founder muốn giải quyết mọi vấn đề của user, và của mọi user tiềm năng. Trong khi thực tế họ chỉ nên tập trung vào một nhóm nhỏ user ban đầu và những vấn đề quan trọng nhất của nhóm đó, rồi bỏ qua phần còn lại cho tới sau này.

Theo anh (video đăng ngày 01/08/2019), bạn nên có một tầm nhìn cho tất cả mọi người, nhưng MVP thì phải rất nhỏ. Tất cả những gì nó là chỉ là một cái nền để iterate. Vậy thôi. Nó chỉ là điểm khởi đầu, không đặc biệt gì cả. Bạn chỉ cần bắt đầu. Vì thế anh nhờ mọi người đừng cảm thấy MVP của mình quá đặc biệt.

![Slide Lean MVP (in most cases) với bốn gạch đầu dòng](https://homus.dev/photos/1hHMwLxN6EM-0525.jpg)

Slide trong video đăng ngày 01/08/2019, "Lean MVP (in most cases)": "Very fast to build (weeks not months)", "Very limited functionality", "Appeal to a small set of users", "Base to iterate from".

## 6. Ví dụ 1: Airbnb

Michael đưa ra một ví dụ kinh điển: một trong những landing page đầu tiên của Airbnb, theo anh nhớ là vào năm 2008 (theo lời kể trong video đăng ngày 01/08/2019). Trên slide, trang này mang tên "AirBed&Breakfast", dòng phụ "Forget hotels.", có ô tìm chỗ ở San Francisco với ngày check in June 03, 2008 (slide trong video đăng ngày 01/08/2019).

![Slide Example 1: Airbnb với ảnh trang AirBed&Breakfast và ba gạch đầu dòng](https://homus.dev/photos/1hHMwLxN6EM-0608.jpg)

Slide trong video đăng ngày 01/08/2019, "Example 1: Airbnb": ảnh landing page AirBed&Breakfast với dãy nhà ở San Francisco, cột Host, Travel, New Listings, và ba ý bên phải: "No payments", "No map view", "Part-time CTO".

Theo lời kể của Michael (video đăng ngày 01/08/2019), một điều có thể bạn thấy thú vị về sản phẩm đầu tiên của Airbnb là nó không có thanh toán. Khi tìm được chỗ ở trên Airbnb, bạn phải trao tiền trực tiếp cho chủ nhà. Khỏi phải nói, đó là một vấn đề cực kỳ lớn. Nhưng họ vẫn bắt đầu mà không có thanh toán.

Cũng theo Michael (video đăng ngày 01/08/2019), sản phẩm đó không có map view. Bạn biết khi tìm trên Airbnb, bạn thấy được căn nhà nằm ở đâu trong thành phố chứ? Hồi đó không có, anh nói "xin lỗi". Và người viết toàn bộ code, Nate, khi đó chỉ làm part time.

Michael nói ai cũng kể những câu chuyện thần kỳ rằng mọi thứ đã hoàn hảo ngay từ đầu. Theo anh, Airbnb không hoàn hảo ngay từ đầu (video đăng ngày 01/08/2019).

## 7. Ví dụ 2: Twitch, khi còn là Justin.tv

Ví dụ tiếp theo là Twitch. Michael chiếu Twitch trông như thế nào vào ngày đầu tiên và nói nó không quen thuộc lắm; hay có lẽ hơi quen một chút: có video ở đó, có chat ở đó. Ngoài ra thì không có gì khác (theo lời kể trong video đăng ngày 01/08/2019).

![Slide Example 2: Twitch (Justin.tv) với ảnh trang justin.tv và ba gạch đầu dòng](https://homus.dev/photos/1hHMwLxN6EM-0713.jpg)

Slide trong video đăng ngày 01/08/2019, "Example 2: Twitch (Justin.tv)": ảnh trang justin.tv với khung video "Lifecasting 24/7", cột "What's Happening?", khung Live Chat bên dưới, và ba ý bên phải: "1 channel", "Low res video", "No video games".

Theo lời kể của Michael (video đăng ngày 01/08/2019), Twitch launch dưới tên Justin.tv, một chương trình truyền hình thực tế trực tuyến. Chỉ có một channel duy nhất: Justin. Bạn phải theo dõi cuộc sống của anh ấy. Nếu không thích cuộc sống của anh ấy, bạn phải rời trang web. Chỉ có vậy.

Video có độ phân giải cực kỳ thấp (theo Michael, video đăng ngày 01/08/2019). Anh kể một chuyện mà anh thấy buồn cười: hồi đó có một founder hỏi anh, chẳng phải kỳ lắm sao khi anh và nhóm đặt video trong căn hộ của mình, chẳng phải có đủ thứ giấy tờ bí mật mà người ta có thể nhìn thấy sao? Câu trả lời của anh: người ta còn gần như không nhận ra mặt anh và nhóm, nói gì tới giấy tờ.

Và quan trọng nhất, theo Michael (video đăng ngày 01/08/2019), là không có video game, không hề có video game, trừ khi anh và nhóm quyết định chơi game trong căn hộ. Đó là lúc duy nhất video game từng xuất hiện. Anh nói: bạn có thể làm được thứ như vậy rất nhanh. Còn Twitch lúc anh nói (video đăng ngày 01/08/2019) thì phức tạp hơn nhiều.

## 8. Ví dụ 3: Stripe, khi còn là /dev/payments

Ví dụ cuối là Stripe, mà hồi đó chưa phải là Stripe: nó tên là "/dev/payments", Michael đọc là "slash dev slash payments", rồi nói "vì sao lại không chứ?". Anh nói thêm, kiểu như: hãy đặt một cái tên thật dễ nhớ (theo lời kể trong video đăng ngày 01/08/2019).

![Slide Example 3: Stripe (/dev/payments) với ảnh trang web devpayments](https://homus.dev/photos/1hHMwLxN6EM-0728.jpg)

Slide trong video đăng ngày 01/08/2019, "Example 3: Stripe (/dev/payments)": ảnh trang web với dòng chữ lớn "Payment Processing Done Right.", ba cột "Sane, simple, open-source APIs", "Immediate sign-up", "Powerful analytics" và nút "Try it now".

Theo lời kể của Michael (video đăng ngày 01/08/2019), đây là Stripe ngày đầu tiên. Không có thoả thuận với ngân hàng nào. Anh nói anh sẽ không kể chính xác họ xử lý thanh toán thế nào, chỉ biết là theo một cách rất "startup". Gần như không có tính năng.

Và còn hay hơn nữa, theo Michael (video đăng ngày 01/08/2019): nếu bạn muốn dùng Stripe, chính các founder của Stripe sẽ tới văn phòng của bạn và tích hợp nó giúp bạn. Anh hỏi lại: tử tế quá phải không? Một nửa là vì họ quá khát có bất kỳ ai dùng nó, và một nửa là vì đó là cách tuyệt vời để tìm ra bug trước khi user tìm ra. Tự tay tích hợp.

Theo Michael (video đăng ngày 01/08/2019), đó chỉ là ba ví dụ về những MVP cực kỳ đơn giản, build cực kỳ nhanh. Anh nói cả ba đều là công ty tỷ đô, và tất cả đều bắt đầu với một thứ mà phần lớn mọi người sẽ gọi là khá tồi tàn.

## 9. Heavy MVP, trong rất ít trường hợp

Theo Michael (video đăng ngày 01/08/2019), trong rất ít trường hợp bạn phải build một heavy MVP. Anh nói anh vừa nghĩ ra thuật ngữ "heavy MVP" khi làm bài trình bày này hai ngày trước, nên biết đâu nó sẽ thành một thứ.

![Slide Heavy MVP (in very few cases) với hai gạch đầu dòng](https://homus.dev/photos/1hHMwLxN6EM-0848.jpg)

Slide trong video đăng ngày 01/08/2019, "Heavy MVP (in very few cases)": "Significant regulation (insurance, banking)" và "Hardtech".

Các trường hợp Michael kể (video đăng ngày 01/08/2019): nếu bạn ở trong một ngành có quy định pháp lý đáng kể, như bảo hiểm hay ngân hàng, đôi khi là drone, dù đôi khi lại không, thì launch khó, khó hơn, vì bạn phải qua một loạt cơ quan quản lý trước. Nếu bạn làm hard tech, nếu bạn build tên lửa, thì khó mà build một quả tên lửa trong vài tuần. Biotech: khó mà phát minh ra một loại thuốc trị ung thư trong vài tuần. Moonshot thì cứ tự điền vào các chỗ trống còn lại: khó mà khoan đường hầm trong lòng đất và có những phương tiện cực nhanh thay thế ô tô trong vài tuần.

Nếu bạn ở trong tình huống đó, theo Michael (video đăng ngày 01/08/2019), hãy nhớ rằng MVP của bạn có thể bắt đầu bằng một website đơn giản, rất đơn giản, giải thích bạn làm gì. Khi bạn nói chuyện, tương tác với mọi người, có một thứ để họ xem lại là có ích. Đó có thể là điểm khởi đầu của bạn, và bạn có thể build website đơn giản đó trong vài ngày, không phải vài tuần.

Vậy nên, theo anh (video đăng ngày 01/08/2019), ở nhiều mặt, có thể heavy MVP của bạn lại nhanh hơn lean MVP, theo một cách kỳ lạ nào đó.

## 10. Launch không đặc biệt như bạn nghĩ

Michael muốn nói về launch một chút, vì theo anh nhiều founder có quan niệm sai về launch (video đăng ngày 01/08/2019). Họ thấy các công ty lớn launch sản phẩm và cho rằng startup cũng làm vậy. Thậm chí họ thấy những công ty mà họ vẫn coi như startup; anh nói Facebook thật ra không còn là startup nữa (theo video đăng ngày 01/08/2019), nhưng họ thấy các công ty đó được báo chí đưa tin, được bàn tán rầm rộ, vân vân, và trong đầu họ nghĩ đó là hình ảnh một công ty thành công khi launch.

Michael hỏi khán phòng lần lượt: ở đây có ai còn nhớ ngày Google launch không, rồi Facebook, rồi Twitter. Sau ba câu hỏi, anh kết luận: hoá ra launch chẳng đặc biệt chút nào. Nếu bạn đang có ý tưởng thần kỳ về một buổi launch thần kỳ, hãy vứt nó đi, nó không đặc biệt đến vậy. Điều số một thật sự quan trọng là có được vài khách hàng (theo Michael, video đăng ngày 01/08/2019).

![Slide chữ đen: Launch simply means to start getting customers.](https://homus.dev/photos/1hHMwLxN6EM-1030.jpg)

Slide trong video đăng ngày 01/08/2019: "Launch simply means to start getting customers."

Để mọi người thấy dễ chịu hơn, Michael đề nghị dùng hai thuật ngữ khác nhau (video đăng ngày 01/08/2019). "Launch" là khi bạn có bất kỳ khách hàng nào. Còn "press launch", rất ấn tượng, là khi người ta viết về bạn, mọi thứ đều hào hứng và bạn có đủ thứ tiếng vang. Theo anh, hãy đẩy press launch lùi lại, và đẩy cái launch "có bất kỳ khách hàng nào" lên thật, thật sớm. Đó là mục tiêu ở đây.

## 11. Học từ khách hàng dễ hơn khi có MVP

Theo Michael (video đăng ngày 01/08/2019), học từ khách hàng khó hơn rất nhiều khi họ không có một sản phẩm để dùng thử. Bạn có thể nói chuyện với khách hàng cả ngày, nhưng bạn không hề biết thứ bạn muốn build có giải được vấn đề của họ hay không. Nếu bạn đặt sản phẩm trước mặt họ và nó không giải được vấn đề, bạn biết ngay lập tức.

![Slide chữ đen: Learning from customers is easier with an MVP than without.](https://homus.dev/photos/1hHMwLxN6EM-1050.jpg)

Slide trong video đăng ngày 01/08/2019: "Learning from customers is easier with an MVP than without."

Vì vậy, theo anh (video đăng ngày 01/08/2019), mọi nghiên cứu trên đời đều tốt, nhưng cho tới khi bạn đặt được một thứ trước mặt mọi người, bạn hoàn toàn không biết nó có chạy hay không. Thế nên dồn hết thời gian vào một pitch deck không có giá trị bằng dồn thời gian build bất cứ thứ gì bạn có thể đưa cho khách hàng.

## 12. Mẹo build MVP nhanh: timebox và viết spec ra

Cuối cùng, Michael đưa ra vài mẹo để build MVP cực kỳ nhanh (video đăng ngày 01/08/2019). Thứ nhất: timebox spec của bạn. Spec là danh sách những thứ bạn cần build trước khi launch. Hãy timebox nó. Hãy nói: được rồi, chuyện gì xảy ra nếu tôi muốn launch trong ba tuần? Vậy thì những thứ duy nhất được nằm trong spec là những thứ tôi build được trong ba tuần. Theo anh, việc đó làm cuộc sống của bạn đơn giản hơn nhiều, vì nó cho phép bạn bỏ đi mọi tính năng không build được trong ba tuần.

![Slide Hacks for building an MVP quickly với bốn gạch đầu dòng](https://homus.dev/photos/1hHMwLxN6EM-1258.jpg)

Slide trong video đăng ngày 01/08/2019, "Hacks for building an MVP quickly": "Time box your spec", "Write your spec", "Cut your spec", "Don't fall in love with your MVP!".

Thứ hai: viết spec ra (theo Michael, video đăng ngày 01/08/2019). Nghe thì có vẻ rất hiển nhiên, nhưng anh nói phần lớn mọi người làm hỏng bước này. Rất dễ đổi thứ bạn đang làm trước cả khi launch nó, vì bạn chưa bao giờ viết nó ra. Bạn bắt đầu làm một thứ, bạn nói chuyện với một user và họ bảo "ồ, tôi sẽ không bao giờ dùng cái đó", hoặc tệ hơn, bạn nói chuyện với một nhà đầu tư và họ bảo "ồ, cái này không bao giờ thành một công ty được", và Michael nói thêm: vì nhà đầu tư thì biết hết mọi thứ mà.

Theo Michael (video đăng ngày 01/08/2019), thế là bạn quyết định đổi thứ đang làm. Và vì chưa bao giờ viết nó ra, bạn thậm chí không thật sự nhận ra mình đang đổi. Thế là kế hoạch ba tuần thành kế hoạch ba tháng. Nếu bạn viết mọi thứ ra, ít nhất bạn có thể thành thật với chính mình rằng bạn đang đổi spec liên tục.

## 13. Cắt spec, và đừng yêu MVP của mình

Mẹo tiếp theo là cắt spec (theo Michael, video đăng ngày 01/08/2019). Sau một tuần của đợt sprint ba tuần, nhiều khả năng bạn nhận ra mình đã thêm quá nhiều thứ vào spec và sẽ không kịp deadline. Không sao cả. Cứ cắt những thứ rõ ràng là không quan trọng. Và nếu không còn thứ gì không quan trọng, hãy bắt đầu cắt cả những thứ quan trọng.

Theo Michael (video đăng ngày 01/08/2019), mục tiêu ở đây phần lớn chỉ là đưa được bất cứ thứ gì ra thế giới. Một khi đã có thứ gì đó ngoài kia, đà để giữ cho nó tiếp tục là cực kỳ mạnh. Còn nếu chưa có gì ngoài kia, rất dễ cứ trì hoãn, trì hoãn, trì hoãn mãi.

Các mẹo build MVP nhanh mà Michael đưa ra trong video đăng ngày 01/08/2019, theo ví dụ kế hoạch ba tuần của anh: timebox spec, viết spec ra, cắt spec khi không kịp deadline, đưa một thứ ra thế giới, và đừng yêu MVP.

Và cuối cùng, theo Michael (video đăng ngày 01/08/2019): đừng yêu MVP của mình. Rất nhiều người yêu tầm nhìn trong đầu họ, và không sản phẩm nào anh vừa cho xem có tầm nhìn ban đầu giống với thứ cuối cùng nó trở thành. Vậy nên anh nhờ mọi người đừng yêu MVP của mình. Nó chỉ là bước một của một hành trình. Bạn sẽ không yêu một bài văn mình viết hồi lớp một, và theo anh, đó thường là mức tác động mà MVP của bạn có.

Michael khép lại: thật vui được nói chuyện với tất cả mọi người, cảm ơn rất nhiều.

## Nguồn và liên kết

- Tên gốc: Michael Seibel - How to Plan an MVP
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=1hHMwLxN6EM](https://www.youtube.com/watch?v=1hHMwLxN6EM)

- Kênh YouTube Y Combinator (Michael Seibel): [youtube.com/channel/UCcefcZRL2oaA_uBNeo5UOWg](https://www.youtube.com/channel/UCcefcZRL2oaA_uBNeo5UOWg)

- Trang "How to plan an MVP" của bài giảng này trong YC Startup Library, kèm slide (đọc ngày 08/11/2026): [ycombinator.com/library/6f-how-to-plan-an-mvp](https://www.ycombinator.com/library/6f-how-to-plan-an-mvp)

Nguồn: https://homus.dev/talks/michael-seibel-how-to-plan-an-mvp · cập nhật 2026-11-08