7 Counterintuitive Rules for Growing Your Business Super-Fast

🎯 هنر رشد بی‌رحمانه | Blitzscaling

مدتی پیش دوستی بهم این مقاله را معرفی کرد. مقاله ای که Reid Hoffman (هم‌بنیان‌گذار لینکدین) نوشته و ۷ قاعده‌ی بر خلاف شهود را برای رشد خیلی سریع توضیح داده. رشدی که با مفهومی که خودش ابداع کرده - Blitzscaling - توضیحش می‌ده. مفهوم این واژه تقریبا میشه رشد خیلی سریع، بی‌ثبات، دردناک و در عین حال ضروری.

متاسفانه این مقاله پشت paywall سایت مدیوم رفته بود و دیگه در دسترس نبود. برا همین کل مقاله رو یک‌جا جمع‌آوری کردم و با کمک هوش مصنوعی، ترجمه‌ای کاربردی و روون هم کنارش گذاشتم.

📎 توی این مقاله، هافمن به قواعد نانوشته‌ی بلیتزاسکیلینگ اشاره می‌کنه:

• چطور با آشوب کنار بیایم، نه فرار کنیم
• چرا باید با یک محصول «ناقص اما واقعی» لانچ کرد
• اینکه چرا لازمه، «کارهای غیرقابل مقیاس» انجام بدیم
• کی باید مشتری‌ها رو نادیده گرفت!

To achieve 'blitzscaling', you have to go against common sense

برای رسیدن به رشد فوق سریع لازمه که بر خلاف شهود سنتی عمل کنی

When it comes to startups, there's growth, and then there's ultra-rapid growth—what I like to call "blitzscaling." Blitzscaling a company isn't easy; if it were, everyone would do it. Like most things of value in this world, blitzscaling is contrarian. To succeed, you'll have to violate many of the management "rules" that are designed for efficiency and risk minimization. In fact, to achieve your aggressive growth goals in the face of uncertainty and change, you need to follow a new set of rules that fly in the face of what is taught in business schools and are completely counterintuitive to accepted "best practices" of either early stage startups or classic corporate management.

در دنیای استارتاپ‌ها، رشد وجود دارد و سپس چیزی فراتر از آن هست به نام «رشد فوق‌سریع» — چیزی که من آن را بلیتز‌اسکیلینگ می‌نامم. رساندن یک شرکت به مرحله بلیتز‌اسکیلینگ کار ساده‌ای نیست؛ اگر ساده بود، همه انجامش می‌دادند. مانند بسیاری از چیزهای ارزشمند در این دنیا، بلیتز‌اسکیلینگ یک مسیر خلاف‌آمد عادت است. برای موفقیت در آن، باید بسیاری از «قوانین مدیریتی» را زیر پا بگذارید — قوانینی که برای بهره‌وری و کاهش ریسک طراحی شده‌اند. در واقع، برای دستیابی به اهداف جسورانه‌ی رشد در شرایطی پر از ابهام و تغییر، باید از مجموعه‌ قوانینی پیروی کنید که نه تنها در مدارس کسب‌وکار تدریس نمی‌شوند، بلکه کاملاً برخلاف شهود و «بهترین‌رویّه‌ها»ی پذیرفته‌شده‌ی مدیریت در استارتاپ‌های اولیه یا شرکت‌های بزرگ هستند.

Rule #1: Embrace Chaos

Annual plans. Revenue guidance. Traditional business strives for order and regularity in management, operations, and financial results. This desire for order and regularity makes sense, because it allows companies to fine-tune their approach to be as efficient as possible and gives shareholders a pleasing sense of stability. But when you're blitzscaling, you're explicitly choosing to sacrifice efficiency for speed, which means the traditional focus on order and regularity needs to be replaced with a unique willingness to embrace a level of chaos that would horrify most Harvard MBAs and their professors.

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

Yet simply throwing up your hands is unlikely to bring success; passively succumbing to chaos is not a winning strategy. Embracing chaos, on the other hand, means accepting that uncertainty exists and, therefore, taking steps to manage it. If you know you'll make mistakes, the answer isn't to sit back and wait for answers to find you, nor is it to charge ahead without preparation or forethought. You can still make smart decisions based on your estimate of the probabilities, even without certainty. And, perhaps most important, you can make sure that you have the ability to correct your mistakes.

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

