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

Продукт

Продукт != продакшн. Разработчики не создают продукт, они его автоматизируют. Продукт создают те, кто ищут рынок и пробуют выходить на него. Крайне важно знать, что такое продукт, иначе есть риск впустую потратить много времени и денег.

Прежде чем менять продукт (делать pivot по продукту), спросите себя - на каких других сегментах рынка этот продукт может быть восстребован? Проверить продукт на другом сегменте всегда дешевле и быстрее, чем искать другой продукт на том же самом рынке.

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

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

Продажи

Продажи - это самое узкое место в стартапе на этапе problem-solution fit, поэтому CEO лично отвечает за продажи на старте. Если это не так, то есть высокая вероятность зря потратить время и инвестиции.

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

Не надо спешить продавать, если кто-то хочет купить. На ранних стадиях попытка понравиться всем похоронит проект. Лучше кушать слона по частям: выбрать сегмент и сначала сосредоточиться только на нем, а уже потом (желательно после ТБУ) расширяться в другие.

Если мне не удается продать продукт без продукта, то у меня точно проблема с ценностью. MVP в IT-проекте, даже если это только эскизы (прототип), нужен не для того, чтобы облегчить продажи, а для того, чтобы убедиться в том, что я не вру своему клиенту во время продажи.

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

Почему клиент должен купить функционал моего продукта, если на рынке уже есть функционал? Причина только одна - я могу предложить ему альтернативный пользовательский опыт. Покупатель всегда сравнивает моё предложение с каким-то другим способом решения своей задачи. А это значит, что ключевой вопрос в продажах: "Как вы сейчас решаете задачу?". Поэтому мы и начинаем стартап с проблемных интервью, чтобы выявить текущий пользовательский опыт, увидеть (или не увидеть) в нём болевые точки и начать моделировать альтернативу.

Команда

Если вы бизнес-ангел и хотите в IT-стартап, то либо запускайте его сами, либо ищите тех, кто и без вас запускает и пробуйте инвестировать в них. Вариант "нанять CEO" точно не сработает, даже если вы отдадите ему 85%, а 15% оставите себе.

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

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

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

Не стоит искать способы мотивировать людей на работу. Гораздо эффективнее искать и убирать демотиваторы в их работе.

В стартапе на ранней стадии крайне важно использовать scrum-подход. Когда нас двое-трое и мы ещё не нашли problem-solution fit, то безотносительно кто из нас за что отвечает (маркетинг, продажи, продукт), мы должны всё делать вместе. Пока маркетолог ищет лидов для интервью, продавец и продакт ходят вместе с ним и как минимум внимательно смотрят. Когда продавец делает интервью в этих лидов, маркетолог и продакт также как минимум внимательно наблюдают. Когда продакт делает MVP, продавец и маркетолог также внимательно смотрят. Только так можно достичь максимально возможной скорости в стартапе.

Разработка

Изобретать велосипед в IT - это повторять то, что уже кто-то сделал. Не проще ли скопировать? И когда копируем, то лучше Kanban-методом, а не Scrum-фреймворком. Scrum-фреймворк понадобится позже, когда начнется новое (то, чего на рынке ещё нет).

В разработке также важен scrum-подход. Если меня не устраивает time-to-market, то в первую очередь я пробую уменьшить WIP-лимит до единицы и убедительно попрошу команду не отвлекаться, даже если кому-то кажется, что ему нечего делать. Навряд ли команда сможет работать в таком режиме 100% рабочего времени, однако несколько итераций вполне хватит, чтобы расшить большинство узких мест.

Если вы Scrum-мастер, и у вас Scrum-фреймворк никак не заводится, то самое время вспомнить, что Scrum и Agile - не синонимы. Чаще всего бизнесу нужен всё таки Agile, а не Scrum-фреймворк. Попробуйте план Б: Kanban-метод (видео, статья). Если вы всё равно хотите Scrum, то будьте готовы его измерять и продавать.