Уроки по разработке продукта от Илона Маска

Ниже цитаты Маска с моими комментариями, давайте посмотрим вместе.

Make your requirements less dumb.

Совет насколько простой, настолько же и трудновыполнимый.

Если бы мы осознавали, где проблема с нашими требованиями, наверное мы бы их упростили сами, нет? Это примерно как в анекдоте про успех на бирже – “чтобы заработать на бирже, нужно покупать дешево и продавать дорого”.

Опыт помогает.

It’s not a gospel. Everyone’s wrong some of the time. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.

Требования это не “библия” и в них могут быть ошибки или вещи, о которых не подумали, забыли, плохо объяснили и т.д.

Общая ответственность ПМ и команды – понимать это и действовать соответственно. Не бояться переспрашивать, ставить под сомнение, смотреть аналитику, предлагать альтернативные решения.

Whatever requirement or constraint you have it must come with a name, not a department. Because you can’t ask the department, you have to ask a person.

Очень важно трекать откуда пришли требования. “Пользователи хотят” не годится. Кто конкретно спрашивал, в каком контексте, где контакты этого пользователя или компании.

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

Нет.

Задача поддержки – передать полный контекст разговора, а задача ПМ – разбираться с этим фидбеком дальше.

Возможно пользователи действительно хотят Х, но это наверное 20% случае. В остальных 80% может быть что угодно – пользователь пытался решить другую проблему, плохо объяснил что он хочет, есть другое решение, которое не требует разработки, whatever it is.

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

If you’re not occasionally adding things back in, you are not deleting enough.

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

Упрощать, упрощать, упрощать.

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

The most common error of a smart engineer is to optimize a thing that should not exist.

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

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

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

Чтобы сделать сложную (complex) работающую систему надо начинать с простой работающей системы, которая со временем усложняется. Если ты начинаешь со сложной (complicated) системы, впереди только еще более complicated и неработающая система.

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

Now, I have personally made the mistake of going backwards on all five steps multiple times. So I have to repeat this - yes, multiple times.

Me too, Elon, me too.

Мне казалось это я какой-то особенно тупой, потому что наступаю на одни и те же грабли по несколько раз, но может быть и нет, since it happens to the best of us.

Еще на эту тему:
- Как Netflix ведет разработку продукта
- Product mindset vs аутсорсинг