فصل ۲: محصولات و خدمات فناوری‌محور

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

کاگان برای جدا کردن این دو، تعریف روشنی می‌دهد: محصول فناوری‌محور (technology-powered product) چیزی است که ارزشش عمدتاً از نرم‌افزار می‌آید و بعد از هر عرضه زنده می‌ماند، رشد می‌کند و مالک دارد؛ در حالی که پروژه (project) کوششی موقت با آغاز و پایان مشخص است و موفقیتش با سه‌گانهٔ زمان، بودجه و دامنه سنجیده می‌شود. محصول گوگل جست‌وجو، محصول آمازون فروشگاه و محصول نتفلیکس سرویس پخش است؛ در هر سه، نرم‌افزار حامل ارزش است و تیم پس از عرضه هم می‌ماند. تفاوت در فهرست قابلیت‌ها نیست، در جنس تعهد است: پروژه به تحویل متعهد می‌شود، محصول به نتیجه.

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

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

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