Rule #2: Hire Ms. Right Now, Not Ms. Right

For most of Silicon Valley's history, the conventional wisdom on hiring executives into a startup was to quickly bring in an executive who could scale. This meant hiring someone who had experience with much bigger organizations, the idea being that their experience would come in handy at a later stage.

در بیشتر دوران تاریخ سیلیکون‌ولی، تفکر رایج درباره جذب مدیران اجرایی برای استارتاپ‌ها این بود که خیلی زود باید کسی را بیاورید که بتواند شرکت را در مسیر رشد مقیاس‌پذیر هدایت کند. این یعنی جذب فردی با تجربه در سازمان‌های بسیار بزرگ‌تر، با این تصور که آن تجربه بعدها به درد خواهد خورد.

Hiring someone who has been managing 1,000 people to run a 10-person company is actually counterproductive.

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

In today's startup world, this rule no longer applies. The Darwinian competition is so fierce that your organization needs to be all-in on the current stage of scaling. You need managers and executives who are "just right" for the current phase of growth; after all, you won't have to worry about that next phase if your team can't actually get you there. Hiring someone who has been managing 1,000 people to run a 10-person company is actually counterproductive, because the skills needed to succeed during those two phases are very different.

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

Part of hiring Ms. Right Now also means knowing when to let someone go when the moment passes. For example, a great designer might excel at running a one-woman show but is less effective working as part of a larger design team.

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

Rule #3: Tolerate "Bad" Management

When blitzscaling, speed is more important than having a "well-run" organization. Under normal circumstances, you should strive for organizational coherence and stability. Chaotic, unstable organizations make employees nervous and hurt morale. But when you're scaling up at lightning speed, you may need to reorganize the company three times in a single year or repeatedly churn through members of your management team. When your organization is growing 300 percent per year, you might have to promote people before they're ready and then swap them out if they sink rather than swim. You don't have time to be patient and wait for things to work out; you have to act quickly and decisively. There's always a lot of change, and much of it isn't voluntary. You're simultaneously building teams and the company. In the interest of speed, you might even surprise or blindside your people to reduce the time required to make and implement important decisions.

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

Consider the example of PayPal. While PayPal was a great success, the company was badly managed — and I write that statement as one of its senior managers. We did a few good things, such as making sure that every employee had a clear primary job and staying focused when working on certain important projects, but for the most part, PayPal's management was a lack of management. There were no one-on-one career development conversations with employees. There was no work done to form teams beyond simply picking who was going to belong to them.

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

But PayPal's "bad" management provided a number of counterintuitive strengths while we were blitzscaling. During the critical times when PayPal was developing its business model innovations and scaling up, we found ourselves needing to navigate a series of make-or-break challenges, or as I like to call them, "Oh shit!" moments.

اما همین «مدیریت بد» در پی‌پال، در دوران بلیتزاسکیلینگ به ما یک‌سری مزایای غیرمنتظره و ضدشهودی داد. در دوره‌ی حساس توسعه‌ی مدل کسب‌وکار و رشد سریع پی‌پال، بارها با چالش‌هایی مواجه شدیم که واقعاً می‌توانستند شرکت را نابود کنند — لحظاتی که من دوست دارم به آن‌ها بگویم: «وای به فنا رفتیم!» لحظاتی مثل:

Oh shit, we have a fraud problem and we're losing millions of dollars we don't have. Oh shit, Visa says we have to change the product or they'll shut us down. Oh shit, eBay, our most important business partner, just started its own venture to directly compete with us.

وای، با مشکل تقلب (fraud) روبه‌رو شدیم و میلیون‌ها دلاری که نداریم را داریم از دست می‌دیم. وای، ویزا گفته یا باید محصول رو تغییر بدیم یا اینکه ما رو تعطیل می‌کنن. وای، eBay که مهم‌ترین شریک تجاری‌مونه، خودش یه کسب‌وکار رقیب راه انداخته.

