← Barcha maqolalar Zoboto · Blog · Discovery

Product Discovery va SMART: muammoni to'g'ri topish va yozish

Jamoa ikki hafta ishlab, chiroyli funksiyani chiqardi. Dizayn puxta, kod toza, sprint vaqtida yopildi. Bir muammo: hech kim undan foydalanmadi. Sabab — jamoa to'g'ridan-to'g'ri Delivery'ga (qurishga) o'tib ketgan, Discovery (nimani va nega qurish kerakligini aniqlash) bosqichini o'tkazib yuborgan. Quyida — muammoni qanday topish, kim uchun yechayotganingizni (persona) qanday aniqlash va uni SMART usulida qanday aniq yozish mumkinligi haqida amaliy yo'l xaritasi.

⏱ ~10 daqiqa · yangi menejerlar uchun referens 🎯 Product Manager, Product Owner va jamoa rahbarlari uchun 🧭 6 mavzu + SMART tekshiruv testi + 2 bosqichli workshop

Discovery nima

"To'g'ri narsani qurayapmizmi" — degan savolga javob beruvchi bosqich: foydalanuvchini kuzatish, muammoni aniqlash, persona qurish va yechimni shakllantirish. Delivery esa "buni to'g'ri qurayapmizmi" — ijro bosqichi.

Nega bu muhim

Discovery'siz Delivery — noaniq muammoga aniq yechim qurish degani. Natija ko'pincha bir xil: sifatli, lekin hech kimga kerak bo'lmagan funksiya.

Bu maqoladan keyin nima qila olasiz

Muammoni faol qidira olasiz, persona quriladigan asosni bilasiz va har qanday muammoni SMART formatida — aniq, o'lchanadigan va muddatli — yoza olasiz.

Kimlar uchun va nimaga erishasiz

Bu maqola yangi ishga kirgan mahsulot menejerlari uchun onboarding materiali sifatida va jamoaviy workshop uchun qayta ishlatsa bo'ladigan referens sifatida yozilgan.

Kimlar uchun foydali
Product Manager Product Owner Business Analyst Jamoa rahbari
O'qib bo'lgach, siz
  • Discovery va Delivery farqini va ularning manba-hujjatlarini bilasiz (SVPG, Product Talk)
  • Muammoni faol qidirish manbalarini (intervyu, support, shikoyatlar) qo'llay olasiz
  • Persona nima uchun kerakligini va uni qanday qurishni tushunasiz
  • Har qanday muammoni SMART formatida yoza olasiz

Discovery va Delivery — bir nazarda

Marty Cagan (Silicon Valley Product Group) 2005 yildan boshlab "discovery" atamasini "nimani qurish kerakligini aniqlash" ma'nosida, 2007 yildan esa uni "delivery"ga qarshi qo'yib ishlata boshlagan. Quyida ikki faoliyat besh o'lchov bo'yicha solishtirilgan.

O'lchov Discovery Delivery
Asosiy savolTo'g'ri narsani qurayapmizmi?Buni to'g'ri qurayapmizmi?
MaqsadMuammoni va yechimni isbotlash — sifatli, foydali, amalga oshiriladiganIsbotlangan yechimni sifatli qurish, sinash va yetkazish
Chiquvchi natijaValidatsiya qilingan backlog band(lar)iIshlab chiqarishga tayyor kod
Asosiy faoliyatIntervyu, kuzatuv, prototip, A/B testDizayn, kodlash, test, deploy
Xato narxiArzon — bir necha kunlik suhbat yoki eskizQimmat — haftalar/oylik ishlab chiqarish resursi
01

Nega Discovery bosqichi kerak

Ko'p jamoalar to'g'ridan-to'g'ri Delivery'ga o'tib ketadi — ya'ni "narsalarni to'g'ri qilish". Lekin bundan oldin Discovery turadi — "to'g'ri narsani qilish".

Marty Cagan SVPG 2005–2007
Discovery maqsadi

Silicon Valley Product Group'ning ta'kidlashicha, discovery'ning maqsadi — ishlab chiquvchilarga "buni qur" deb aytishdan oldin, bu harakat behuda ketmasligiga dalil to'plash. Discovery texnikalari foydalanuvchini chuqurroq tushunish va g'oyani sifat va son jihatidan tekshirish uchun ishlatiladi: svpg.com/discovery-vs-delivery

Natija

Discovery'siz Delivery — noaniq muammoga aniq yechim qurish degani. Natija ko'pincha bir xil: chiroyli, sifatli, lekin hech kimga kerak bo'lmagan funksiya — jamoaning haftalar davomidagi mehnati behuda ketadi.

