Этот стартап превращал мух в еду — пока не погас свет

Еда из мух

Компания Inseco должна была стать успешным примером в производстве белка для насекомых в Африке. Вместо этого, спустя семь лет и после seed раунда в $5,3 млн. , компания закрылась и распродала свои активы.

Agtech cтартап потратил восемь лет и $51,7 млн. на создание гигантских дронов для опрыскивания сельскохозяйственных культур. У них было разрешение Федерального управления гражданской авиации, надёжная технология и несколько летающих прототипов...

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

Знакомо?

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

Послушал интервью с бывшим сотрудником Palantir и понял, что раньше почти ничего не знал об этой компании. Оказывается, это не просто Big Data-компания, а нечто намного интереснее.

Palantir создает решения, которыми пользуются государства, армии и крупнейшие корпорации. Их платформы помогают:

– ловить террористов (по слухам сыграли не последнюю роль в поиске Бен Ладена)
– доставлять вакцины (помогали в борьбе с Covid в США и Великобритании)
– собирать авиалайнеры ( ускорили сборку самолета AirBus A360)
– предотвращать аварии на нефтяных платформах (в клиентах крупнейшие нефтяные компании)
– помогают НАТО и не только в военных конфликтах (кого-то официально поддерживают, кого-то не очень)
-и пр.

У них около 4 тыс. сотрудников, капитализация около 300 млрд.$, причем за последний год выросли более чем в 6 раз!

Широко известно, что рынок найма в техе сегодня заметно охладился по сравнению с 2020–2022 годами. Количество вакансий для инженеров-программистов снизилось во всех крупных регионах, а доля полностью удалённых позиций продолжает постепенно сокращаться. В то же время, по другим метрикам видно, что рынок начинает восстанавливаться — по крайней мере, для инженеров старшего уровня. Об этом говорилось в прошлом месяце в статье "Состояние рынка найма стартапов и scaleup-компаний глазами рекрутеров". Всё это создаёт ситуацию нестабильности и неопределённости, через которую предстоит пройти и кандидатам, и работодателям.

Эта статья — попытка прояснить, как меняются технические собеседования, через призму того, что видят сами инженеры, проходящие интервью. Чтобы разобраться в этом, я обратился к Эвану Кингу и Стефану Маю, сооснователям стартапа по подготовке к интервью — Hello Interview. До запуска своего проекта Эван четыре года работал Staff Engineer в Meta, а Стефан — шесть лет был менеджером инженернов в Amazon и затем старшим менеджером инженернов в Meta. Оба провели сотни собеседований, причём Стефан также выступал в роли нанимающего менеджера. С момента запуска Hello Interview они помогли тысячам инженеров подготовиться к интервью и собрали большой объём информации о текущем состоянии рынка и ожиданиях работодателей.

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

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

OpenAI часто упрекают в недостаточном внимании к продуктовой составляющей. Критикуют, что компания никак не может перестроиться с роли исследовательской лаборатории на полноценную коммерческую структуру.

В то же время Perplexity активно делает акцент именно на продукте. Их CEO в одном из недавних интервью заявил, что ключевое конкурентное преимущество компании заключается именно в тщательной работе над продуктовой частью.

Решил провести небольшой эксперимент и сравнить два похожих инструмента — Deep Research от OpenAI и аналогичную функцию у Perplexity.

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

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

За два десятилетия моей работы в этой сфере я никогда не был так зол на себя за пропущенную историю, как в пятницу, когда Apple объявила, что «более персонализированные функции Siri» в Apple Intelligence, которые должны были появиться в период до WWDC, будут отложены до «следующего года».

Мне следует проверить голову.

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

Как я это пропустил, можно понять двояко.  Во-первых, меня убаюкал послужной список Apple, стабильно выпускающий заранее анонсированные продукты и функции. Их послужной список в этом отношении не был идеальным, но исключения, как правило, были по мелочам. (Никто особенно не требовал от Apple создания коврика для индуктивной зарядки для нескольких устройств, поэтому это никогда не вызывало особых споров. когда AirPower оказался полным провалом.) Во-вторых, я по глупости отвлекся на бренд «Apple Intelligence». Это отличная идея для Apple - объединить свои функции ИИ под общим термином, подобно тому, как куча разрозненных функций, обеспечивающих взаимодействие различных устройств Apple, объединены под зонтиком «Continuity» (непрерывность). Но с технической точки зрения не существует такого понятия, как «Continuity». Это не значит, что внутри Apple существует проект Xcode под названием Continuity.xcodeproj, и весь код, который поддерживает все, от AirDrop до Sidecar, зеркалирования iPhone и совместного использования буфера обмена, весь реализован в одной и той же структуре кода. Это маркетинговый термин, но полезный: он помогает Apple объяснить функции и помогает пользователям понять их.

Вопрос: Как эффективно сочетать культуру дебатов и дискуссий при разработке продукта с быстрым продвижением и доставкой?

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

Некоторые из вас качают головами: «Ни в коем случае, Адам, ни одна компания не попадает в одну из этих двух крайностей». Другие кивают с таким энтузиазмом, что их головы вот-вот оторвутся от шеи.

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

Представьте, что вы умеете отлично запускать вирусные приложения для подростков (у вас это получилось дважды), вы неплохо заработали, стали знаменитым, а потом вас «кинули», как раз в той нише где вы эксперт. Как бы вы поступили? Никита Бир не захотел это оставлять просто так. Его новое детище, Explode, — это не просто стартап, а «месть, замаскированная под приложение». Как он сам это называет: «Explode — это spite app» (то есть приложение из spite — злобы). И всё из-за Snapchat.

