Connect with us

Статьи

Почему авторы Trello не смогли создать бизнес на 1 миллиард долларов

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

Анна Гуляева

Опубликовано

/

     
     

Почему инновационный и популярный продукт не принес своим создателям максимально возможную прибыль? Создатель нескольких SaaS-компаний Хитен Шах разобрал ошибки, которые допустили создатели Trello.

В 2011 Джоэл Спольски на TechCrunch Disrupt запустил новый продукт компании Fog Creek под названием Trello. Он был похож на белую доску со стикерами, перенесенную в веб-браузер и в приложение для iPhone. Вместо того, чтобы перемещать физические заметки на доске, вы могли перетаскивать карточки на доске в браузере.

За считанные дни Trello удалось привлечь внимание 131 тысячи человек. 22% из этих людей зарегистрировались. Trello хотели создать простой и полезный продукт, который сможет использовать кто угодно. Он распространялся, как лесной пожар.

Поэтому Trello в итоге пришлось продать Atlassian за $425 миллионов, хотя он и мог стать следующим SaaS-приложением на миллиард долларов.

Спустя пару месяцев после запуска Спольски написал пост, в котором предвидел самую большую сложность:

Создать большой горизонтальный продукт, полезный в любой сфере жизни, почти невозможно. Вы не можете заработать очень много, потому что соревнуетесь с другими горизонтальными продуктами, которые могут покрыть расходы на разработку при помощи огромного числа пользователей. Это высокий риск, но и высокая награда.

В точности следуя этому, в Trello успешно создали горизонтальный продукт, быстро набравший миллионы пользователей и инвестиции в сотни миллионов долларов. Однако в Trello так и не справились с привлечением платящих клиентов.

Они были сфокусированы на первоначальном создании пользовательской базы и лишь последующей монетизации, но когда взглянули на своих подписчиков, было уже поздно – момент был упущен. Хотя Trello является идеальным дополнением к набору инструментов для повышения производительности от Atlassian, это затрудняет дальнейшее развитие продукта.

Давайте поговорим о возможности, которую упустил Trello, и что следовало сделать вместо этого.

Почему Trello нужно было заниматься продажами

Trello был создан вокруг концепции канбан-доски. Канбан – это система для гибкого производства, которую Toyota сделали популярной в 1940-х. Идея заключалась в том, что каждая карточка представляла собой продукт, его часть или инвентарь. Когда карточку перемещали на доске, это означало, что что-то физически переместили от поставщика на фабрику.

На практике это выглядело так:

Когда Trello только появился, технически было действительно сложно создать браузерную доску, в которой вы сможете совместно перемещать карточки в разные списки. Многие SaaS-инструменты того времени были большими базами данных с визуальным интерфейсом, натянутым поверх (например, Salesforce). Создавалсь архитектура, в которой вы структурируете данные по лидам, клиентам или задачам.

В Trello подошли к этому с противоположного направления. Видение продукта заключалось в том, чтобы все сломать и опираться на визуальную идею карточек на досках. Чтобы это сделать, Trello внедрили инновационный стек. Одностраничное веб-приложение в основном работало как оболочка, которая вытаскивала все данные с серверов менее чем за полсекунды и менее чем за 250 килобайт. После первого посещения они кэшировали страницу, чтобы Trello загружалась еще быстрее.

Они построили свои сервера на Node и использовали MongoDB для хранения данных, поэтому веб-приложение загружалось очень быстро. Каждый раз, когда пользователь перемещал карточку в новый список или менял запись на доске, Trello отправлял эти данные в другие браузеры, чтобы доска открывалась почти мгновенно.

Архитектура Trello

Результат был удивительно простым. Вы делали изменение на доске, и оно отображалось во всех других местах.

Все это было новым в то время и привлекло к Trello много внимания. Но в 2016 подобное красивое и отзывчивое  приложение стало не так сложно создать, и канбан-доски начали появляться везде:

GitHub представили канбан-доски в сентябре 2016:

Asana анонсировали канбан-доски в ноябре 2016:

Airtable запустили канбан-доски в ноябре 2016:

