Спасибо за комментарий! Способы проверки достоверности потребностей — тема для отдельного лонгрида). Если кратко — у нас несколько способов проверки: 1. Во-первых, на протяжении всей жизни сервиса (это 6 лет по одному продукту, и полгода по другому) мы ведем бэклог: записываем каждое пожелание от пользователей в Jira. То есть на момент появления любого пожелания мы уже знаем, сколько клиентов хотят такую же или похожую фичу и что они имеют ввиду, когда ее просят. 2. Сразу после того, как клиент высказывает пожелание, мы задаем вопрос «Чтобы что?». Такая постановка вопроса помогает узнать, какую проблему хочет решать клиент. Например (в продукте SMM): у нас есть встроенное сокращение ссылок с трекингом кликов. Клиент говорит, что ему срочно нужна функциональность UTM-меток. Мы спрашиваем: «Что вы хотите отслеживать метками?». Варианта ответа 2 (по большому счету): либо собирать отчеты в Google Analytics, либо смотреть, сколько кликов было по каждой ссылке в разрезе соцсетей (знать, какая сеть активнее). Клиент говорит, что второй вариант. У нас эта функциональность уже есть — рассказываем клиенту, учим пользоваться и показываем, почему удобнее. 3. Когда считаем, что поняли задачу клиента (именно результат, который он хочет получить), то проводим исследование. В зависимости от типа обновления (массовое, или специфическое) сегментируем клиентов и спрашиваем у них, как часто возникает задача, как они ее решают и т.д. Маячок, что проблема надумана: когда пользователи говорят: ДА, ПРОБЛЕМА ЕСТЬ!!!111, и на вопрос «Как справляетесь?» говорят: «Да никак, так и живем». Если бы проблема реально была, люди бы ее решали, а не просто переживали. После опроса принимаем решение о вводе обновления и его конечном виде.
Но! Сразу оговорюсь: часто еще на этапе высказывания пожелания просто видно (без исследований и т.д.), клиенту не хватает функциональности или просто хочется поучаствовать. По нашему опыту — когда требуют «здесь и сейчас», стоит взять отсрочку и подождать минимум неделю — скорее, пользователь ищет маневр для отказа, чем действительно хочет изменений.
Это та компания, которая прислала вам сегодня письмо «Оператор связи «Теле2» изменяет политику предоставления услуг. В связи с этим с 1 марта 2018 года в SMS Aero изменятся цены на SMS-рассылки». К сожалению, в случае с SMS мы не создаем услугу, а предоставляем комфортный доступ к уже имеющейся. Ценовая политика не всегда зависит только от нас: например, сейчас абсолютно все сервисы SMS-рассылок поднимают тарифы.
Вот написал ты статью. Опубликовал (а это на VC ого-го как непросто). Сидишь и радуешься. И тебе «блямц!» уведомление, что кто-то комментит. И ты радостный заходишь, а там спам. И как лицом об стену. Нехорошо. Спамер, не спамь!
Комментарий удалён модератором
Спасибо за комментарий! Способы проверки достоверности потребностей — тема для отдельного лонгрида). Если кратко — у нас несколько способов проверки:
1. Во-первых, на протяжении всей жизни сервиса (это 6 лет по одному продукту, и полгода по другому) мы ведем бэклог: записываем каждое пожелание от пользователей в Jira. То есть на момент появления любого пожелания мы уже знаем, сколько клиентов хотят такую же или похожую фичу и что они имеют ввиду, когда ее просят.
2. Сразу после того, как клиент высказывает пожелание, мы задаем вопрос «Чтобы что?». Такая постановка вопроса помогает узнать, какую проблему хочет решать клиент. Например (в продукте SMM): у нас есть встроенное сокращение ссылок с трекингом кликов. Клиент говорит, что ему срочно нужна функциональность UTM-меток. Мы спрашиваем: «Что вы хотите отслеживать метками?».
Варианта ответа 2 (по большому счету): либо собирать отчеты в Google Analytics, либо смотреть, сколько кликов было по каждой ссылке в разрезе соцсетей (знать, какая сеть активнее).
Клиент говорит, что второй вариант. У нас эта функциональность уже есть — рассказываем клиенту, учим пользоваться и показываем, почему удобнее.
3. Когда считаем, что поняли задачу клиента (именно результат, который он хочет получить), то проводим исследование. В зависимости от типа обновления (массовое, или специфическое) сегментируем клиентов и спрашиваем у них, как часто возникает задача, как они ее решают и т.д. Маячок, что проблема надумана: когда пользователи говорят: ДА, ПРОБЛЕМА ЕСТЬ!!!111, и на вопрос «Как справляетесь?» говорят: «Да никак, так и живем». Если бы проблема реально была, люди бы ее решали, а не просто переживали. После опроса принимаем решение о вводе обновления и его конечном виде.
Но! Сразу оговорюсь: часто еще на этапе высказывания пожелания просто видно (без исследований и т.д.), клиенту не хватает функциональности или просто хочется поучаствовать. По нашему опыту — когда требуют «здесь и сейчас», стоит взять отсрочку и подождать минимум неделю — скорее, пользователь ищет маневр для отказа, чем действительно хочет изменений.
Это та компания , которая прислала мне сегодня письмо "с 1 марта мы поднимаем цены. Цены вы сможете узнать 1 марта в разделе Цены"?
Это та компания, которая прислала вам сегодня письмо «Оператор связи «Теле2» изменяет политику предоставления услуг. В связи с этим с 1 марта 2018 года в SMS Aero изменятся цены на SMS-рассылки».
К сожалению, в случае с SMS мы не создаем услугу, а предоставляем комфортный доступ к уже имеющейся. Ценовая политика не всегда зависит только от нас: например, сейчас абсолютно все сервисы SMS-рассылок поднимают тарифы.
Комментарий удалён модератором
Вот написал ты статью. Опубликовал (а это на VC ого-го как непросто). Сидишь и радуешься. И тебе «блямц!» уведомление, что кто-то комментит. И ты радостный заходишь, а там спам. И как лицом об стену.
Нехорошо.
Спамер, не спамь!