Создание продуктов — где грань между инженерным творчеством и переклейкой этикеток?

 Публичный пост
8 апреля 2026  558

Disclaimer: Пост написан без генерирования текста через ИИ. Claude Code использовался в качестве “говорящей уточки” - то есть, он давал обратную связь по моим идеям, идеи и текст придумывал я.

Про что это всё вообще?

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

Несмотря на все сомнения, я считаю, что можно. На самом деле, именно так обычно новые продукты и создаются :)

Давайте разберёмся на примерах из моего опыта:

1. Создание категории умного дома в компании EKF

В EKF я 2 года отвечал за продуктовую категорию устройства умного дома. EKF - электротехничкская компания, российский аналог Legrand, ABB и Scheider Electroc. Категория была создана с нуля, до моего прихода умных устройств у компании в ассортименте не было. Через 2 года у компании была линейка из более 40 умных устройств, мобильное приложение EKF Connect для iOS и Android, интеграция со всеми российскими голосовыми ассистентами - Алисой от Яндекса, Марусей от VK, Салютом от Сбера, продажи по категории больше чем на 10 миллионов рублей в месяц.

Из того, что запомнилось - я очень оперативно сделал интеграцию с Салютом от Сбера, в результате в пресс-релизе от Сбера было только 4 партнёра - EKF, Aqara, Elari и Philips Hue.

А что под капотом? Решение от китайской компании Tuya, которая поставляет Wi-Fi и Zigbee чипы, а также облачную платформу и конструктор мобильного приложения, в котором можно поменять все надписи, иконки и картинки. 40 с лишним артикулов в линейке производятся на 16 фабриках в Китае.

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

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

2. Okra Solar, создание Wi-SUN шлюза для электрификации деревень в Нигерии

Компания Okra Solar, где я работаю сейчас. Австралийский стартап с основным офисом в Португалии, делающий B2B решения по солнечной энергетике для Нигерии и Гаити.

Первый продукт, которым я занимался полтора года - IoT-шлюз Beacon, который собирает данные с умных счётчиков по протоколу Wi-SUN и отправляет к нам в облако.

До меня был только прототип продукта - в японский водонепроницаемый корпус запихнули индустриальный 4G роутер от GL.iNet и одноплатный компьютер BeaglePlay с чипом Wi-SUN от Texas Instruments, который не отличался стабильностью и не тянул больше 100 устройств в одной сети.

Я понял, что развивать этот дизайн невозможно, нужно пересобирать продукт. За основу взял китайский одноплатник NanoPi Neo Core, который уже был проверен в похожих решениях. Чип Wi-SUN взял от Silicon Labs, так как знал их качество по опыту работы с Zigbee. Новый корпус нашёл, поискав в интернете китайских производителей уличных 4G роутеров.

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

В итоге - продукт запущен в серийное производство, стоит на 25% дешевле предыдущего прототипа, есть удалённый мониторинг и система обновления прошивки, 300 Wi-SUN устройств в одной сети тоже работают, пока на тестовом стенде, но скоро и в полях проверим.

Можно ли называть это новым продуктом, если в основе - сильно модифицированная плата от Zigbee хаба, который я разрабатывал в EKF, одноплатник, корпус, 4G модем, Wi-Fi чип - от китайских поставщиков, а Wi-SUN чип от американской компании Silicon Labs?

3. Okra Solar, иногда убить продукт бывает полезнее, чем его создать

Второй мой продукт в Okra Solar - сенсор для измерения общего тока, забираемого с батареи, он нужен, так как к одной батарее подключаются несколько домов и нужно видеть, не ворует ли кто-то через левое подключение электричество.

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

Я нашёл на китайском рынке датчик силы тока с интерфейсом CANBUS, который тоже есть в нашем умном счётчике, но этот датчик оказался примерно в 2,5 раза дороже существующего решения.

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

Стоимость по сравнению с существующим устройством увеличилась примерно на 50%, но зато не нужно отдельное устройство производить и отгружать. В итоге получили классическое решение по ТРИЗу - продукт перестал существовать, а функция его выполняется.

Можно ли такое назвать созданием продукта, если продукт в итоге вообще закопали?

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