Режим основателя — это шутка. Это для слабаков. Вы хотите правду? Режим основателя — это чистое заблуждение, удобная ложь для тех, кто слишком боится идти ва-банк. Хотите повысить уровень? Это Ultra Founder Mode (Ультра-режим основателя), где интенсивность никогда не падает, давление никогда не ослабевает, а оправдания стираются.

Вам не удастся уклониться от суровой истины.

У вас возникнет искушение обвинить мошенников. Вы захотите сказать, что они не понимают, как трудно вести корабль сквозь шторм. Вы почувствуете тягу объяснить, оправдать, кричать, «Они не понимают!» Но вина лежит на хрупких. Вина лежит на тех, кто слишком боится иметь свой вес. Непрекращающийся газлайтинг? Это просто топливо для вашего самосознания и смирения. Никто не может до конца понять, и это не их вина. Вы не для того подписались, чтобы это поняли. Вы подписались, чтобы переопределить мир, пробиться сквозь стены, о существовании которых другие даже не подозревают. Речь идет не о комфорте или подтверждении. Вы здесь не для того, чтобы вас похлопывали по плечу. Вы здесь, чтобы разрушить барьеры и построить то, что никто другой не сможет. Вы владеете своей судьбой.

Посидите спиной к команде 30 минут. Ты ничего не скажешь. Ты не дрогнешь. Вам скажут именно то, что вы не хотите слышать, и вы впитаете в себя каждое грубое слово. Ваш позвоночник натянется, как стальной трос, готовый порваться, и правда обрушится на вас, как разрушительный шар, летящий с 10-го этажа. Только самые безжалостные лидеры могут выдержать такую ​​жару и не сломаться. Задача? Заткнись и слушай. Речь идет не о комфорте. Речь идет о том, чтобы увидеть, сколько чистой честности вы можете выдержать, прежде чем ваше эго разобьется на тысячу осколков.

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

Давайте разберемся, что к чему.

На выходных с семьей побывали в испанском диснейленде парке «Порт Авентура» . Помимо удовольствий и впечатлений, меня, как продакт-менеджера, поразило, как искусно и грамотно здесь продуман каждый аспект для максимальной монетизации и удовлетворения потребностей посетителей. Масштаб продукта тоже впечатляет, такой город в городе с несколькими сотнями работников и тысячами посетителей.

Решил поделиться моими наблюдениями.

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

Делать новые продукты сложно, а делать новые хардверные продукты невероятно сложно. Apple закрыла своё автомобильное направление, Amazon прекратила производство своего смартфона, у Google не получилось с очками... А ведь некоторые компании пытаются делать что-то совсем инновационное.

Это вторая и последняя часть ответа нас двоих Gergely Orosz и Kent Beck:

на статью McKinsey «Да, вы можете измерить продуктивность разработчиков программного обеспечения».

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

«На прошлой неделе McKinsey опубликовала статью под названием «Да, вы можете измерить продуктивность разработчиков программного обеспечения». Эта статья вызвала настоящий переполох в сообществе разработчиков ПО. Кент Бек — инженер-программист и создатель экстремального программирования —написал что «Отчет настолько абсурден и наивен, что нет смысла подробно его критиковать».

Хотя мне не понравилось куда клонит этот отчет, я решил взглянуть на положительную сторону: то, как участие McKinsey сигнализирует о растущей потребности даже в «традиционных» компаниях лучше понимать, как работают команды разработчиков программного обеспечения.

Но что-то было не так. Через несколько часов после публикации этой статьи я уже созванивался с Кентом, поскольку мы пытались определитьточно почему мы оба были разочарованы этим отчетом. Мы почти сразу оказались на одной волне и решили, что можем помочь сообществу разработчиков программного обеспечения, изложив словами то, что мы обсуждали. Ниже приведен наш ответ, написанный мной и Кентом Беком, одним "общим голосом".

Я много раз слышал о том, что ChatGPT галлюцинирует, то есть придумывает то, чего в реальности нет, но никогда с этим не сталкивался. Были какие-то неточности, но я их списывал на неактуальность базы данных или не замечал.
Или как-то попросил его исправить грамматические ошибки, он их исправил, только зачем-то еще и текст в 2 раза сократил.
На днях дочке задали выучить слова. Текст был написан от руки, и ей было трудно читать. Я подумал, что надо бы сделать печатные быквы и распечатать, переписывать не хотелось, решил использовать ChatGPT.

Марти Каган — известный эксперт по продуктовому менеджменту, поделился своим мнением как ИИ изменит продуктовую разработку. В целом у него довольно позитивный взгляд на вещи, и есть несколько рекоменадаций как подготовиться.

Самая популярная в мире CMS (система управления контентом) это WordPress. Почти половина (43%) веб-сайтов в мире управляется с помощью нее, и доля растет ().
Бразильский стартап Deco.cx хочет бросить вызов такому грозному сопернику. В начале года они привлекли раунд в 2,2 млн.$

Деньги планировали потратить на добавление ИИ в свой сервис, и судя по всему уже добавили.

Уверяют, что их продукт увеличивает скорость разработки в 10 раз. Проверить и поверить сложно, возможно какую-то часть SDLC действительно делают делают быстрее, но ведь часто долгий выпуск продукта не связан непосредственно с разработкой.