Сегодня хотел сказать пару слов про инновации.
Есть 2 противоположные точки зрения относительно создания чего-то нового. Точка зрения инноватора и точка зрения инвестора.
На стороне инноватора выступает Генри Форд с цитатой: «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь».
На стороне инвесторов... все инвесторы :) Их позиция - «Если у вас нет конкурентов, значит вы делаете то, что никому не нужно».
Почему они противоположные?
Инвестор не хочет вкладывать в то, что никому не нужно. Подтверждение того, что ваша идея кому-то интересна, это наличие рынка и конкурентов на нем. Инвесторы понимают, что трендсеттинг это очень дорого. Позволить это себе в глобальном масштабе может (мог) только softbank :)
Инноватор хочет... инноваций. Зачем делать то, что делают другие, даже если ты знаешь (думаешь, что знаешь) как сделать это же лучше? Го делать новые крутые штуки, которые никто не делал!
Такая же проблема возникает, когда ты начинаешь разговаривать с потенциальными клиентами. У них есть свой скоуп, в нем есть какие-то проблемы, они их как-то решают.
Им может быть понятно предложение решать их проблемы быстрее-дешевле-надежнее, но они должны осознавать проблему.
Вы спросите - как можно не осознавать проблему, если это проблема? Для меня в свое время это тоже было открытием, поэтому я попробую сэкономить вам немного (на самом деле много) времени. Скорее всего вы меня не послушаете (я бы сам не стал), но это будет поводом потом покряхтеть, что я предупреждал :)
После того, как очередной собеседник ни черта не понимает в том, что ты ему питчишь, у тебя начинают появляться сомнения.
Может быть этой проблемы нет и ты ее выдумал? Да ну не, бред какой-то...
Если ты взрослый и умный, наверное перед тем, как начать что-то делать, ты начнешь кастдевить. Т.е. опрашивать людей - а что же у них болит?
И оказывается, что у них ничего не болит. Ну как ничего... Болит конечно, но не на столько, чтобы тратить какие-то значимые ресурсы на решение.
Вы когда-нибудь пробовали выбрать систему управления проектами? Jira, asana, youtrack, clubhouse, wrike, targetprocess и т.д. и т.п. Мы пробовали. На это было потрачено много ресурсов и в итоге плюнули и решили остановиться на issue в гитлабе. Продолжало у нас после этого болеть? Да. Но заставить нас вернуться к процессу выбора еще раз было практически невозможно. Процессы криво-косо настроили, на это тратилось какое-то количество ручного труда, но это считалось приемлемыми потерями.
Обычно в этот момент приходят истории про дисрапт. Твой продукт должен наносить драматически бОльшее количество пользы, чем та, которая наносится сейчас, чтобы клиент посмотрел в твою сторону.
Есть история про такой продукт fibery.io, который много лет делал один из создателей targetprocess и который должен был дисраптить тему. Я попытался попробовать. Очень интересно, но ничего не понятно...
Но с дисраптом все та же беда - проблема для клиента должна быть очевидной. Была у клиента проблема, которую решал Форд своими автомобилями? Судя по его цитате в начале поста, проблемы не было :) Ну да, лошади, пахнут, надо кормить, они болеют, но процесс налажен. Зачем менять это все на какие-то железки, которые пахнут, им надо заливать топливо, они ломаются и тд? Да и лошадки красивее :) Бегали бы побыстрее, а так норм. Дисраптом в современном понимании была бы телепортация...
Короче, если ты инноватор - кастдевить бестолку, будет только хуже :)
По результатам множества разговоров я сделал такой вывод: я пытаюсь решить сконцентрированную проблему. Ее сконцентрировал лично я и конкретно в том месте, в котором мне это показалось оптимальным.
Мои потенциальные клиенты этого не делают. Напротив, они стараются размазать проблему тонким слоем по всем своим процессам. Или сконцентрировать ее в том месте, где существуют какие-то инструменты для ее решения. Как правило, эти инструменты - ручной труд (дешевый или не очень) и забрасывание деньгами.
Например, в QA дешевле нанять много дешевых ручных тестеров, чем наладить автоматизированное тестирование. А проблемы с тормозами бэкенда можно довольно долго решать апгрейдом сервера.
Оставим за скобками тему насколько это оправдано стратегически и насколько дороже это в итоге обойдется.
Можно привести много примеров из моих разговоров, но я постараюсь сделать выжимку.
Итак, встречайте!
10 кейсов, после которых вы расхотите тратить время на кастдев :)
Disclamer: за платными советами по кастдеву идите к Ивану Замесину. Ниже я выражаю свой дилетантский взгляд на эту тему, основанный на опыте кастдева и поиска пилотных внедрений инновационного иструмента статического анализа SQL-запросов holistic.dev
Пример №1: hand made
Если в компании разные люди пишут приложение и SQL-запросы, возникают проблемы синхронизации результатов их работы. Типы, версионирование и тд. Частично решается тестами, но бОльшая часть автоматизации не поддается. Решение - страдать, колоться и жрать кактус. Никто не любит заниматься этим вручную, но считается, что это необходимое зло и все с ним мирятся. "Это работа программиста, нам за это платят".
Размазали проблему между несколькими разработчиками. Это снизило их мотивацию и замедлило работу. Инструмент - недешевый ручной труд.
Пример №2: cheap staff
Если в компании не пишут чистых SQL-запросов, а используют разного рода ORM, то возникают проблемы с производительностью всего. Решение - купить железо помощнее.
Кажется, что получается сэкономить на разработчиках и сократить time to market, а растущие технический долг и затраты на инфраструктуру - "это неизбежно и так у всех".
Размазали проблему по всему проекту. Инструмент - забрасывание деньгами.
Пример №3: startup (vc will pay)
Совокупность двух предыдущих примеров. Я как-то рассказывал про стартап, где не использовали нормализацию базы потому что join'ы страшные и тормозят, но при этом в базе нет ни одного индекса. Инструмент - недешевый ручной труд + забрасывание деньгами.
Во всех этих случаях нет главного - осознания проблемы. Как говориться, признание проблемы - это 50% ее решения.
У всех есть налаженные процессы, потери на которых приняты как приемлемые.
Почему никто ничего не делает?
Перенастройка процессов может стоить дорого и/или не дать никакого результата.
Ничего не трогай, ничего не меняй (с) анекдот
Кастдевить таких клиентов бестолку. Может сложиться ощущение, что ты делаешь то, что никому не нужно.
Пример №4: look-alike
Есть какая-то осознанная проблема, которая кажется похожей на ту, которую может решить твой продукт.
"О, круто ты придумал! Твой инструмент же расскажет мне каких индексов не хватает?" Это не самая большая из проблем, связанных с базой. Потратив день, можно вручную идентифицировать и устранить 80% проблем, связанных с индексами. Мой инструмент полезен не этим.
"Твой анализатор не ругается на поля в запросе, которых нет. Это не правильно." Это правильно. Это анализатор для DBA. Он не рассчитан, на то, что в него будут прилететь запросы, которые не валидны в run-time. Клиент хочет от инструмента для DBA получить функционал инструмента для разработчиков.
Это не те проблемы, которые ты собирался решать.
Такой кастдев, как мне кажется, так же не принесет особой пользы.
Стоит бросить задуманный функционал и начать решать то, что озвучили? Можно. Но, скорее всего, ты погружен в предметную область гораздо сильнее и у тебя уже есть big picture. Возможно, ты допилишь этот функционал когда-нибудь потом. Возможно, решать эту проблему не надо совсем, потому что это не проблема.
Но если вам одно и тоже сказали 90% опрошенных, и это одно и то же укладывается в концепцию продукта, то, наверное, стоит пересмотреть приоритеты.
Если не укладывается, то это еще ничего не значит. Просто идите дальше.
Пример №5: go disrupt somewhere else
Возможно, что ваш продукт можно использовать не только по прямому назначению. Что, если с его помощью можно улучшать другие продукты?
Мой продукт может добавить очевидной ценности к managed db у облачных провайдеров для того, чтобы провайдеры привлекли в клиенты тех, кто запускает базы на вируалках.
Или, например, прокачать учебные курсы по SQL, добавив новые типы задач, которые раньше невозможно было сделать из-за отсутствия подходящих инструментов.
Но, как мы знаем "Он нам и нах@# не нужен, интернет ваш!". Живут люди спокойно со своими проблемами, бэклогом и роадмепом. А тут появляется какой-то хмырь и рассказывает как космические корабли бороздят (зачеркнуто) учит нас делать наш продукт.
Пример №6: go open source
Найдется какое-то количество людей, которые будут рекомендовать выложить все в опенсорц и будут утверждать что это "отличная модель для твоего бизнеса". Есть предположение, что они сами никогда так не делали.
На днях наткнулся на oss проект, в который вложились YC, c очень оригинальной моделью монетизации. https://supabase.io/docs/pricing - "дайте денег, мы поставим ваш логотип в README". Это как в зоопарках можно встретить таблички: "Этот крокодил поддерживается ЧОП Аллигатор".
Пример №7: where is my profit?
Бизнес хочет цифр. Собеседник хочет знать сколько он получит/сэкономит.
На одном сайте, который торговал инструментом аналитики git-репозиториев был калькулятор. Указываешь количество инженеров, он умножает их на средний кост $100k/y. Потом следовало утверждение, что внедрение их инструмента даст прирост производительности в 27.5%. Итого - 25 разрабов * $100k * 0.275 = $687k в год будет сэкономлено. При стоимости инструмента в $799/m ROI будет равен x71.
Четко и твердо :)
Но, во-первых, далеко не всегда можно этот ROI посчитать, а во-вторых, это скорее всего брехня :)
Например, лицензия на PVS-Studio стоила 400000 рублей (около $6k на тот момент) в год. В абсолютных цифрах это дофига. Но в месяц это $500. Это половина зарплаты джуна. Только вместо джуна вы получаете экспертизу 10 синьоров. Как тут посчитать ROI?
Один дополнительный индекс может увеличить скорость запроса на 2 порядка, что повысит удовлетворенность клиентов, что приведет к росту выручки. Так же это даст возможность сделать дополнительные фичи, которые раньше было сделать нельзя. Как тут посчитать ROI?
Как посчитать ROI от внедрения автотестов? А от написания документации? А от кофемашины в офисе? :) Да, есть исследования, которые говорят, что стоимость бага, обнаруженного в процессе разработки до 400 раз ниже того же самого бага, обнаруженного в проде. Вы верите? Вот именно!
Тут можно только наврать. Fake it till you make it, как говорится.
Пример №8: don't touch me!
Кроме всего этого, вполне возможно, что человек, с которым вы разговариваете, преследует совершенно неочевидные для вас цели. Ему не хочется брать на себя работу и ответственность за сбор размазанной проблемы в одну точку. Он придумает 100500 причин, почему ваш проект плохой и вам стоило бы пойти на завод и не тратить его время.
Пример №9: we will call you back
Скорее всего, человек ни черта не понял, но послать вас ему мешает воспитание или культурный код.
В западной культуре считается нормальным написать человеку followup, когда у вы найдете время переработать message и сделаете какой-то значимый апдейт своего продукта.
Пример №10: incredible amazing awesome!
Этот человек тоже ни черта не понял :) Но он может пропитчить вас кому-то еще, не теряйте с ним контакт.
Специалисты по кастдеву к этому моменту, скорее всего, допивают вторую пачку корвалола. Я же писал disclamer, но его никто не прочитал :)
Давайте еще раз - я выразил свое мнение по поводу кастдева инновационного проекта, полученное в результате множества питчей.
Если вы хотите делать проект на рынке, где уже существует много игроков, то не надо меня слушать. Делайте кастдев, читайте Морейниса, считайте юнит экономику, показывайте трекшен и далее по списку.
Если у вас нет денег на то, чтобы покупать еду пока вы пилите свой проект, то не надо меня слушать. Идите на работу или к vc. Но оказывается, что заниматься привлечением денег это отдельная фуллтайм работа. И ей нужно заниматься в рабочее время. Так что, скорее всего, сразу на работу.
Если вы абсолютно все пилите в одиночку, то не надо меня слушать. Скорее всего у вас рано или поздно поедет кукуха и в голове появится голос, который будет говорить что нужно делать :)
Подведем итог.
Если вы делаете что-то новое, чего еще никто не делал, вы просто потратите время на мнение людей inside the box. Их много и они обязательно повлияют на ваш продукт и своими советами сделают его хуже.
Из всех моих многочисленных питчей, только одна беседа принесла очевидную пользу.
Большинство людей, которым вы будете это все питчить - не ваша ЦА. Не расстраивайтесь, это нормально :)
"Но ты же пивотнулся", - заметит постоянный читатель. Да, пивотнулся. Но в пределах концепции. Я поменял фокус и ЦА. Общая идея осталась прежней.
Стоит подготовить несколько вариантов питчей, формулируя message для разных аудиторий. From the scratch вы этого не сделаете, но в процессе общения, скорее всего все станет понятно. Основное правило - питчите почаще. Чем больше вы будете рассказывать о своем проекте другим людям, тем лучше сами его поймете :)
Знаете сколько раз мы меняли тексты на сайте? А сколько раз я переделывал питч?...
"Ты вот дофига умный, а какой результат?"
Выраженный в цифрах - никакой :)
Я в процессе и все только начинается.
"Что делать-то?"
Я не знаю :) Моя стратегия - делать продукт и делать его максимально хорошо.
Кто был прав покажет время :)
Больше на канале в телеграме: https://t.me/nosingularity