Мои мысли по этому поводу

Вот три вывода, которые я после этих размышлений сделал для себя:

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

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

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

Обратная связь и дискуссия приветствуется :)

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

  • Насколько часто в вашей практике что-то создаётся с нуля?
  • Как вы принимаете решение, создавать что-то самим или закупать у внешних поставщиков?

P.S. Кстати, в Okra Solar я работаю до конца апреля, если вдруг вам нужен technical product manager, чтобы строить с нуля или развивать существующие продукты - буду рад пообщаться. В целом, хотелось бы остаться где-то ближе к аппаратным продуктам, при этом новые технологии и продукты осваивать я умею, так что готов рассмотреть разные варианты. Вот ссылка на мой комментарий в треде про поиск работы.

Связанные посты
38 комментариев 👇

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

Но именно инженерное творчество, имхо, подразумевает создание решения задачи из примитивов.

Построить без инструкции дом из Lego - инженерная задача.

Купить Барби, Кена, заказать им домик на АлиЭкспресс и продать это всё как один набор - уже не очень.

  Развернуть 1 комментарий

@FEARmeR, спасибо, это именно то, что я хотел услышать :)

Тем не менее, если мы свою печатную плату разрабатывали и отлаживали, может я уже немного дальше этикеток продвинулся? :)

  Развернуть 1 комментарий

@FEARmeR, Кстати, если у тебя есть интересный опыт решения инженерных задач, расскажи, было бы любопытно послушать.

  Развернуть 1 комментарий

@DKvasnikov, как-то раз, мы с коллегой, два инженера были на крайнем севере в командировке. И была у нас задача - доставить упаковку от шести радиостанций (прибор размером с холодильник, ящики из дерева и фанеры) до места утилизации по глубокому снегу.
При помощи инструмента Гордона Фримена ящики были разобраны до состояния плоских деревянных панелей, после чего лучшее, до чего мы с коллегой додумались, было взять по две штуки один спереди, второй сзади и нести в таком виде (они ещё и довольно тяжёлые были). Итого светило нам что-то типа 6*6/2 = 18 рейсов туда-обратно.

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

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

  Развернуть 1 комментарий

@FEARmeR, "менеджер по переклейке этикеток" – вообще нет. Менеджеры по переклейке – это на заводе Интеграл. Здесь вполне нормальная глубина проработки, да, вполне себе engineering. Не хочется скатываться до абсолютизма "и язык программирования свой не написал, а мог!" и "чипы не сделал, а мог!"

  Развернуть 1 комментарий

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

По поводу "что-то своё" - мне нравится поинт про ремикс-культуру. Нельзя сказать, что Лиам Хоулетт или Африка Бамбаата не сделали свои треки. Хотя в случае, например, Firestarter там нет ни одного своего звука - рифф Weenie Beenie из Foo Fighers (переигран студийником, но все-таки) и The Breeders - SOS, барабаны взяты у Chemical Brothers и Ten City (а те взяли семпл для трека из фанкового кавера на The Doors), вокальные семплы - Art of Noise. Своё с нуля там только Кит Флинт.

Всё что ты заявил как проекты - такие же ремиксы. Обвязку софта писали вы, нет вопросов. Почему не твоё? Вот вопрос - AirGradient - свой продукт?

В софтверном девелопменте вообще писать своё в 95% случаев - моветон. В датасаенсе подавно. Хз что у вас там у продактов. :)

  Развернуть 1 комментарий

Железнячный продакт - редкий зверь. Очень интересно наблюдать его в естественной среде обитания.

Я больше про софт и такими категориями как инженерное творчество мыслю редко.
Почему? Потому, что если это не что-то из категории deeptech, то в 99% случаев уже есть готовое решение которое позволит нашему маркетплейсу, банку, приложению по подсчёту калорий (подставьте нужное) решить задачу по продаже продукта конкретному клиенту.
И это нормально.

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

Хочется решать инженерные задачи? Возможно, стоит что-то менять, думали делать продукт самому или становиться инженером?

  Развернуть 1 комментарий

