UpStarter

+91
с 2022
4 подписчика
29 подписок

Стартап – это только проверка бизнес-гипотез.
Стартапер – энтузиаст, который решил эти бизнес-гипотезы проверить. Все! Только проверка!
Самая частая причина провалов стартапов – это когда стартап проверяет «фантазии» основателей, а не бизнес-гипотезы из жизни.
Бизнес-гуру ставят задачи стартаперам, что они могут «просто придумать гениальную идею», быстро сделать MVP и проверить рынком (Product-Market Fit), но это не так!
У стартапера нет задачи «придумывать» идеи. Задача стартапера – видеть их, когда они появляются вокруг нас. Голова – худший источник для придумывания новых идей, придумывается много, но либо очевидного, либо никому не нужного.
Есть только две одинаково важные мысли о своем стартапе – "я хочу что-то построить" или "я хочу что-то сломать".
Стартап — это не попытка любой ценой пропихнуть на рынок то, что мы придумали. Стартап — это попытка угадать, что рынку нужно. Любой ценой! Даже ценой отказа от идеи, которую мы считаем гениальной, и дела, которое мы начали.
Лучший источник хороших идей – окружающая жизнь, другие люди и ваши интересы.
Пол Грэм говорил:
- Ни Билл Гейтс, ни Марк Цукерберг не знали, насколько огромными станут их компании. Они знали лишь то, что им удалось что-то «нащупать».
- Реальный способ сделать что-то большое — начать с мáлого. И вырастить это.
- Не пытаться определить финальную точку в будущем, думая, как тебе попасть туда.
- Не быть «предсказателем будущего», а быть кем-то, вроде Колумба — тот просто считал, что на западе «что-то есть». И поэтому поплыл туда.
- То есть просто начни с чего-то, что работает (где есть «зацеп»/«тяга», как иногда говорят), с чего-то небольшого… А затем, когда появится возможность, двигайся на свой «запад».
- Иметь в самом начале большие амбиции — плохая идея. Потому что чем они больше, тем больше вероятность того, что ты ошибёшься.
- Популярный образ визионера — это человек с очень точным видением будущего. Но на практике лучше иметь лишь размытое представление о нём.
Из выступления Пола Грэма, сооснователя Y Combinator

1

Протестировать мессенджер MAX в деле пока не удалось, нет знакомых, у кого бы он был установлен. В App Store https://apps.apple.com/app/id6739530834 приложение вообще недоступно. В Google Play https://play.google.com/store/apps/details?id=ru.oneme.app MAX доступен только для пользователей из РФ? Распространение мессенджера MAX явно имеет проблемы, приложению уже много месяцев, а минимального функционала еще нет. Должны быть группы, каналы, поиск, стандартные вещи для современной платформы. Непонятно назначение и целевая аудитория. Это всё ещё мертвый мессенджер.
----
PS. Если нужен хороший анонимный мессенджер без спама и рекламы в каналах, то советую VoxTel Anonymous - https://voxtel.io/

6
1

Базовое изложение книги Эрика Риса для стартаперов?
1.У каждого профессионального предпринимателя/компании есть или должна быть книга рецептов?! (бр-р-р-р)
2.Первое – создать?! (бр-р-р-р)
3.Оказывается, что MVP - это продукт?! (бр-р-р-р, получается, что MVP мерседеса – это велосипед?)
4.Продукт, который будет себя продавать сам?! (бр-р-р-р)
5. Необходимо глубже понять боли клиентов. И, возможно, изменить позиционирование или создать новый продукт, чтобы решить их проблему?! (бр-р-р-р)
—————————
1.Стартап – это дешевый способ проверки гипотез. Если проверка пройдет, то стартап превратится в бизнес, иначе – умрет. Что сработало один раз – больше не сработает никогда! «Книга рецептов» нужна, чтобы так больше не делать. Главный вопрос, который должен будоражить мозг стартапера – это не «что» хотят его потенциальные клиенты, а «почему». Еще можно узнать: Чем люди перестанут пользоваться или что перестанут делать, если начнут пользоваться вашим продуктом? Кого вы вытесняете? Конкретного конкурента? Привычный способ что-то делать?

2.Первое – это продать, а не создать. Найти «голодающую» толпу. Заметить на что люди уже тратят деньги. Найти, что изменилось на рынке, в привычках людей и технологиях, что сделало возможным появление вашего продукта именно сейчас? Прежде, чем начать «создавать» найдите, кто будет покупать. Не знаете, как найти покупателей? А зачем тогда «создавать»?

3.MVP – это не «велосипед вместо мерседеса», а рекламное предложение или «воронка продаж», если так понятнее! Продукт стартапа – это не то что вы «недорого пилите напильником в своем гараже», а что вы уже продаете своим первым покупателям.

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

