Почти $1 млрд списаний после провала планшета Surface RT не заставили Microsoft закрыть направление Surface — и именно этот эпизод Панос Панай предлагает помнить стартапам. Глава подразделения Amazon Devices, Alexa и Leo считает, что ошибки в разработке продуктов неизбежны, если команда действительно пытается выйти за привычные границы, а не выпускает безопасные итерации уже знакомого решения.
Об этом Панай рассказал на конференции TechCrunch Disrupt в Сан-Франциско, сообщает TechCrunch. Руководитель, проработавший в Microsoft более 19 лет, назвал Surface RT одним из самых заметных собственных провалов: на фоне слабых продаж компания списала почти $1 млрд стоимости запасов. Но, по его версии, проблемой был не сам публичный ярлык «провал», а решения, которые к нему привели задолго до выхода устройства на рынок.
Surface RT был первым планшетом Microsoft и работал на ARM-версии Windows. В выступлении Панай не разбирал технические детали платформы, зато перечислил типичные точки, где продукт начинает проигрывать ещё до релиза: незавершённое ПО, неверно рассчитанные запасы, ошибки в работе с розницей. Для команд это полезное напоминание: неудачный запуск редко объясняется одним дефектом, одной презентацией или плохим кварталом. Обычно он складывается из серии компромиссов, которые никто вовремя не собрал в общую картину.
Панай предлагает не романтизировать неудачи, а проводить их разбор без поиска удобных оправданий. Сам факт ошибки в разработке продуктов ничего не даёт компании автоматически: можно признать убыток, сменить формулировки в презентации и повторить тот же сценарий. Ценность появляется, когда команда способна назвать конкретную причину, проверить её данными и изменить следующий цикл разработки, закупок или вывода продукта на рынок.
Отдельно Панай предостерёг от двух противоположных реакций. Первая — бросить исходную идею после первого серьёзного сбоя. Вторая — слишком долго держаться за решение, потому что команда так и не признала момент провала. По его словам, корректировка курса чаще похожа не на разворот на 180 градусов, а на сдвиг примерно на 30: видение сохраняется, но продукт, приоритеты и способ его доставки пользователю меняются после полученного опыта.
Для российских разработчиков и продактов эта логика особенно применима к проектам с дорогой инфраструктурой, железом, маркетплейсами и корпоративными внедрениями. В таких продуктах поздно найденная ошибка быстро превращается в складские остатки, сорванные интеграции, перегруженную поддержку и конфликт между разработкой, продажами и финансами. Ретроспектива после релиза должна отвечать не на вопрос «кто виноват», а на более неприятные вопросы: какие сигналы проигнорировали, кто мог остановить решение и почему этого не произошло.
Фаундеры часто слышат совет «быстрее ошибаться», но его легко превратить в индульгенцию для хаоса. Из слов Паная следует другая практическая формула: рисковать можно, если команда заранее понимает, какие гипотезы проверяет, где увидит тревожный сигнал и что именно изменит при отрицательном результате. Тогда ошибки в разработке продуктов становятся не частью корпоративной мифологии, а управляемой стоимостью обучения.
История Surface показывает, что публичный провал не обязательно отменяет продуктовую ставку: линейка Surface продолжила развиваться и после RT. Более важный вопрос для рынка — смогут ли компании сохранять амбицию после неудачи, не подменяя анализ красивыми словами о «ценном опыте». Полный комментарий Паная доступен в материале .