چشم انداز – فصل ۳ یادگیری
بهعنوان یک کارآفرین، هیچ چیز بیش از این پرسش آزارم نمیداد که آیا شرکت من در مسیر ایجاد یک کسبوکار موفق پیشرفت میکند یا نه. بهعنوان مهندس و سپس مدیر، عادت کرده بودم پیشرفت را با این بسنجـم که کار طبق برنامه جلو میرود، کیفیت بالاست و هزینهها کمابیش مطابق برآورد ماست.
پس از سالها کارآفرینی، نگران شدم که آیا این شیوه سنجش درست است. اگر مشغول ساختن چیزی باشیم که هیچکس نمیخواهد چه؟ در آن صورت، چه اهمیتی دارد که بهموقع و در چارچوب بودجه انجامش دادهایم؟ وقتی پایان روز به خانه میرفتم، تنها چیزی که مطمئن بودم این بود که آن روز مردم را مشغول نگه داشته و پول خرج کردهام. امید داشتم تلاشهای تیم ما، ما را به هدف نزدیکتر کرده باشد و اگر در نهایت معلوم میشد راه را کج رفتهایم، تنها دلخوشیام این بود که دستکم چیزی مهم آموختهایم.
متأسفانه «یادگیری» قدیمیترین بهانه برای توجیه شکست در اجراست. مدیران وقتی به نتایجی که وعده دادهاند نمیرسند، به آن پناه میبرند. کارآفرینان هم زیر فشار موفقیت، در نشاندادن اینکه «چه آموختهایم» بیاندازه خلاق میشوند. وقتی شغل، آینده یا اعتبارمان در میان باشد، همه میتوانیم داستانی شنیدنی تعریف کنیم.
با این حال، «یادگیری» تسلّی ناچیزی است برای کارکنانی که همراه یک کارآفرین به ناشناختهها قدم میگذارند؛ تسلّی ناچیزی است برای سرمایهگذارانی که پول، زمان و انرژی ارزشمند خود را به تیمهای کارآفرین میسپارند؛ و برای سازمانهای کوچک و بزرگ که بقای خود را به نوآوری کارآفرینانه گره زدهاند. نمیتوان یادگیری را به بانک برد؛ نه میتوان آن را خرج کرد و نه سرمایهگذاری. نه میتوان آن را به مشتریان داد و نه به شرکای محدود بازگرداند. عجیب نیست که «یادگیری» در محافل کارآفرینی و مدیریتی، نام خوشی ندارد.
بااینهمه، اگر هدف بنیادی کارآفرینی «نهادسازی در شرایط عدمقطعیت شدید» است، حیاتیترین کارکرد آن «یادگیری» است. باید حقیقت را بیاموزیم: کدام عناصر راهبرد ما واقعاً در تحقق چشماندازمان مؤثر است و کدامیک تنها خیالپردازی است. باید بفهمیم مشتریان واقعاً چه میخواهند؛ نه آنچه میگویند میخواهند و نه آنچه ما میپنداریم باید بخواهند. باید کشف کنیم آیا در مسیری هستیم که به رشد یک کسبوکار پایدار بینجامد یا نه.
در الگوی استارتاپ ناب، به «یادگیری» با مفهومی به نام «یادگیری معتبر»، دوباره اعتبار میبخشیم. «یادگیری معتبر» نه عقلانیسازیِ پس از واقعه است و نه داستانی خوشساخت برای پنهانکردن شکست؛ بلکه روشی سختگیرانه برای نشاندادن پیشرفت، آن هم در خاکِ عدمقطعیت شدیدی که استارتاپها در آن رشد میکنند. «یادگیری معتبر» فرایند نشاندادنِ تجربیِ این است که تیم، حقایق ارزشمندی درباره وضعیت کنونی و چشمانداز آیندهی کسبوکار استارتاپ کشف کرده است. این روش ملموستر، دقیقتر و سریعتر از پیشبینیهای بازاری یا برنامهریزی کلاسیک کسبوکار است و پادزهر اصلیِ معضل مرگبارِ «دستیابی به شکست» است: اجرای موفق برنامهای که به هیچ کجا نمیانجامد.
یادگیری معتبر در IMVU
برای توضیح این مفهوم، از مثالی در مسیر حرفهای خودم استفاده میکنم. بسیاری از مخاطبان، داستان شکلگیری IMVU و اشتباهات فراوان ما در توسعهی نخستین محصول را شنیدهاند. اکنون یکی از آن خطاها را با جزئیات بیشتر شرح میدهم تا «یادگیری معتبر» روشنتر شود.
ما که در بنیانگذاری IMVU نقش داشتیم، میخواستیم واقعاً راهبردی و سنجیده بیندیشیم. هر یک از ما در تلاشهای قبلی شکست خورده بود و نمیخواستیم آن تجربه تکرار شود. دغدغههای اصلیمان در روزهای آغازین اینها بود: چه بسازیم و برای چه کسی؟ به کدام بازار میتوانیم وارد شویم و در آن برتری یابیم؟ چگونه ارزشی ماندگار خلق کنیم که رقابت نتواند بهسادگی آن را فرسایش دهد؟
راهبرد درخشان
تصمیم گرفتیم وارد بازار «پیامرسانی فوری» (IM) شویم. در سال ۲۰۰۴، صدها میلیون نفر در سراسر جهان بهطور فعال از IM استفاده میکردند. با اینحال، اغلب کاربران بابت این خدمت پولی نمیپرداختند. در عوض، شرکتهای بزرگ رسانهای و پورتالها مانند AOL، مایکروسافت و یاهو شبکههای IM خود را بهعنوان سکوی جذب کاربران برای خدمات دیگر اداره میکردند و از راه تبلیغات، درآمد اندکی به دست میآوردند.
IM نمونهای از بازاری با «اثر شبکه» قوی است. مانند بیشتر شبکههای ارتباطی، تصور میشود IM از «قانون متکالف» تبعیت میکند: ارزش کل شبکه با مربع تعداد کاربران نسبت مستقیم دارد. یعنی هرچه افراد بیشتری در شبکه باشند، شبکه ارزشمندتر است. این شهودی است: ارزش برای هر کاربر، عمدتاً به تعداد افرادی بستگی دارد که میتواند با آنها ارتباط بگیرد. تلفنی را تصور کنید که تنها شما دارید؛ بیارزش است. وقتی دیگران هم تلفن داشته باشند، آنگاه ارزش پیدا میکند.
در سال ۲۰۰۴ بازار IM در اختیار چند بازیگر مسلط بود. سه شبکهٔ برتر بیش از ۸۰ درصد مصرف کلی را در دست داشتند و با کاهش سهمِ چند بازیگر کوچکتر، موقعیت خود را تثبیت میکردند. باور رایج این بود که ورود یک شبکهی IM تازه بدون صرف هزینههای بازاریابیِ خارقالعاده عملاً ناممکن است.
دلیل این باور روشن است. بهسبب قدرتِ اثر شبکه، مشتریان مجبور بودند از همان محصول IM استفاده کنند که دوستانشان استفاده میکردند. این هزینههای بالای جابجایی برای مشتریان، یک مانع ورود به بازار IM ایجاد میکند: با توجه به اینکه همه مصرفکنندگان به محصول یک شرکت بزرگ وابسته شدهاند، هیچ مشتریای باقی نمیماند که بتوان با او یک جای پا ایجاد کرد..
در IMVU به راهبردی رسیدیم که محصولی بسازیم با «جذابیتِ عام»ِ IM سنتی، اما با «درآمدِ بالا بهازای هر مشتری» همچون بازیهای سهبعدی (3D) و جهانهای مجازی. چون آوردنِ یک شبکهٔ تازهٔ IM به بازار تقریباً غیرممکن بود، تصمیم گرفتیم «افزونهای (add-on)» بسازیم که با شبکههای موجود سازگار باشد. بدینترتیب، مشتریان میتوانستند بدون تعویض ارایه دهندهٔ IM، بدون یادگیریِ یک رابط کاربری تازه و (مهمتر از همه) بدون مجبورکردنِ دوستانشان به کوچ، از «کالای مجازی» و فناوری «آواتارِ ارتباطیِ» IMVU استفاده کنند.
در واقع، همین نکتهی آخر را حیاتی میدانستیم. برای مفیدبودن افزونه، مشتری باید آن را با دوستان فعلیاش به کار میگرفت. هر پیام، دعوتنامهای در دل خود برای پیوستن به IMVU حمل میکرد. محصول ما ذاتاً «ویروسی» میشد و مانند یک اپیدمی در شبکههای موجود گسترش مییافت. برای دستیابی به این رشدِ ویروسی، لازم بود افزونهٔ ما تا حد امکان شبکههای بیشتری را پشتیبانی کند و روی انواع رایانهها درست کار کند.
شش ماه تا عرضه
با مشخصشدن این راهبرد، من و همبنیانگذارانم دورهای از کار فشرده را آغاز کردیم. بهعنوان مدیر ارشد فناوری، از جمله مسئولیتهایم نوشتن نرمافزاری بود که قابلیت همعملی (interoperability) میان شبکههای پیامرسان را پشتیبانی کند. ماهها با ساعتهای کاری دیوانهوار کار کردیم تا نخستین محصول را آمادهٔ انتشار کنیم. برای خودمان ضربالاجل سختی گذاشتیم: شش ماه—۱۸۰ روز—برای عرضهٔ محصول و جذب اولین مشتریان پرداختکننده. برنامهٔ طاقتفرسایی بود، اما مصمم بودیم بهموقع لانچ کنیم.
محصول افزونه آنقدر بزرگ و پیچیده و پر از اجزای متحرک بود که ناچار شدیم برای بهموقع رساندنش از بسیاری گوشهها بزنیم. بیپرده بگویم: نسخهٔ اول وحشتناک بود. ساعتهای بیپایانی را صرف بحث میکردیم که کدام باگ را برطرف کنیم و با کدام میتوانیم کنار بیاییم، کدام ویژگی را حذف کنیم و کدام را به زحمت جا بدهیم. زمانهای هم دلنشین و هم هراسآور بود: از یکسو پر از امید به امکان موفقیت، و از سوی دیگر نگران پیامدهای ارسالِ محصولی بدکیفیت.
شخصاً نگران بودم که کیفیت پایین محصول، اعتبارم را بهعنوان مهندس خدشهدار کند؛ نکند بگویند بلد نیستم محصول باکیفیت بسازم. همهٔ ما هم بیم داشتیم برند IMVU آسیب ببیند؛ بالاخره از مردم برای محصولی که چندان درست کار نمیکرد پول میگرفتیم. تیترهای کوبندهٔ روزنامهها جلوی چشممان بود: «کارآفرینان ناشی محصولی دهشتناک ساختند.»
هرچه به روز عرضه نزدیکتر میشدیم، ترسمان بیشتر میشد. در چنین موقعیتی خیلی از تیمهای کارآفرین تسلیم ترس میشوند و تاریخ عرضه را عقب میاندازند. گرچه این وسوسه را میفهمم، خوشحالم که پافشاری کردیم؛ چون تعویق، خیلی استارتاپها را از بازخورد لازم محروم میکند. شکستهای قبلی ما را از سرانجامی حتی بدتر از تحویلِ محصول بد میترساند: ساختن چیزی که هیچکس نمیخواهد. پس با دندانهای بههمفشرده و عذرخواهیِ آماده، محصول را عمومی منتشر کردیم.
عرضه (لانچ)
و بعد، هیچ اتفاقی نیفتاد! معلوم شد ترسهای ما بیاساس بوده، چون اصلاً کسی محصول را امتحان هم نکرد. اولش خیالم راحت شد که دستکم کسی از بد بودن محصول باخبر نمیشود؛ اما خیلی زود جای خود را به سرخوردگی جدی داد. پس از آن همه بحث دربارهی اینکه چه ویژگیهایی را بگذاریم و کدام باگها را رفع کنیم، «پیشنهاد ارزش» ما آنقدر پرت بود که مشتریان اصلاً تا جایی پیش نمیرفتند که بفهمند انتخابهای طراحیمان چقدر بد است؛ حتی حاضر نبودند محصول را دانلود کنند.
در هفتهها و ماههای بعد، با تمام توان برای بهترکردن محصول کوشیدیم. از مسیر ثبتنام و دانلود آنلاین، جریان ثابتی از مشتریان را وارد میکردیم. مشتریان هر روز برایمان کارنامهی تازهای بودند تا بفهمیم چطور پیش میرویم. سرانجام یاد گرفتیم جایگاهگذاریِ محصول را عوض کنیم تا دستکم مشتریان آن را دانلود کنند. بهطور پیوسته زیرساخت محصول را بهبود میدادیم و هر روز اصلاح باگ و تغییرات جدید منتشر میکردیم. بااینحال، بهرغم تمام تلاشها، فقط توانستیم تعداد ناچیزی را به خرید محصول متقاعد کنیم.
با نگاه به گذشته، یک تصمیمِ درستمان این بود که از همان روزهای نخست، اهداف درآمدیِ شفاف تعیین کردیم. در ماه اول قصد داشتیم در مجموع ۳۰۰ دلار درآمد داشته باشیم، و به زحمت به آن رسیدیم. از دوستان و خانواده زیاد کمک خواستیم (درستتر بگویم: التماس کردیم). هر ماه هدفهای کوچک درآمدی قدری بالا میرفت: اول ۳۵۰ دلار، بعد ۴۰۰ دلار. هرچه بالاتر میرفت، تقلا بیشتر میشد. خیلی زود دوستان و خانواده تمام شدند؛ ناامیدیمان شدت گرفت. هر روز محصول را بهتر میکردیم، اما رفتار مشتریان تغییری نمیکرد: همچنان استفاده نمیکردند.
اینکه نتوانستیم اعداد را تکان بدهیم، ما را واداشت تلاشها را تندتر کنیم و مشتریان را برای مصاحبههای حضوری و آزمونهای کاربری به دفتر بیاوریم. این اهداف کمی، انگیزهی پرداختن به پرسشهای کیفی را ایجاد کرد و در نوع پرسشها راهنماییمان شد؛ الگویی که در سراسر کتاب تکرار میشود.
ایکاش میتوانستم بگویم من بودم که خطا را دیدم و راهحل پیشنهاد دادم، اما واقعیت این است که آخرین نفری بودم که مشکل را پذیرفتم. خلاصه اینکه کل تحلیل راهبردیمان از بازار کاملاً غلط بود. این را نه از گروههای کانونی و پژوهش بازاری، بلکه بهصورت تجربی و از راه آزمایش فهمیدیم. مشتریان نمیتوانستند به ما بگویند چه میخواهند، بسیاری از آنها اصلاً نام «آواتار سهبعدی» را نشنیده بودند. در عوض، وقتی ما برای بهترکردن محصول تلاش میکردیم، آنها حقیقت را با «عمل» یا «بیعملی»شان آشکار کردند.
با مشتریان صحبت کردن
از سر ناچاری تصمیم گرفتیم با چند مشتری بالقوه صحبت کنیم. آنها را به دفتر آوردیم و گفتیم: «این محصول جدید را امتحان کنید؛ اسمش IMVU است». اگر طرف نوجوان بود، کاربر پرمصرف پیامرسان (IM) یا از پذیرندگان اولیهی فناوری، وارد تعامل میشد؛ اما اگر فردی «عمومی» بود، پاسخ میداد: «خب دقیقاً میخواهید چه کار کنم؟» با این گروه به جایی نمیرسیدیم؛ IMVU را زیادی عجیب میدانستند.
فرض کنید دختر هفدهسالهای روبهرویمان مینشیند تا محصول را ببیند. آواتارش را انتخاب میکند و میگوید: «اوه، خیلی بامزه است.» شروع میکند به شخصیسازی و انتخاب ظاهر. بعد میگوییم: «خُب، وقت دانلود افزونهی پیامرسانی فوری است.» و او میپرسد: «افزونهی پیامرسانی چیست؟»
میگوییم: «چیزی است که با نرمافزار پیامرسان شما همعمل میشود.» به ما نگاه میکند و با خودش میگوید: «هرگز چنین چیزی نشنیدهام؛ دوستانم هم نشنیدهاند؛ چرا باید این کار را بکنم؟» نیاز به کلی توضیح داشت؛ «افزونهی پیامرسان» اصلاً در ذهن او یک دستهی محصول محسوب نمیشد.
اما چون در اتاق با ما بود، توانستیم راضیاش کنیم انجامش دهد. محصول را دانلود میکند و ما میگوییم: «خُب، یکی از دوستانت را دعوت کن بیاید چت کنیم.» و او میگوید: «عمراً!» میپرسیم: «چرا؟» میگوید: «نمیدانم این چیز واقعاً باحال هست یا نه. میخواهید ریسک کنم و دوستم را دعوت کنم؟ اگر بد باشد، فکر میکند من هم بدسلیقهام، نه؟» ما میگوییم: «نه نه، وقتی دوستت بیاید خیلی خوش میگذرد؛ این یک محصول اجتماعی است». تردید توی صورتش موج میزند؛ آشکارا همینجا همهچیز میریزد. بار اول که این صحنه را دیدم، گفتم: «اشکال ندارد؛ فقط همین یک نفر بود؛ بفرستید برود و نفر بعد». نفر دوم هم همان را گفت. نفر سوم هم همینطور. الگوها کمکم نمایان شد و هر قدر هم لجباز باشید، پیدا است که مشکلی بنیادی وجود دارد.
مشتریان مدام میگفتند: «میخواهم اول تنها استفاده کنم. میخواهم اول خودم امتحان کنم ببینم واقعاً خوب است یا نه، بعد دوستی را دعوت کنم.» تیم ما از صنعت بازی ویدئویی آمده بود، پس منظورشان را میفهمیدیم: «حالت تکنفره». بنابراین نسخهی تکنفره ساختیم.
مشتریان جدید را به دفتر میآوردیم. مثل قبل آواتار را شخصیسازی میکردند و محصول را دانلود. بعد وارد حالت تکنفره میشدند و ما میگفتیم: «با آواتارت بازی کن و لباس بپوشان؛ حرکتهای جالبش را ببین.» و بلافاصله: «حالا وقتش است یکی از دوستانت را دعوت کنی.» حدس میزنید چه میشد. میگفتند: «عمراً! این باحال نیست.» ما هم میگفتیم: «خب گفتیم تجربهی تکنفرهی محصول اجتماعی جذاب نیست! هدف حالت تکنفره در یک محصول اجتماعی چیست؟» تصور میکردیم صرفِ گوشدادن به مشتری باید برایمان «ستارهی طلا» بیاورد؛ اما مشتری هنوز محصول را نمیپسندید. به ما نگاه میکرد و میگفت: «ببین آقا، متوجه نمیشوی. چرا باید قبل از اینکه مطمئن شوم باحال است، دوست دعوت کنم؟» این یک سدّ کامل بود.
از سر ناامیدی بیشتر، ویژگیای به نام «چتنَو» (ChatNow) اضافه کردیم که با فشردن یک دکمه، بهصورت تصادفی شما را با فردی در هر نقطهی دنیا جفت میکرد. تنها وجه اشتراک این بود که هر دو همان لحظه دکمه را زده بودید. ناگهان در آزمونهای خدمات مشتری، مردم میگفتند: «اوه، این جالب است!»
آنها را میآوردیم، از «چتنَو» استفاده میکردند و شاید با کسی روبهرو میشدند که به نظرشان عالی بود. میگفتند: «این طرف خوب بود؛ میخواهم به فهرست دوستانم اضافهاش کنم. فهرست دوستم کجاست؟» ما میگفتیم: «نه، فهرست جدید نمیخواهی؛ از فهرست معمولیِ AOL خودت استفاده کن.» یادتان باشد، این طوری میخواستیم از همعملی بهره بگیریم تا اثرات شبکهای و رشد ویروسی رخ دهد. حالا طرف به ما نگاه میکرد و میپرسید: «دقیقاً میخواهید چه کار کنم؟» میگفتیم: «نام کاربری AIM خودت را به این غریبه بده تا در فهرست دوستانت اضافهاش کنی.» چشمهایشان گرد میشد: «شوخی میکنید؟ یک غریبه در فهرست AIM من؟» و ما پاسخ میدادیم: «بله؛ وگرنه باید یک برنامهی پیامرسان کاملاً جدید با فهرست دوستان جدید دانلود کنی.» میگفتند: «میدانید من الان چند پیامرسان اجرا میکنم؟»
ما: «نه. یکی دو تا، شاید؟»؛ آنقدر که در دفتر خودمان استفاده میکردیم. نوجوان پاسخ میداد: «نه، من همزمان چندتایشان را دارم.» ما اصلاً نمیدانستیم در دنیا چند برنامهی پیامرسان وجود دارد.
پیشانگارهی نادرست ما این بود که یادگرفتن نرمافزار جدید دشوار است و انتقال دوستان به فهرست جدید کار سختی است. مشتریان نشان دادند این حرفها بیمعناست. ما دوست داشتیم روی وایتبرد نمودار بکشیم و توضیح بدهیم چرا راهبردمان «درخشان» است، اما مشتریان مفاهیمی مثل «اثرات شبکهای» و «هزینهی جابهجایی» را درک نمیکردند. اگر میکوشیدیم توضیح دهیم چرا باید طبق پیشبینی ما رفتار کنند، فقط با تعجب سر تکان میدادند.
مدل ذهنی ما از نحوهی استفادهی مردم از نرمافزار، سالها عقبمانده بود؛ و سرانجام (بهسختی و پس از دهها جلسه مشابه) کمکم دریافتیم که مفهوم «افزونهی پیامرسان» اساساً معیوب است.
مشتریان ما افزونهی پیامرسان نمیخواستند؛ یک شبکهی پیامرسان مستقل میخواستند. یادگیری یک برنامهی جدید را مانع نمیدانستند؛ برعکس، پذیرندگان اولیهی ما همزمان از چندین برنامهی پیامرسان استفاده میکردند. ایدهی بردن دوستان به شبکهی جدید هم برایشان ترسناک نبود؛ معلوم شد از این چالش لذت میبرند. حتی شگفتانگیزتر، این فرض که مشتریان میخواهند پیامرسان مبتنی بر آواتار را عمدتاً با دوستان موجودشان به کار ببرند نیز غلط بود. آنها میخواستند دوستهای جدید پیدا کنند؛ کاری که آواتارهای سهبعدی بهویژه برایش مناسباند. ذرهذره، مشتریان «راهبرد اولیهی بهظاهر درخشان» ما را از هم گسستند.
به دور انداختن کارم
شاید بتوانید با وضعیت ما همدلی کنید و لجاجت مرا ببخشید. بالاخره این «کار چند ماههی من» بود که باید دور ریخته میشد. من روی نرمافزاری عرق ریخته بودم که برای همعملیِ برنامهی پیامرسان ما با سایر شبکهها لازم بود؛ چیزی که در قلب راهبرد اولیهمان قرار داشت. وقتی زمانِ چرخش و کنار گذاشتن آن راهبرد رسید، تقریباً تمام کارِ من (هزاران خط کد) دور ریخته شد. احساس خیانتدیدگی داشتم. من شیفتهی تازهترین روشهای توسعهی نرمافزار (که بهطور جمعی «توسعهی چابک» نامیده میشود) بودم؛ روشهایی که وعده میدادند اتلاف را از توسعهی محصول بیرون کنند. با وجود این، بزرگترین اتلاف ممکن را مرتکب شده بودم: ساختن محصولی که مشتریان از استفادهاش سر باز زدند. این واقعاً ناامیدکننده بود.
با خود فکر میکردم: با توجه به اینکه کارم اتلاف وقت و انرژی از آب درآمد، آیا شرکت اگر من شش ماه گذشته را در ساحل، در حالی که نوشیدنیام را مینوشیدم، میگذراندم، به همان اندازه وضعیت خوبی نداشت؟ آیا واقعاً به من نیازی بود؟ آیا بهتر نبود اصلاً کاری نمیکردم؟
همانطور که در آغاز این فصل گفتم، همیشه یک پناهگاه آخر برای کسانی هست که میخواهند شکست خود را توجیه کنند. خودم را دلداری میدادم که اگر آن نسخهی نخستین (با همهی خطاها) را نمیساختیم، هرگز به این بینشهای مهم دربارهی مشتریان دست نمییافتیم. هرگز نمیفهمیدیم راهبردمان معیوب است. در این بهانه حقیقتی هست: آموختههای آن ماههای حساسِ نخست، IMVU را در مسیری قرار داد که به موفقیت چشمگیرِ بعدیمان انجامید.
مدتی این دلداریِ «یاد گرفتهایم» حالم را بهتر کرد، اما آرامشم دوام نیاورد. پرسشی که بیش از همه آزارم میداد این بود: اگر هدف آن ماهها کسبِ همین بینشهای مهم دربارهی مشتریان بود، چرا اینقدر طول کشید؟ چه مقدار از تلاش ما به درسهای واقعاً ضروری مربوط بود؟ آیا اگر من اینقدر مشغول «بهتر کردن» محصول با افزودن ویژگی و رفعِ باگها نبودم، میتوانستیم زودتر همان درسها را بیاموزیم؟
ارزش در برابر اتلاف
به بیان دیگر، کدامیک از تلاشهای ما ارزشآفرین بود و کدامها اتلاف؟ این پرسش در قلب انقلاب «تولید ناب» قرار دارد؛ اولین پرسشی که هر پیروِ تولید ناب برای طرحش آموزش میبیند. توانایی دیدن اتلاف و سپس حذف نظاممند آن، شرکتهای ناب (مانند تویوتا) را قادر کرده است بر تمام صنایع چیره شوند. در دنیای نرمافزار، روشهای توسعهی چابکی که تا آن زمان تمرین میکردم، ریشه در همین تفکر ناب داشتند؛ آنها نیز برای حذف اتلاف طراحی شدهاند.
با این حال، همان روشها مرا به مسیری بردند که در آن، بخش عمدهی تلاشهای تیمم هدر میرفت. چرا؟
پاسخش در سالهای بعد، آرامآرام برایم روشن شد. تفکر ناب، «ارزش» را «ارائهی فایده برای مشتری» تعریف میکند؛ هر چیز دیگر اتلاف است. در کسبوکار تولیدی، مشتریان اهمیتی نمیدهند محصول چگونه مونتاژ شده؛ فقط میخواهند درست کار کند. اما در یک استارتاپ، اینکه «مشتری کیست» و «چه چیزی را ارزشمند مییابد» نامعلوم است؛ جزئی از همان عدمقطعیت شدیدی که در تعریف استارتاپ نهفته است. دریافتم که بهعنوان یک استارتاپ، به «تعریف تازهای از ارزش» نیاز داریم. پیشرفت واقعی ما در IMVU همان چیزهایی بود که در آن ماههای نخست دربارهی «چه چیزی برای مشتریان ارزش میسازد» آموختیم.
هر کاری که در آن ماهها کردیم و به یادگیری ما کمک نکرد، شکلی از اتلاف بود. آیا ممکن بود همان چیزها را با تلاش کمتر بیاموزیم؟ آشکارا پاسخ، بله است.
برای نمونه، به همهی بحثها و اولویتگذاریهایی فکر کنید که صرف ویژگیهایی شد که مشتری هرگز آنها را کشف نکرد. اگر زودتر عرضه میکردیم، میتوانستیم از آن اتلاف بپرهیزیم. همچنین همهی اتلافی را در نظر بگیرید که «فرضهای راهبردیِ نادرستِ ما» ایجاد کرد. من همعملی با بیش از یک دوجین کلاینت و شبکهی پیامرسان ساخته بودم. آیا واقعاً برای آزمون فرضهایمان لازم بود؟ آیا میتوانستیم همان بازخورد را با نصف آن شبکهها بگیریم؟ با فقط سه تا؟ با فقط یک شبکه؟ از آنجا که مشتریان همهی شبکههای پیامرسان، محصول ما را به یک اندازه نامطلوب میدیدند، سطح یادگیری یکسان میماند؛ اما تلاش ما بهطرز چشمگیری کمتر میشد.
اندیشهای که شبها خواب از چشمانم میربود این بود: آیا اصلاً لازم بود هیچ شبکهای را پشتیبانی کنیم؟ آیا ممکن بود بدون ساختن هیچچیز، به نامعتبر بودن فرضهایمان پی ببریم؟ مثلاً اگر تنها «امکان دانلود محصول بر مبنای ویژگیهای پیشنهادی» را (پیش از ساختِ هر چیز) به مشتریان عرضه میکردیم، چه؟ به یاد بیاورید که تقریباً هیچ مشتریای حاضر نبود از محصول اولیهی ما استفاده کند؛ پس اگر نمیتوانستیم تحویل دهیم، نیازی نبود زیاد عذرخواهی کنیم. (توجه کنید این متفاوت است از اینکه از مشتریان بپرسیم چه میخواهند؛ اغلب مشتریان از پیش نمیدانند چه میخواهند). میتوانستیم «آزمایشی» اجرا کنیم: به مشتریان فرصت امتحان چیزی را بدهیم و سپس رفتارشان را بسنجیم.
این «آزمایشهای ذهنی» برایم بهغایت ناآرامکننده بود، زیرا «شرحِ وظایفم» را زیر سؤال میبرد. بهعنوان مسئول توسعهی محصول، میپنداشتم کارم تضمینِ تحویلِ بهموقعِ محصولات و ویژگیهای باکیفیت است. اما اگر بسیاری از آن ویژگیها اتلاف وقت بودند، پس بهجای آن باید چه میکردم؟ چگونه میتوانستیم از این اتلاف پرهیز کنیم؟
به این باور رسیدهام که «یادگیری» واحدِ اساسیِ پیشرفت برای استارتاپها است. هر تلاشی که برای فهمیدن «آنچه مشتری میخواهد» مطلقاً ضروری نباشد، قابل حذف است. من این را «یادگیری معتبر» مینامم، زیرا همیشه با «بهبودهای مثبت در سنجههای هستهای استارتاپ» نشان داده میشود. همانطور که دیدیم، فریب دادنِ خود، دربارهی اینکه «فکر میکنیم» مشتری چه میخواهد آسان است؛ آموختن چیزهای کاملاً بیربط نیز آسان است. ازاینرو، «یادگیری معتبر» با «دادههای تجربیِ گردآمده از مشتریان واقعی» پشتیبانی میشود.
اعتبار را از کجا پیدا کنیم؟
از تجربه میگویم: هر کسی که در یک استارتاپ شکست میخورد میتواند ادعا کند چیزهای زیادی یاد گرفته است و داستان قانعکنندهای تعریف کند. در روایت IMVU تا اینجا شاید متوجه خلعای شده باشید. با آنکه گفتهام در ماههای نخست بسیار آموختیم و همان درسها ما را به موفقیت رساند، هنوز هیچ شاهدی ارائه نکردهام. با نگاه به گذشته، طرح چنین ادعاهایی آسان و حتی قابلباور است (و بعدتر در کتاب شواهدی خواهید دید)؛ اما خودِ ما را در ماههای آغازین IMVU تصور کنید که میکوشیدیم سرمایهگذاران، کارمندان، اعضای خانواده و از همه مهمتر خودمان را قانع کنیم که وقت و منابعمان را هدر ندادهایم. چه مدرکی داشتیم؟
بیتردید روایت شکستهایمان شنیدنی بود و نظریههای جذابی دربارهی خطاها و آنچه باید برای ساخت محصول موفق انجام دهیم داشتیم. با این حال، «اثبات» زمانی پدیدار شد که آن نظریهها را به عمل تبدیل کردیم و نسخههای بعدی محصول را ساختیم؛ نسخههایی که نزد مشتریان واقعی نتایج بهتری نشان دادند.
چند ماهِ بعدی جایی است که داستان واقعی IMVU آغاز میشود؛ نه با فرضها و راهبردهای درخشانِ روی وایتبرد، بلکه با کار سخت کشف آنچه مشتریان واقعاً میخواهند و وفقدادن محصول و استراتژی با آن خواستهها. ما این دیدگاه را پذیرفتیم که کار ما یافتن آمیزهای است میان چشماندازمان و آنچه مشتری میپذیرد؛ نه تسلیمشدن در برابر تصورات مشتری از «آنچه فکر میکند میخواهد» و نه دیکتهکردن «آنچه باید بخواهد».
هرچه مشتریانمان را بهتر شناختیم، توانستیم محصولاتمان را بهبود دهیم و با این کار، سنجههای بنیادین کسبوکار تغییر کرد. در روزهای نخست، با وجود همهی تلاشها برای بهبود، نمودارها لجبازانه تخت بود. هر روز مشتریان همانند «کارنامهی تازه» بودند: درصد تازهواردهایی را که رفتاری چون دانلود و خرید نشان میدادند میسنجیدیم. هر روز تقریباً همان تعداد اندک خرید رخ میداد؛ عددی که با وجود بهبودهای فراوان، به صفر نزدیک میماند.
اما بهمحض چرخش از راهبرد اولیه، اوضاع دگرگون شد. وقتی محصول با راهبردی برتر همسو شد، بهرهوری توسعهی ما «جادویی» بالا رفت؛ نه چون سختتر کار میکردیم، بلکه چون هوشمندانهتر و همراستا با نیازهای واقعی مشتری کار میکردیم. تغییرات مثبت در سنجهها به «تأییدِ عددی» تبدیل شد که نشان میداد یادگیریمان واقعی است. این حیاتی بود، زیرا میتوانستیم به ذینفعان (کارمندان، سرمایهگذاران و خودمان) نشان دهیم واقعاً پیش میرویم، نه اینکه خودمان را فریب دهیم. همچنین این دقیقترین نگاه به «بهرهوری استارتاپ» است: نه بر پایهی «حجم ساختهها»، بلکه بر پایهی «میزان یادگیری معتبر»ی که از هر تلاش به دست میآوریم. برای نمونه، در یکی از آزمایشهای اولیه، تمام وبسایت، صفحهی اصلی و جریان ثبتنام را تغییر دادیم تا «گفتوگوی آواتاری» را با «پیامرسانیِ فوری سهبعدی» جایگزین کنیم. مشتریان جدید بهصورت خودکار میان دو نسخه تقسیم میشدند؛ نیمی این را میدیدند و نیمی آن را. توانستیم تفاوت رفتار دو گروه را اندازه بگیریم: افراد گروه آزمایشی نهتنها بیشتر ثبتنام میکردند، بلکه احتمال تبدیلشدنشان به مشتریان بلندمدتِ پرداختکننده نیز بیشتر بود. البته آزمایشهای ناموفق هم کم نداشتیم. دورهای که میپنداشتیم مشتریان بهدلیل نفهمیدن مزایای متعدد محصول از آن استفاده نمیکنند، حتی به پشتیبانان پول دادیم تا برای تازهواردها «تور معرفی ویژه» اجرا کنند؛ اما آن مشتریان هم بیش از دیگران فعال یا پرداختکننده نشدند. حتی پس از کنار گذاشتن راهبرد افزونهی پیامرسان، ماهها طول کشید تا بفهمیم چرا نگرفت. سرانجام، پس از پیوت و آزمایشهای بسیار، به این بینش رسیدیم: مشتریان میخواستند با IMVU «دوستان جدید آنلاین» پیدا کنند. آنها بهصورت شهودی چیزی را میفهمیدند که ما دیر دریافتیم: همهی محصولات اجتماعی موجود بر «هویت واقعیِ» مشتری متکی بودند، درحالیکه فناوری آواتارِ IMVU بهطور یگانه برای آشنا شدن ایمن، بیآنکه حریم یا هویت به خطر افتد، مناسب بود. وقتی این فرضیه را صورتبندی کردیم، احتمال موفقیت آزمایشها بالاتر رفت: هرگاه محصول را طوری تغییر میدادیم که «یافتن و نگهداشت دوستان جدید» آسانتر شود، درگیرشدن مشتریان افزایش مییافت.
این یعنی بهرهوری واقعی استارتاپ: کشف نظاممند «چه چیزهایی را باید ساخت». اینها فقط چند آزمایش از میان صدها آزمایشی بود که هفتگی اجرا میکردیم تا بیاموزیم کدام مشتریان از محصول استفاده میکنند و چرا. هر دانشی که به دست میآوردیم، الهامبخشِ آزمایشهای تازه میشد و سنجهها را پلهپله به هدف نزدیکتر میکرد.
جسارتِ صفر
با وجود موفقیتهای اولیهی IMVU، اعداد کلی ما هنوز کوچک بود. متأسفانه طبق شیوهی رایجِ ارزیابی کسبوکارها، این وضعیت خطرناک است. تناقض ماجرا اینجاست: معمولاً وقتی «صفرِ درآمد، صفرِ مشتری و صفرِ کشش» دارید، جذب سرمایه یا منابع دیگر سادهتر از زمانی است که «کمی» عدد دارید. صفر، جا برای خیالپردازی میگذارد؛ اما اعداد کوچک، این پرسش را پیش میکشند که آیا این اعداد هرگز «بزرگ» میشوند یا نه. همه قصههایی (یا گمان میکنند میدانند) از محصولاتی شنیدهاند که یکشبه جهش خیرهکننده داشتهاند. تا وقتی چیزی عرضه نشده و دادهای جمع نشده، همیشه میتوان آن «یکشبه موفقشدن» را در آینده تصور کرد؛ ولی اعداد کوچک آبِ سردی بر آن امید میریزند.
این پدیده یک مشوقِ خشن میسازد: «جمعآوری هیچ دادهای را به تعویق بینداز تا وقتی که از موفقیت مطمئن شوی.» اما همانطور که خواهیم دید، چنین تأخیری حجمِ اتلافِ کار را بالا میبرد، بازخوردِ ضروری را کم میکند و خطرِ ساختن چیزی را که هیچکس نمیخواهد، بهشدت افزایش میدهد.
از آن طرف، صرفِ «عرضهی محصول و امید بستن به بهترین نتیجه» هم برنامهی خوبی نیست، چون همین مشوق واقعاً اثر دارد. وقتی IMVU را لانچ کردیم، از این مسئله بیخبر بودیم. سرمایهگذاران و مشاوران اولیهی ما برنامهی درآمد ۳۰۰ دلاری در ماه اول را بامزه میدیدند؛ اما پس از چند ماه که درآمدمان حوالی ۵۰۰ دلار ماند، برخی از آنها (و حتی بعضی از مشاوران، کارمندان و همسرانمان) ایمانشان را از دست دادند. در مقطعی، بعضی سرمایهگذاران جدی پیشنهاد میدادند محصول را از بازار بیرون بکشیم و دوباره به «حالت پنهان» برگردیم. خوشبختانه، با پیوتکردن و انجام آزمایشها و واردکردنِ آموختهها به توسعهی محصول و بازاریابی، اعداد رو به بهبود رفتند.
اما نه خیلی! از یکسو خوششانس بودیم که الگویی شبیه «نمودار چوب هاکی» شکل گرفت؛ از سوی دیگر، منحنی فقط تا چند هزار دلار در ماه بالا میرفت. این نمودارهای اولیه (با آنکه نویدبخش بودند) برای جبران ازدسترفتنِ اعتماد کافی نبودند و ما زبان «یادگیری معتبر» را برای ساختن یک مفهوم بدیلِ اجماعآفرین نداشتیم. خوشاقبال بودیم که برخی از سرمایهگذاران اولیهی ما اهمیت موضوع را فهمیدند و فراتر از ارقام کوچک، «پیشرفت واقعی» را دیدند (در فصل ۷ همان نمودارها را خواهید دید).
پس میتوان اتلافی را که از «جسارتِ صفر» ناشی میشود با «یادگیری معتبر» مهار کرد. باید نشان میدادیم که تلاشهای توسعهی محصول، ما را (بدون لغزیدن به سمت «شاخصهای فریبا» و «تئاتر موفقیت») بهسوی موفقیت عظیم میبرد. میتوانستیم با میانبرهای بازاریابی، تبلیغِ گران سوپربول یا روابطعمومی پرزرقوبرق، ارقام ظاهری را باد کنیم؛ اینها شاید توهم کشش به سرمایهگذاران میداد؛ اما فقط برای مدتی کوتاه. در نهایت، بنیادهای کسبوکار حرف آخر را میزنند و بادِ روابطعمومی میخوابد. اگر منابع کمیاب را صرف نمایش کرده بودیم، نه پیشرفت، واقعاً به دردسر میافتادیم.
شصت میلیون آواتار بعد، IMVU همچنان پرقدرت ادامه میدهد. میراث آن فقط محصولی عالی، تیمی درخشان و نتایج مالی امیدوارکننده نیست؛ بلکه «روشی تازه برای سنجش پیشرفت استارتاپها» است.
درسهایی فراتر از IMVU
از وقتی مدرسهی کسبوکار استنفورد یک مطالعهی رسمی از سالهای آغازین IMVU نوشت، بارها فرصت یافتهام این داستان را بهعنوان «مطالعهی موردی» تدریس کنم؛ این کیس اکنون بخشی از درسهای کارآفرینی در چندین مدرسهی کسبوکار (از جمله هاروارد، جایی که بهعنوان کارآفرین مقیم خدمت میکنم) است؛ و این روایت را در کارگاهها، سخنرانیها و کنفرانسهای بیشمار بازگو کردهام.
هر بار که داستان IMVU را تدریس میکنم، دانشجویان وسوسه میشوند روی «تاکتیکها» تمرکز کنند: عرضهی پروتوتایپ کمکیفیت اولیه، گرفتن پول از روز اول و استفاده از اهداف درآمدیِ کمحجم برای ایجاد پاسخگویی. اینها مفیدند، اما «اخلاق داستان» نیستند؛ استثنا زیاد است. مثلاً همهی مشتریان، پروتوتایپ کمکیفیت را نمیپذیرند. یا تردیدکنندگان میگویند این تاکتیکها فقط برای شرکتهای نرمافزاری اینترنتِ مصرفی یا کاربردهای غیرحیاتی جواب میدهد و به صنعت آنها ربطی ندارد.
این برداشتها سود چندانی ندارند. «استارتاپ ناب» مجموعهای از ترفندهای جدا از هم نیست؛ رویکردی «مبتنی بر اصول» برای توسعهی محصول جدید است. تنها راهِ فهمِ توصیهها این است که اصول زیربناییِ کارآمدیِ آنها را درک کنیم. همانطور که در فصلهای بعد خواهید دید، الگوی استارتاپ ناب در صنایع و کسبوکارهای متنوعی بهکار رفته است: تولید، کلینتک، رستوران و حتی رختشویی. ممکن است تاکتیکهای داستان IMVU با کسبوکار شما جور درنیاید؛ یا بیاید.
راه درست این است که هر استارتاپی را (در هر صنعتی) «یک آزمایش بزرگ» ببینیم. پرسش اصلی این نیست که «آیا این محصول را میتوان ساخت؟»؛ در اقتصاد امروز تقریباً هر چیزی که تصور شود، قابل ساختن است. پرسشهای درست ایناند: «آیا باید این محصول ساخته شود؟» و «آیا میتوانیم پیرامونِ این سبدِ محصولات و خدمات، کسبوکاری پایدار بنا کنیم؟» برای پاسخ، باید روشی داشته باشیم که یک طرحِ کسبوکار را نظاممند به اجزایش بشکند و هر جزء را بهصورت تجربی بیازماید.
به بیان دیگر، به «روش علمی» نیاز داریم. در الگوی استارتاپ ناب، هر محصول، هر ویژگی و هر کمپین بازاریابی (یعنی هر کاری که استارتاپ انجام میدهد) «آزمایشی» است که برای رسیدن به «یادگیری معتبر» طراحی شده است. این رویکرد تجربی، در صنایع و بخشهای گوناگون کار میکند؛ همانطور که در فصل ۴ خواهیم دید.