Because of our "bad" management, we didn't have any preconceived notions of "this is what the company must look like in three years." The chaotic nature of our management actually kept us nimble in the face of these serious, unexpected land mines. When everyone in the organization has roles that are undefined and in flux, it's easier to say, "I know this is what you've been working on for the past four days, but now we're doing something different." The internal chaos had the effect of normalizing radical change for our people, which meant they were better able to adjust to the radical changes the outside world was throwing at us.

به‌دلیل «مدیریت بد» ما، هیچ تصور از پیش‌ساخته‌ای نداشتیم که مثلاً «شرکت باید در سه سال آینده این شکلی باشه». همین آشوب مدیریتی باعث شد در مواجهه با این مین‌های ناگهانی و جدی، چابک باقی بمونیم. وقتی نقش‌ها در یک سازمان مشخص و ثابت نیستند، گفتن جمله‌ی «می‌دونم چهار روزه روی این موضوع کار می‌کنی، ولی الان باید روی یه چیز دیگه تمرکز کنیم» راحت‌تره. این بی‌نظمی درونی، تغییرات شدید رو برای افراد به یک امر عادی تبدیل کرده بود — و این یعنی تیم ما بهتر می‌تونست با تغییرات شدیدی که از دنیای بیرون بهمون تحمیل می‌شد، کنار بیاد.

Rule #4: Launch a Product That Embarrasses You

It's not that you should strive to produce a bad product. Rather, if you need to choose between getting to market quickly with an imperfect product or getting to market slowly with a "perfect" product, choose the imperfect product nearly every time. Getting to market fast allows you to start getting the feedback you need to improve it. Any product that you've carefully refined based on your instincts rather than real user reactions and data is likely to miss the mark and will require significant iteration anyway. Speed really matters, and launching early lets you climb the learning curve to a great product faster.

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

I learned this lesson the hard way when I was running my first startup, SocialNet. I didn't want to be embarrassed by our first release, so the approach we took was to complete the entire product before we pulled back the curtain and let people sign up. This approach delayed SocialNet's launch by a year, and when we finally did launch, we quickly realized that half the features we'd painstakingly implemented weren't important, and half the important things that our service would be useless without were missing because we hadn't thought of them. While there were other reasons why SocialNet failed, not launching early and iterating based on market feedback was probably the main cause of death.

من این درس را با سختی یاد گرفتم، زمانی که اولین استارتاپم، SocialNet را اداره می‌کردم. نمی‌خواستم از نسخه‌ی اولیه‌مان خجالت‌زده شوم؛ برای همین تصمیم گرفتیم کل محصول را کامل کنیم و بعد آن را رونمایی کنیم و اجازه‌ی ثبت‌نام بدهیم. این تصمیم باعث شد راه‌اندازی SocialNet یک سال به تأخیر بیفتد — و وقتی بالاخره محصول را منتشر کردیم، خیلی زود فهمیدیم نیمی از قابلیت‌هایی که با وسواس زیاد پیاده‌سازی کرده بودیم، اصلاً مهم نبودند؛ و نیمی از چیزهایی که بدون آن‌ها سرویس عملاً بی‌فایده بود، غایب بودند چون اصلاً به فکرمان نرسیده بود. دلایل مختلفی برای شکست SocialNet وجود داشت، اما مهم‌ترین‌شان احتمالاً همین بود: اینکه زود عرضه نکردیم و براساس بازخورد بازار پیش نرفتیم.

After my experiences at PayPal and the success we found through rapid launches and product iteration, I was determined to launch LinkedIn as soon as possible. Our team defined a list of features that we thought were the minimum required to enter the market. Years later, Steve Blank and Eric Ries would dub this a "minimum viable product" (MVP). For LinkedIn, the MVP included a user's professional profile, the ability to connect to other users, a search function to find other users, and a mechanism for sending messages to friends.

