02برنامهریز محصول
اول محصول مفید را بسازید، بعد محصول پرزرقوبرق را.
درخواست مبهم را به یک مسیر روشن برای کاربر، نسخه اول حسابشده و نرمافزاری تبدیل میکنیم که در استفاده واقعی دوام بیاورد.
- ۰۱ / شروع
- یک مشکل واقعی کاربر
- ۰۲ / تمرکز
- کوچکترین نسخه مفید
- ۰۳ / ادامه
- انتشار و بهبود
۰۱مسئله
فهرست قابلیتها معمولاً از شواهد سریعتر رشد میکند.
خیلی از تیمها با راهحلی میآیند که از قبل به چند صفحه و قابلیت تبدیل شده است. ما یک قدم عقب میرویم: چه چیزی باید برای کاربر تغییر کند؟ کدام رفتار ایده را ثابت میکند؟ چه چیزی میتواند صبر کند؟
هدف فقط کوچککردن محصول نیست. محصول باید آنقدر روشن باشد که نتوان کاربرد اصلیاش را اشتباه فهمید.
- بررسی مسئله و تحقیق محصول
- مسیر کاربر و نقطههای تصمیم
- نسخه اول و نقشه راه
- تجربه کاربر، رابط، نمونه اولیه و جهت فنی
۰۲ساخت
یک تیم محصول از فکر تا انتشار.
استراتژی با ارائه یک فایل تمام نمیشود و طراحی هم با تحویل صفحهها. همان تصمیمها باید وارد معماری، توسعه، کنترل کیفیت، انتشار و دور اول یادگیری شوند.
این پیوستگی وقتی مهمتر میشود که محدودیت واقعی به پروژه فشار میآورد. میتوانیم اندازه کار، زمان و پیچیدگی را تغییر دهیم بدون اینکه دلیل ساخت محصول گم شود.
- محصول وب و موبایل
- دیزاین سیستم و پایه کامپوننتها
- فرانتاند، بکاند، API و اتصال ابزارها
- تحلیل رفتار، آمادهسازی انتشار و بهبود
۰۳محصولات خودمان
محصولات ما اجازه نمیدهند توصیهها فقط حرف بمانند.
Morthi فایلهای پراکنده مطالعه را به یادداشت، ترجمه، هایلایت و منبع ذخیرهشده تبدیل میکند. Drip حافظه کمد را وارد تصمیم لباس و خرید میکند. هیچکدام با نام یک فناوری شروع نشدند؛ هر دو با یک مشکل تکراری شروع شدند.
وقتی محصول خودمان را میسازیم و نگه میداریم، مجبوریم بعد از انتشار هم با تصمیمها زندگی کنیم؛ همان بخشی که در اسکرینشات پورتفولیو دیده نمیشود.
مشاهده Morthi۰۴نسخه اول خوب
آنقدر کوچک که بتوان یاد گرفت؛ آنقدر کامل که بتوان اعتماد کرد.
میتوانیم بعضی قابلیتها را برای بعد نگه داریم. اما محصولی را منتشر نمیکنیم که کاربر را گمراه کند، ابهام را پنهان کند یا در همان وعده اصلی شکست بخورد. مرز انتشار، اعتماد است نه کمال.
FAQ
پاسخ روشن به پرسشهای معمول.
فقط طراحی محصول انجام میدهید؟
نه. میتوانیم از تشخیص مسئله و تجربه کاربر تا نرمافزار نهایی، انتشار و بهبود محصول همراه باشیم.
با تیم محصول فعلی هم کار میکنید؟
بله. میتوانیم مسئول یک بخش مشخص شویم، مسیر گیجکنندهای را اصلاح کنیم، پایه طراحی و فنی را بسازیم یا کنار تیم محصول و فنی شما کار کنیم.
نسخه MVP را چطور تعریف میکنید؟
MVP کوچکترین نسخهای است که نتیجه اصلی را میدهد و شایسته اعتماد کاربر واقعی است؛ نه نمونهای که اسم محصول نهایی روی آن گذاشته شده باشد.