(این مقاله برگرفته از سخنرانی در Startup School 2006 است.)
استارتاپهایی که تاکنون سرمایهگذاری کردهایم، سرعت رشد خوبی دارند، اما بعضی سریعتر درس میگیرند و بعضی دیرتر. دلیلش این است که برخی نکات دربارهی استارتاپها کمی غیرقابل حدس و گاهی عجیب هستند.
ما حالا روی تعداد کافی شرکت سرمایهگذاری کردهایم که توانستهام یک راه برای تشخیص نکات غیرقابل حدس پیدا کنم: آنها همان نکاتی هستند که مجبورم بارها تکرار کنم.
پس میخواهم این نکات را شمارهگذاری کنم. شاید در آینده بتوانم به جای توضیح جزئیات، تنها با گفتن «نکته شماره چهار» به آنها اشاره کنم.
---
۱. زود منتشر کن.
چیزی که بیش از همه تکرار میکنم این است: یک نسخهی اولیه (نسخه ۱) سریع آماده کن و بعد بر اساس بازخورد کاربران آن را بهبود بده.
وقتی میگویم «زود منتشر کن» منظورم این نیست که چیزی پر از باگ منتشر کنی، بلکه نسخهای حداقلی عرضه شود. کاربران با باگ مشکل دارند، اما به نظر نمیرسد با یک نسخهی حداقلی مشکل داشته باشند، به شرطی که به زودی نسخههای بعدی هم بیاید.
چند دلیل وجود دارد که سریع آماده کردن نسخه ۱ ارزشمند است:
اول، این روش درست نوشتن نرمافزار است، چه برای استارتاپ و چه غیر آن. از سال ۱۹۹۳ این را تکرار میکنم و چیزی خلافش ندیدهام. استارتاپهای زیادی به دلیل دیر منتشر کردن شکست خوردهاند، ولی هیچکدام به خاطر سریع منتشر کردن شکست نخوردهاند.
دوم، وقتی چیزی محبوب بسازی، کاربران خودت را نمیشناسی. مثلاً Reddit حالا نزدیک نیم میلیون بازدیدکنندهی منحصر به فرد در ماه دارد. هیچ استارتاپ وبی نمیداند کاربرانش دقیقاً چه کسانی هستند. و چون کاربران خودت را نمیشناسی، حدس زدن اینکه چه چیزی دوست دارند خطرناک است. بهتر است چیزی منتشر کنی و بگذاری خودشان بگویند.
مثال Wufoo: آنها فرمساز خود را قبل از آماده شدن پایگاه داده منتشر کردند. هنوز نمیتوانستند واقعاً از آن استفاده کنند، اما ۸۳,۰۰۰ نفر آمدند و آن را امتحان کردند و بازخورد دادند. Wufoo از این بازخوردها چیزهای ارزشمندی یاد گرفت: کاربران لینوکس شکایت کردند که استفادهی بیش از حد از Flash است، بنابراین نرمافزارشان را بازنویسی کردند. اگر همه چیز را یکباره منتشر میکردند، این مشکل دیرتر و وقتی بیشتر در سیستم تعبیه شده بود کشف می شد
حتی اگر هیچ کاربری هم نداشته باشی، زود منتشر کردن هنوز هم مهم است، زیرا برای یک استارتاپ، انتشار اولیه حکم یک «آزمایش عملی» را دارد. اگر چیزی اساسی خراب باشد—مثلاً ایده خوب نباشد یا بنیانگذاران با یکدیگر مشکل داشته باشند—فشار ناشی از آماده کردن نسخهی اول همهی مشکلات را آشکار میکند. و اگر چنین مشکلاتی وجود داشته باشد، بهتر است آنها را زود پیدا کنید.
شاید مهمترین دلیل برای انتشار زودهنگام این باشد که باعث میشود بیشتر کار کنید. وقتی روی چیزی کار میکنید که هنوز منتشر نشده، مشکلات جالب به نظر میرسند. اما وقتی چیزی منتشر شده است، مشکلات نگرانکنندهاند. پس از انتشار، فوریت بسیار بیشتری وجود دارد. و فکر میکنم این دقیقاً همان دلیلی است که مردم آن را به تأخیر میاندازند: آنها میدانند بعد از انتشار باید خیلی بیشتر تلاش کنند.
---
۲. مداوم ویژگی اضافه کنید.
البته «زود منتشر کردن» یک جنبهی دیگر هم دارد، بدون آن، توصیه ناقص خواهد بود. اگر میخواهید با چیزی که عملکرد زیادی ندارد شروع کنید، بهتر است آن را سریع بهبود دهید.
من خودم همیشه جملهی «ویژگی اضافه کن» را تکرار میکنم. و این قانون فقط برای مراحل اولیه نیست؛ این کاری است که هر استارتاپی باید تا زمانی که میخواهد یک استارتاپ باقی بماند، انجام دهد.
البته منظورم این نیست که نرمافزار را پیچیدهتر کنید. منظورم از «ویژگی» یک واحد کوچک بهبود است—یک اقدام مشخص که زندگی کاربران را بهتر میکند.
همانطور که در ورزش، پیشرفت باعث پیشرفت بیشتر میشود، در توسعه هم همینطور است: هر چه ایدههای بیشتری را اجرا کنید، ایدههای بیشتری به ذهنتان میرسد. شما باید سیستم خود را حداقل هر یک یا دو روز کمی بهتر کنید.
این فقط روش خوبی برای پیشبرد توسعه نیست؛ بلکه نوعی بازاریابی هم هست. کاربران سایتهایی که دائماً در حال بهبود هستند را دوست دارند. در واقع، کاربران انتظار دارند سایت بهبود پیدا کند. تصور کنید سایتی را بازدید کنید که بسیار خوب به نظر میرسد، و دو ماه بعد دوباره بروید و هیچ تغییری نکرده باشد؛ آیا کمکم بیاهمیت و کسلکننده نمیشود؟
وقتی به نظرات کاربران پاسخ دهید و بر اساس آنها بهبود دهید، محبوبیت شما بیشتر خواهد شد، زیرا اکثر شرکتها کاربران را نادیده میگیرند. اگر جزو استثناها باشید—شرکتی که واقعاً گوش میدهد—وفاداری شدید کاربران را جلب خواهید کرد. دیگر نیازی به تبلیغ نیست، زیرا کاربران خودشان این کار را برای شما انجام میدهند.
این هم به نظر واضح میآید، پس چرا باید آن را مرتب تکرار کنم؟ مشکل این است که مردم به وضعیت فعلی عادت میکنند. وقتی محصول از مرحلهای که دارای نقصهای آشکار بود عبور میکند، کمکم به آن عادت میکنند و ویژگیهایی که دارد، هویت آن محصول را شکل میدهند. برای مثال، فکر نمیکنم بسیاری از کارکنان Yahoo (یا حتی Google) متوجه شده باشند که سرویس ایمیل وب چقدر میتواند بهتر باشد، تا زمانی که Paul Buchheit آن را نشان داد.
راه حل این است که فرض کنید هر چیزی که ساختهاید به مراتب کمتر از ظرفیت واقعیاش است. خودتان را وادار کنید، به عنوان یک تمرین ذهنی، همیشه به فکر بهبود باشید. خوب، مطمئناً آنچه دارید عالی است، اما اگر مجبور باشید چیزی را تغییر دهید، چه چیزی خواهد بود؟
اگر محصول شما به نظر تمامشده میرسد، دو احتمال وجود دارد:
الف) واقعاً تمام شده، یا
ب) شما تخیل کافی ندارید. تجربه نشان میدهد که احتمالا مورد ب) هزار برابر بیشتر است.
این مقاله ادامه دارد ....
