quick wins что это
Благодаря чему обеспечивается скорость внедрения?
Я проповедую IT решения и инструменты, которые приносят быстрые победы, имеют относительно непродолжительный цикл внедрения.
Благодаря чему обеспечивается скорость внедрения? – скорость внедрения обеспечивается благодаря снижению уровня бюрократии, а также благодаря тому, что нет необходимости в передаче эстафетной палочки между бизнес аналитиком, системным аналитиком, программистом, тестировщиком, нет эффекта испорченного телефона.
Когда выгодно разделение труда? – когда задачи по автоматизации однотипные, идут потоком, и каждый ИТ специалист работает быстро, четко и эффективно, как на конвейере.
Вот только так уж обычно получается, что ИТ проекты очень не похожи друг на друга. Конвейер сделать не удается. Как только удается сделать конвейер, кому-то, шибко умному, приходит в голову этот конвейер автоматизировать.
А у меня получается, подход не конвейерный, а бутиковый.
Из этого следует, что обращаться ко мне имеет смысл только тогда, когда задача у вас нетипичная. Типичную задачу дешевле, чем ее делают на конвейере, я не сделаю.
Да, но у меня есть готовые сервисы, это как раз то, что можно назвать автоматизированным конвейером. И готовые сервисы я могу предоставлять дешевле, чем крупные компании, потому что мои издержки меньше. У меня нет начальников, которые забирают львиную часть прибыли, и отнимают время у программистов.
Для успешного своевременного внедрения недостаточно только лишь моего профессионализма. Необходима также быстрая реакция и хорошая мотивация со стороны заказчика.
Мои решения могут быть успешно привиты к стратегическим IT проектам, что позволит долгосрочным проектам сохранить доверие спонсора, заказчиков и других стейкхоулдеров.
quick wins
Смотреть что такое «quick wins» в других словарях:
quick win — n. Everyone in business is always looking for quick wins, small steps or initiatives that will produce immediate, positive results … Business English jargon and slang
Quick Recall — is an academic competition comparable to Quiz Bowl. Quick Recall, featuring 2 halves of tossup and bonus questions, is used primarily for traditional academic competition in Kentucky. In Ohio, Quick Recall is different as it offers a round of… … Wikipedia
Quick Step — Infobox Cycling team teamname=Quick Step Innergetic code=QST base= BEL founded=2003 disbanded= manager=Patrick Lefevere teammanager= discipline=Road status=ProTour season=2003 2004 2005 2006 2007 2008 oldname=Quick Step Davitamon (QSD) Quick Step … Wikipedia
WINS (AM) — Infobox Radio station name = WINS city = New York City area = New York City area branding = 1010 WINS slogan = All news, all the time airdate = 1924 (as WGBS) frequency = 1010 kHz HD Radio 102.7 3 FM (HD Radio) format = Commercial, News power =… … Wikipedia
Smiley Quick — Lyman Loren Smiley Quick (March 19, 1909 ndash; December 23, 1979) was an American professional golfer who played on the PGA Tour in the 1940s and 1950s.Quick was born in Centralia, Illinoiscite web | title=Today in Golf History: March 19 |… … Wikipedia
Get-rich-quick scheme — Easy money redirects here. For other uses, see Easy Money (disambiguation). A get rich quick scheme is a plan to acquire high rates of return for a small investment. The term get rich quick has been used to describe shady investments since at… … Wikipedia
The Quick and the Dead (1995 film) — Infobox Film name = The Quick and the Dead caption = The Quick and the Dead Theatrical poster director = Sam Raimi producer = Joshua Donen Patrick Markey Allen Shapiro writer = Simon Moore starring = Sharon Stone Gene Hackman Russell Crowe… … Wikipedia
ITIL Planning to implement service management — The planning to implement service management is a set in the Information Technology Infrastructure Library (ITIL) framework. This set is about the alignment of business needs and IT provision requirements. Besides, this set describes how to… … Wikipedia
Due Diligence Process Management — (DDPM) ist ein Prozessmanagement Verfahren zur Prozessoptimierung und dient als Basis für umfassende Veränderungen in Unternehmen. Außerdem ermöglicht das Verfahren eine Unternehmensbewertung nach Aspekten des Prozessmanagements. Folgende… … Deutsch Wikipedia
Crime Syndicate of America — For the concept of crime syndicates in general, see Organized crime. Crime Syndicate of America The anti matter Crime Syndicate of Amerika (and counterparts) feature on the cover of the JLA: Earth 2 graphic novel. Art by Frank Quitely. Upside… … Wikipedia
Crime Syndicate — Infobox comics organization name=Crime Syndicate of America imagesize= caption= The antimatter Crime Syndicate of AmeriKa (and counterparts) feature on the JLA: Earth 2 cover. Art by Frank Quitely. publisher=DC Comics debut=Historical Syndicate:… … Wikipedia
quick win
быстрая победа
(ITIL Continual Service Improvemen
Деятельность по совершенствованию, возврат инвестиций от которой ожидается в кратчайшее время при относительно небольших затратах и усилиях.
См. тж. принцип Парето.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
quick win
(ITIL Continual Service Improvement)
An improvement activity that is expected to provide a return on investment in a short period of time with relatively small cost and effort.
See also Pareto principle.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
Смотреть что такое «quick win» в других словарях:
Quick-Win — Unter dem Begriff schneller Erfolg (englisch quick win) versteht man, aus betriebswirtschaftlicher Sicht, eine Strategie mit dem Ziel zunächst jene Vorhaben zu realisieren, die schnell zu sichtbaren, verbesserten Ergebnissen führen. Die erzielten … Deutsch Wikipedia
Quick-win — Unter dem Begriff schneller Erfolg (englisch quick win) versteht man, aus betriebswirtschaftlicher Sicht, eine Strategie mit dem Ziel zunächst jene Vorhaben zu realisieren, die schnell zu sichtbaren, verbesserten Ergebnissen führen. Die erzielten … Deutsch Wikipedia
quick win — n. Everyone in business is always looking for quick wins, small steps or initiatives that will produce immediate, positive results … Business English jargon and slang
Win Elliot — Win Elliott (born Irwin Elliot Shalek; May 7, 1915 in Chelsea, Massachusetts September 17, 1998 [ [http://www.highbeam.com/doc/1P1 19525453.html Longtime Sportcaster Win Elliot Dies AP Online] ] in Norwalk, Connecticut) was a fight announcer… … Wikipedia
Quick-change — is a performance style in which a performer or magician changes quickly within seconds from one costume into another costume in front of the audience.Modern Quick Change ArtistsThere are few internationally acclaimed quick change artists, all of… … Wikipedia
quick on the trigger — or[trigger happy]
quick on the trigger — or[trigger happy]
quick on the draw — See: QUICK ON THE TRIGGER … Dictionary of American idioms
quick on the draw — See: QUICK ON THE TRIGGER … Dictionary of American idioms
Quick As a Flash — was a 30 minute radio quiz program which featured drama segments with guest actors from radio detective shows.Created by director Richard Lewis and emcee Ken Roberts, the program debuted over the Mutual network Sunday, July 16, 1944. Sponsored by … Wikipedia
quick trick — noun : honor trick * * * Bridge. a card, or group of cards, that will probably win the first or second trick in a suit, regardless of who plays it or at what declaration. [1925 30] * * * quick trick noun (bridge) A card that should win a trick in … Useful english dictionary
Quick win, приведший к epic fail, или Как в гонке за ИТ-продажами не потерять всё
Пролог
Каждый, кто работал в аутсорсинге сервисов и бизнес-процессов, не понаслышке знает о важности продаж тех самых сервисов.
Мало просто делать хороший сервис. Нужно обеспечивать бесперебойную воронку продаж, чтобы бизнес оставался рентабельным и приносил прибыль. Казалось бы, что проще, продавай: рынок перенасыщен компаниями, которые не хотят или не умеют делать качественные сервисы, просто потому что улучшение качества обслуживания клиентов влечет за собой увеличение расходов на их удержание. Не каждый готов тратить время и деньги на это, предпочитая быстро масштабироваться, захватывать новые рынки, отдав самое сложное на аутсорсинг. Тем более, если аутсорсинговая компания имеет международные масштабы и давно зарекомендовала себя на рынке.
В этой статье я хочу поделиться соответствующим опытом с прошлого места работы, который позволил всей нашей команде на собственных шишках понять, как не надо управлять процессом продажи аутсорса и что стоит делать, чтобы эти шишки не были набиты еще раз.
Итак, некогда мне посчастливилось работать в одной из таких компаний – с мировым именем, с большим числом направлений продаж. Наше подразделение было сосредоточено на оказании услуг контакт-центра для различных сегментов рынка. Наш контакт-центр был сформирован в 2008 году и к 2018 году, в котором начали развиваться эти события, портфель наших клиентов был нельзя сказать, что большой, но и не маленький – 8 якорных заказчиков, на которых работали достаточно крупные команды выделенных операторов и несколько групп шаренных специалистов.
Но помимо этих 8 сервисных проектов было и непреодолимое желание продавать. А вот продавать не получалось. Вдруг в какой-то момент мы ощутили острый кризис – потенциальных клиентов больше не интересовал качественный сервис, их интересовала низкая стоимость услуги. Сделки были, но главным шоу-стоппером всегда выступала цена – как только дело доходило до ценового предложения, клиенты бежали от нас со словами: «Слишком дорого по рынку, продавайте за такой ценник в Европе».
Отсутствие продаж влекло за собой внутренние проблемы: мы не могли развивать инфраструктуру нашего контактного центра из-за отсутствия финансирования от топ-менеджмента компании. Каждый раз наши ТОПы говорили одно и то же: «Вы не умеете продавать. Вот когда научитесь, поговорим о финансировании».
Завязка
Меж тем шёл 3 отчетный квартал, а планы по продажам были недостижимыми и успех стремился к нулю. Абсолютно все перепрофилировались в сотрудников продаж и суетливо искали разные варианты. И как это обычно бывает, суета не доводит до добра.
В какой-то день к нам прилетел вдохновленный сейл со словами: «Вы не поверите, кого я вам нашел». «Это супер-сделка. Это наш шанс выйти на новый уровень и впечатлить глобалов». «Вот оно!» – подумали мы, и пустились во все тяжкие.
К слову, о клиенте: он действительно был найден — молодая питерская компания, организованная талантливыми стартаперами. Парни поставили на поток вызов эвакуаторов для бедолаг, попавших в неприятные ситуации в пределах московской и ленинградской областей.
И, как любая молодая быстроразвивающаяся компания, они не были готовы тратить время на проработку сделки, которая в подобных нашей компаниях занимает всегда не мало времени из-за наличия многочисленных этапов, состоящих их бесконечных обсуждений, расчётов и повторных обсуждений и согласований итоговой стоимости услуги.
Условие нашего успешного участия в этой сделке было очень простым – быстрая оценка стоимости сервиса и коммерческое предложение в самые сжатые сроки. Что уже противоречило всем регламентам нашей компании.
Помимо того, что это была чуть ли не первая хот-сделка в году, главной вишенкой на этом торте было и то, что это был не типичный для нас сервис, а BPO (business process outsourcing). Об этих трёх буквах писали все, кто был хоть как-то причастен к аутсорсингу сервисов и пытался быть в тренде в то время. И мы знали, что нам надо запрыгнуть в этот уезжающий поезд, чтобы в нашем портфолио гордо красовались эти три буквы. И поезд тронулся.
Когда ты работаешь в крупной компании с большим количество условностей в виде правил и процедур, ты принимаешь тот факт, что нужно потратить достаточно много времени на работу со сделками. Это целый квест, состоящий из кучи этапов с участием целой группы согласователей и лиц, принимающих решение.
Мы понимали, что у нас этого времени нет. И мы пошли на первый риск, решив проигнорировать все требования и все гайдлайны по проработке сделок, чтобы не потерять перспективный аккаунт.
Итак, переговоры начаты, клиент на всех звонках максимально дружелюбен, но на любые запросы о предоставлении данных о приблизительных объёмах для точного расчёта ресурса и цены говорит очень приблизительно, в итоге так и не предоставив оцифрованных данных. Как вы понимаете, расчёт был сделан, но он был очень приблизительным.
Дальше события стали развиваться ещё стремительнее и интереснее. Пришло время подписывать договор. И почему-то у лиц, принимающих решение на стороне заказчика, в тот самый момент календарь забился настолько сильно, что найти даже час времени не удавалось на протяжении недели. В итоге переговоры зашли в тупик и мы сошлись на подписании гарантийного письма.
Внимание, спойлер! Никогда так не делайте. Дальше вы поймёте, почему.
Кульминация
Это история шла к своему логическому завершению. Мы наняли рассчитанное количество сотрудников, оборудовали рабочие места, подготовили всё, что было необходимо для запуска сервиса. И гордившиеся собой ждали дня Х.
И он настал! Начинается смена, а с ней и полный хаос.
Во-первых, то количество звонков, о котором говорил клиент, даже близко не совпадало с действительностью. Посыпались звонки, мы не укладывались в SLA, уровень потерь был немыслимым для контакт-центра.
Помимо этого мы столкнулись с негативом клиентов практически на каждом звонке. Дело в том, что тот скрипт, который был подготовлен для сотрудников, никак не учитывал потребностей нашего конечного клиента.
Представьте себе ситуацию: вы прокалываете колесо где-то за МКАДом, опаздывая на деловую встречу (ну а кто в Москве не опаздывает), звоните в компанию, которая заявляет в рекламе о том, что в течение 10 минут приедет эвакуатор и заберет вашу машину, и ваша жизнь начнет налаживаться. Но на деле ожидания расходятся с реальностью – трубку берет милая девушка и начинается разговор в духе самого что ни на есть шаблонного классического КЦ: «Добрый день. Вы позвонили на ГЛ компании __. Мы очень рады, что вы обратились к нам…» и т. д.
Конечно, вы будете скорее всего в ярости. Да вам плевать на все эти «спасибо» и «пожалуйста», вы хотите, что вам предоставили помощь на дороге и как можно скорее.
В итоге клиенты начали сбрасывать звонки и перезванивать, создавая дополнительную искусственную очередь на линии. Так и не получив ожидаемый сервис, они писали гневные отзывы на просторах интернета, не рекомендуя обращаться за услугой в эту компанию.
Развязка
Мы начали тушить пожары. Пришлось искать дополнительных людей, которые не были учтены в первоначальных расчётах, поменять процедуру общения с пользователями услуги, принимать бесконечные эскалации от клиента. На то, чтобы устранить последствия непрофессионального запуска проекта, у нас ушло порядка 3 недель.
Но тут в один из дней нам на почту приходит письмо от клиента, в котором черным по белому написано, что организация заказчика прекращает свою деятельность и, как следствие, больше не нуждается в наших услугах. А дальше ключевые лица перестают выходить на связь и мы понимаем, что платить нам никто не собирается.
Эпилог
В сухом остатке: проекта нет, но есть штат сотрудников (порядка 25 человек), которых некуда утилизировать и, очевидно, с которыми нужно расставаться, что само по себе является риском для бренда работодателя. А в качестве вишенки на торте мы получаем дебиторку, которую ещё предстоит долго и упорно выбивать под аккомпанемент гневных коммуникаций с топ-менеджментом компании. Но это уже другая история.
Конечно, продажи – чуть ли не важнейшая составляющая любого аутсорсинга. Но реалии рынка таковы, что продавать типовые услуги становится всё сложнее: если предложение не уникально, то и не конкурентноспособно.
Если упали продажи, не нужно впадать в панику и пытаться лихорадочно продавать всё и всем. В первую очередь нужно задаться вопросом – что вы делаете не так, что спрос на услугу стремительно падает. После детального анализа вы точно выявите точки роста для ваших продаж. И уж лучше сфокусироваться на них, чем тратить время впустую на поиск клиентов, ничего не изменив в стратегии продаж.
Тщательно проверяйте потенциальных клиентов. Фокусируйтесь на поиске надежных клиентов, с которыми вам удастся выстроить партнерские отношения на долгие годы и благодаря которым вы сможете наращивать вашу прибыль, продавая им всё больше услуг и продуктов. Апсейл – это отличная альтернатива поиску новых клиентов.
Если вы нашли потенциального клиента, не игнорируйте все правила и требования к проработке сделки. Точный расчет позволит вам избежать неприятных сюрпризов в BAU. Контрибуционную маржу никто не отменял, а немаржинальный сервис не принесет ничего, кроме постоянных забот. И хотя вы приблизитесь к выполнению планов продаж, ваши финансовые показатели начнут стремительно падать.
Knowledge transfer – обязательный атрибут приёмки сервиса. Если клиент просит опустить это требование, либо всячески игнорирует все попытки получить хоть какую-то информацию, это тревожный сигнал. Ведь в таком случае оказание сервиса априори не может быть качественным.
Даже если всё складывается гладко (расчет проведен, передача знаний запланирована), настаивайте на grace-периоде, чтобы защитить себя от неприятных сюрпризов, которые могут возникнуть в первые месяцы оказания сервиса.
И финальное – начинайте оказывать сервис только на основании договора на оказание услуг, подписанном обеими сторонами до старта оказания сервиса. Это единственная гарантия того, что ваш труд будет оплачен. И даже если возникнет ситуация, когда клиент по какой-то причине попытается уклониться от оплаты, вы сможете с легкостью отстоять свои права.
Соблюдайте эти простые правила и будет вам счастье!
Фильтры восприятия фич из вашего Product Backlog
Если все фичи в процессе разработки продукта кажутся одинаково важными, то выбрать самую приоритетную из них порою очень сложно. Тогда на помощь менеджеру продукта могут прийти полезные фильтры для определения приоритетов.
Я хорошо представляю, как тяжело выбирать фичи для разработки, когда ваш product backlog просто ломится от “вкусных” фич. Но нам, менеджерам продуктов, приходится совершать этот выбор ежедневно. Потому что наша основная задача — дать пользователю value, как можно скорее и как можно больше. И мы не можем сидеть сложа руки. Наша задача — быстро принимать решения в условиях некоторой неопределенности.
Вопрос звучит просто: какая фича самая важная для нас сейчас? Но если они почти все важные? Этот вопрос слабо помогает нам в принятии решения.
Рассмотрим набор фильтров, которые помогут глубже понять степень важности или степень влияния фичи на ваш продукт. А это понимание поможет принять правильное в данный момент и в данном месте решение.
1. Стратегическая/тактическая
Фича соответствует нашей долговременной стратегии или нет. Например, для нас стратегическая фича — интеграция с Jira. Эта фича позволит нам уйти от прямой конкуренции с Jira и занять новую нишу — софт для менеджеров продуктов. Пример тактической функции — поддержка нового стандарта GDRP, который должен быть внедрен до 25 мая 2018 года, иначе мы рискуем попасть на большой штраф.
2. Влияет на метрику/не влияет (долги, баги)
Фича может улучшать какие-то конкретные показатели, например, увеличивать конверсию из регистраций в покупку подписки. А может, вообще не влиять в случае с фиксом багов или с переходом на новую библиотеку по обработке фотографий.
3. Улучшает UX/портит UX
Фича может улучшать UX и делать жизнь пользователя в вашем продукте лучше, а может, наоборот, усложнять его жизнь, но при этом повышать доход.
4. Нужна многим клиентам/нужна единицам
Сравните: фича, которая касается onboarding и которую увидят и прочувствуют абсолютно все новые пользователи, и фича, которая понадобится пользователям только на 7 день после регистрации. Например, экспорт в PDF time tracking отчета.
5. Нужна часто клиентам/нужна редко
Фича shortcuts или hot keys нужна часто тем пользователям, которые активно пользуются Hygger, в отличие от фичи «Смена типа доски с Канбан на Спринт», которая нужна только один раз, когда клиент импортирует свои данные в Hygger из Jira или Trello.
6. Время и стоимость разработки: высокие/низкие
Тут все просто: нужно оценить трудозатраты на разработку фичи. Если есть функции с маленькими затратами, но с большим value, то их надо делать первыми. Мы их еще называем Quick Wins. Но нельзя забывать и про большие функции с большим value. Их желательно разбивать на более мелкие куски и делать постепенно. Ибо они могут дать хороший value вашему продукту.
7. Время и стоимость внедрения: высокие/низкие
Себестоимость фичи складывается не только из времени разработки. Для фичи надо написать документацию, снять и смонтировать видео, сделать рассылку, настроить ивенты в аналитике, сделать Dashboard в BI туле, провести вебинар и так далее.
8. Требует vip клиент/требует не платящий клиент
Если фичу просит vip клиент, логотип которого вы гордо показываете всем посетителям на лендинге, то не спешите говорить «нет».
9. Ожидаемая/нет
Если в вашем продукте не будет ожидаемой по модели Кано функции, то пользователь просто уйдет. Например, если бы в Hygger не было комментариев у задач, вряд ли бы у нас были пользователи.
10. Желаемая/нет
Пример желаемой по Кано функции — объем доступной памяти на Dropbox. Чем больше памяти доступно пользователю, тем выше его удовлетворенность. Как правило, это линейные свойства продукта, то есть, чем этого больше, тем лучше. Другие примеры:
11. Восхищающая/нет
Если ваша фича является восхищающей по Кано, то она станет «пасхалкой» для пользователя. То есть, это всегда что-то неожиданное, то, чего пользователь совсем не ожидает от вашего продукта. Например, в случае с Hygger, это может быть 2-х уровневое комментирование задач или возможность с помощью тачпада перемещаться по доске в разных направлениях.
Если этой функции не будет в вашем продукте, ну и ладно — пользователи даже не заметят этого. Но, с другой стороны, пользователи могут быть настолько впечатлены функцией, что поделятся своим открытием с другими.
12. Есть у конкурентов/инновация
Если фича есть у конкурентов, это значит только то, что она есть у конкурентов. А вдруг ей никто не пользуется, и конкурент собирается ее скоро «выпилить»? Но иногда фича у конкурентов становится ожидаемой по Кано, и нам приходится ее повторять у себя. А лучше делать новые и классные фичи первыми!
13. Идея проработана/не проработана
Вы готовы отдавать фичу в разработку? Не спешите, убедитесь, что она детально изучена и описана так, что ее четко и ясно поймут ваши программисты и тестировщики. Степень детализации выбирать вам — вы как product manager лучше знаете ваших людей. Если понимаете друг друга с полуслова — отлично, можно не писать «Войну и мир». Работаете с банковским продуктом, у вас в команде есть свои бизнес-аналитики — прекрасно, пусть они моделируют фичу в UML хоть во всех 7 диаграммах.
14. Уверенность в том, что выстрелит: высокая/низкая
Оцените в процентах вероятность того, что фича действительно оправдает возложенные на нее ожидания.
15. Измерима/нет
Идеально, если все фичи измеримые. Это дает нам возможность численно оценить их вклад в успех продукта.
16. Проблема выявлена на UX
Если проблема выявлена на юзабилити-тестировании (UX-тестировании), то это придает нам уверенности в том, что мы решаем реальные проблемы пользователей, а не «галлюцинируем», как в случае с гипотезами, которые мы сами формулируем.
Конечно, наблюдение проблемы у 5 человек — это одно, а гипотеза на основе анализа поведения 1000000 пользователей — это другое. Тогда и не стоит это сравнивать, а надо формулировать гипотезы и проверять их asap.
17. Технический долг
Команда со временем накапливает технические долги, которые надо отдавать. Это может быть временный, не очень красивый код, который решает задачу, но топорно. Это может быть заглушка для функции, которая может быть вызвана в очень исключительной ситуации.
Если такие долги не отдавать, то со временем могут «накапать» очень большие проценты и на рефакторинг кода может уйти намного больше времени, чем эти долги позволили выиграть на старте.
Lean Prioritization или как мы приоритезируем в Hygger
Далеко не факт, что в вашем продукте будут нужны все эти фильтры. Как правило, менеджер продукта выбирает 3-7 критериев и использует их для скоринга фич. В результате, каждая фича получает числовое значение, и их уже можно сравнивать в одной плоскости.
Мы в Hygger.io используем метод Lean Prioritization. Он легковесен и эффективен, поэтому мы им пользуемся практически каждый день.
Это метод, представляющий собой 2×2 матрицу, которая помогает в принятии решений и определяет, что важно, что рискованно, и куда направлять свои усилия. Матрица активно применяется и для определения приоритетов в разработке продуктов.
Если не поддерживать бэклог постоянно, он быстро может стать свалкой для десятков, сотен и даже тысяч фич и багов.
Используя Lean Prioritization для работы с матрицей можно просто нарисовать большой знак плюс «+» на доске и задать значения «Value» и «Efforts» вдоль вертикальной и горизонтальной осей. Однако, многие согласятся, — эффективнее и удобнее будет использовать специальный онлайн инструмент, особенно, если у вас распределенная команда.
В Hygger это Backlog Priority Chart, где, помимо параметров Value и Efforts, предлагаются 4 сегмента: Big Bets, Quick Wins, Time Sinks и Maybes, каждый из которых представляет собой степень приоритетности:
Наверняка, список способов для определения приоритетности продуктовых фич может быть расширен. А по каким критериям вы оцениваете фичи? Возможно, у вас есть решение, которое может помочь другим?