Что Изменилось В Вашем Продукте За 5 Лет?
Около 7 лет назад я пользовался сервисом LinguaLeo для изучения английского и вот решил вернутся к этой практике, предвкушая изменения в продукте. По моим ощущениям, за все время моего отсутствия в этом сервисе практически ничего не изменилось, хотя я и предполагаю, что за 7 лет внутри была проделана колосальная работа. И это меня натолкнуло на один вопрос.
Как сильно изменился ваш продукт для пользователя за 5+ лет?
Я ушел в рефлексию, вспоминая все компании, где мне удалось поработать. Пытался вспомнить, что и как менялось в продукте именно с точки зрения пользователя и чем в это время занималась разработка.
Если это был готовый продукт - он менялся крайне медленно. Изменения в основном носили визуальный характер. Много всего делалось для повышения операционной эффективности: чтобы визуал могла менять не только разработка, чтобы быстрее получать какие-то данные и строить отчеты, чтобы клиент (внутренний и внешний) совершал меньше действий. Ну и конечно периодически рождались второстепенные продукты, которые не часто показывали способность зарабатывать.
Меня все это натолкнуло на несколько разных, но косвенно связанных мыслей, которые я попробовал организовать в небольшой манифест разработки.
Манифест продуктовой разработки
1. Core-функционал не будет меняться
Если продукт нашел свой Product Market Fit - то сложно представить, что его core-функционал будет серъезно меняться. Такое возможно только если PMF не найден. В остальном это, как правило, реинженеринг или доработки по расширению.
Именно поэтому очень важно правильно выделить core-функционал и сделать его максимально хорошо. Дальше он будет только расширяться, чтобы рядом появлялись второстепенные сервисы и проверялись новые гипотезы.
2. Фронтенд точно будет меняться
По моим наблюдениям - единственное, что стабильно меняется у разных продуктов - это его UI. Важно соответствовать ожиданиям пользователя и важно развивать UX. Мысль, что фронтенд может быть полностью переписан, не так уж и плоха. Иногда это даже значительно дешевле и развязывает руки для экспериментов.
3. Аналитика - отдельно
Если ваш сервис переваривает какие-то данные - рано или поздно появится запрос на их выгрузку и визуализацию. Однозначно лучше делегировать эту способность аналитическим инструментам и позаботиться об этом заранее, на этапе проектирования core-функционала. Аналитическая функциональность в сервисах ест много времени на разработку, а потом на поддержку. Лучше это время инвестировать в развитие core-функционала и проверку новых гипотез.
4. Инвестируйте в стабильность и удобство Сore-части для пользователя
Пользователь с вами из-за базового функционала. Именно он приносит деньги компании за продукт. Базовый функционал должен быть максимально стабилен и удобен для пользователя. Если эта часть работает не очень - никакими доп. сервисами и плюшками пользователя не удержать.
5. Следите за трендами и конкурентами
При условии наличия стабильной core-части у вас высвобождается достаточно ресурса в пользу проверки гипотез. Вы можете спокойно реализовывать второстепенные сервысы рядом с базовым функционалом. Возможно, какой-то из этих сервисов в будущем станет core-частью.
6. Закрывайте сервисы, которые не можете поддерживать
Если у вас нет ресурса на поддержку второстепенного сервиса, то вероятно он не так уж и важен. Как для вас, так и для пользователя. Не нужно тянуть такие сервисы, они отнимают ваш ресурс, ваше внимание и не приносят большой пользы. В какой-то момент, в будущем, они могут наоборот приносить вред, так как они не развиваются.
Чего я не заметил в LinguaLeo после 7 лет отсутствия - так это каких-то новых сервисов, которые бы плохо работали. Либо их не появлялось, либо они оказались закрыты по итогу.
Вместо выводов
Было довольно любопытно разогнать мысль, как удивление от неизменности одного сервиса за 7 лет превратилось в набор довольно очевидных правил для разработки продукта. В очередной раз убеждаюсь, что стоит уделять внимание как негативным, так и позитивным ощущениям. Так как за ними могут скрываться очень интересные идеи.