ترجمه و برداشت آزاد از ایده‌های اصلی مقاله، با ارجاع به منبع اصلی.

این مقاله از زاویه معکوس به ساخت شرکت نگاه می‌کند: به جای اینکه بگوید چه کارهایی حتماً موفقیت می‌آورد، نشان می‌دهد چه خطاهایی معمولاً تیم را از مسیر خارج می‌کند. ایده مرکزی ساده است: بیشتر شکست‌ها در نهایت به یک چیز برمی‌گردند؛ تیم چیزی نمی‌سازد که کاربران واقعاً بخواهند. بقیه خطاها، شکل‌های مختلف همین فاصله گرفتن از کاربر و واقعیت بازارند.

بخش مهمی از این خطاها از انتخاب مسئله شروع می‌شود. وقتی تیم فقط از روی یک شرکت موفق کپی می‌کند، یا از ترس رقابت سراغ گوشه‌ای خیلی کوچک و بی‌اهمیت می‌رود، معمولاً مسئله‌ای جدی در دست ندارد. مسئله خوب باید آن‌قدر واقعی باشد که آدم‌ها برای حلش رفتارشان را تغییر دهند. اگر کاربر مشخص نیست، درد مشخص نیست، و شواهد بیرونی نداریم، ایده هنوز بیشتر شبیه حدس است تا پایه یک شرکت.

Graham روی کاربر مشخص تأکید جدی دارد. ساختن برای «مردم»، «شرکت‌ها» یا «بازار» کافی نیست. باید بدانی دقیقاً چه کسی با این مشکل درگیر است، امروز چطور آن را حل می‌کند، چرا راه‌حل فعلی ناکافی است، و آیا می‌توانی چند نفر از همین آدم‌ها را قانع کنی محصول ناقص اولیه را امتحان کنند یا نه. اگر نتوانی با کاربر واقعی تماس بگیری، عملاً با ابزار کور حرکت می‌کنی.

اشتباه بعدی به زمان لانچ برمی‌گردد. دیر لانچ کردن معمولاً خطرناک‌تر از زود لانچ کردن است، چون یادگیری را عقب می‌اندازد. اما زود لانچ کردن هم اگر بدون یک هسته مفید باشد، اعتماد کاربر اولیه را می‌سوزاند. راه عملی این است که کوچک‌ترین نسخه‌ای را بسازی که خودش به تنهایی فایده دارد و بعد بتواند رشد کند. این نسخه قرار نیست کامل باشد؛ قرار است تماس واقعی با کاربر بسازد.

در مقاله، تیم اولیه هم یک عامل تعیین‌کننده است. تک‌بنیان‌گذار بودن، هم‌بنیان‌گذار نامناسب، اختلاف حل‌نشده، یا استخدام آدم‌هایی که نمی‌توانی کیفیت‌شان را بسنجی، فقط مسئله منابع انسانی نیست؛ روی سرعت یادگیری و کیفیت تصمیم اثر مستقیم دارد. در شروع، تیم کوچک باید بتواند سریع فکر کند، سریع بسازد، مستقیم با کاربر حرف بزند و وقتی فرضیه غلط شد، بدون فرسایش مسیر را اصلاح کند.

پول هم در این نگاه ابزار زمان است، نه نشانه موفقیت. کم پول گرفتن ممکن است تیم را قبل از رسیدن به مرحله بعد زمین‌گیر کند؛ زیاد پول گرفتن هم می‌تواند سرعت را کم کند، فشار بیرونی بسازد و انعطاف تغییر مسیر را بگیرد. خرج زیاد، مخصوصاً استخدام زودهنگام و سنگین، هم هزینه را بالا می‌برد و هم تصمیم‌گیری را کند می‌کند. معیار درست این است که پول چقدر runway و یادگیری واقعی می‌خرد.

ارزش عملی مقاله در این است که می‌شود آن را مثل چک‌لیست مرور هفتگی استفاده کرد. آیا کاربر مشخص داریم؟ آیا چیزی لانچ شده که از آن یاد بگیریم؟ آیا داریم برای حل مسئله واقعی می‌سازیم یا برای دفاع از ایده اولیه؟ آیا پول، تیم و سرمایه‌گذارها به یادگیری کمک می‌کنند یا آن را سنگین‌تر کرده‌اند؟ اگر این سؤال‌ها مرتب پرسیده شوند، مقاله از یک فهرست خطا به یک ابزار عملیاتی تبدیل می‌شود.

  1. قبل از ساخت بیشتر، کاربر هدف را با اسم و موقعیت دقیق تعریف کن؛ «شرکت‌ها» یا «مصرف‌کننده‌ها» تعریف کافی نیست.
  2. اگر ایده شبیه نسخه ضعیف‌تر یک شرکت موفق است، دوباره از مسئله شروع کن و نه از راه‌حل موجود.
  3. یک هسته کوچک اما مفید لانچ کن؛ چیزی که ناقص است ولی ارزش مستقل دارد.
  4. هر تصمیم استخدامی در شروع باید یا ساخت محصول را بهتر کند یا رسیدن به کاربر را سریع‌تر.
  5. runway را با مرحله بعد بسنج: نمونه اولیه، لانچ، رشد اولیه یا درآمد واقعی.
  6. سرمایه زیاد را با دقت بگیر؛ پولی که انعطاف را کم کند، همیشه مزیت نیست.
  7. اختلاف هم‌بنیان‌گذارها را زود و صریح حل کن؛ ابهام در رابطه مؤسس‌ها در بحران بزرگ‌تر می‌شود.
  8. از کارهای بیرون از کدنویسی فرار نکن؛ در شروع، فروش، مذاکره و گفت‌وگو با کاربر بخشی از محصول است.
  • هر هفته بررسی کن آیا کار امروز تیم مستقیماً به ساختن چیزی که کاربر می‌خواهد نزدیک‌تر شده یا نه.
  • برای هر ایده، کاربر مشخص، درد مشخص و شاهد رفتاری مشخص بنویس.
  • لانچ را تا داشتن محصول کامل عقب نینداز؛ یک هسته مفید و قابل گسترش کافی است.
  • استخدام و جذب سرمایه را با اثرشان روی سرعت یادگیری بسنج، نه با ظاهر رشد.
  • وقتی داده کاربر با ایده اولیه نمی‌خواند، دفاع از ایده را با اصلاح مسیر اشتباه نگیر.

این مقاله چه چیزی را برایت روشن کرد؟

یک واکنش انتخاب کن یا سؤال و تجربه‌ات را بنویس. بازخوردهای خوب، موضوع یادداشت‌های بعدی را شکل می‌دهند.

با ارسال، برنامه ایمیل دستگاه باز می‌شود.

این متن ترجمه آزاد و بازنویسی‌شده است، نه بازنشر کلمه‌به‌کلمه مقاله اصلی.