Какие проблемы должен решать продукт
Эта статья о том, как определить и конкретизировать проблемы клиента, которые решает отдельный продукт.
Статья отвечает на вопросы:
- Что такое проблема клиента?
- Почему для команды разработки важно перед началом работы над продуктом четко формализовать проблемы клиента?
- Какие шаги нужно сделать, чтобы точно понять, какую из проблем решает конкретный продукт?
- Какие трудности возникают в процессе формализации проблем?
О том, как размытое понимание проблемы стало причиной остановки разработки продукта
Мой первый стартап начался с личной проблемы. В то время я начал работать руководителем проектов. Работы было много, и я мало успевал.
Чтобы стать более продуктивным я пробовал внедрить Getting Things Done. Затем в течение года перепробовал десяток других методик, сервисов и приложений. Ни одна из систем не приживалась.
Со временем у меня сформировалась собственная система повышения продуктивности. Эта система работала на бумаге и мне никак не удавалось перевести систему в цифровой вид. В итоге я и запустил собственный стартап, чтобы реализовать свою бумажную систему в виде цифрового продукта.
За пару месяцев я придумал HELP PEN и весной 2014 года предложил моему другу Александру реализовать идею. Александр первым делом спросил: «Какую проблему клиента будет решать продукт?». Я понимал, что хочу классный, удобный и простой список дел, но ничего внятного о проблеме сказать не смог.
Потом каждая встреча по проекту начиналась с обсуждения проблем нашего клиента. Александр хотел точнее понять, чем мы занимаемся, а я формулировал что-то вроде:
«Часто клиент не успевает сделать то, что запланировал на день»
Встречи и обсуждения продолжались больше года. Мы топтались на месте. Я не хотел разбираться, как правильно выделять проблемы клиентов, а Александр не хотел делать продукт, без понимания проблемы.
После сотни обсуждений, мы все-таки остановились на списке проблем. Список был компромиссный и не очень нам нравился. Но мы уже устали от бесконечных обсуждений и решили наконец начать разработку первой версии продукта.
Из за того, что мы плохо проработали проблему клиента стали возникать трудности с формированием виденья продукта. Мы спорили из за расстановки приоритетов разработки. То и дело мы возвращались к обсуждениям проблем. Было тяжело держать в голове цель разработки без точного понимания проблемы клиента.
В конечном итоге, размытая и непонятная проблема клиента HELP PEN стала причиной остановки разработки.
Оказалось, что ясное и четкое понимание проблемы клиента — это важная вещь для мотивации и сплочения команды. Начинать разработку без общего понимания проблемы — большая ошибка. Для меня стало важно не повторять эту ошибку в будущем и я решил разобраться, как правильно определять проблему, которую решает продукт.
О том, что такое «проблема» и какие проблемы возникают с проблемами
Лично я всегда думал, что проблема — это задача, которую непонятно как решить. Понятно, что должно получиться в результате, но неясно, как этого достичь.
А вот, что написано в толковых словарях:
Большая Советская Энциклопедия. Проблема (от греч. рroblema — задача), в широком смысле сложный теоретический или практический вопрос, требующий изучения, разрешения.
Даль. Проблема — это задача, вопрос, загадка, что предложено на разрешенье, на научное решенье или задача, для отысканья неизвестного по данному.
Ожегов. Проблема — это сложный вопрос, задача, требующие разрешения, исследования.
Ушаков. Проблема — теоретический или практический вопрос, требующий разрешения, задача, подлежащая исследованию.
Если обобщить, получается, что:
Проблема — это сложная задача.
Получается, что проблема которую решает продукт — это одна из сложных задач клиента. Но не все так просто. Кроме проблемы у клиента может быть боль. Или у клиента может быть простое желание или потребность что-то купить.
Приведу несколько цитат из фейсбука:
Андрей Тян — трекер во ФРИИ пишет:
Продукты должны решать проблему! а не закрывать потребность или давать возможность.
На банке с витаминами написано, что они закрывают потребность дневной дозы витаминов, но ПРОБЛЕМУ человек видит только после того, как у него начинают выпадать волосы.
…и только после этого человек начинает искать решение Проблемы, решение потребности он не ищет
Алексей Крол — предприниматель, автор, лектор и кинопродюсер, как будто отвечает Андрею:
Есть такая мантра — найди боль клиента, страдание, реши проблему и будет у тебя крутой стартап.
Это полная лажа, которая придумана прыщавыми гиками-задротами, и это не соответствует реальности. Но «Я тебя полюбил, я тебя научу!» (с) Зеф (Киндза-дза).
Наслаждение и боль — это смысл нашей жизни. Эмоции это единственное, что отличает живое от всего остального. Мы развиваемся потому, что стремимся убежать от боли, или обрести наслаждение.
Эти цитаты довольно показательные. Каждый понимает под проблемой клиента что-то свое.
Для того, чтобы правильно определять проблему клиента, нужно разобраться в чем ее отличие от боли и желания. Кроме того, нужно ответить на вопрос, как отличить проблемы клиента от его потребностей. Без этого понимания описать проблему будет трудно. Путаница в понятиях рано или поздно даст о себе знать.
О том, как развиваются проблемы клиента и чем проблема отличается от боли
Пришло время обратиться к моей любимое книге о продажах — «СПИН Продажи». Ее автор, Нил Рекхем, пишет о нескольких стадиях развития потребности клиента:
- Сначала покупатель не подозревает о существующих у него потребностях.
- Затем начинается развитие скрытой потребности: обнаруживаются небольшие недостатки или легкая неудовлетворенность текущим положением.
- Потом происходит осознание реальной проблемы и серьезных трудностей. Недовольство нарастает.
- В конце концов, потребность становится явной необходимостью, желанием или намерением действовать.
Описанный процесс происходит в голове клиента до каких-либо действий. Клиент только осознает, что что-то надо делать, чтобы выбраться из текущего положения. Он готов тратить время, чтобы оказаться в более приемлемых условиях. Я уверен, что после осознания желания действовать процесс развития потребности не останавливается. Это легко проверить. Рассмотрим упрощенный сценарий покупки автомобиля:
После осознания своего желания получить машину клиент должен сделать кучу шагов. Сама покупка — это один из шагов на пути к успеху. Процесс выбора и покупки машины сложный и долгий. Но и в небольших сделках есть шаги помимо покупки. Давайте посмотрим, как клиент покупает шоколадку:
Даже такая простая сделка содержит несколько шагов и решений помимо самой покупки.
Чтобы приблизиться к пониманию отличия проблемы от боли и желания клиента, предлагаю шаг за шагом разобрать продажу от появления первого смутного желания что-то поменять до совершения конкретной покупки.
Чтобы не утонуть в деталях, возьмем условный пример — один парень решил купить себе машину. Моей жене нравится рисовать кроликов, и она помогла мне с иллюстрациями. Этого парня зовут Кролень.
Условия жизни вполне устраивали Кроленя, пока он не узнал, что на свете есть транспорт. Для Кроленя стало неожиданностью, что передвигаться можно быстрее и проще. Текущие условия перестали его устраивать. Не узнай он о транспорте — так бы и дожил до глубокой старости без беспокойства. Но все знакомые уже вовсю передвигаются на транспорте и Кроленю больно осознать себя отсталым.
Боль — клиент не может не замечать недостатков своих условий и готов их поменять при первой возможности.
Теперь у Кроленя проблема. Нужно узнать какой бывает транспорт, как он работает. Ему нужно понять что конкретно выбрать для себя: машину, троллейбус или самокат. Кролень хочет лучше представить будущие условия.
Друзья рассказали Кроленю про машины, автобусы и скейтборды. Кролень понял, что хочет машину.
Желание — представление более подходящих условий.
В мечтах Кролень видит себя за рулем тачки с открытым верхом. Ему кажется, что очень круто иметь возможность проехать через весь лес за полчаса с ветерком.
Чтобы попасть в новые условия, нужен план. У Кроленя нет опыта покупки автомобилей. Он снова советуется с друзьями. Друзья советуют Кроленю достать денег, найти автосалон и купить там машину.
Позже, в автосалоне продавец рассказывает Кроленю нечто новенькое. Оказывается, что машины бывают обычные и спортивные. Кролень привык к высокой скорости своих лап и уже видит себя в спортивном кабриолете. По ходу продвижения к цели Кролень все точнее и точнее осознает условия, в которые он хочет попасть.
Потребность — необходимость получения конкретного продукта для решения конкретной задачи.
Кролень почти прошел намеченный путь, но как часто бывает, в конце все пошло не по плану. Денег на кабриолет не хватило. Кроме того, оказалось, что машину нужно регулярно заправлять и обслуживать. Зато Кролень узнал, что в качестве транспорта можно использовать велосипед. Продавец объяснил ему, что это так же полезно для здоровья, как бегать на лапах. На велосипед денег хватило, и Кролень рад своим новым условиям.
От момента осознания желания до момента покупки Кролень столкнулся с тремя базовыми проблемами:
- Проблема выбора и конкретизации будущих условий — «Что выбрать для себя?»
- Проблема выбора плана попадания в новые условия — «Как мне получить желаемое?»
- Проблема совмещения желаемых и возможных условий — «Как найти компромиссное решение?»
Кроме того, Кролень испытал боль от того, что не вовремя влился в тренд с транспортом и желание получить транспорт, чтобы быстрее передвигаться по лесу.
О том, как выделять проблемы, которые решает продукт
По итогу разбора примера я выделил пять шагов, которые нужно сделать для определения, проблемы которую на самом деле решает продукт.
Шаги снабжены примером, на основе продукта HELP PEN, о котором я говорил в начале.
1 | Описать текущие условия клиента Перегруженный срочными делами менеджер не знает, за что хвататься и живет в круглосуточном стрессе |
2 | Определить, в какие условия клиент хочет попасть Менеджер хочет получить важные результаты и снизить уровень стресса |
3 | Cоставить план шагов к новым условиям Чтобы добиться своего, менеджер должен:
|
4 | Найти место своего продукта в цепочке шагов к новым условиям: какие задачи клиента продукт решит Менеджеру нужен продукт, который реализует его собственную систему ведения дел |
5 | Выбрать какие еще задачи клиента на пути к результату можно решить. За решение этих задач клиент заплатит лояльностью. Еще менеджеру будет полезно узнать какие методики ведения дел вообще бывают. Он готов подписаться на рассылку про продуктивность |
Проблема (или задача), которую решает HELP PEN — это повышение продуктивности клиента. А вот проблему, которую решает Велосипед для Кроленя вы теперь можете определить самостоятельно.
Краткое резюме, для тех кто торопится
Процесс удовлетворения потребности клиента всегда содержит несколько шагов:
- Покупая что-то, клиент стремится из неудовлетворительных текущих условий в более приемлемые новые условия.
- Покупка продукта — это только один из шагов на пути клиента из текущих условий в желаемые. Есть и другие задачи.
- На пути к желаемым условиями у клиента всегда есть три базовые проблемы, связанные с покупкой: конкретизация желаемых условий в начале, выбор пути к новым условиям, совмещение желаний и возможности реализации в конце.
- Чтобы понять какую проблему решает продукт, нужно найти его место на пути клиента к новым условиям.
* * *
Это была первая итерация по систематизированию способа описания проблем клиента. Спасибо, что прочитали до конца. В следующих статьях я буду развивать мысль и разбирать конкретные примеры.
Если вам показалось, что я неправ, и это так не работает — напишите в комментариях свои мысли. Буду рад критике и дополнениям.
Есть наблюдение, что продавцы сталкиваются с определенными проблемами клиентов в процессе продажи, с которыми не могут справиться. В итоге мы получаем меньшее количество продаж, падение дохода компании и нежелание продавцов продавать. Причиной этого является отсутствие знаний и навыков в сфере продаж. Поэтому я хочу помочь вам, предоставив правильные данные. Возможно, это будет вам полезным.
Проблемы клиента — это те ситуации, обстоятельства, мысли, ложные данные, мнения других людей, советы из рекламы, которые мешают ему разбираться в том, что ему действительно необходимо и приобретать правильный товар или услугу.
Перечисленные ниже проблемы клиентов должен решать продавец. Они, непосредственно, касаются работы продавца, и он должен находить для них решения, если хочет быть богатым и успешным в вашей компании!
Итак, хотелось бы обратить особое внимание на некоторые проблемы клиентов, которые у них есть. Любой клиент хочет решить эти проблемы, а именно, чтобы продавец им помог в этом.
1. Клиент не доверяет продавцам из-за прошлого негативного опыта: боится, что ему навяжут, и, поэтому не хочет разговаривать вообще. Он не знает, какой продавец с ним разговаривает, и, поэтому подозревает худшее. На начальном этапе контакта клиент неразговорчив (стесняется, не доверяет, видит в продавце врага). Заинтересуйте клиента к общению. Здесь может помочь любая история из жизни, притча, цитата, интересный факт, которые привлекут внимание и клиент начнет просто слушать вас, после чего обязательно согласится или не согласится и между вами завяжется диалог.
2. Клиент не способен сам увидеть ценность товара/услуги. Это проявляется в следующем: говорит «дорого», «я подумаю». Вы должны абсолютно точно понимать, что это всего лишь оправдания для того, чтобы закончить разговор. Никто не будет думать об этом в дальнейшем, если вы пустите ситуацию на самотек. Если клиент хочет подумать, то вам следует настоять на том, чтобы он обязательно подумал, потому что если это не то, что ему подходит в последствии это расстроит, в первую очередь, клиента и вас. Объясните, что вы нацелены только на помощь и вовлеките в обсуждение преимуществ.
3. Клиент не может представить себе товар или услугу в действии/в использовании (клиент не может представить себе — как будет решаться его проблема). Что вы можете сделать в этом случае? Начните с того, что зададите ему несколько вопросов, которые связаны с его бизнесом, с его сферой деятельности. Наверняка, он расскажет вам о проблемах, которые у него есть и тогда ключ у вас в кармане. Начните вовлекать в пользы вашего товара/услуги, говорите о ценностях и о том, как это поможет ему: — «Вы сказали, что у вас плохо пишет ручка и всегда снимается колпачок…. это действительно доставляет неудобства, и именно поэтому наши ручки разработаны таким способом, что…. это могло бы убрать ваши неудобства…?»
4. Клиенту трудно принять решение, и он не хочет, чтобы ему мешали, чтобы на него давили при принятии решения. Не проблема. Дайте ему свободу выбора: — «В любом случае, это ваше решение, каким бы оно не было…». Оттолкните немного его: — «Возможно, это вообще не для вас, вам это не нужно…». Давая человеку свободу выбора, у вас появляется больше шансов на то, что он примет положительное решение.
5. Если клиент не готов платить прямо сейчас, это не значит, что он не может платить вообще. Просто необходимо выяснить с какими трудностями сталкивается при оплате клиент, возможно, вы сможете ему помочь какими-то действиями со своей стороны. Предложите помощь с реальным желанием помочь и человек не будет бороться с вами.
6. Для менеджеров, работающих по телефону: клиент сам не звонит (менеджер не находит повод позвонить: — «А что я ему скажу?»). На самом деле существует множество причин позвонить клиенту. Не обязательно звонить с целью продать. Можно поздравить с днем рождения, сообщить о новости, поинтересоваться, было бы ему интересно прочитать статью на тему… или же: — «Говорил с одним клиентов и вспомнил о Вас…» — это, в первую очередь, забота и помощь, что в совокупности рождает желание сотрудничать. И, конечно, главное — это количество действий и количество подходов к клиенту.
7. В начале разговора у клиента единственный критерий для выбора — цена. Это действительно так. При любой продаже мы сталкиваемся с чашей весов «Цена» — «Ценности». Задача продавца складывать гирьки на чашу весов «Ценности» и держать внимание клиента на ценностях товара или услуги, которую он предлагает. Напоминать неоднократно про преимущества, которые он получит. Расскажите чем ваша компания отличается от других подобных, вовлекая клиента в обсуждение польз.
Обычно эти все проблемы прослеживаются следующим образом: клиент не в состоянии сам сделать правильный выбор, он сомневается о качестве, о цене. И, здесь, конечно, ему необходима забота, помощь и понимание к тем беспокойствам и сомнениям, которые у него возникают. Но, в то же время, доверия к продавцам нет и он их постоянно обходит.
Как, по-вашему, существуют ли в вашем бизнесе и у ваших клиентов трудности при выборе? Такие, как перечислены выше, или подобные им?
Посмотрите, какие из этих проблем являются проблемами ваших клиентов, но продавцы не считают их своими задачами и объясняют этим низкие объемы продаж?
Еще раз подумайте и определите для себя — решают ли ваши продавцы проблемы клиентов? Или преподносят их Вам как нерешаемые ситуации в продажах и всё это превращается в сплошные «сложности при продажах»?
Перевод колонки вице-президента по продуктам инструмента для общения с пользователями Intercom Пола Адамса.
Перевод подготовлен командой онлайн-школы английского Skyeng.
Пол Адамс
За последние несколько лет мы в Intercom многое узнали о создании продуктов.
Какие-то идеи оказались более удачными, а какие-то не «выстрелили». Чтобы научиться повторять свой успех и показать новым сотрудникам, что на самом деле работает, мы много размышляли над своими процессами.
Есть одна вещь, которую я считаю ключевым фактором наших успехов. А именно: мы глубоко обдумываем проблему, которую должен решить проект. Звучит банально, и все говорят, что делают то же самое, но мы делаем это немного по-другому.
Вот как выглядит стандартный процесс разработки продукта, которого более или менее придерживается большинство компаний:
Расстановка приоритетов — определение проблемы — проектирование (дизайн) — разработка продукта — бета-тестирование — анонс и запуск
Если каскадной модели вы предпочитаете гибкую, процесс, вероятно, будет выглядеть так:
И будет включать следующие активности:
План — бриф по проекту — исследование пользователей — проверка гипотезы
Может быть, у вас всё не совсем так, и вы, например, возвращаетесь от бета-тестирования назад к разработке и так далее. Это неважно. Этот материал не о том, какая диаграмма идеально изобразит agile, lean, scrum или какой-то другой процесс. Он о том, на что вы тратите своё время.
Представьте, что время, которое вы отводите на проект, можно поделить на сто единиц. Сюда включена работа менеджеров по продукту, дизайнеров, исследователей, аналитиков, разработчиков и так далее.
У большинства команд, занимающихся разработкой продукта, время распределяется примерно так:
Небольшая предварительная работа по расстановке приоритетов, затем определение проблем. Значительно дольше длится проектирование, а основная часть времени уходит на разработку.
Однако иногда всё распределяется вот так:
Такое происходит, когда у кого-то из руководства появляется идея, которую он хочет увидеть воплощённой в жизнь. Эта «очень важная идея» обычно посещает его в машине, иногда — в душе, иногда — после разговора с соседом, которого он, как «обычного человека», спросил, как можно улучшить продукт.
Как только идея сформулирована, нельзя терять ни минуты, сразу нужно разрабатывать и собирать. Эта «идея очень важного человека» может быть большой или маленькой. Хуже всего, когда план работы целиком состоит из множества мелких, постоянно меняющихся «идей очень важного человека», большая часть которых никак между собой не связаны.
То, как мы решаем работать, зависит от нашего прошлого опыта. В моём случае я часто сталкивался с «идеями важного человека», когда работал над проектами в Google. Много было таких людей с большими идеями из машины, душа или разговора с соседом. Большинство этих проектов провалились. Я знаю, что с другими проектами Google дела обстояли лучше, но мой опыт таков.
Подобные вещи — распространённая практика для стартапов, которые в итоге провалились. Когда я разговариваю с людьми из этих стартапов и спрашиваю их о том, как они работают, они описывают именно этот принцип. Они могут говорить об исследованиях и общении с клиентами, но это всего лишь формальности и пустые слова.
Большинство проектов, которые я видел в Facebook, выглядели так:
Лучше, чем в Google (исходя из моего опыта), но в стратегии Facebook было два конфликтующих пункта. Вот они, в прекрасной книге, которую все мы получили в день IPO несколько лет назад:
Безжалостная приоритизация
Умение решать проблемы далеко не так важно, как умение выбирать правильные проблемы для решения.
- Сосредоточьтесь на решении масштабных проблем.
- Сосредоточьтесь на том, чтобы помочь большинству.
- Сосредоточьтесь на том, что будет иметь влияние.
Кто побеждает в споре
Создавать важнее, чем разговаривать. Важнее, чем быть штатным сотрудником. Важнее, чем хорошо одеваться, складно говорить и быть известным. Важнее, чем быть популярным. Важнее, чем войти в ближний круг Марка (Цукерберга — прим. ред.).
Задача проста: создавайте то, что будет решать масштабные проблемы. Если вы не можете этого сделать, ничто другое не имеет значения. Если можете, ничто другое тоже не имеет значения.
На игровом поле все равны. Если вы сможете создать проект, то победите.
Я не согласен, что время, потраченное на написание кода, важнее определения проблемы. Готовый код может быть неплохим аргументом в споре о выборе решения, но его успешность зависит от понимания сути проблемы.
Случалось, что кто-то писал код, чтобы помочь понять проблему, но это обычно касалось технических проблем, а не потребностей клиентов. Эта зацикленность на разработке заставляет людей слишком быстро проходить этап определения проблемы.
В Intercom мы тратим время примерно так:
Сорок из ста наших единиц оказываются потрачены ещё до стадии разработки. Мы много времени и ресурсов тратим на приоритизацию и определение проблемы.
Иногда я свожу коллег с ума, допытываясь, достаточно ли глубоко мы понимаем проблему, которую пытаемся решить. Мы призываем менеджеров по продукту открыто делиться и обсуждать ранние формулировки проблем, которым мы пытаемся дать определение.
Почему мы так поступаем? Потому что хорошее решение зависит от хорошего понимания проблемы. Это неоспоримо. И всё равно большинство команд стараются побыстрее проскочить этап определения проблемы.
Мы изо всех сил стараемся научно подойти к этой громоздкой предварительной работе. У нас трудятся:
- команда клиентской поддержки (они размечают каждый разговор с клиентом, которые затем изучат наши менеджеры по продукту, для этого мы, конечно, используем Intercom);
- команда продаж и команда маркетологов (они строят матрицу продукта и рынка на основе собранной информации);
- команда исследователей (в них мы основательно вложились с самого начала);
- команда аналитиков (это направление мы активно развиваем сейчас).
Иногда мы доходим до стадии бета-тестирования и осознаём, что всё ещё недостаточно хорошо понимаем проблему, и тогда возвращаемся к её определению. Поэтому время от времени происходит следующее:
Возникает вопрос: если хорошее решение напрямую зависит от хорошего понимания проблемы, то почему столько компаний и команд стремятся побыстрее проскочить эту часть работы? Думаю, на то есть три больших причины:
- Это тяжёлая работа. Она требует снова и снова общаться с многочисленными клиентами, копать глубже, выстраивать новые вопросы. Залезать к пользователям в голову. Добираться до их глубинных истинных потребностей, а не довольствоваться первым, что они скажут. Люди часто описывают свои проблемы в форме решения, которое хотят получить. Плохие продуктовые команды довольствуются этим и воплощают это решение. Как правило, оно не достигает цели, поскольку настоящая потребность пользователей зарыта на несколько слоёв глубже. Хорошие продуктовые команды не останавливаются на первых формулировках, они продолжают искать причины. Это эмоционально тяжело и отнимает время.
- Ей недостаёт эффектности. Что круче: отчёт об исследовании, новый макет интерфейса или работающий прототип чего-то нового? Большинство руководителей любят смотреть на новые продукты, которые вроде как работают, но у них нет времени читать отчёты. В современных компаниях чтение и размышление, которые позволяют приобрести глубокие знания, не считаются чем-то интересным или важным. Это плохо. В работе нет привлекательных и непривлекательных вещей. Только важные.
- Видимый результат не отражает масштаб проделанной работы и затрудняет справедливую её оценку. Иногда люди работают неделями, а итогом их работы становится простой короткий абзац, в котором сформулирована проблема, требующая решения. Руководству, которое не способно оценить этот процесс, сложно обосновать важность работы, основываясь на её результате.
Вот почему большинство компаний не занимаются этим. Это тяжёлая работа, её несправедливо считают неинтересной, а первые результаты сложно оценить. И всё-таки я считаю, что это одна из наиболее важных вещей, которые мы делаем, и один из главных факторов успеха наших проектов.
Эта работа существенно снижает вероятность того, что вы создадите что-то ненужное или бесполезное, и вам не придётся выяснять это уже после того, как вы потратили время на разработку и сборку.
Попытайтесь изменить принцип распределения времени. Начните с малого, целиком сосредоточьтесь на формулировке проблемы, и тогда вы быстро поймёте, что нужно делать. Когда вы создадите продукт, то увидите, что клиенты его оценят, ведь вы поняли, в чём они нуждаются.
{
«author_name»: «Саша Море»,
«author_type»: «self»,
«tags»: [«u043au0435u0439u0441u044b»],
«comments»: 11,
«likes»: 36,
«favorites»: 38,
«is_advertisement»: false,
«subsite_label»: «flood»,
«id»: 31749,
«is_wide»: false,
«is_ugc»: true,
«date»: «Mon, 15 Jan 2018 17:34:00 +0300»,
«is_special»: false }