02

Discovery'ning to'rtta bosqichi

Discovery tartibsiz "brainstorming" emas — u ketma-ket to'rtta bosqichdan iborat.

Empatiya Muammo Persona Yechim
To'rtta bosqich
  1. Empatiya va observatsiya — foydalanuvchini kuzatish, uning muhitiga kirish
  2. Muammoni aniqlash — nima og'riyapti, qayerda
  3. Persona qurish — kim uchun yechayapmiz
  4. Yechimni shakllantirish — g'oya generatsiyasi va ustuvorlashtirish (prioritization)
Doimiy jarayon sifatida

Teresa Torres "Continuous Discovery Habits" (2021) kitobida bu to'rt bosqichni bir martalik loyiha emas, balki jamoaning haftalik odatiga aylantirishni tavsiya qiladi — kross-funksional jamoa har hafta kamida bitta mijoz bilan gaplashadi: producttalk.org

03

Persona: kim uchun yechayapmiz

Persona bo'lmasa, jamoa "o'zi uchun" mahsulot quradi — bu eng ko'p uchraydigan xatolardan biri.

Alan Cooper 1999 Nielsen Norman Group
Ta'rif

Persona tushunchasini 1999 yilda Alan Cooper "The Inmates Are Running the Asylum" kitobida taqdim etgan: bu — maqsadli foydalanuvchi segmentini ifodalovchi, tadqiqotga asoslangan arxetip — uning maqsadlari, muammolari, xatti-harakati va konteksti bilan. Cooper ta'kidlashicha, persona o'ylab topilmaydi — u tadqiqot natijasida "topiladi".

Amalda qanday qurish

Nielsen Norman Group'ning "Personas: Study Guide" qo'llanmasiga ko'ra, persona — mahsulotning odatiy yoki maqsadli foydalanuvchisini tavsiflovchi, xayoliy, ammo realistik tavsif; u empatiyani oshirish, maqsadli foydalanuvchilarni yodda saqlash, funksiyalarni ustuvorlashtirish va dizayn qarorlarini asoslash uchun ishlatiladi: nngroup.com

Muhokama uchun savol: sizning joriy loyihangizda persona qanday shakllantirilgan — yozma hujjat sifatida bormi, yoki hamma "boshida" bilamiz deb o'ylaydimi?

04

Muammoni qayerdan topish kerak

Muammo havoda paydo bo'lmaydi — uni faol qidirish kerak. "Yaxshi mahsulot menejerlar shunchaki yechim yetkazib bermaydi — ular muammoni topadi."

User interview Support chatlar Shikoyatlar
Uchta asosiy manba
  • User interview'lar — foydalanuvchi bilan to'g'ridan-to'g'ri suhbat
  • Support chatlar — foydalanuvchi shikoyatlari va savollari
  • Shikoyatlar — ijtimoiy tarmoq, review'lar, churn (mijoz yo'qotish) sabablari
Muntazamlik muhim

Teresa Torres'ning "continuous discovery" yondashuvida bu manbalar bir martalik tadqiqot emas, balki haftalik odat sifatida ishlatiladi — shunda muammolar to'plami "opportunity solution tree" (imkoniyat-yechim daraxti) orqali biznes natijasi bilan bog'lanadi.

05

Yechimni shakllantirish

Muammo aniq bo'lgach, ikki bosqich boshlanadi: g'oya generatsiyasi va ustuvorlashtirish.

Idea generation Prioritization
Ikki bosqich
  • G'oya generatsiyasi (idea generation) — imkon qadar ko'p variant yig'ish, hali baholamasdan
  • Ustuvorlashtirish (prioritization) — hamma yechimga vaqt yetmaydi, shuning uchun eng ta'sirli va oson amalga oshiriladiganlari tanlanadi
Vositasi: Opportunity Solution Tree

Teresa Torres taklif qilgan bu vosita — biznes natijasidan mijoz imkoniyatlariga, undan esa yechim va tajriba (test)larga qadar vizual bog'lanish yaratadi, shunda jamoa nafaqat "nimani qurayapmiz", balki "nega qurayapmiz"ni ham ko'rib turadi: producttalk.org/opportunity-solution-trees

06

SMART: muammoni aniq yozish vositasi

Ko'pchilik SMART'ni faqat maqsad (goal) uchun ishlatadi, lekin uni muammoni yozishda ham qo'llash mumkin.

