Как стартапу разработать свой продукт
Сооснователь двух американских стартапов и партнер акселератора Y Combinator Майкл Сайбел рассказал об опыте создания продукта в своих компаниях.
«Многие проблемы, с которыми я сталкивался на ранних этапах развития своих компаний, заключались в том, что у меня не было конкретного плана по выведению продукта. Вместо этого я и мои соучредители много времени тратили на обсуждения, которые часто приводили к спорам.
Со временем я понял, что мало кто говорит о том, как вывести продукт на рынок. И мы придумали собственный процесс:
1. Определились с графиком разработки продукта. Мы трудились над приложением для iOS, которое требовало одобрения Apple, поэтому мы выбрали двухнедельный цикл разработки.
2. Назначили ответственного за продукт. Им был я. Это не означало, что я полностью решал, что делать. Я лишь должен был контролировать весь процесс, чтобы продукт успешно вышел на рынок.
3. Договорились о том, каким будет наш KPI. Ключевыми показателями эффективности компании выбрали контент, привлечение новых пользователей и удержание старых.
4. Ответственный за продукт придумывал тему для каждого цикла разработки продукта на основе KPI. Допустим, это было удержание пользователей. Мы собирали всех людей в компании и устраивали мозговой штурм. Это была единственная официальная встреча, на которой мы сидели столько, сколько потребуется для того, чтобы прийти к конкретным выводам. В начале встречи на большой доске мы начертили три разные категории: новые функции, ошибки и тесты, которые хотели запустить. Затем каждый предлагал свои идеи по тому, как сделать KPI эффективнее. Все идеи выписывали на доске под каждую категорию. Ни одну из них мы не обсуждали.
4. Следующий процесс мы назвали «Легко, средне, сложно». Все должны были отметить степень сложности реализации каждой идеи, выписанной на доске. В основном они оценивались в зависимости от того, сколько времени займет работа: полдня или несколько дней.
5. Закончив с идеями, каждый в команде чувствует себя вовлеченным в процесс разработки. Человек видит идеи своих коллег и оценивает собственную: может чья-то идея лучше моей? А во-вторых отмечает, какие идеи выполнить сложнее, а какие легче. И самое веселое, что, возможно, одно из лучших решений на доске – это «легкая» идея, которую можно осуществить быстро. Таким образом перед вами организованная структура, основанная на фактах, а не на том, что вы думаете верно.
6. Следующий процесс мы назвали «Сначала выбирай сложное». Если вы решите сначала взяться за задачи средней или низкой сложностью, идеи сложного характера отодвинутся на второй план, а потом и вовсе могут сойти на нет. Поэтому мы начинали сначала со сложных, потом переключались на средние, и только после этого переходили на легкие. Их всех выписывали по порядку, к каждой идее прикрепляли ответственного и назначали крайний срок выполнения каждой задачи.
7. Как только мы приходили в конкретным выводам, собрание заканчивалось, и все приступали к работе. Если чья-то идея не поддерживалась, ничего страшного, через две недели мы устраивали следующую встречу. Человек мог подготовить необходимую информацию для того, чтобы доказать, что его идея стоит реализации.
8. Так как мы занимались разработкой мобильных продуктов, нашим последним циклом было тестирование. Проводили мы его всей командой, так как никто из нас не любил этим заниматься. После каждого двухнедельного цикла мы вносили новые вещи для тестирования и обновляли список технических ошибок.
Процесс разработки продукта и его выхода на рынок заканчивался в тот момент, когда мы завершали все тестирования и исправляли ошибки.
Я рекомендую каждому стартапу создать свой цикл работы над продуктом, чтобы не оттягивать его выход на неопределенный срок»
#maliktrip_стартапы #maliktrip_перевод
Сооснователь двух американских стартапов и партнер акселератора Y Combinator Майкл Сайбел рассказал об опыте создания продукта в своих компаниях.
«Многие проблемы, с которыми я сталкивался на ранних этапах развития своих компаний, заключались в том, что у меня не было конкретного плана по выведению продукта. Вместо этого я и мои соучредители много времени тратили на обсуждения, которые часто приводили к спорам.
Со временем я понял, что мало кто говорит о том, как вывести продукт на рынок. И мы придумали собственный процесс:
1. Определились с графиком разработки продукта. Мы трудились над приложением для iOS, которое требовало одобрения Apple, поэтому мы выбрали двухнедельный цикл разработки.
2. Назначили ответственного за продукт. Им был я. Это не означало, что я полностью решал, что делать. Я лишь должен был контролировать весь процесс, чтобы продукт успешно вышел на рынок.
3. Договорились о том, каким будет наш KPI. Ключевыми показателями эффективности компании выбрали контент, привлечение новых пользователей и удержание старых.
4. Ответственный за продукт придумывал тему для каждого цикла разработки продукта на основе KPI. Допустим, это было удержание пользователей. Мы собирали всех людей в компании и устраивали мозговой штурм. Это была единственная официальная встреча, на которой мы сидели столько, сколько потребуется для того, чтобы прийти к конкретным выводам. В начале встречи на большой доске мы начертили три разные категории: новые функции, ошибки и тесты, которые хотели запустить. Затем каждый предлагал свои идеи по тому, как сделать KPI эффективнее. Все идеи выписывали на доске под каждую категорию. Ни одну из них мы не обсуждали.
4. Следующий процесс мы назвали «Легко, средне, сложно». Все должны были отметить степень сложности реализации каждой идеи, выписанной на доске. В основном они оценивались в зависимости от того, сколько времени займет работа: полдня или несколько дней.
5. Закончив с идеями, каждый в команде чувствует себя вовлеченным в процесс разработки. Человек видит идеи своих коллег и оценивает собственную: может чья-то идея лучше моей? А во-вторых отмечает, какие идеи выполнить сложнее, а какие легче. И самое веселое, что, возможно, одно из лучших решений на доске – это «легкая» идея, которую можно осуществить быстро. Таким образом перед вами организованная структура, основанная на фактах, а не на том, что вы думаете верно.
6. Следующий процесс мы назвали «Сначала выбирай сложное». Если вы решите сначала взяться за задачи средней или низкой сложностью, идеи сложного характера отодвинутся на второй план, а потом и вовсе могут сойти на нет. Поэтому мы начинали сначала со сложных, потом переключались на средние, и только после этого переходили на легкие. Их всех выписывали по порядку, к каждой идее прикрепляли ответственного и назначали крайний срок выполнения каждой задачи.
7. Как только мы приходили в конкретным выводам, собрание заканчивалось, и все приступали к работе. Если чья-то идея не поддерживалась, ничего страшного, через две недели мы устраивали следующую встречу. Человек мог подготовить необходимую информацию для того, чтобы доказать, что его идея стоит реализации.
8. Так как мы занимались разработкой мобильных продуктов, нашим последним циклом было тестирование. Проводили мы его всей командой, так как никто из нас не любил этим заниматься. После каждого двухнедельного цикла мы вносили новые вещи для тестирования и обновляли список технических ошибок.
Процесс разработки продукта и его выхода на рынок заканчивался в тот момент, когда мы завершали все тестирования и исправляли ошибки.
Я рекомендую каждому стартапу создать свой цикл работы над продуктом, чтобы не оттягивать его выход на неопределенный срок»
#maliktrip_стартапы #maliktrip_перевод
