<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??一站式輕松地調用各大LLM模型接口,支持GPT4、智譜、豆包、星火、月之暗面及文生圖、文生視頻 廣告
                # Michael Seibel - 如何計劃 MVP > 原文:[https://jotengine.com/transcriptions/aZ1TLnOlGWyuHlmYpW222g](https://jotengine.com/transcriptions/aZ1TLnOlGWyuHlmYpW222g) > Michael Seibel: 我叫 Michael,我在 Y Combinator 工作。 我幫助運行了加速器,然后我做了兩家 YC 創業公司,一家在 2007 年,一家在 2012 年。 今天,我將與您談談最低限度可行產品,因此是 MVP。 我們總是對創始人大喊大叫,不要使用行話,但是我們卻擁有一整套愚蠢的啟動行話,而 MVP 就是其中之一。 當您想到一個 MVP 時,您只是在想一些簡單的事情,這是您可以給想要定位的第一批用戶的第一件事,以查看是否可以向他們提供任何價值。 僅此而已,這非常簡單。 我知道你們上周進行了一次有關如何提出想法,如何提出要解決的問題的演講。 我要告訴您的是,在您決定建立 MVP 之前與一些用戶交談是很有幫助的。 這并不意味著您必須進入一種為期三年的研究環境,或者您必須在行業中工作 10 年,但是一些對話是有幫助的。 如果您是自己的用戶,它會更加有用,這樣您就可以判斷您的產品是否對您有用。 我總是會遇到一個奇怪的問題,即如何獲得我的第一個用戶,這總是使我感到困惑,因為從理論上講,您決定解決某個已知的人所遇到的問題,因此,獲得第一個用戶的方式就是與該人交談 您知道有問題。 如果是您,那就更容易了。 因此,如果您要為一組神秘的用戶構建產品,而您卻不知道他們是誰,那么請稍稍提出一些問題。 好的。 因此,啟動前啟動的目標非常簡單。 第一步,快速啟動。 從一開始,這就是 YC 精神的一部分,十年來一直是很棒的建議,現在仍然是很棒的建議。 如果您可以擺脫本演示文稿中的一件事,那就是它很快就會推出一些不好的東西。 從字面上看,我要說的其余部分基本上將是同一件事的重新匯總版本。 初創企業顯然需要做的第二件事是獲得一些初始客戶。 讓任何人使用您的產品。 您不必了解如何使所有人使用它,而只有每個人進行交互并查看他們是否從產品中獲得了價值。 您會驚奇地發現,在單個用戶實際上與他們創建的產品進行交互之前,有多少創始人之旅結束了。 這非常非常普遍,因此請跳過此步驟,這非常重要。 下一個是,與您的用戶(在您啟動此 MVP 之后進行交流)進行交流,并獲得反饋。 這也是一個非常普遍的錯誤,因為大多數創始人頭腦中都有自己想要構建的想法。 因此,他們會有一種奇怪的感覺,即如果我還沒有構建完整的東西,那么獲取關于糟糕的初始東西的反饋是沒有用的。 當然,這是行不通的,不是全部。 一個完整的團隊需要花三年的時間,即一千萬美元,所以對這個小事情的反饋是沒有用的。 現實是,從某種意義上說,完整的東西是您腦子里的一個很棒的主意,您應該始終牢記在心,但是它應該非常非常靈活,因為它可能會證明您想要構建完整的東西, 根本不是客戶想要的。 所以我有這樣的說法,緊緊抓住您要解決的問題,緊緊抓住客戶,松緊地解決要解決的問題。 最后也是最重要的一點,就是迭代,我想對迭代和透視進行區分。 許多創始人一旦弄清楚如何構建東西,就會愛上它。 因此,如果這對于某些用戶不起作用,他們會開始思考:“好吧,我想知道這東西還能解決什么其他問題?嗯,螺絲刀實際上并不擅長擰入任何東西,但是我想知道其他什么 它可以解決的問題。” 然后他們說:“也許您可以用它來做飯,也許您可??以用它來做清潔。” 就像,不,問題是,我需要擰螺絲,用戶是機械師,如果螺絲刀不能幫助機械師解決問題,請保留機械師,保持問題,我需要擰些螺絲 在里面,修理那把螺絲刀。 那是壞東西,對嗎? 壞的不是機制,也不是他們需要擰東西的事實。 因此,進行迭代,繼續改進您的解決方案,直到它真正解決了問題。 在大多數情況下,大多數人都應該建立非常精益的 MVP。 因此,我們的意思是,您應該能夠在幾周而不是幾個月內快速構建它。 這可能涉及軟件,或者說實話,我們看到初創企業只是從登錄頁面和電子表格開始,但是大多數初創企業可以非常非常快地啟動。 第二個功能極為有限,您需要精簡用戶需求... 您的初始用戶需要的東西非常簡單。 創始人常常想解決所有用戶問題以及所有潛在用戶,而實際上,他們應該只關注少量的初始用戶及其最高順序的問題,然后忽略其余問題,直到后來。 您應該對所有人都有一個愿景,您應該擁有非常小的 MVP。 所有這些就是迭代的基礎,僅此而已。 這只是一個起點,不是... 無論如何,這并不特殊,您只需要開始即可。 因此,請確保您不會覺得自己的 MVP 太特別。 好的。 這是一個經典的例子。 我相信,這是 2008 年 Airbnb 的第一批登陸頁面之一。 您可能會對 Airbnb 的第一款產品感興趣的一件事是沒有付款。 當您找到在 Airbnb 上住宿的地方時,您必須親自與房東進行兌換。 毋庸置疑,這是一個非常糟糕的大問題,但是他們一開始沒有付款。 沒有地圖視圖。 您知道在搜索 Airbnb 時如何看待房屋在城市中的位置嗎? 你沒有那個抱歉。 而且,編寫所有代碼的人正在兼職。 好的? 因此,每個人都會講這類神奇的故事,講述 Airbnb 從一開始就如何完美,而不是從一開始就完美。 下一個,Twitch。 這就是 Twitch 在第一天的樣子,并不十分熟悉。 好吧,也許有點熟悉。 那里有一些視頻,那里還有一些聊天,除此之外,別無其他。 Twitch 以 Justin.tv 的形式啟動,這是一個在線現實電視節目。 賈斯汀只有一個頻道,您必須跟隨他的生活。 如果您不喜歡他的生活,則必須離開該網站。 這就是全部。 該視頻的分辨率極低。 那天有一天,一位創始人問我,這很有趣,“哦,你們的公寓里有視頻嗎,難道不是嗎?難道沒有所有這些秘密文件和人們可以看到的東西嗎?” 我當時想,“您幾乎無法認出我們的面孔,更不用說我們擁有的文件了。” 最重要的是,沒有視頻游戲。 沒有電子游戲,除非我們決定在自己的公寓里玩電子游戲。 那是視頻游戲出現的唯一時間。 因此,我要說的是您可以快速做到。 當您想到 Twitch 時,它現在要復雜得多。 最后,Stripe(不是 Stripe)被稱為/ dev / payments,因為為什么不這樣做。 讓我們命名一個非常容易記住的名字。 這是 Stripe 的第一天,沒有銀行交易。 我不會確切告訴您他們如何處理付款,但這是一種非常新穎的方式。 幾乎沒有功能。 更酷的是,如果您想使用 Stripe,Stripe 創始人將來到您的辦公室為您集成。 那有多好? 一半是因為他們迫切希望讓任何人使用它,一半是因為這是在用戶發現 bug 之前自行發現 bug 的好方法。 因此,這只是構建 MVP 極其簡單,極其快速的三個示例。 所有這些都是一家市值十億美元的公司,而且它們都是以大多數人說的很糟糕的開頭。 在極少數情況下,您必須構建沉重的 MVP。 兩天前的演講中,我只是發明了這個術語,重型 MVP。 如果您所處的行業有嚴格的法規,例如保險或銀行業,則有時使用無人駕駛飛機,雖然有時沒有,但很難啟動。 很難啟動。 您必須首先通過一系列監管機構。 我是在做硬技術,如果要制造火箭,那么很難在幾周內制造出火箭。 生物技術,很難在幾周內發明出抗癌藥。 Moonshots 很好地填補了所有其他空白,很難在地球上開鑿隧道,并且擁有非常快的車輛可以在幾周內取代汽車。 因此,如果您處于這種情況,請記住,您的 MVP 可以從一個簡單的網站開始,該網站介紹您的工作。 當您與人交談并與他人互動時,這會很有幫助,他們可以參考某些東西。 這樣就可以開始了,您可以在幾天而不是幾周內建立一個簡單的網站。 因此,在許多方面,也許您的重型 MVP 以某種奇怪的奇怪方式比精益 MVP 更快。 現在,我想談一談啟動,因為許多創始人對啟動有誤解。 他們看到大公司發布產品,并認為這就是初創公司所做的。 實際上,他們會看到他們像初創公司那樣思考的公司。 Facebook 不再是一家真正的初創公司,但他們看到他們獲得了很多媒體的關注,并引起了很多轟動,而 yada,yada,yada 卻在他們的腦海中,這就是一家成功的公司成立之初的樣子。 。 好吧,讓我問你一個問題,有多少人還記得 Google 成立的那一天? 沒有。 Facebook 怎么樣? 好的。 那 Twitter 呢? 沒有。 大。 事實證明,發射根本沒有那么特別,好嗎? 因此,如果您對自己想要的神奇發射有一個神奇的想法,那就把它扔掉,這沒什么特別的。 真正重要的第一件事是獲得一些客戶。 因此,為了讓人們感覺更好,讓我們使用不同的術語。 怎么樣,當您獲得任何客戶時? 當人們撰寫有關事物的文章時,新聞發布會真是令人印象深刻,那一切令人興奮,而您得到的所有嗡嗡聲呢? 讓我們推動新聞發布會,然后推動新聞發布會,真正,非常快地讓所有客戶啟動。 這就是我們的目標。 當客戶沒有可玩的產品時,要向他們學習要困難得多。 您可以整天與客戶交談,但是您不知道您想要制造的東西是否可以解決他們的問題。 如果您把東西放在他們面前,但不能解決他們的問題,您馬上就會知道。 因此,世界上所有的研究都是好的,但是在您不能將某些東西擺在人們面前之前,您還不確定是否會奏效。 因此,將所有這些時間花在推銷平臺上,并不比花時間建立可以提供給客戶的東西有價值。 最后,一些黑客可以極快地構建 MVP。 首先,在您的規格書中注明時間。 因此,您的規范列出了在啟動之前需要構建的東西的清單,并在時間上打了勾。 說,“好吧,如果我想在三周內發布,會發生什么?好吧,根據我的規格,唯一可以在三周內構建的東西。” 這使您的生活變得簡單得多,它使您可以刪除三周內無法構建的所有功能。 其次,編寫您的規格。 這似乎很簡單,但是大多數人都把它搞砸了。 在啟動之前,很容易更改您正在處理的內容,因為您從未寫下來。 您開始做某事,然后與用戶交談,他們說:“哦,我永遠不會使用它。” 或者,上帝禁止,您與投資者交談,他們說:“哦,那永遠不可能是一家公司”,因為投資者了解所有事情,因此您決定更改自己的工作。 而且因為您從未寫下來,所以您甚至沒有真正意識到您正在更改它。 因此,您的三周計劃變成了三個月計劃。 如果寫下來,至少您可以誠實地說自己一直在更改規格。 下一個是,削減您的規格。 在進行為期三周的沖刺的一周后,您可能會意識到自己在規范中添加了太多內容,并且您不會設定截止日期,這沒關系,只剪掉顯然不重要的內容。 如果沒有不重要的事情,那就開始削減重要的事情。 這里的大多數目標只是為了使世界上的一切都變得無所不包。 一旦您從世界上獲得了任何東西,保持一切前進的動力就非常強大。 一旦有什么... 如果世界上什么都沒有,那么延遲,延遲,延遲都是很容易的。 最后,不要愛上您的 MVP。 如此眾多的人迷上了他們腦海中的愿景,而我之前向您展示的所有產品都不是最初的愿景。 因此,請不要愛上您的 MVP,這只是旅程的第一步。 您不會愛上一年級寫的一篇論文,這就是您的 MVP 經常具有的影響力水平。 好的,這就是話題,我有一點時間來提問。 任何問題? 完美,沒有問題。 > Speaker 2: 我正在與用戶交談,我有幾個子類型的細分,當然每個細分受眾群都想要一件特定的事情,而另一個細分受眾群想要一件特定的事情。 因此,數字是如此之小,以至于它們甚至是均勻的,怎么... 什么... > Michael: 好問題。 因此,您與用戶交流,他們擁有要構建的所有這些東西,它們之間沒有太多重疊嗎? 因此,我將為您提供一些元答案,從不要求用戶提供功能。 永遠不要讓用戶告訴您他們想要什么。 提出功能不是用戶的工作,而是您的工作。 用戶的工作是給您帶來問題。 因此,我認為,如果您正在與這些用戶交談,那么他們所遇到的問題將具有一定的連續性。 他們可能不知道如何解決問題,因此他們可能會給您一長串他們認為可以解決問題的潛在功能,而不是花很多時間談論他們的問題是什么, 他們是否經歷過它,它有多強烈?他們是否愿意為解決方案付費?他們是否知道其他有問題的人。 因此,這些就是我們要設法擺脫的問題,如果您看到某人潛入某個功能區,例如,“哦,您知道,我喜歡 Microsoft Word,但我希望有人可以構建一些可以 我做,等等,等等,等等,”那么,您必須將其歸結為:“哦,那您為什么要這樣做,等等,等等,您有什么問題? 您多久遇到一次該問題,”然后重新解決。 這樣可以避免功能失效。 這是非常普遍的。 是啊 > Speaker 3: 我發現自己一直專注于我的 MVP,但由于我發現一件更好的東西而改變了它,這之間的界限很細。 因此,我開始了自己的 MVP,與所有潛在用戶進行了交談,然后我說:“不,不,不,讓我添加一下,讓我添加一下,我們必須添加一下。” 因此,我應該服用我的 ADT 藥物,然后繼續按照我的開始做,還是什么時候停下來說:“好吧,這有必要改變?” > Michael: 哦,是的,對不起。 所以問題是,我陷入了這個循環,在這個循環中我不斷更改我的 MVP,但我沒有啟動。 我看到很多人陷于該循環中,并且有很多啟動問題,答案就是停止做您正在做的事情。 停下來 您不必繼續更改 MVP。 之所以更改 MVP 的原因之一是因為您認為它很特別。 如果您認為它不是特別的,則可以停止對其進行更改,也可以停止對其進行編輯。 > Speaker 3: 先生,我不懂,請再說一遍。 > Michael: 如果您認為自己的 MVP 很特別,則認為它必須是完美的。 如果您認為它必須是完美的,那么您會花很多時間弄亂它。 如果您認為它一定很糟糕,那么... 如果您認為:“好吧,我實際上是想在壁櫥里找到一件我可以用來涂漆然后銷毀的襯衫,”您不會花很多時間來剪裁襯衫,對嗎? 因此,如果您認為自己的 MVP 不太特殊,那么花在修補它上的時間就會更少。 是的 > Speaker 4: 假設您啟動了 MVP,并且正在尋找反饋,那么您想問[聽不清]的關鍵是什么? > Michael: 這是一個非常簡單的問題。 當您想獲得有關 MVP 的反饋時,要學習的關鍵知識是什么? 它可以解決我想解決的問題嗎? 而已。 您可以找到 80 種不同的方法來回答該問題,但是如果您清楚地了解您要解決的問題,那么這很明顯... 通常,您不必問。 如果它在用戶面前,您可以查看他們是否正在做您希望他們做的事情,或者是否沒有。 通常,您可以在數字中看到它。 如果您每天遇到問題,并向用戶介紹問題,他們第二天會回來嗎? 我從來沒有真正看過能夠解決人們每天遇到的問題的產品,而實際上可以解決用戶停止使用它的問題,因為無論如何。 因此,這里有許多完全相關的怪異之處。 用戶做事情,解決您要他們解決的問題嗎? 其他問題,在后面。 > Speaker 5: MVP 應該持續多長時間? 我的意思是,您開始成長,接下來該怎么做? > Michael: 您知道初創公司的樂趣嗎? 我不喜歡考慮時間表,也不喜歡考慮路線圖。 對于處于 MVP 之前階段的人,知道,發布某些東西,請弄清楚。 您決定做一個初創公司,而初創公司的特征之一是,如何從 A 到 Z 尚不清楚。 因此,如果您過于關注“哦,嗯,我知道獲得 MVP 是步驟 B,但是我確實專注于步驟 C,D 和 E”,我會告訴您,“嘿, 首先解決您面前的問題。” 是啊 > Speaker 6: 那么,您如何在提高 MVP 來增加客戶保留率方面進行權衡,而不是押注著在問題方面擴大并購和潛在客戶的努力呢? > Michael: MVP 后,您應該致力于增長還是應該留住人才? 我喜歡這個問題,它是世界上最有趣的問題,因為它允許我給出一個荒謬的罐頭答案。 都。 是的 這就是發生的情況,許多創始人從根本上理解他們的創業是一個多變量問題,但是多變量問題很難,因此他們嘗試將其簡化為一個變量。 因此他們問秘密顧問:“哦,增長或保留更重要?” 更重要的是,沖個澡或去洗手間并進行第二? 我希望你們都做。 抱歉,兩者都很重要。 作為創始人,您將不得不處理許多事情。 是啊 > Speaker 7: 好的。 讓我與一個沒有與最終用戶交談的初創公司分享一個故事,這些最終用戶不會談論這個問題,您如何克服這個問題,您知道嗎? > Michael: 明確地說,問題是,如果用戶遇到不想談論的問題,該如何與他們交談? 你為什么不告訴我那是什么。 有什么問題? > Speaker 7: 兩型糖尿病。 > Michael: 兩型糖尿病。 我完全有信心,您可以找到 10 個人來談論他們的 2 型糖尿病。 如果您不認識愿意與您交談的患有二型糖尿病的人,我想請您創辦一家初創公司來幫助二型糖尿病患者。 因此,我認為那是那些錯誤的設置之一,我拒絕這個問題的前提。 好吧,下一個問題,繼續。 > Speaker 8: 在向投資者介紹之前,例如,根據哪個[聽不清]市場規模,有多少人足以注冊,或者有多少活躍用戶可以加入 MVP。 > Michael: 這是一個很好的問題。 如果我要總結一下,我想說的是在與投資者交談之前您走了多遠。 我也會對此作出回應。 我認為將會有一個關于何時應該與投資者交談的整個講座,所以我會說,等待那個講座。 誰給它,都會在回答這個問題上做得很好。 > Speaker 8: 好的謝謝。 > Speaker 9: 我的問題是,您應該在尋找什么類型的數字或吸引力之前 > Michael: 我再改一下這個問題,您怎么知道什么時候適合產品市場? 好的。 經典的答案實際上是正確的,而創始人真的很討厭,那就是,如果您提出要求,那么您就沒有適合市場的產品。 當您擁有適合產品市場的產品時,往往會發生的事情是,人們開始大量使用您的產品,您從做其他事情轉變為不只是使產品保持在線狀態。 這就是產品適合市場的趨勢。 因此,您不再考慮新功能,不再考慮通過渠道來提高轉化率,不再考慮如何獲得更好的分配,而您實際上就像在說:“天哪,我不知道該怎么做。 服務明天要來我產品的人們。 我很茫然。 下周,我很茫然。 而且我很確定我們會死的,因為我們有太多的用戶。”有趣的是,當我這樣說時,不難知道你是否在那兒。 令人震驚的現實是,幾乎沒有人能使產品適應市場。 幾乎沒有人。 幾乎沒有人。 很多人喜歡亂扔這些條款,很多人喜歡重新定義它,因為有人在使用我的產品。 那不是這個詞。 某人使用您的產品的術語是,您有一個用戶。 很好,但是不適合產品市場。 在后面。 > Speaker 10: 我們與之交談的用戶越多,問題的定義就越來越大。 因此,在考慮 MVP 時,我們在哪里[聽不清]? 我們開始只與一個用戶一起工作,并且嘗試與他們進行一個小實驗,但是與此同時,我們了解了問題本身的更多屬性。 > Michael: 那么,如果您了解更多有關該問題的信息,并且在您開始與用戶互動時問題又擴大了,會發生什么? 沒關系,實際上是可以預期的。 我要說的是,創始人通常會犯錯誤的地方是,他們認為必須為所有用戶解決問題。 因此,最重要的是,如果您的一個用戶遇到一系列問題,那么要做的一件好事就是嘗試找出是否有其他人喜歡他們。 您可以做的一件有趣的事,就是問他們:“嘿,您認識其他遇到同樣問題的人嗎?” 任何問題,當您回過頭來考慮任何創始人的愿景時,實際上都涵蓋了問題的整個子集。 而且我認為讓人們真正搞砸其 MVP 的原因在于,他們的愿景很大,他們不愿意擁有較小的 MVP。 他們覺得好像沒有在先解決所有潛在用戶,那么他們就失敗了。 創業公司有很多事情要做,或者創始人必須做很多事情,而他們在同一時間牢記兩件事,對嗎? 視野大,MVP 小,對不對? 成長并保留。 我們在 YC 經常談論的一件事,就是您的投資者和客戶的建議截然不同。 創始人總是想把這些東西混在一起,或者殺死它們,因為將其視為一個單一的問題要容易得多…… 腦海中只有一件東西,腦海中有兩件相對的東西。 我們真的想為所有人付款,并且有一個很難使用的小 API 以至于我們必須為人們安裝它,這是真的嗎? 就像兩件事都是對的,您必須對此感到滿意。 好吧,再說一遍。 是啊 > Speaker 11: 在制藥領域,我的用戶是其他科學家還是實際上是患者? > Michael: 在制藥領域,您的用戶是誰? 我認為那是您的問題。 您正在創辦公司,知道您要建立的公司,知道要解決的問題,知道是誰出了問題,我什么都不知道。 行。 非常高興與大家交談,非常感謝。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看