Джастин Розенштейн, сооснователь одного из крупнейших конкурентов Trello, Asana, сказал: “Мы определенно отдаем должное Trello. Этот продукт первым создал подобное видение”. Но Джастин непреклонен в вопросе копирования функции досок Trello: “Мы рассматриваем Trello как функцию, а не как продукт”.

Trello мог стать миллиардным бизнесом, если бы он был ”системой записи”, то есть, единственным надежным источником информации для компаний. Представьте, что вы можете использовать Trello не только чтобы отслеживать вашу маркетинговую воронку, но и чтобы перемещать информацию с маркетинговой доски в пайплайн продаж и план развития продукта. Вместо отдельной доски для каждой команды у вас могла бы быть большая доска для всей компании.

Trello не стал такой системой записей. Он стал сильной визуальной метафорой, которую скопировали его конкуренты. Канбан-доска оказалась отличной UX-функцией, но не защищенной от копирования.

В SaaS побеждает не первая компания и не компания с лучшей идеей. Побеждают те, кто постепенно лучше решают проблему. Когда вы создаете популярную или успешную функцию, конкуренты её крадут.

В Trello могли бы удвоить свою прибыль, переведя индивидуальных клиентов на платную подписку. Они могли сосредоточиться на создании функций для малого и среднего бизнеса. Или они могли расшириться на предприятия. Всё это привело бы к повышению оценочной стоимости компании до более чем миллиарда долларов. Давайте обсудим, что Trello могли бы сделать на каждом шаге, начиная с индивидуальных пользователей.

1. Trello недостаточно быстро монетизировался

При помощи freemium модели возможно построить нацеленную на пользователей миллиардную компанию. В 2013, спустя шесть лет после запуска, Dropbox был оценен в 8 миллиардов долларов, их доход – 200 миллионов долларов, а количество пользователей – 200 миллионов человек. Это было даже до того, как Dropbox запустил тариф для бизнеса – доход компания преимущественно получала от продажи пользователям месячной подписки за 10 долларов.

Спустя три года после запуска рост количества пользователей Trello обещал превысить уровень Dropbox: в 2015 году у Trello было 10 миллионов пользователей (через три года после запуска у Dropbox было четыре миллиона клиентов). Но Trello было гораздо сложнее переводить неплатящих пользователей на свой план “Trello Gold”.

Запуск Trello Gold в 2013 был освещен этим постом в блоге, которые выделил три причины, по которые пользователю следует платить 5 долларов в месяц за Trello:

  • Настраиваемый фон доски
  • Ограничение в 250 МБ для файлов, прикрепленных к карточке (против 10 МБ в бесплатном плане)
  • Стикеры и кастомные эмодзи

Хотя все любят эмодзи, это не очень хорошая причина тратить деньги на приложение. Бесплатный тариф Dropbox предоставляет 2 ГБ пространства. Платный тариф предоставляет 1 ТБ, что в 50 раз больше бесплатной версии.

Определить ценностное предложение Trello было сложно, потому что они должны были ещё в начале понять, за какие функции захотят платить индивидуальные пользователи.

Решение: Изучить кейсы freemium-модели

В самом начале в Trello решили создавать горизонтальный freemium-продукт, который будет использовать каждый, а о монетизации подумать попозже. Вместо этого им следовало погрузиться в кейсы с самого начала, чтобы понять, почему люди регистрируются, для чего им нужен продукт и за что они будут готовы платить.

Если у вас есть продукт с множеством возможных применений, посмотрите сначала все кейсы его использования:

  • Существует ли у вас конкурент, который может делать то же самое или уже делает это сейчас?
  • Каков потенциальный доход этого варианта?

Исследуя свою клиентскую базу и пользователей вашего конкурента, вы можете выделить кейсы с наибольшей прибылью за время жизни пользователя.

Предположим, что Trello обнаружил, что в его пользовательской базе юристы, риэлторы и дизайнеры принесут потенциально самую большую прибыль. Они могли бы узнать, что дизайнеры хотят доступ к календарю с доски, а юристы хотят доски с режимом только для чтения, которыми они смогут поделиться с клиентами.