بعد از تجربه‌ام در پی‌پال و موفقیتی که از طریق عرضه‌ی سریع و تکرارهای پی‌در‌پی محصول به‌دست آوردیم، مصمم بودم LinkedIn را هرچه زودتر راه‌اندازی کنم. تیم ما فهرستی از قابلیت‌هایی تهیه کرد که فکر می‌کردیم حداقل نیاز برای ورود به بازار هستند. سال‌ها بعد، استیو بلنک و اریک ریس این رویکرد را «محصول پذیرفتنی اولیه» یا MVP (Minimum Viable Product) نام‌گذاری کردند. برای لینکدین، این MVP شامل یک پروفایل حرفه‌ای برای کاربر، امکان ارتباط با دیگران، قابلیت جستجو برای یافتن افراد، و سیستمی برای ارسال پیام به دوستان بود.

Shortly before launch, we started worrying about whether LinkedIn would be useful without a critical mass of profiles. If a user logged in to LinkedIn, how could we make it useful even if none of that user's friends had signed up yet? We decided that what was missing was a Contact Finder, a version of search that would let a LinkedIn user find potential vendors. Our engineering team estimated that it would take us a month to build this feature. We were presented with a difficult choice — delay the launch by a month, or launch without a feature that we thought might be essential to our success. Operating on the embarrassment principle, we launched without Contact Finder. And quickly we discovered a far bigger problem: Unlike users of personal social networks like Friendster, which were growing explosively as new users invited their friends to join, LinkedIn users weren't sending any invites. Our user growth was stalled. Our baseline product was embarrassing because no one was using it! If we had delayed the launch a month to build Contact Finder, there still wouldn't have been enough people hanging around to use it, meaning we would have lost a month building a feature that didn't address the core problem. We estimated that we would need at least 1 million users before search (and Contact Finder) would be useful, and solving that problem was the top priority.

کمی قبل از راه‌اندازی، نگران شدیم که آیا لینکدین بدون داشتن تعداد قابل‌توجهی پروفایل اصلاً کاربردی خواهد بود یا نه. اگر یک کاربر وارد لینکدین شود، چطور می‌توانیم تجربه‌ای مفید به او بدهیم وقتی هیچ‌یک از دوستانش هنوز ثبت‌نام نکرده‌اند؟ تصمیم گرفتیم چیزی که کم داریم، یک Contact Finder است — نسخه‌ای از جستجو که به کاربران لینکدین اجازه می‌دهد تأمین‌کنندگان یا شرکای بالقوه را پیدا کنند. تیم مهندسی ما تخمین زد که ساخت این قابلیت حدود یک ماه زمان می‌برد. در این نقطه با یک انتخاب دشوار روبه‌رو بودیم: آیا عرضه‌ی محصول را یک ماه عقب بیندازیم یا محصول را بدون قابلیتی که فکر می‌کردیم شاید برای موفقیت حیاتی باشد، منتشر کنیم؟ بر اساس اصل «عرضه‌ی خجالت‌آور»، تصمیم گرفتیم بدون Contact Finder لانچ کنیم.و خیلی زود متوجه شدیم یک مشکل بسیار بزرگ‌تر وجود دارد: برخلاف کاربران شبکه‌های اجتماعی شخصی مانند Friendster، که با دعوت از دوستان‌شان به سرعت رشد می‌کردند، کاربران لینکدین اصلاً کسی را دعوت نمی‌کردند. رشد کاربری ما متوقف شده بود. محصول اولیه‌مان «خجالت‌آور» بود، چون هیچ‌کس از آن استفاده نمی‌کرد! اگر راه‌اندازی را یک ماه عقب انداخته بودیم تا Contact Finder را بسازیم، باز هم تعداد کاربران به‌حدی نبود که کسی از آن استفاده کند — یعنی یک ماه وقت تلف کرده بودیم برای ساختن قابلیتی که مشکل اصلی را حل نمی‌کرد. تخمین زدیم که حداقل به یک میلیون کاربر نیاز داریم تا جستجو (و Contact Finder) واقعاً کاربردی شود — و از آن لحظه، حل این مسئله اولویت اصلی‌مان شد.

Based on the launch data, we focused on trying to increase virality, which is how we became the first social network to allow you to upload your address book. This feature helped LinkedIn get to a critical mass of more than 1 million user profiles, and the rest is history.