5. Часто говорят, что стартап должен найти боль клиентов и создать продукт, который эту боль снимает. Да ну ладно, неужели пользователи кнопочных смартфонов чувствовали какую-то боль? Нет. Это Джобс показал им айфон, и они почувствовали боль от того, что у них половину корпуса занимает не экран, а кнопки. Или какую боль снимает айфон 15 для владельца айфона 13? Только ту, что он как лох ходит с тринадцатым айфоном, а настоящие пацаны — с пятнадцатым максом. И так со всем, что становится по-настоящему массовым. В два раза больше пикселей, 16-дюймовый экран вместо 15-дюймового, процессор на 2 гигагерца вместо 1 и т.д. Для людей, снимающих фотографии типа «я и Федя на даче в Подмосковье», или использующих компьютер в качестве печатной машинки — и старое подходило. А тут вдруг оп-па, и мысль — а как я без этого мог обходиться? В общем, перестаньте искать фантомные боли потребителя. Вы рискуете напороться на фантазии, за лекарства от которых никто из них не будет готов платить. Лучше задумайтесь о том, как вы можете создать боль на пустом месте. Стартапы должны создавать «условия для боли», а не лечить боль. Все боли, которые можно было вылечить — уже давно вылечили.

Навеяно рассказом О.Генри «Корабли», в котором мистер Гемстеттер решил продавать башмаки туземцам, потому что они все ходили босыми. Но ему это почему-то (!) не удавалось. Дальше идет его диалог с консулом:
— Но что вы намерены делать? Создать спрос?
— Много вы понимаете в политической экономии, — ответил консул довольно невежливо. — Спроса создать нельзя [Во-во, это даже О.Генри это знал!]. Но можно создать условия, которые вызовут спрос. Вот этим-то я и занят.
А занят он был заказом репейника из Америки, который он потом раскидал по улицам. И туземцы не смогли ходить босиком. И им пришлось купить сандалии.
———————-—
ПС. Попытайтесь не просто переводить :)))

2

Ребята, статья — это полет фантазий автора :))
Мобильные приложения в ecommerce – это попытка натянуть сову на глобус!
Ответьте себе на простой вопрос: «Зачем пользователю нужно скачивать и устанавливать мобильное приложение, если ему просто нужно купить «любое-что-нибудь»?»

2

Другой алгоритм действий даст более точные результаты и совершенно бесплатно:
1. Осуществляем сбор всевозможных запросов по тематике
2. Подаем эти запросы в парсер, который в течении 2-3 рабочих дней периодически (утром, в обед, и вечером) парсит все объявления Яндекс.Директ
3. Строим рейтинги конкурентов по частотности ключей/стоимости ключей/позиции объявления в выдаче и т.д.
В качестве приятного бонуса получаем возможность выбрать лучшие объявления конкурентов, раскидать по ним свои ключи и быстро создать свою РК для Директа :))
ПС. Для выполнения всех действий нужна всего одна бесплатная утилита и никаких платных сервисов :)

2

Спасибо за ваше терпение и ответы! Именно в этом комментарии (для меня) раскрылась суть объектных СУБД. Безусловно – это очень интересные БД, которые могут быть применимы во многих ИС-ах.

1

Спасибо за ликбез :))) Теперь понимаю, что я действительно не понимаю, как работают объектные СУБД. Я ошибочно думал, что - это NoSQL database по типу firebase database, которые хранят данные в JSON – объектах. Еще хуже, что я не представляю себе прикладные задачи, для которых может понадобиться объектная БД, в которой хранится класс Java в том виде, в котором он используется в памяти? Для чего это может быть нужно? В чем сила такого хранения данных? Как такая БД кластеризируется?

«Но если использовать объектно-ориентированный язык программирования, то лучше применять объектную СУБД» - это никак не связано! Сегодня все языки программирования - объектно-ориентированные! И что? Как это связанно с хранением/обновлением данных и построением информационных систем (ИС)?
Объектные СУБД очень «быстрые» только с точки зрения добавления новых записей. Поэтому их удобно использовать, когда нужно быстро «накидывать» туда разношерстные и избыточные данные. Позже, когда дело доходит до четкой структуризации данных, построении индексов/выборок данных из миллиардов записей по составным ключам, то без реляционных БД и языка запросов (типа SQL) ничего у вас не получится :).
Главная проблема всех объектных СУБД — это полное отсутствие транзакций, отсутствие точечных UPDATE/DELETE (пакетные UPDATE/DELETE в некоторых объектных БД есть), ограниченная поддержка синтаксиса JOIN, строгие типы с необходимостью явного приведения, для некоторых операций промежуточные данные должны помещаться в оперативную память, отсутствие полноценного оптимизатора запросов, точечного чтения, присутствие ограничений в реализации большинства функций.
Поэтому, все объектные БД в своем развитии приходят к созданию «ClickHouse» ©Yandex – используют собственный диалект SQL близкий к стандартному, но содержащий различные расширения: массивы и вложенные структуры данных, функции высшего порядка, вероятностные структуры, функции для работы с URI и гео-данными, возможность для работы с внешними key-value хранилищами («словарями»), специализированные агрегатные функции, функциональности для семплирования, приблизительных вычислений, возможность создания хранимых представлений с агрегацией, наполнения таблицы из потока сообщений Apache Kafka и т. д.
———--—
ПС. Основной посыл в вашем посте, «что мол давайте, больше не использовать реляционные БД - айда все в Versant Object Database (VOD)». Это неудачная попытка с вашей стороны создать несуществующий спрос на слишком нишевый продукт (VOD), который по факту никому не нужен. Уверяю вас, что ни один здравомыслящий архитектор ПО не будет рекомендовать VOD для построения своих ИС, тем более взамен реляционных БД.

1