Эти функции Trello включили в свой план для бизнеса, но не подчеркнули их в маркетинге, потому что хотели охватить более глобальные вещи. Вместо этого Trello могли бы создать отдельные лендинги для того, чтобы перенаправлять пользователей без подписки на специфические кейсы.

Когда у вас есть обширный продукт, особенно важно рассмотреть индивидуальные варианты его применения, потому что это позволит вам создавать особые функции для этих вертикалей Если вы не хотите строить свой бизнес на freemium-модели, вы можете подняться выше и нацелиться на малый и средний бизнес (SMB).

2. Trello не стал незаменимым для SMB

Даже без доходного B2C-бизнеса Trello могли стать SaaS-инструментом для работы компаний, закрепившись на SMB-рынке. Проблема заключалась в том, что Trello не доказал свою незаменимость в качестве инструмента для управления рабочими процессами, чтобы оправдать свою стоимость перед компаниями.

В 2013 Trello запустил первый план Business Class для малого и среднего бизнеса. Сначала они установили цену в 200 долларов в год для организации, прежде чем перейти к более традиционной модели ценообразования SaaS за рабочее место.

Trello Business Class стоил 10 долларов за пользователя (плата взималась раз в год), и за эти деньги вы получали:

  • Безграничную интеграцию досок
  • Дополнительные функции совместной работы
  • Режим “только для чтения” и настройки приватности

Когда Дэвид Кэнсел, со-основатель Drift, упомянул годовую стоимость Trello в своей презентации, вся команда была шокирована – цена составила 1700 долларов. Как говорит Дэвид: “Только несколько людей используют Trello ежедневно. Однако мы платим за количество подключенных людей. Очевидно, существует разрыв между ценой, которую мы платим, и пользой, которую мы получаем”. Дэвид затем перевел свою команду обратно на бесплатный план.

В статье на Forbes CEO Trello Майкл Прайор сказал: “Я не хочу, чтобы люди проводили по десять часов в Trello ежедневно, мы не продаем рекламу и не хотим получать больше вашего времени, как это делают социальные платформы”.

Это нормально. Когда вы берете плату по количеству пользователей, вам не нужно оптимизировать свой продукт, чтобы эти пользователи заходили в приложение чаще. Но вам нужно найти способ продемонстрировать свою ценность компании.

Что следовало сделать Trello?

Решение: Создать лучшую интеграцию для SMB

Trello могли бы создать более нужный продукт, сильнее интегрировав его с другими инструментами, чтобы команды просто не могли его заменить.

Представьте возможность открывать и закрывать GitHub Issues прямо внутри Trello. Представьте, что все ваши лиды из Salesforce автоматически открываются или закрываются в Trello. Trello мог бы стать доской управления всеми остальными инструментами компании, что было бы очень ценно.

Вместо этого главные функции Trello были скопированы. Представителю GitHub задали вопрос о создании досок для визуального управления вопросами, на что он сказал: “Все ожидали этой функции и спрашивали, почему у нас её не было”. Поэтому GitHub создали доски.

Если вы создаете подобное горизонтальное SaaS-приложение, разделите своих пользователей по интеграциям:

  • Какие API используют люди?
  • Сколько данных входит в продукт и выходит из него?

Это дает ценный взгляд на другие типы использования вашего продукта. Если много данных уходит из вашего продукта в другой, это значит, что конкуренция накаляется. Создавая лучшую интеграцию и новые функции, вы можете предотвратить попадание конкурента на вашу территорию.

На рынке SaaS-приложений для малого и среднего бизнеса очень большая конкуренция, и компаниям все проще перейти с одного решения на другое. Вы можете либо перехитрить конкурентов, либо расширить свой продукт для больших корпораций.

3. Trello не подходил для предприятий

Смена фокуса на рынок предприятий – доказанная модель для SaaS. Slack сделал это, запустив Enterprise Grid. Trello могли бы построить прибыльный бизнес таким же образом, быстро переключившись на рынок предприятий.

Менее чем через год после запуска стратегии корпоративных продаж, ежегодные платежи (ARR) достигли отметки в 10 миллионов долларов. В своем интервью вице-президент Trello по продажам Кристен Хабахт сказала, что Trello следует достаточно простой стратегии корпоративных продаж:

«Наша команда по работе с предприятиями рассматривает [клиентов], у которых действительно много пользователей Trello. Большая часть нашей стратегии исходящих продаж – это просто связаться с этими компаниями и сказать: У вас более 2 000 человек пользуются Trello, с кем мы можем поговорить об этом?»

10 миллионов повторяемых платежей – это не мало. Проблема со стратегией Trello заключалась в том, что она опиралась только на то, что люди в компании уже использовали Trello. Команды продаж, маркетинга и развития продукта могли использовать массу разных досок. Но сложнее было бы организовать всю компанию вокруг Trello.

Решение: Стать системой хранения данных для предприятия

Trello должны были задать такой вопрос: “Как нам интегрироваться с системами, которые используют большие компании, и стать незаменимой частью рабочего процесса?”.

Один из способов – стратегия Slack. С ростом компании они пытались распространиться от индивидуальных разработчиков к командам, а от команд к компаниям. Slack обнаружил здесь проблему, потому что, в отличие от инструмента продаж или маркетинговой аналитики, почти каждый человек в команде мог наложить вето на инструмент повышения продуктивности. Поэтому Slack провел шесть месяцев в приватном бета-тестировании, изучая свою клиентскую базу и рассказывая им о необходимости в инструменте внутренней коммуникации. Они оптимизировали процесс онбординга вокруг метрики в 2000 отправленных внутри организации сообщений. Сегодня 93% этих компаний продолжают использовать Slack.

Видение, стоящее за корпоративным продуктом Slack, позволяет организациям создавать “структуры” при помощи Slack. Функциональность приложения для предприятия отличается пользовательского. Команды в компании могут организовываться в “рабочие пространства” и формировать подразделения в соответствии со структурой организации. В Slack пытались понять, как и почему продукт распространяется от маленьких команд к отделам и целым организациям, и поэтому они смогли выделить ключевые проблемы предприятий и решить их в Enterprise Grid.

Большие компании любят гибкость и конфигурируемость. Как и Slack, Trello мог занять нишу в предприятии, позволяя ему настраивать Trello согласно структуре организации. Преимущество Trello заключается в том, что это действительно многосторонний и простой в использовании продукт. Предоставив компании возможность создавать структуру подразделений, Trello мог бы выступить соединительной тканью между частями организации.

Поздравляю, Trello

Смотреть в прошлое, конечно, проще. Хотя большая часть статьи посвящена упущенной возможности Trello, мы не должны забывать, что создание SaaS-бизнеса, оцененного в 425 миллионов долларов, это большое достижение.

Команда Fog Creek заплатила за создание Trello из своего кармана. Приложение стало успешным с момента запуска на TechCrunch Disrupt. За два года Trello приобрел 500 тысяч пользователей, а за четыре года – 4,75 миллиона, и это до привлечения средств инвесторов. Команда создала удивительный продукт, который опередил свое время. Он был простым, изящным и легким в использовании.

В прошлом году я написал такой твит:

Вот такое влияние Trello оказал на SaaS, и вы видите его следы везде: от GitHub до Jira.

Но если вы хотите создать следующее SaaS-приложение на миллиард долларов, вы должны помнить о постоянном развитии своего продукта. Не фокусируйтесь на одной функции, которую могут украсть конкуренты. Вместо этого интегрируйте эту функцию во все другие продукты, чтобы копировать её стало бессмысленно.

Помимо прочего, вы должны понимать своих клиентов с самого начала, потому что так вы будете знать, что внедрить в свой продукт и в каком направлении его развивать. Исследования и усердная работа – это единственный способ сохранять ваш продукт востребованным на рынке.

 

Анна Гуляева
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Разработка

Интересные материалы для разработчика мобильных приложений #190 (13-19 ноября)

Microsoft выпустила несколько интересных инструментов для мобильных и ML разработчиков, Apple написала как определяет лица, Google как работает смешанная стабилизация в новых Pixel, а разработчики Shadow Fight 3 о том, как они делали новую версию игры. Все это и многое-многое другое в нашей еженедельной подборке.

Леонид Боголюбов

Опубликовано

/

Сжимаем несжимаемое – как уменьшить дистрибутив мобильного приложения