@masinskiy, в целом, нет, принципиально менять пока ничего не хочу. В плане написания любого программного кода простые вещи уже можно делать через AI, а делать дизайн печатных плат и сидеть с паяльником, пожалуй, не совсем моё :)

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

  Развернуть 1 комментарий

@DKvasnikov, ну тут только как в старом анекдоте про врача, пенсионера и его соседа: "ну и вы рассказывайте..."

  Развернуть 1 комментарий

@DKvasnikov,

а в реальной жизни чаще нужны комбинации существующих решений

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

  Развернуть 1 комментарий

@DKvasnikov, ага. А если потом выйти на работу к ребятам с Инжнерными Прорывами и Продуктовыми Метриками, а у них те же яйца, вид в профиль.
"А разговоров-то было" (тм)

  Развернуть 1 комментарий

@tr1cks, кстати, в тему удачной комбинации существующих идей: надо таки найти себя и сделать селедку под шубой с сыром Филадельфия вместо мазика, маринованной свеклой, морковкой по-корейски, маринованными и копченными яйцами, дранниками и само собой на красной рыбе

  Развернуть 1 комментарий
Vlad Bokov чиню неонку у ней внутри 8 апреля в 23:51

Продающий пост, конечно, удачи найти новое место ;)

Первый пример (где явное переклеивание ярлыков) ты, видимо, вставил, чтобы разжечь тут? Последние 2 примера нормальные, и я (как человек активно вытесняемый клод-кодом) даже завидую немного :)

Из "трушной" хардвар-разработки почему-то стереотипно вспомнился флиппер, но в чем "creator-ская" разница между твоим шлюзом и флиппером - не очень просто объяснить (флиппер явил новый класс устройств, "wireless-мультитул"?), но я ее чувствую.

  Развернуть 1 комментарий

@razum2um, клод код, кстати, железное тоже, скорее всего сможет отлаживать достаточно скоро

  Развернуть 1 комментарий

@smallkaa, но итерироваться быстро и параллельно в реальном мире сложно, нельзя worktree, нельзя запустить еще gpu on demand чтобы масштабировать на пару часов :)

  Развернуть 1 комментарий

@razum2um, я обычно в железках стараюсь итерироваться параллельно, но с минимальными дополнительными затратами.

Например, когда у нас Beacon был примерно на 70% готовности, я нашёл в Китае поставщика с очень похожим устройством на LoRa. Они поменяли модуль LoRa на Wi-SUN и прислали нам образец и мы его протестировали. Если бы что-то критично пошло не так, уже был резервный поставщик на подхвате.

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

  Развернуть 1 комментарий

@razum2um, LOL, этот текст, кстати, родился из тестового задания на позицию в Flipper :)

Я им в итоге чем-то не подошёл, судя по всему, но пост получился довольно интересный.

  Развернуть 1 комментарий
Evgeniy Petukhov Фулл-стек TypeScript разработчик 8 апреля в 17:57

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

  Развернуть 1 комментарий
Кристина Крицкая Модератор Команда Клуба 8 апреля в 14:26

Дмитрий, привет! Отличный пост, спасибо, что поделился опытом и наблюдениями. Будет здорово, если получится поделить длинные абзацы на поменьше и добавить несколько заголовков. В целом оформление окей, но заголовки и более короткие абзацы сильно упростят читателю задачу. Если нужна помощь с маркдауном (ну вдруг!) - пиши, я помогу :)

  Развернуть 1 комментарий

Кристина, привет!

Большое спасибо за обратную связь, мне самому в исходном оформлении не всё нравилось.

Я побил текст на абзацы поменьше, заголовки добавил просто в виде жирного шрифта. Если в Markdown это можно как-то лучше сделать - подскажи, плиз.

  Развернуть 1 комментарий
Evgeniy Petukhov Фулл-стек TypeScript разработчик 9 апреля в 14:42

😱 Комментарий удален модератором...

  Развернуть 1 комментарий
Pavel Kotlyarov Еще один этот ваш айтишник 10 апреля в 20:52

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

  Развернуть 1 комментарий

@tr1cks, хороший вопрос. Очень мало с этой технологий сталкивался, только на примере подключения ТВ-приставок от МГТС. На мой взгляд - дорого и сама схема преобразования занимает много места.

