Рубрика «продуктовая разработка» - 3

Как правильно рассказать покупателям о ценности НЕ уникального продукта

«Как мне обозначить ценность продукта, который мы продаем? Ведь он не уникален!»

Если вы хотите улучшить состояние дел своего бизнеса, вы наверняка знаете: донести ценность обладания вашим товаром до потребителя никогда не бывает лишним. При этом вы наверняка видели немало удачных примеров, но когда дело доходит до собственных товаров, вы не знаете, как к этому подступиться.

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

Как тут поступить?
Читать полностью »

«Хотели бы вы зарабатывать больше денег?», «Сложно ли нанимать людей?», «Завалены почтой?», «Хотите улучшить свое здоровье и форму?»

Конечно же, большинство людей ответит на эти вопросы «да». Это прописные истины. Глобальные проблемы. И они не решаемы.

В очень многих стартапах путают глобальное видение (big vision) и попытки решить вселенские проблемы. Глобальное видение важно. Необходимо ставить высокие, благородные цели, направленные на то, чтобы изменить мир. Но, если вы утверждаете, что решаете глобальные проблемы, вы, скорее всего, не понимаете проблем реальных.
Читать полностью »

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

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

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

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

Как создать новый продукт для рынка электроники. Часть 1

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

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

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

Многие читатели Хабра знакомы с внутренней кухней разработки ПО, а ведь железо — это совсем другая история. Готовы? Тогда поехали.
Читать полностью »

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

Почему иногда не стоит изобретать велосипед

Причина 1. Вы не знаете, как такие велосипеды устроены

Посмотрите внимательно на предыдущий топик. Генри Форд — с детства изучал технику. Его сестра как-то сказала, что в детстве любую игрушку старались спрятать от него, потому что он ее тотчас разберет на винтики. Работал инженером в «Электрической компании Эдисона», был совладельцем «Детройтской автомобильной компании». Он точно знал, что такое — автомобиль. Он точно знал технические нюансы. Он точно знал. что черная краска сохнет два дня, а любая другая — две недели! Ну не из-за прихоти же он однажды сказал, что автомобиль будет только черным.

Игорь Сысоев, прежде чем делать свой nginx, уже имел «достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста».

Знаете ли вы, что вам предстоит на пути создания своего велосипеда? Или просто готовы окунуться с головой, не проверив глубину водоема?

Мы как-то по просьбе своего заказчика сделали реализацию почтовой рассылки, которая делала рассылку новостей зарегистрированным пользователям. И каково было удивление нашего заказчика, когда после первой такой рассылки его заблокировали как спаммера. Пришлось копать дальше, но в итоге оказалось, что гораздо проще интегрироваться с каким-нибудь MailChimp и не изобретать велосипеда. Там не только все продумано, но есть еще и отчеты — сколько прочитало, сколько кликало по ссылкам, сколько нажали «отписаться от рассылки» и другие очень важные моменты, которые заказчик, попросивший «сделайте нам возможность разослать новости нашим пользователям», может захотеть сделать сразу же после реализации базового функционала.

Читать полностью »

«Попался. Предатель. Ржунимагу». Как-то так реагируют люди, узнав, что у меня iPhone. И вот стою я перед вами, уличенный в пользовании продуктом конкурента — и признаю себя виновным.

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

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

В продолжении перевода первой статьи Стивена Синофски о продуктовой разработке — перевод его второй статьи, про важность обмена опытом в команде, разрабатывающей продукт.

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

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

Зачем делать отчеты о поездках?

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

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

Подходы

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

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

От кода к продукту. Ciklum Speakers Corner, Днепропетровск

Приглашаем Вас на очередное мероприятие серии Ciklum Speakers’ Corner под названием «От кода к продукту» от Димы Маленко. На мероприятии вы сможете нырнуть в мир особенностей продуктовой разработки.

Что будет обсуждаться:
— Разработчики любят код
— Готовый продукт – это намного больше, чем просто код
— Мечтаешь создать свой стартап? Научись быть инженером, дизайнером, админом и…
— Стартап? Простые способы стать знаменитыми
Читать полностью »

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

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

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

Естественное напряжение (sic!)

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

Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js