В рамках этой статьи мы расскажем, с помощью каких приемов мы смогли уложиться в это ограничение на проекте Gardenscapes для платформы iOS. Статья касается в основном мобильных игр, но методы сжатия универсальны и могут пригодиться для любых проектов с тяжелой графикой.

Ключевые анонсы Connect(); 2017

В Нью-Йорке в эти дни проходит ежегодная конференция Microsoft Connect 2017. На ней уже анонсировали множество обновлений существующих продуктов и большое количество новых инструментов.

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 Устройства, IoT, AI

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Статьи

Применение инженерного подхода к собеседованиям

Многие технологические компании не применяют принципы разработки и улучшения программ для своих внутренних процессов, в частности для процесса найма новых сотрудников. Как понять, что компания стремится нанять того, кто им действительно нужен? Просто задайте рекрутеру два вопроса.

Анна Гуляева

Опубликовано

/

В последнее время я много собеседовался на позицию разработчика, и на каждом интервью я задавал два вопроса, на которые не всегда получал правильные ответы:

  1. Какова ваша цель при проведении собеседования?
  2. Как вы оцениваете достижение этой цели?

Какова ваша цель при проведении собеседования?

От некоторых рекрутеров я слышал фразу “Хм, я не совсем знаю, кого мы ищем”, но обычно многие делятся на такие категории:

  1. Найти лучшего человека.
  2. Понять, подойдет ли кандидат для компании.
  3. Оценить, как хорошо кандидат сможет справляться с той работой, на которую он хочет попасть (это довольно редкий ответ).

Менее 10% компаний сказали, что их процесс собеседования создан, чтобы оценить, насколько эффективно человек будет справляться с работой, на которую хочет устроиться. Найм “лучших” и “подходящих” людей кажется мне нелепой стратегией, основанной на предрассудках рекрутера, а не на способностях кандидата.

Если вы считаете оценку способностей кандидата к работе идеалом для собеседования, то это показывает в целом неправильное положение дел с интервью в технологических компаниях. У меня никогда не было интервью, на которых пытались бы оценить мою способность работать в команде или расставлять задачи по приоритету, хотя оба этих навыка более важны, чем способность решать анаграммы.

Как вы оцениваете достижение цели?

Большинство компаний отвечают, что не производят оценку. Если вы оптимизируете программу, и вашим показателем успеха является “Не знаю, я что-то изменил, и оно стало работать лучше”, то вас высмеют. Но мы применяем эту тактику к процессу собеседования. Хотя люди и говорят, что команда является самой важной частью стартапа, большинство компаний поверхностно относятся к процессу найма и не применяют инженерный подход.

Первым шагом должна быть оценка ваших текущих сотрудников. Ваши лучшие сотрудники показали себя лучше всего на собеседовании? Если нет, то почему? Многие компании хранят данные о собеседовании и проводят обзоры продуктивности, но немногие собирают эти данные воедино, чтобы улучшить процесс найма сотрудников.

Это лучше, чем ничего, но есть и вторая часть уравнения. Что насчет людей, которых вы не нанимаете? Люди часто говорят, что менее рискованно отвергнуть хорошего кандидата, чем нанять плохого, но я думаю, что это бессмысленно. Я постоянно слышу, что лучшие компании жаждут талантливых разработчиков и что на рынке труда их сложно найти, но те же самые компании отвергают множество людей, потому что они не там учились или они не так быстро решили тестовое задание. Даже если вы думаете, что менее рискованно сократить (и так уже маленький) пул людей, которых вы нанимаете, чем нанять неправильного человека, вам стоит быть уверенными, что вы ищете среди правильной группы людей.

Это действительно сложная проблема: если бы у вас была информация, которая бы изменила ваше мнение о кандидате, вы бы уже наняли этого человека. Несмотря на все это, проблему можно отчасти решить:

Проведите ваше собеседование на существующих сотрудниках

Если вы хотите изменить свой процесс собеседований, проведите его на своих текущих сотрудниках. Если кто-то его провалит, спросите себя, стоит ли уволить этого человека. Ответом, скорее всего, будет нет.

Составьте “набор для оценки”