George Doran 1981
Besh harf
HarfMa'noSavol
SpecificAniqlikMuammo aniq nimada?
MeasurableO'lchashQanday raqam bilan tasdiqlanadi?
AchievableErishish mumkinligiBu jamoa doirasida hal qilinadimi?
RelevantDolzarblikBiznes maqsadga bog'liqmi?
Time-boundMuddatQachongacha hal qilinishi kerak?
Original va zamonaviy versiya

George T. Doran SMART akronimini 1981 yilda Management Review jurnalida chop etilgan "There's a S.M.A.R.T. way to write management's goals and objectives" maqolasida taklif qilgan. Qiziqarli jihati: original versiyada "A" — Assignable (aniq javobgar belgilangan), "R" — Realistic (mavjud resurslar bilan erishish mumkin) degan ma'noni bildirgan. Bugungi kunda ko'proq tarqalgan "Achievable" va "Relevant" versiyasi — vaqt o'tishi bilan amaliyotchilar tomonidan moslashtirilgan variant.

Misol

❌ "Oson kredit beramiz" — bu maqsad (goal), muammo emas.
✅ "Yangi mijozlarning 40%'i kredit arizasini to'ldirish jarayonining 3-bosqichida tashlab ketmoqda (oxirgi 30 kunda), sababi — hujjat yuklash murakkab" — bu SMART tarzda yozilgan muammo.

Tekshiruv testi: bu muammo SMART yozilganmi?

Har bir bayonot uchun u SMART formatida yozilganmi yoki yo'qligini tanlang, so'ng izohni ko'ring.

1

"Foydalanuvchi tajribasini yaxshilashimiz kerak."

SMART emas — bu maqsad, muammo emas: aniq son, muddat va "qayerda" degan ma'lumot yo'q.
2

"So'nggi 30 kunda yangi mijozlarning 40%'i kredit arizasining 3-bosqichida (hujjat yuklash) to'xtab qolmoqda."

SMART — aniq (3-bosqich), o'lchanadigan (40%), muddati bor (so'nggi 30 kun) va biznes bilan bog'liq.
3

"Mijozlar ilovadan norozi, biror narsa qilishimiz kerak."

SMART emas — na aniq (qaysi funksiya, qaysi bosqich), na o'lchanadigan (necha foiz, qanday manba), na muddatli.
4

"Support'ga oxirgi chorakda tushgan shikoyatlarning 25%'i parolni tiklash havolasi ishlamasligi haqida — bu Android v12'da uchraydi."

SMART — aniq platforma va funksiya, o'lchanadigan (25%), vaqt oralig'i (oxirgi chorak) berilgan.
5

"Raqobatchilarimizda bor funksiyalarni bizda ham qilish kerak."

SMART emas — bu muammo emas, taxmin: qaysi mijoz, qaysi vaziyatda, qancha ta'sir qilishi noaniq.

Discovery'ni boshlash uchun checklist

O'z loyihangizda Discovery'ni tizimli boshlash uchun quyidagi tartibda harakat qiling.

  1. Joriy backlog'dagi 3 ta bandni tekshiring: ular haqiqiy muammoga asoslanganmi, yoki taxminga?
  2. Kamida bitta yozma persona bor-yo'qligini tekshiring — bo'lmasa, uni tuzishni rejalashtiring
  3. Support/shikoyat kanallarini ko'rib chiqib, takrorlanuvchi 3 ta muammoni ajrating
  4. Haftada kamida bitta foydalanuvchi bilan suhbat rejalashtiring (continuous discovery odati)
  5. Topilgan muammolarni SMART formatida yozib chiqing
  6. Har bir muammo uchun kamida ikkita yechim g'oyasini yig'ing, hali baholamasdan
  7. G'oyalarni ta'sir va amalga oshirish qulayligiga qarab ustuvorlashtiring
  8. Ushbu maqoladagi SMART tekshiruv testi va workshopni jamoa bilan o'tkazing

Workshop mashqi: 10 muammo, SMART formatida (15–20 daqiqa)

Ikki bosqichli mashq — jamoa yoki individual tarzda bajarish mumkin.

1-topshiriq
  • O'z loyihangizdagi 10 ta muammoni yozing
  • Har birini SMART formatida — aniq, o'lchanadigan, erishish mumkin, dolzarb, muddatli — yozing
  • Yuqoridagi tekshiruv testidagi mezonlar bilan o'z-o'zingizni tekshiring
2-topshiriq
  • Har bir muammo uchun kamida bitta yechim taklif qiling
  • Har bir yechimni ta'sir (qancha muammoni hal qiladi) va amalga oshirish qulayligiga qarab baholang
  • Eng yuqori ta'sir + eng oson amalga oshiriladigan 3 tasini tanlang
  • Natijani jamoa kanaliga joylang

