## Контекст Andrew Ng на лекции в Стэнфорде рассказал о сдвиге, который он наблюдает в Кремниевой долине. Раньше код был дорогим. Написать фичу — неделя работы. Поэтому компании нанимали много разработчиков и мало продакт-менеджеров. Типичное соотношение: 8 инженеров на 1 PM. Иногда 4:1, иногда 7:1, но порядок такой. Сейчас код подешевел. Агенты пишут за час то, что раньше занимало дни. Это изменило баланс. --- ## Узкое место сместилось > *«When it is increasingly easy to go from a clearly written software spec to a piece of code, then the bottleneck increasingly is deciding WHAT to build»* Когда превратить спецификацию в код стало просто, узким местом стало понимание — что именно строить. Ng называет это «узким местом продакт-менеджера». Писать код научились ускорять, а понимать пользователя — нет. --- ## Новое соотношение Ng говорит, что в командах, с которыми он работает, соотношение меняется: - Было: 8:1, 7:1, 4:1 - Сейчас: 2:1, иногда 1:1 Это радикально отличается от традиционной структуры. Один продакт на одного инженера — такого раньше не было. --- ## Самые быстрые люди в долине > *«The subset of engineers that learn to talk to users, get feedback, develop deep empathy for users — those engineers are the fastest moving people that I'm seeing in Silicon Valley today»* Инженеры, которые научились разговаривать с пользователями, собирать обратную связь, чувствовать их потребности — сейчас самые быстрые люди в долине. Идея проста: объединить инженера и продакта в одном человеке. Не ждать, пока кто-то другой покажет продукт клиентам. Написал → показал → услышал → поправил → повторил. Скорость итерации возрастает в разы. --- ## Оговорка Ng признался, что раньше совершил ошибку — пытался убедить инженеров делать больше продуктовой работы. В итоге хорошие инженеры чувствовали себя плохими продактами и были несчастны. > *«That was a mistake I made. Regretted that for years.»* Не всем это нужно. Есть инженеры, которые не хотят общаться с пользователями — и это нормально. Но те, кто хочет и умеет — получают огромное преимущество. --- ## Как это работает на практике Цикл такого инженера: 1. Написать код 2. Показать пользователю 3. Услышать, что нравится и что нет 4. Скорректировать понимание продукта 5. Повторить > *«If you're not waiting for someone else to take the product to customers — you just write code, have a gut for what to do next and iterate — that velocity of execution is much faster»* Если не ждёшь посредников — сам пишешь, сам чувствуешь направление, сам итерируешь — скорость совсем другая. --- ## К чему это ведёт Это объясняет несколько вещей: 1. **Стартапы из одного человека стали реальностью** — можно и кодить, и общаться с пользователями 2. **Прототипы важнее чистого кода** — быстрая итерация на ранних этапах ценнее архитектуры 3. **Продуктовое мышление дорожает** — технические навыки есть у многих, понимание пользователя — редкость --- ## Вопросы - Можно ли этому научиться? - Как совмещать глубину технической экспертизы с продуктовой эмпатией? - Что происходит с «чистыми» инженерами в этом новом мире?