Другим подходом к определению работоспособности вашей существующей стратегии может стать более глубокий взгляд на некоторых отвергнутых кандидатов, который поможет вам понять, был ли отказ этим людям вашим верным решением.

У этого подхода есть несколько проблем:

  1. Он необъективен к людям, у которых нет GitHub/Twitter/блога или другого присутствия онлайн.
  2. Существует много кандидатов, которые не умеют программировать, поэтому нахождение проблем в процессе собеседования может занять время.

Несмотря на эти проблемы, я думаю, что это может стать хорошей стратегией для некоторых компаний, особенно если у вас сравнительно небольшое число кандидатов.

Это вполне осуществимо для личных интервью. Сложнее применить эту стратегию к резюме, так как существует много неквалифицированных кандидатов, но и там, я думаю, этот подход может быть полезен.

Заключение

Многие компании будто слепнут, когда дело доходит до процесса собеседования. Я обнаружил, что часто HR-менеджеры не знают, кого ищут при помощи своих процессов, и мало кто пытается изменить свой подход. Среди компаний, пытающихся оценить свои процессы собеседования, многие фокусируются на методах, подтверждающих пригодность кандидатов, а не изменить интервью, чтобы дать шанс талантливым кандидатам, которые обычно не проходят собеседование.

Если вы сейчас проходите собеседования, я советую вам задать эти вопросы в компаниях. Это действительно может дать вам много полезной информации.

Анна Гуляева
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

Студия AppCraft рассказала нам, стоит ли патентовать идею мобильного приложения, а если нет, то как лучше подойти к развитию своего продукта.

AppCraft

Опубликовано

/

Автор:

Многие начинающие предприниматели, придумавшие бизнес идею в области мобильных приложений, первым делом ищут возможности получить патент на изобретение. Замысел понятен – сразу после старта любой желающим может обойти на повороте, воспользовавшись новым видением и потенциалом.

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

Поэтому в случае с мобильными приложениями, как правило, защищается не сам продукт, а общая идея функционирования сервиса, отражающая некоторую новизну подхода к решению той или иной задачи. Запатентовать код тоже можно, но только в некоторых юрисдикциях, например, в США или Южной Корее.

Это долго и дорого

Получение патента на мобильное приложение отнимает драгоценное время, которое на старте продукта лучше потратить на проверку гипотезы о работающей бизнес модели.

Вам не только нужно найти патентного поверенного, который может взяться за работу по описанию и оформлению вашей идеи, но и заплатить за его услуги, оплатить патентные взносы, переводчика и так далее.

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

Практически всегда желание защитить бизнес возникает на стадии первой идеи. Как только прошло достаточно времени на обдумывание плана, сразу возникает мысль о защите еще будущего предприятия. Желание понятно, однако идея и ее реализация – всегда разные вещи.

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

Как только вы начнете запускать идею, с вероятностью близкой к 100% вам придется если не полностью изменить вашу задумку, то значительно ее переработать. Зачем в этом случае патентовать в самом начале то, от чего в последствие вы сами откажетесь?

Забывается главное

А главное – это скорость проверки гипотез о работающих моделях, сбор фидбека с потенциальных клиентов и реализация MVP. Любой, кто работает на этом же рынке и справляется с этим лучше, опередит вас, несмотря на наличие патента. Потому что, во-первых, он понимает рынок лучше, а во-вторых, открытая им более эффективная модель наверняка не будет совпадать с вашим патентом.

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

Если патент – неэффективный способ защиты бизнеса в самом его начале, то это вовсе не означает, что не нужно принимать вообще никаких оборонительных мер. В силу простоты и дешевизны можно использовать такие способы:

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

Патентовать изобретения важно и нужно, но это совершенно не то, что стоит делать первым делом, когда вы занимаетесь стартапом. Многие компании стали заниматься защитой интеллектуальной собственности только после того, как начали генерировать прибыль.

В самом начале стоит полностью сфокусироваться на самой идее продукта, ее проверке, продумывании виральности и создании MVP, находясь при этом на постоянной, максимально близкой связи с вашими будущими клиентами.

AppCraft
Комментарии Facebook
Продолжить чтение




Календарь

ноябрь

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.