Сегодня вечером наконец разослал бета версию своего продукта. И решил, что пришло таки время выложить/упорядочить свои мысли по поводу создания собственного продукта.
Сейчас коротенько пробегусь по ним, а дальше может выложу рассусоленные детальные описания (если что-то потребует большей детализации).
По каждому пункту я указал свои ошибки (который, ой как хотелось бы не совершать).
1. Опыт работы над продуктом в наемном виде не равен опыту создания своего продукта.
В целом, в момент наемной работы гораздо меньше чувствуется обратная связь. С одной стороны принимаешь меньше решений, с другой стороны видишь меньше информации, с третьей стороны плохие решения не бьют по карману.
Когда я начинал работу над продуктом, то я думал, что я знаю достаточно много о продуктопроизводстве (так как последние 4 года работал в продуктовых компаниях) и наступлю на меньшее (чем оказалось) количество грабель.
2. Всегда нужно иметь ПОЛНЫЙ список задач, который нужно сделать до выпуска. И когда я говорю ПОЛНЫЙ, я таки имею в виду ПОЛНЫЙ.
Как только, вы вспоминаете, что вам нужно крепко прикрутить пымпочку A к фитюле Б и что без этого ничего не будет работать, то это обязательно вносить в список.
Хотя я и работал по какому-то упрощенному Scrum процессу, записывая дела, но все равно, по приближению к release, я начал обнаруживать, что 20% оставшихся
задач таки хотят поесть 80% времени, так как выплывают разные отложенные, забытые или незапланированные задачи.
3. Нужно все делать Just In Time.
Когда работаешь над своим продуктом, то вероятнее всего количество ресурсов очень ограниченно. Нужно делать всего самое важное и только тогда, когда оно таки уже нужно.
То есть, с одной стороны, нельзя (точнее можно, но не выгодно) тратить два месяца на написание супер-пупер расширяемой архитектуры, которая дай бог будет использована к версии 3.0. C другой стороны нельзя и откладывать на потом решение важных проблем, так как их таки придется решать до выпуска продукта.
Наиболее важно это относительно качества. Очень сложно балансировать между бесконечным вылизыванием кода и тем, чтобы просто набросать код кое-как для получения еле работающей функциональности.
По этому пункту, я успел профукать момент, когда качество в продукте упало и потом его пришлось сцепив зубы вытаскивать по выходных назад.
4. Выбор идеи для продукта
Если вы надеетесь получить инвестиции (или вложить много своих денег/времени), то вы можете работать только над большими идеями (либо которая должна собрать по $100 от миллиона людей, либо $1M от 100 компаний). Под маленькую идею вы не получите инвестиций, а свои деньги/время только потратите.
Если вы собираетесь потихоньку раскручивать продукт сами не беря денег у других и не вбухивая свои, то вы можете начинать только с маленьких идей ($20 долларов от 500 человек). На большую идею у вас просто не хватит времени и денег.
Этот пункт спорный… Но, мне кажется что большинства компаний так оно и будет работать.
Я выбрал не слишком удачный вариант. Идея слишком мала, чтобы в нее кто-то вложился, но слишком большая, для того, чтобы первую версию можно было сделать быстро.
5. Размеры релиза
Я бы рекомендовал до начала работы над продуктом делать релиз N0. Внутри этого релиза вы должны сделать все, чтобы доставить Hello World макет вашего проекта от вашего рабочего компьютера покупателю в товарном виде.
То есть, вы должны собрать, выложить, иметь документацию, website и т.п.
Это слегка противоречит принципу JIT, но зато очень помогает написанию списка задач.
Внезапно вы обнаружите, что желательно иметь build машину, которая собирает ваши изменения, какие-нибудь скрипты, документацию, веб сайт и т.п. Гораздо лучше обнаружить все эти детали в релизе номер 0, чем получить их незапланированными задачами релиза N1.
Касательно релиза N1. Выберите, ту функциональность которую вы хотите включить в него. Разбейте на три раздела — обязательно, желательно и возможно. Выкиньте желательно и возможно. Теперь разделите обязательно на две части — супер обязательно и просто обязательно. Просто обязательно отложите на релиз 1.5. Над оставшимся супер обязательно — начинайте работать.
6. Заручитесь поддержкой своей жены/мужа/девушки/парня/собаки/рыбок.
Вероятнее всего вам предстоят длинные вечера в которые вместо того, чтобы расслабляться, вы будете матюгаюсь исправлять какие-нибудь левые баги, писать документацию и т.п.
При том, что я достаточно упорный и выдержанный человек, после нескольких месяцев в постоянном режиме «через неделю выпущу бету» хочется послать продукт к чертовой матери.
Понимание и поддержка людей, которые находятся рядом очень-очень помогает.
Я безумно благодарен моей жене, которая с одной стороны активно поддерживает меня в том, что я пытаюсь создать новый бизнес, а с другой стороны гоняет меня в тренажерный зал и на свежий воздух, когда я уж совсем застряю за компом не давая себе передыху.
7. Используйте Open Source
Сейчас гигантское количество разного open sourc’а, который можно применять в коммерческих продуктах.
Лучше две недели потратить, на то, чтобы разобраться с готовым, отдебаженным, работающим, протестированным софтом и потом еще за неделю выкусить из него
готовый хороший кусок, чем за три дня написать похожую функциональность, потом добавить 5 фичи по 3 дня уже реализованных в open source варианте, а потом еще две недели все это дебажить, тестировать и доводить до ума.
Вот тут я лажанулся очень серьезно. Недавно нашел open source проект, который позволил бы мне сократить где-то количество собственно писанного кода в раза два и думаю сократил бы время разработки на пару месяцев.
8. Время на НЕ разработку
Последнее, что хочу сказать в этой статье, что не бойтесь тратить время на НЕ разработку (маркетинг, поиск open source продуктов, поиск похожих продуктов, их опробование и т.п.) В большинстве случае час потраченный на сторонюю деятельность сокращает на 5 часов разработку.
Полезные мысли. Со всем согласен. Но на практике частенько об этом всём забывается 🙂
А можете поподробней описать что входило в релиз N0 для вашего продукта?
У меня его не было. По подходу к бета тестированию вдруг появляться кучи незапланнированных или плохо запланнированных задач :
— документация
— инсталлер
— пререквизиты в инсталлере
— сборка всего в единое целое
— рассылка писем
и т.п.
Тогда я и придумал эту концепцию.
привет!
нема у меня своего блога, поэтому напишу тут 🙂
1. опыт работы наемным. тут все зависит. если удалось наработать связи, то может очень помочь. другое дело, что мне повезло работать в весьма солидных организациях, с очень качественным циклом разработки. и это был минус, т.к. в своем бизнесе может оказаться модель «сделай как угодня и сейчас» намного лучше продумывания и спецификаций и тестирования. я долго не мог отойти от нее. в общем из-за нее и сорвалась очень важная сделка, которая могла повлиять на дальнейшее развитие. пока мы вылизывали и думали как лучше сделать UI закачик потерял интерес. но там проект был для big enterprise, совсем фигню было делать нельзя
2. список важен что бы понимать чем я занимаюсь сегодня. очень часто бывает что путь не виден если списка нет. что=то пропущенное не так важно, даже иногда и неплохо напропускать всего. а вот понимать что я должен закончить и не делать что=то другое очень важно. мы стараемся ставить цели на неделю.
3. just in time… хм… сидеть и выписывать архтектуру накладно, но тут только зависит от профессиональных качетсв участников. мы забили на спеки и согласование дизайна, просто доверяем друг другу. иногда делаем Код Ревью, но это по желанию
4. -8. а объяеденю все, и хочу большими буквами написать:
разработка часто вторична: сначала поймите как вы это будет продавать! после того как поняли сделайте прототайп и раздайте беплатно. если он будет кривым и малофункциональным никто не обидется. зато вы поймете — есть заходы или нет, есть ли интерес. а самое главное вы поймете как вы ошибались когда поняли «как вы будете продавать». Я все это пишу с точки зрения если вы программист (даже если вы сейчас ПМ). Я был ПМом в не самом маленьком бизнесе (даже не пишу проекте, потому что проектов было 4+, и был в нем и продукт манагером и прожет манагером и даже архитектом). так вот не смотря на весь опыт я понимаю что мне легче сесть доделать фичу, чем понять что бы сделать для продаж.
все выше описанное относится к продажам не для home users. там я пока не работал. наш проект для big enterprise потерпел EPIC FAIL ;), мы сделали маленький проект, который должен был помочь с рекламой первого. но получилось там что этот маленький проект привнес в нашу жизнь активность. но пока не деньги 🙂 (продажи пока смешные).
По поводу 1).
Тут действительно многое зависит от обстоятельств.
Если вы работали в enterprise, наработали связи и собираетесь продавать тем же enterprise с которыми есть связи — то да, таки это полезно. Но полезны именно связи, а не опыт принятия каких-то решений.
В целом я имел в виду, что метод принятия решений при наемной труде и ведение бизнеса — отличается.
2. Я бы сказал, список еще важен для того, чтобы понимать насколько продвинулся и близок к цели. Иначе стандартная ситуация — 20% оставшегося съедает 80% времени.
3. согласен.
4. Безусловно. Самое важное — это продажи. Тут спорить бесполезно. Собственно самые толковые люди, зачастую (пре)продают свой продукт, а потом уже пишут. Чуть менее толковые — делают эту параллельны. Остальные тормозящие (такие как я 🙂 пишут, а потом продают (чаще не продают).
1. опыт принятия решений тоже важен. вообще на эту тему трудно говорить абстрагированно. например если я знаю по опыту что базворд намного полезнее функционала, то это пришло только через опыт. логика совсем другая.
4. это можно сделать если вы уже работаете с кем-то и можете утащить на сторону. с нуля имхо практически невозможно.
кстати, когда читал вашу статью именно пункт про финансирование понравился больше всего. это то над чем я сейчас больше всего думаю. не в плане что нужно получить это финансирование, а в плане того, что это хорошая лакмусовая бумажка. например я продолжаю заниматься своими проектами, но даже близко не вижу возможности покрыть ими мой day job. именно потому что для серьезного проекта b2b нужне проф сейл или связи, а гланое идея, которая реально заработает. а мелкие прокты, которые хоть и генерят активность, но до покрытия моей основной работы ууууууууууууххххх как далеко. причем я понимаю, что мой идеал далеко не facebook или twitter, гугль и прочее. тут проще играть в лотерею, шансы примерно те же. а вот получить компанию, которая будет приносить от 300000 в год пока как-то не видно как….
По поводу 4. Продавать раньше умеют sales — это их основная работа. Естественно для программистов или ПМ’ов — продать до написания — очень малореалистично.
Насчет пункта про финансирование. Спасибо. Я бы сказал, что это чуть ли не основная мысль, которую я вынес за прошлый год работы работы над продуктом.
Единственное, что могу сказать, что мелкие проекты иногда развиваются в более крупные проекты. Хотя конечно, до дохода сопоставимого с работой боюсь, что дотягивают немного.
Исходя из цифры, вы живете в какой-то из развитый стран или Москве?
То, что я читал, что важно, чтобы продукт стабильно приносил порядка 80% от зарплаты, тогда можно на него переходить полностью.
sales это такая мифическая персона :). как правильно Джоел написал в своей «последней» статье — хорошие сейлы не захотят работать с вами, а плохие вам и самому не нужны. у меня много знакомых сейлов, но пока постичь что бы сделать я не могу. вероятно простой бродкаст емейлов помог, но мы пока на это в полной мере не решились. сейчас ищем как сделать так, что бы все склеилось в более полную картину.
вот то, что можно случайно получить крупный проект и есть основная идея на данный момент. у нас у всех кто сейчас работает над проектом весьма неплохие условия на day job, но хочется именно своего :), это основной драйвер.
в общем идей много, времени на реализацию всех не хватает, а главное не понятно где клад. и это почему я написал КАК продавать. например AdWords сейчас съедает 100 в месяц просто так. я думаю его отключить нафиг. т.е. если есть идя можно купить AdWords и редиректить на страничку — coming soon. и посмотреть будет ли выхлоп.
что до где я — в штатах сейчас. 80% это все-таки очень с потолка. сорри :). ведь не понятно будет завтра эти 80% или нет. а так же надо учитывать все бенефиты, а не только з/п. в общем пока от $300000 в год не будет, можно и не дергаться
По поводу сейлов — полностью согласен.
По поводу того, почему хочется своего продукта — сам в той же лодке. Аналогично по поводу времени 😉
80% — это средняя температура по больнице. Ясно, что у каждого своя толерантность к риску, объем бенефитов, вера в продукт и т.п.
Я в северной вирджинии живу, если вдруг ты где-то рядом, можно живьем пересечься — попить чайка/пивка.
Кстати, а что за big enterprise продукт?
И если не секрет, как финансировали разработку?
да секрета нет. система сканирования из браузера для корпораций и больших нагрузок. финансирования не было никакого… все делалось на голом интузиазме больше года в паралель к основной работе. проблема в том, что кастомеру все было нужно, а потом мы затянули и кастомер пропал… надо было с самого начала высылать ему чуть не каждую недею
Понял…
У меня какое-то дежавю. Либо мы уже по этому поводу общались, либо я видел ваших конкурентов. По-моему таки первое.
Удивлен, что такое время выдержали на энтузиазме.
мы до сих пор держимся 🙂
неа, мы точно не говорили на эту тему или вообще об этом с вами. я так несколько раз коменты оставлял (или один раз) до этого и все
забавно.
теперь я точно помню, что я с кем-то общался по поводу продукта со сканирование через броузер. Если я не ошибаюсь, он еще был основан на какой-то разработке EMC.
Если что могу покопаться, может вам имеет смысл с ними пообщаться.
То, что держитесь — молодцы. 🙂
В русском язык принято предложения начинать с большой буквы. Так их легче читать (Это так для затравки).
1. …Будет просто холивар…
2. Цели на неделю или списки задач это конечно хорошо. Пришли обсудили с «покупателем», что ему еще надо и ушли на неделю в подполье. А потом он сбежал (наверное надоело ему за вас планы на год в перед составлять). По этому я сразу за два списка. Список «больших» задач и список задач, которые нужно решить «сейчас».
3. Согласен.
4. Мне понравилась фраза «сначала поймите как вы это будет продавать! после того как поняли сделайте прототип и раздайте бесплатно». Но не об этом. Самое важное не КАК продавать, а ЧТО продавать. Взять хотя бы туже самую тулзу для тестирования. Перед разработкой можно было написать компаниям разрабатывающим ПО и поинтересоваться нужна ли им такая тулза, если нужна то что они от нее ожидают. После чего предложить уведомить их о выпуске (можно еще сказать приблизительное время релиза). И т.д. и т.п. Конечно написать сотне другой по уникальному письму адский труд (зато начать можно в любое время).
4 с хвостиком. Желающих сначала сделать, а потом продать столько, что они не следят за актуальностью своих идей. А потом страдают от «маленьких продаж» (тут хотелось бы передать несколько приветов, но не буду).
…
Предлагаю добавить:
9. Выгода.
Получать выгоду даже там, где её еще нет (ура! Да будет рекурсия).
Как сие сделать: в цели записать «если проект успешен — получаем $$$$$, если проект провалился — получаем что-нибудь интересное»
(да здраствует биз….PS: твиттер маленький сайт был когда-то. И многие стартапы не большие (правда о сомнительные).
Мои 2 cent’а:
>Самое важное не КАК продавать, а ЧТО продавать.
Очень спорный вопрос.
В IT все больше акцент становится на КАК продавать. Можно иметь распрекрасную тулзу для тестирования и печатать объявления в местной газете. Продаж будет ноль.
Можно иметь достаточно посредственную тулзу, но найти выход … ну скажем на правильных
людей в Microsoft, и они пропихнут ее через свои каналы в три десятка крупных контор.
А можно, просто выложить на сайт и ждать пока по google adwords придут люди.
Безусловно. Если взять большинство bootstrap стартапов, то таки приходится еще и делать ЧТО продавать. Для инвестиционного бизнеса зачастую ЧТО продавать решается уже потом.
>Желающих сначала сделать, а потом продать столько, что они не следят за >актуальностью своих идей.
Все таки нужно отличать две категории людей «трепло обыкновенно» и «умелый sales». Первый пытается втюхать что-то, но не имеет не опыта, не связей, не плана. Умелый sales таки имеет все три компонента. У первых вероятность удачи очень близка к нулю, у вторых вероятность удачи достаточно хорошо выше рыночной.
Хм есть примеры не майкрософтских продаж в Microsoft?
А можно сделать это все вместе и вновь не думать о КАК. И заняться позиционированием продукта*. Хотя можно накуриться той же травы, что и Apple и выкладывать самопозиционирующиеся гаджеты.
*Под ЧТО я подразумеваю именно позиционирование, а не «х знает что делать, но надо сначала это продать».
> Хм есть примеры не майкрософтских продаж в Microsoft?
Не понял вопроса.
>под ЧТО я подразумеваю именно позиционирование, а не “х знает что делать, но >надо сначала это продать”.
У нас тогда серьезно расхождение в терминологии.
На вопрос — «ЧТО вы продаете» я отвечаю «продукт для автоматизации тестирования».
На вопрос — «КАК вы продаете или КАК вы монетаризируете» я уже рассказываю о методах продаж.
не понял почему холивар в первом… тема вроде нехоливарная.
что до пункта 2. все зависит от размера, ситуации. если софт заказной, то да, нужно иметь четкий график. если это шаровара на коленке, то нафиг не надо, все равно не получится его придерживаться, а на мозг давить будет.
по пункту 4. плевать ЧТО продавать. если есть канал можно продать все что угодно. Как правильно заметил Виктор, можно иметь идеальную тулу, но никто не купит. по очень многим причинам. например у нас причина была в том, что брать наш продукт в оборот компании не хотели, т.к. боялись «фирмы однодневки». т.е. нам нужна репутация. это один из примеров. я могу привести много.
касательно совета про «написать компаниям разрабатывающим ПО». вот маленький вопрос, вы это делали? да плевать компании в почте хотели на такие вопросы. мне переодически такое приходит, но у меня нет банально времени бесплатно кому-то на что-то отвечать. будет продукт — может быть гляну. хоть это и звучит грубо, но запас времени ограничен весьма. Кстати если вы пишите «предложить уведомить» то это выдает что вы этого не делали :). т.к. кто делал знает, что нельзя предлагать то от чего откажутся. надо ставить ногу в дверь. как у нас мы пытались быть хорошими в начале. присали «мы не будем вас беспокоить бла-бла». Все обещание сделано… второй раз не войти. Зато если не писать (за язык никто не тянет) — можно и понадоедать.
4а. актуальность идей — у нас уже 8000 скачиваний и 2000 бесплатных регистраций. наш бесплатный продукт слишком был хорош в бесплатной версии. никому нафиг не надо было обновляться. самое смешное, что купли в основном те, кто не осилил как получить бесплатную лицензию 🙂
9. фигня все это :). выгода она меряется в $$$, все остальное от лукавого. можно конечно делать себе имя. например вася пупкин софтваре. но для чего? если просто для славы, ну может быть… слава-то какая-то сомнительная.
Насчет пункта 2. Для первого релиза таки нужен большой список задач, которые __НАДО__ сделать. После того, как все зажило, то действительно можно обходится более коротким списком.
Насчет 4а. Ого-го… очень пристойно. Надеюсь версия 2 — более платная?
2. Что случится с вашим продуктом через два года в этом случае? Это будет мотающаяся туда сюда кучка говна. А команда если такая была разбежится (может даже появится несколько таких проектов).
4. Я бы тоже не купил идеальный Hello World. А вот относительно идеальности всего остального можно долго и напряженно спорить, но лучше оставить разработчиков в уверенности что их продукт «идеальный». Насколько вы могли заметить я не про какие «мы не будем вас беспокоить» и не сказал. Да и если знаете что откажут, то писать не стоит (вы ведь так бережете свое время…).
4a. Предлагаю не мерять актуальность числом бесплатных скачиваний вашего продукта. Я не знаю сколько у меня бесплатных скачиваний. Зато видел последствия повышения цены с 0 до 1. Хоть ваш продукт покупали за 0 и он их устраивал, но за 1 они уже не купят («не стоит он того» и т.д.).
9. Согласен. Где-то встречал определение безумия: вы повторяете одно и тоже действие и надеетесь получить другой результат.
Open Source Free to reuse for commercial purposes. В принципе, могут долбануть за нарушение авторских прав и очень сильно (для такого размера копмании).
Долбануть за что?
Если лицензии, которые позволяют использовать код для любых целей. Обычно ограничение только то, что надо упомянуть то, что основано на этом коде.
Пример:
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment (see the following) in the product documentation is required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
коменты к статье — полная херня. 🙂 я бы даже не стал отвечать. но наверное поэтому я и не держу блогов.
а сама статья формулируется тремя словами — «учитесь продавать продукт» 🙂 продавать — это вам не паски лепить.
Не согласен не с первым не со вторым.
Касательно формулировки статьи.
1-3, 5, 7 — учитесь организовывать разработку
4, 8 — учитесь продавать продукт
6 — учитесь балансировать бизнес с другими ценностями
Можно конечно все свести и к одному слову «Учитесь». Оно будет очень правильно и абсолютно бесполезное.
По поводу «час потраченный на сторонюю деятельность сокращает на 5 часов разработку» — очень интересно, откуда взялась именно такая цифра ))) Хотя по сути конечно правильно.
Есть по этому поводу старая байка: тот, кто придумал технологию, получает 1$, тот, кто реализовал её на практике — 10$, а тот, кто сумел это продать — 100$.
Витя, добро пожаловать в клуб!
— Что выделает, когда вам надо закончить книгу?
— Обычно я проклинаю тот день, когда начал ее.
(с) Герберт Уэлс
Список дел, которые «обязательно» нужно сделать, чтобы выпустить продукт, будет пополняться все новыми пунтками. Надо стиснуть зубы, напрячься, и сделать все. Дальше будет немного легче.
PS. если что — я уже дома, звони-пиши.
Хм.. Спасибо, очень интересное руководство, причем для различных областей применения.
А главное — можно его дополнять, расширять, и в результате получится универсальный трактат)…