Jamoa formatida: 4–6 kishini juftlikka bo'ling, har juftlik 10 tadan muammo yozadi (jami ancha katta ro'yxat hosil bo'ladi), so'ng butun jamoa birga eng yaxshi 5 tasini tanlaydi. Agar jamoada haqiqiy support/shikoyat ma'lumotlariga kirish bo'lsa, mashqni "taxmin" emas, real ma'lumot asosida bajarish tavsiya etiladi.

Xulosa

Yaxshi mahsulot menejerlar shunchaki yechim yetkazib bermaydi — ular avval muammoni topadi, kimga tegishli ekanini (persona) aniqlaydi, so'ng uni aniq yoza oladi.

Asosiy xulosalar
  • Discovery — "to'g'ri narsani qurish", Delivery — "buni to'g'ri qurish"; ikkalasi ham zarur, lekin Discovery avval keladi
  • Muammo havoda paydo bo'lmaydi — intervyu, support va shikoyatlardan faol qidiriladi
  • Persona bo'lmasa, jamoa "o'zi uchun" mahsulot quradi
  • SMART — nafaqat maqsad, balki muammoni ham aniq yozish vositasi (Doran, 1981)
  • Discovery bir martalik loyiha emas — u haftalik odatga aylanishi kerak (Torres)
  • Xatoning narxi Discovery'da arzon, Delivery'da qimmat — shuning uchun tartib muhim
Keyingi qadam
  • Yuqoridagi workshop mashqini bajaring — 10 ta muammo, SMART formatida
  • Backlog'dagi bitta bandni tanlab, uning ortida qanday muammo turganini tekshiring
  • Bu maqolani yangi jamoa a'zolari bilan onboarding paytida qayta ishlating
Fikrlash uchun savol (individual)

Oxirgi marta qachon "muammo"ni emas, balki to'g'ridan-to'g'ri "yechim"ni yozgan holda ish boshlagansiz?

Muhokama savoli (jamoa uchun)

Bizning joriy backlog'imizdagi bandlar qancha foizi haqiqiy tadqiqotga, qancha foizi taxminga asoslangan?

Mini-topshiriq

Joriy loyihangizdagi bitta muammoni SMART formatida qayta yozing va uni jamoa kanaliga ulashing.

Cheklov: har bir kichik tuzatish yoki tezkor bug-fix uchun to'liq Discovery jarayoni shart emas — bu freymvork yangi funksiya yoki katta o'zgarish uchun eng qimmatli, kichik texnik tuzatishlarda ortiqcha vaqt sarflashi mumkin.

AUTHOR INPUT NEEDED: bu maqola Bobur o'tkazgan "Discovery in Product Management" Mentimeter treningi tuzilishi asosida tayyorlangan; nashrdan oldin haqiqiy so'rovnoma natijalari (ishtirokchilar javoblari) bilan boyitilsa, maqola yanada ishonchli bo'ladi.

Manbalar va qo'shimcha o'qish

Discovery vs. Delivery
Marty Cagan, Silicon Valley Product Group (SVPG)

Discovery va Delivery farqining zamonaviy, sanoatda keng tanilgan ta'rifi.

The Origin of Product Discovery
Marty Cagan, Silicon Valley Product Group (SVPG)

"Discovery" atamasining qachon va nega paydo bo'lganini tushuntiradi.

Continuous Discovery Habits
Teresa Torres, Product Talk · 2021

Discovery'ni bir martalik loyiha emas, haftalik jamoa odatiga aylantirish metodikasi.

Personas: Study Guide
Nielsen Norman Group

Persona qurish va undan foydalanish bo'yicha amaliy, tadqiqotga asoslangan qo'llanma.

Alan Cooper — "The Inmates Are Running the Asylum" (1999)
Alan Cooper, Sams Publishing · 1999

Persona tushunchasining birinchi marta taqdim etilgan asosiy manbasi.

SMART criteria (Doran, G.T., 1981, Management Review, 70, 35–36)
George T. Doran · 1981

SMART akronimining original manbasi va uning zamonaviy versiyadan farqi.

Keyingi maqolalar

Project Manager vs Product Manager

Ikki rol qanday farqlanadi va qaror huquqlari qanday taqsimlanadi.
Scrum Master roadmap: o'rganish materiallari va ClickUp

Yangi Scrum Master uchun bosqichma-bosqich interaktiv roadmap.
AI yordamida hodimlarni boshqarish

Sun'iy intellekt jamoa boshqaruvida qayerda haqiqiy foyda beradi.
← Barcha maqolalar Savolingiz bormi? Yozing →