بر اساس داده‌های لانچ، تمرکزمان را روی افزایش ویروسی شدن (Virality) گذاشتیم — و این شد که لینکدین اولین شبکه اجتماعی‌ای شد که به کاربران اجازه داد دفترچه آدرس ایمیل‌شان را آپلود کنند. این قابلیت کمک کرد لینکدین به توده‌ی بحرانی بیش از یک میلیون پروفایل کاربری برسد — و بقیه‌ی ماجرا، تاریخ است.

Keep in mind that you should be embarrassed by your initial release — not ashamed or indicted! The desire for speed is not an excuse to cut dangerous corners. If you trigger lawsuits or burn through your money without learning, it means you did launch too soon.

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

Rule #5: Let Fires Burn

At every stage of blitzscaling, there are always far more problems and issues clamoring for your attention than you have the resources to address. You might feel like a firefighter, except instead of trying to extinguish a blaze in one contained spot, you can see separate fires all around you — and you don't have time to put out all of them. One of the ways blitzscaling entrepreneurs can stay alive is by deciding to let certain fires burn so they can focus on the fires that, if allowed to rage unchecked, really will destroy the company. My Greylock colleague Joseph Ansanelli says, "What you say no to is more important than what you say yes to."

در هر مرحله از بلیتز‌اسکیلینگ، همیشه تعداد مشکلات و مسائلی که فریاد می‌زنند تا به آن‌ها رسیدگی شود، بسیار بیشتر از منابعی است که در اختیار دارید. ممکن است احساس کنید مثل یک آتش‌نشان هستید — با این تفاوت که به‌جای مهار یک آتش در یک نقطه‌ی مشخص، می‌توانید شعله‌های جداگانه‌ای را در اطراف‌تان ببینید و زمانی برای خاموش کردن همه‌ی آن‌ها ندارید. یکی از راه‌هایی که کارآفرینان در مسیر بلیتزاسکیلینگ می‌توانند زنده بمانند، این است که تصمیم بگیرند بعضی آتش‌ها را عمداً به حال خود رها کنند — تا بتوانند روی آن آتش‌هایی تمرکز کنند که اگر مهار نشوند، واقعاً شرکت را نابود خواهند کرد. همکارم در Greylock، جوزف آنسانلی، جمله‌ی خوبی دارد: «نه‌هایی که می‌گویید مهم‌تر از بله‌هایی است که می‌گویید.»

You can't ignore those fires forever — they are actually dangerous and will eventually require attention, but they aren't relevant at most points during blitzscaling, because extinguishing them doesn't move the needle on the expected outcome.

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

Rule #6: Do Things That Don't Scale (Throwaway Work)

Paul Graham, co-founder of Y Combinator, wrote a famous essay in which he advised entrepreneurs to do things that don't scale. This advice is spot-on for young startups, but it's even more important for blitzscaling startups.

A hack that takes a tenth of the time may be more useful than an elegantly engineered solution.

پل گراهام، یکی از بنیان‌گذاران Y Combinator، مقاله‌ای مشهور دارد که در آن به کارآفرینان توصیه می‌کند کارهایی را انجام دهند که مقیاس‌پذیر نیستند. این توصیه برای استارتاپ‌های نوپا کاملاً درست است — اما برای استارتاپ‌هایی که در حال بلیتزاسکیلینگ هستند، حتی مهم‌تر است.

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

Engineers hate doing throwaway work. Not only is it wasteful, but it also offends their sense of efficiency. They are firm believers in the conventional wisdom that says it's better to build your product right the first time so you only have to build it once. But when you're blitzscaling, inefficiency is the rule, not the exception. To prioritize speed, you might invest less in security, write code that isn't scalable, and wait for things to start breaking before you build QA tools and processes. It's true that all these decisions will lead to problems later on, but you might not have a later on if you take too long to build the product. A hack that takes a tenth of the time may be more useful than an elegantly engineered solution, even if it has to be thrown away later.

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