Насколько я понимаю, powerline - это замена Wi-Fi или Ethernet, но скорость там при этом сильно меньше, чем у последних стандартов Wi-Fi.

При этом Wi-Fi устройства проще в установке и настройке, менее подвержены помехам и Wi-Fi роутер всё равно в каждом доме уже есть.

Так что я не очень представляю ситуацию, когда нам в каком-то месте покрытие Wi-Fi совсем не нужно и мы какие-то устройства подключаем по powerline. Ну а если есть покрытие Wi-Fi - проще им и пользоваться.

  Развернуть 1 комментарий

@DKvasnikov, ааа, ну то есть все датчики на батарейках без подведенного питания (иначе все равно провод тянуть)

  Развернуть 1 комментарий

@tr1cks, да, датчики обычно на батарейках и на протоколах Zigbee, Thread, Z-wave. Wi-Fi тоже может быть, но по сравнению с первыми тремя протоколами быстрее ест батарейку.

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

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

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

  Развернуть 1 комментарий

@DKvasnikov, ну, у меня тут просто идея была как подвести питалово и данные одним кабелем один раз и больше никогда не париться. Видимо нет запроса на такое у рынка

  Развернуть 1 комментарий

@tr1cks, это обычно в другую сторону делают: Power over Ethernet (PoE) Куча устройств это уже поддерживает.

  Развернуть 1 комментарий

@yeputons, я с ним столкнулся еще лет 10 назад, как умным-дорогим-активным, так и тупым-дешевым-колхозным. Имхо, он не решает проблему, а наоборот усугубляет потому, что топология звезда, а не шина - для умного дома с кучей всего это не вариант. В PowerLine же по идее можно либо использовать уже существующую инфраструктуру, либо не закладывать отдельную на новом объекте

  Развернуть 1 комментарий

@tr1cks, вообще сейчас мне сходу непонятно даже как по уму проектировать домашнюю сеть, если не wi-fi only. 2 кабеля ethernet в разные углы типа домашнего СКС делали и 15 лет назад, но на практике этого бывает таки маловато. Но может 3-х и достаточно. Или Wi-Fi first делать со своими Access Point в больших пространствах для всего не супер требовательного (там теоретический максимум еще со среднерыночной реальной скоростью похоже неплохо расходится)

  Развернуть 1 комментарий

@tr1cks, Если дом большой, то Wi-Fi mesh, до каждой точки доступа - Ethernet. На мой взгляд, этого вполне достаточно. Если где-то нужно будет больше портов Ethernet, всегда можно свитч добавить.

  Развернуть 1 комментарий

@DKvasnikov, ну, вот в первом приближении да, но хватает нюансов. Может вообще пока чисто Wi-Fi mesh кидать вообще без проводов, чтобы ничего не строить и не закладываться. Главное требовательных потребителей, чтобы ни было, но сходу это в первую очередь игры, а не всем и не всегда надо

  Развернуть 1 комментарий

@tr1cks, powerline проигрывает MoCA по стабильности соединения, у обоих вопросы с пропускной способностью, что часто хуже банального CAT6 разводки. Это решение проблемы вайфая и оно не очень. Тыкал оба, просто продал потом железки, потому что стабильность интранета внутри дома даже по вайфаю была лучше.

  Развернуть 1 комментарий

@mighty_conrad, спасибо за опыт, интересно! Ну, я вообще не как прям замену обычному интернету в квартире, а именно для вумных устройств, так что пропускная способность не так критична, а вот стабильность важна, да. Еще и на входе в квартиру должно терменироваться как-то, чтобы шину всем желающим не светить

  Развернуть 1 комментарий

@tr1cks, для умных устройств уже есть готовые решения, проще на них и делать.

Недорого и без проводов - Zigbee или новомодный Matter over Thread + Wi-Fi для устройств, где нужна высокая скорость или которых почему-то нет с Zigbee.

Надёжно, дорого и с проводами- KNX.

Надёжно, с проводами и подешевле - CANBUS (или его вариант Bus77) или RS-485.

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб