بریده‌هایی از کتاب الهام بخش

پس محصول را منتشر کردیم و انتشار آن را جشن گرفتیم. فقط یک مشکل وجود داشت: هیچ‌کس آن را نخرید.

موفقیت در امر محصول به این معناست که تمام ذی‌نفعان کلیدی را قانع کنید که محدودیت‌هایشان را درک کرده‌اید و متعهد به ارائۀ راه‌حل‌هایی هستید که منطبق با این محدودیت‌ها هستند.

اعتقاد دارم که امروزه بیشتر محصولات در حال تبدیل‌شدن به محصولات فناور‌انه‌اند و شرکت‌هایی که این موضوع را درک نکنند به‌سرعت از هم می‌پاشند.

«در چشم‌انداز خود مصمم، اما در جزئیات آن انعطاف‌پذیر باشید»

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

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

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

ی ایده‌هایی که پتانسیلشان ثابت شده، معمولاً به چند تکرار نیاز دارند تا پیاده‌سازی آن‌ها به نقطه‌ای برسد که ارزش تجاری لازم را نشان دهد. ما آن را «زمان برای پول» می‌نامیم.

تناسب محصول با بازار در مشتریان راضی‌تر، نرخ پایین ریزش، کوتاه‌شدن چرخۀ فروش و رشد سریع، خود را نشان می‌دهد.

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

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

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

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

چشم‌انداز محصول باید «الهام‌بخش» باشد و استراتژی محصول باید «متمرکز» باشد.

برای اینکه تیم محصول توانمند باشد و با درجۀ معینی از خودمختاری عمل کند، باید درک عمیقی از بستری گسترده‌تر داشته باشد. این شناخت با یک چشم‌انداز واضح و برانگیزاننده از محصول شروع می‌شود و مسیر دستیابی به این چشم‌انداز، «استراتژی محصول» است.

مسئله این است که هر زمان فهرستی از ایده‌ها را در یک سند تحت عنوان «نقشۀ راه» قرار دهید، هرچقدر هم گزینه‌های سلب مسئولیت در آن قرار داده باشید، باز هم افراد در سراسر شرکت مفاد آن را همچون یک تعهد تفسیر می‌کنند.

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

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

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

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