Much the same logic applies to nearly every aspect of your business. You'll often have to do things that don't scale when it comes to sales (for example, founder Marc Benioff brought in Salesforce.com's first customer, Blue Martini Software, by calling in a favor from its CEO, Monte Zweben), operations (Paul English listed his personal cellphone number as the original customer service line for Kayak), and so on.

همین منطق در تقریباً تمام جنبه‌های دیگر کسب‌وکار شما هم صدق می‌کند. در زمینه‌ی فروش، عملیات و سایر بخش‌ها، بارها مجبور خواهید شد کارهایی انجام دهید که مقیاس‌پذیر نیستند. مثلاً مارک بنیوف، بنیان‌گذار Salesforce.com، اولین مشتری شرکت یعنی Blue Martini Software را از طریق یک لطف شخصی از مونته زوبن (مدیرعامل آن شرکت) جذب کرد. یا پل انگلیش، شماره موبایل شخصی خودش را به‌عنوان خط خدمات مشتری اولیه‌ی Kayak منتشر کرده بود!

Nor is the world neatly divided into "things that don't scale" and "things that scale," with the former smoothly — and permanently — giving way to the latter. The code or process that scales during one stage of blitzscaling may break down at the very next stage, and whatever you replace it with might not scale at first, either. Consider how the founders of Airbnb solved the problem of hosts posting poor-quality photos of their rental properties on Airbnb.com: They became the photographers. As Brian Chesky told me, "We would borrow cameras from our RISD [Rhode Island School of Design] friends in Brooklyn, then literally knock on the doors of all our hosts."

البته دنیا به‌صورت منظم به دو بخش «کارهای غیرقابل مقیاس» و «کارهای قابل مقیاس» تقسیم نشده که یکی به‌سادگی و برای همیشه جای خودش را به دیگری بدهد. کدی یا فرآیندی که در یک مرحله از بلیتزاسکیلینگ به‌خوبی مقیاس‌پذیر است، ممکن است در مرحله‌ی بعدی کاملاً از کار بیفتد — و حتی راه‌حلی که جایگزینش می‌کنید، ممکن است در ابتدا اصلاً مقیاس‌پذیر نباشد. به‌عنوان مثال، زمانی که بنیان‌گذاران Airbnb با مشکل عکس‌های بی‌کیفیت از خانه‌های اجاره‌ای مواجه شدند، خودشان تبدیل به عکاس شدند! برایان چسکی به من گفت: «ما از دوستان‌مان در RISD [مدرسه طراحی رودآیلند] دوربین قرض می‌گرفتیم و بعد به‌معنای واقعی کلمه در خانه‌ی همه‌ی میزبان‌ها را می‌زدیم.»

Together, Brian and co-founder Joe Gebbia could photograph about 10 homes per day. (Co-founder Nathan Blecharczyk had to stay at the apartment that doubled as their office to make sure the site didn't crash.) Talk about doing things that don't scale!

برایان و هم‌بنیان‌گذارش، جو گبیا، با هم می‌توانستند روزانه حدود ۱۰ خانه را عکاسی کنند. (نیتن بلیچارچیک، هم‌بنیان‌گذار دیگر، مجبور بود در آپارتمانی که هم‌زمان دفتر کارشان هم بود بماند تا مطمئن شود سایت از کار نمی‌افتد.) اگه این مصداق «کارهای غیرقابل مقیاس» نیست، پس چیه؟!

As Airbnb took off, the photography function had to scale up considerably. So the founders hired photographers from Craigslist, hit up their RISD friends, and even recruited Airbnb hosts who listed photography as a hobby. By tapping these sources, the company was able to build a stable of five to 10 photographers who were paid $50 per home and tracked them using the sophisticated management tool of a spreadsheet listing photographers and their assignments.

وقتی Airbnb رشد کرد، بخش عکاسی هم مجبور شد به‌طور چشم‌گیری مقیاس پیدا کند. برای همین، بنیان‌گذاران از Craigslist عکاس استخدام کردند، دوباره سراغ دوستان RISD خود رفتند و حتی از میزبان‌هایی که عکاسی را به‌عنوان سرگرمی در پروفایل‌شان ذکر کرده بودند، کمک گرفتند. با استفاده از این منابع، شرکت توانست تیمی بین ۵ تا ۱۰ عکاس تشکیل دهد که بابت هر خانه ۵۰ دلار دریافت می‌کردند — و کل فرآیند از طریق یک فایل اکسل ساده که شامل نام عکاس‌ها و وظایف‌شان بود، مدیریت می‌شد!

Pretty soon, this system was overwhelmed. So they hired Ellie Thiele from Syracuse University as a summer intern and made managing photographers her full-time job. By focusing solely on managing the photography, Ellie was able to increase the number of active photographers to about 50. It was only at this point that Airbnb went to a truly scalable solution: software. Nathan wrote some code, adding two buttons to the site: one for hosts to request a photographer and the other for Ellie to trigger a payment when a photographer finished an assignment. Eventually, the founders hired Joe Zadeh as an entry-level engineer and asked him to work with Ellie to fully automate the photography process.

خیلی زود این سیستم به بن‌بست خورد. برای همین، آن‌ها الی تیله از دانشگاه سیراکیوز را به‌عنوان کارآموز تابستانی استخدام کردند و مدیریت کل برنامه‌ی عکاسان را تمام‌وقت به او سپردند. الی با تمرکز کامل روی این مسئولیت، توانست تعداد عکاسان فعال را به حدود ۵۰ نفر افزایش دهد. تنها در این مرحله بود که Airbnb به یک راه‌حل واقعاً مقیاس‌پذیر رسید: نرم‌افزار. نیتن کدی نوشت که دو دکمه به سایت اضافه کرد: یکی برای اینکه میزبان بتواند درخواست عکاس بدهد، و دیگری برای اینکه الی پس از انجام مأموریت، پرداخت دستمزد را تأیید کند. در نهایت، بنیان‌گذاران، جو زاده را به‌عنوان یک مهندس تازه‌کار استخدام کردند و از او خواستند با الی همکاری کند تا فرآیند عکاسی را به‌طور کامل اتوماتیک کنند.

Airbnb worked its way through three different ways of handling photography before building any code and has rewritten the photography system multiple times since then. It wouldn't have made sense for Airbnb to start by building a scalable automated photography system; at the point when the company began this journey, the site was receiving a mere 10 visitors per day, and the only engineering resource was Nathan Blecharczyk. Any work he did on this problem would have delayed all the other engineering work Airbnb needed to get done to grow its business. By doing things that didn't scale, the company was able to grow despite the resource constraints and the "wasted" work of building spreadsheets that would have to be thrown away later.

پس Airbnb پیش از آن‌که حتی یک خط کد برای سیستم عکاسی بنویسد، سه روش مختلف برای مدیریت آن را امتحان کرده بود — و از آن زمان تاکنون هم چندین بار این سیستم را بازنویسی کرده است. اگر Airbnb از همان ابتدا تصمیم می‌گرفت یک سیستم مقیاس‌پذیر و خودکار برای عکاسی بسازد، تصمیم درستی نبود؛ چون در آن زمان سایت فقط حدود ۱۰ بازدیدکننده در روز داشت و تنها منبع مهندسی تیم، نیتن بلیچارچیک بود. هر کاری که نیتن روی این سیستم انجام می‌داد، باعث می‌شد سایر وظایف حیاتی مهندسی که برای رشد شرکت ضروری بودند، به تعویق بیفتد. با انجام کارهایی که مقیاس‌پذیر نبودند، شرکت توانست علی‌رغم محدودیت منابع و زحمات «هدررفته» در ساخت اکسل‌هایی که بعداً باید کنار گذاشته می‌شدند، رشد کند.

Rule #7: Ignore Your Customers

The fundamental rule of customer service has long been "the customer is always right." But for many blitzscaling companies, the key rule is "provide whatever customer service you can as long as it doesn't slow you down—and that may mean no service!" Many blitzscaling startups will offer email support only, or no support at all, relying on users to find and help one another on discussion forums.

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

On an absolute scale, ignoring your customers is rarely going to be a positive. Customers like to feel heard, and ignoring them will eventually deplete your company's supply of goodwill. But for blitzscaling companies, letting customers feel ignored is often one of the fires that's easier for you to let burn until you have finished fighting the bigger, more deadly fires.

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