What I Learned at Clubhouse 📓

What I Learned at Clubhouse 📓

Чему я научился в Clubhouse 📓

25 lessons, 2 years, from 1,000 users to millions

25 уроков, 2 года, от 1 000 пользователей до миллионов

I’ve learned a lot about building startups over the past few years, and have become much more opinionated on how to do it well. I spent the last 2 years at Clubhouse, where my learning was supercharged by the caliber of our team, the rate of growth, and the very nature of building in a new product category.

За последние несколько лет я многое узнал о создании стартапов и стал гораздо более уверен в своих взглядах на то, как делать это хорошо. Последние 2 года я провёл в Clubhouse, где моё обучение шло с невероятной скоростью — благодаря уровню команды, темпам роста и самой природе создания продукта в новой категории.

When I started, the app had ~1000 users. Rooms didn’t have titles and “clubs” didn’t exist yet. The team was just the founders. Clubhouse has been built in public since, and as an early employee and Head of Community, I became a quite public person at the company and got to contribute to nearly every part of it.

Когда я начинал, в приложении было около 1 000 пользователей. У комнат не было названий, а «клубов» ещё не существовало. Команда состояла только из основателей. С тех пор Clubhouse строился публично, и как один из первых сотрудников и руководитель направления сообщества я стал довольно публичной фигурой в компании и смог внести вклад практически в каждый её аспект.

In recent months I craved more time to explore new ideas again as a founder, and decided to leave Clubhouse while staying on as an advisor. I’ve taken away many personal lessons and refined perspectives on how to build and scale startups — especially products, communities, and teams — and how to do it in public.

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

Product

Продукт

Lesson #1 — Earn the right to build the next thing

Урок №1 — Заслужите право строить следующую вещь

Commit to following through on what you’ve already planned or launched before you chase the next creative, experimental, or shiny idea. “Earn the right to build” and “have respect for sequencing” are principles I’ve internalized.

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

At the earliest stages, it can mean doing diligence on user needs and testing with no-code MVPs before coding anything. While scoping, it can mean being disciplined about what needs to be in a version 1 of a feature. Post-launch it can mean rigorously ensuring feature quality and evaluating feature success before thinking about what’s next. And so on.

На самых ранних этапах это может означать тщательное изучение потребностей пользователей и тестирование с помощью no-code MVP перед тем, как писать хоть строчку кода. При определении объёма работ это может означать дисциплинированный подход к тому, что действительно должно войти в первую версию фичи. После запуска это может означать тщательную проверку качества фичи и оценку её успешности, прежде чем думать о том, что дальше. И так далее.

At a meta level, it’s valuable to set up a consistent product development process that considers strategic fit, prioritization, scope, launch, evaluation, and iteration.

На мета-уровне полезно выстроить последовательный процесс разработки продукта, учитывающий стратегическое соответствие, приоритизацию, объём, запуск, оценку и итерации.

Lesson #2 — Strive for a great UX and a good enough UI

Урок №2 — Стремитесь к отличному UX и достаточно хорошему UI

Simply put, how things work matters more than how they look. This is especially true in the early stages of a product when you have supportive early-adopters.

Проще говоря, то, как вещи работают, важнее того, как они выглядят. Это особенно верно на ранних стадиях продукта, когда у вас есть лояльные ранние пользователи.

A great UX facilitates your product’s core interactions — clear, easy, and simple. A bad UX makes it hard for users to do the thing you want them to do (or even know you want them to do it). Bad UX can turn users off a good product idea.

Отличный UX обеспечивает ключевые взаимодействия с продуктом — понятные, лёгкие и простые. Плохой UX мешает пользователям делать то, что вы от них хотите (или даже понять, чего вы от них хотите). Плохой UX может оттолкнуть пользователей от хорошей продуктовой идеи.

On the other hand, a “good enough” UI is … good enough (especially since it can be more subjective). For example, color and font schema can influence perception of a product’s purpose and audience (e.g. target age and personality). But, a differentiated product with strong utility and great UX should overcome this.

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

Some evidence that this holds true: bug reports and product feedback are almost always about UX (or new feature requests), and the ones that seem like they’re about UI usually overlap with usability issues.

Подтверждение того, что это работает: баг-репорты и отзывы о продукте почти всегда касаются UX (или запросов на новые фичи), а те, что кажутся относящимися к UI, обычно пересекаются с проблемами юзабилити.

Lesson #3 — Product judgment is more skill than talent

Урок №3 — Продуктовое чутьё — скорее навык, чем талант

Good product judgment is hard to define because it’s empirical; you’re only proven “right” after the fact and over time. It’s also a skill more than it is pure talent; you have to practice to get good and to stay good at it. Arguably the most important way to invest your time — to deeply understand how users:

Хорошее продуктовое чутьё сложно определить, потому что оно эмпирическое: вашу «правоту» подтверждают только постфактум и со временем. Это скорее навык, чем чистый талант; нужно практиковаться, чтобы стать хорошим и оставаться хорошим в этом. Пожалуй, самый важный способ инвестировать своё время — глубоко понимать, как пользователи:

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

Product thinkers say that some combination of expertise, empathy, or creativity underlie good product judgment; deeply understanding the product and the market directly through users will help with all three. This doesn’t have to mean building a UX research function early. The best results can come from doing it yourself (see lessons #6 and #22) and drawing on the collective wisdom of a team.

Продуктовые мыслители говорят, что хорошее продуктовое чутьё основано на некой комбинации экспертизы, эмпатии или креативности; глубокое понимание продукта и рынка напрямую через пользователей поможет со всеми тремя. Это не обязательно означает создание функции UX-исследований на раннем этапе. Лучшие результаты может дать самостоятельная работа (см. уроки №6 и №22) и коллективная мудрость команды.

Lesson #4 — Beware of complexity creep

Урок №4 — Остерегайтесь ползучей сложности

The first version of your product is usually simple. As you keep building, the product becomes more robust in quality, utility, and experience. But, there’s a tipping point after which “robust” can sneakily switch to “complicated.”

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

Some signs your product might be too complicated: You’ve launched a bunch of features and haven’t killed any of them. You’re running out of literal surface area to put new features. Users aren’t clear what to do with the product and how.

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

Complexity creep is a human problem. When we make things, we get attached. We don’t want to seemingly discard people’s work. We may not rely enough on data to make decisions. Or, we just aren’t clear on the one or two core interactions that users need and value, so it’s hard to choose what stays and what goes.

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

Anticipate this, then build in early checkpoints. Define success and failure before a launch. Build a solid process and track the right metrics to help make objective, decisive decisions — and don’t forget to create a framework to sunset things!

Предвидьте это, а затем заложите ранние контрольные точки. Определите критерии успеха и неудачи до запуска. Выстройте надёжный процесс и отслеживайте правильные метрики, чтобы принимать объективные, решительные решения — и не забудьте создать механизм для вывода функций из эксплуатации!

Community

Сообщество

Lesson #5 — A ‘community’ is really a collection of many communities

Урок №5 — «Сообщество» на самом деле — это совокупность множества сообществ

If you have 2 users, you probably have 2 user personas. It’s illustrative but even a small group of users can have a vastly differing set of experiences, perspectives, goals and needs for your team’s attention and your product. Hence, groups of users form and represent many distinct communities as a network grows.

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

User segmentation isn’t an academic exercise; done right, it’s a strategic and operational one. Use qualitative insights, data, and reference users to help define personas. At a strategic level, match value propositions to user segments. Choose to prioritize one user segment and hence not another. At an operational level, classify users into a specific segment and support them accordingly. Then build systems and allocate resources to do it well at scale.

Сегментация пользователей — не академическое упражнение; при правильном подходе это стратегическая и операционная задача. Используйте качественные инсайты, данные и референсных пользователей для определения персон. На стратегическом уровне сопоставляйте ценностные предложения с сегментами пользователей. Выбирайте приоритетный сегмент и, следовательно, не другой. На операционном уровне классифицируйте пользователей по конкретным сегментам и поддерживайте их соответственно. Затем выстраивайте системы и распределяйте ресурсы, чтобы делать это качественно в масштабе.

Lesson #6 — Talk to users (even if you don’t think you need to)

Урок №6 — Разговаривайте с пользователями (даже если думаете, что вам это не нужно)

This shouldn’t be a one-off thing, and it should be something every team does. You should talk to users when you’re trying to figure out what product to build, when you’re ready to launch, or even when users reject it. Talk to them not just about product but also about their motivations and needs from a community. Bonus points if you can engage users in a way that’s native to your product!

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

There are many traps (logical and emotional ones) that can get in the way. The Jobsian philosophy might be cited – “some people say give the customers what they want, but that's not my approach. Our job is to figure out what they're going to want before they do.” Even if this is true, talking to users is still valuable. Just use the insights to understand problems and refine solutions, not to generate them. 

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

Another potential trap — “the most vocal users aren’t the users we want.” If you’re distinguishing between users you want and don’t, make sure you really know the difference (see lesson #5). Then do the work to reach the users you do want. I’m confident you can find both thoughtful advocates and critics of every feature, program, or strategy you might be considering.

Ещё одна потенциальная ловушка — «самые громкие пользователи — не те пользователи, которые нам нужны». Если вы проводите границу между нужными и ненужными пользователями, убедитесь, что действительно понимаете разницу (см. урок №5). Затем проделайте работу, чтобы достучаться до тех пользователей, которые вам нужны. Я уверен, что вы сможете найти как вдумчивых сторонников, так и критиков любой фичи, программы или стратегии, которую вы рассматриваете.

Lesson #7 — Create value through user-to-user interactions

Урок №7 — Создавайте ценность через взаимодействие пользователей друг с другом

A true community is defined by the interactions, relationships, and value exchanged among its members. Hence, building a community alongside your product shouldn’t focus just on team-to-user interactions, but also on user-to-user interactions. Figure out where team needs (e.g. product insight, user education, user growth) align or don’t align with the needs and interests of engaged users. Use this to help identify and test new engagement initiatives.

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

Importantly, don’t just tell, rather show users how you want them to engage. Collaboration between community and product can be very valuable here. For example, to tackle user education, demonstrate the feature in use via the product (e.g. onboarding flow) and in the community (user-led onboarding sessions). If you want users to create, engage existing creators to show what a good process and output looks like. Your users and supporters can augment your team’s impact.

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

Lesson #8 — Trust & safety is a continual effort, not an end point

Урок №8 — Доверие и безопасность — это непрерывный процесс, а не конечная точка

Managing user trust, safety, and privacy has to be a conscious and consistent effort; it’s never too early to start and it’s never fully ‘done.’ The first thing to do is anticipate what challenges your product uniquely presents in this domain. Then, figure out how to tackle challenges with product, process, and team.

Управление доверием, безопасностью и конфиденциальностью пользователей должно быть осознанным и последовательным усилием; начинать никогда не рано, и эта работа никогда не бывает полностью «завершена». Первое, что нужно сделать, — предвидеть, какие уникальные вызовы в этой области создаёт ваш продукт. Затем разберитесь, как справляться с ними с помощью продукта, процессов и команды.

Create an initial set of rules (read: Community Guidelines!) for how you want users to engage with your product, with each other, and with your team. Get input from your existing users. Avoid the legalese up front so it’s a quick exercise. This also helps give clarity to your team and guidance for decisions that arise.

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

This is especially important if you want to build an open network. Figure out which rules you want to centralize versus leave up to users. Anything centralized sets a network-wide standard where your team may be the arbiter; anything decentralized can be taken as permissible and may feel out of your control.

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

Go-To-Market & Growth

Выход на рынок и рост

Lesson #9 — Your friends are false positives until proven otherwise

Урок №9 — Ваши друзья — ложноположительный сигнал, пока не доказано обратное

Often the earliest users of your product are your friends, family, colleagues — people you personally onboarded and who have a vested interest in your success.

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

If you can’t get your day 0 supporters to use and like the product (assuming they’re in the target market), that’s probably an accurate, and negative, signal. But, if they do like it and even act like an ‘ideal’ user would (e.g. sharing the product with their friends), you should still consider it a false positive! It’s valuable feedback but isn’t an objective indicator of quality or growth potential.

Если вы не можете заставить своих сторонников с первого дня пользоваться продуктом и полюбить его (при условии, что они входят в целевой рынок), это, вероятно, точный и негативный сигнал. Но если им нравится и они даже ведут себя как «идеальный» пользователь (например, делятся продуктом с друзьями), вы всё равно должны считать это ложноположительным результатом! Это ценная обратная связь, но не объективный показатель качества или потенциала роста.

Extend out one more degree of separation — if you start to see friends of friends invite their friends repeatedly, now that’s a stronger type of signal. You’re finally seeing intent that doesn’t rely on your direct relationships and influence.

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

Lesson #10 — Product-GTM fit comes before product-market fit

Урок №10 — Product-GTM fit наступает раньше product-market fit

Product-market fit is an end state; a go-to-market (GTM) strategy however is an input you control! And without product-GTM fit, you can’t create product-market fit; you can only stumble upon it (and who wants to depend on luck?).

Product-market fit — это конечное состояние; а стратегия выхода на рынок (GTM) — это входной параметр, который вы контролируете! И без product-GTM fit вы не можете создать product-market fit; вы можете лишь случайно на него наткнуться (а кто хочет зависеть от удачи?).

One example of product-GTM fit is in choosing the right user to serve. If you’re building a group-based product, figure out if there’s a group “leader” archetype and if that’s the user you should explicitly target and build for. Tl;dr — make sure the user you’re courting is right for the product you’re building, and vice versa.

Один из примеров product-GTM fit — выбор правильного пользователя для обслуживания. Если вы строите продукт, основанный на группах, определите, есть ли архетип «лидера» группы и является ли он тем пользователем, на которого вы должны явно нацелиться и для которого строить. Tl;dr — убедитесь, что пользователь, которого вы привлекаете, подходит для продукта, который вы строите, и наоборот.

Another example is in picking an effective seeding strategy. If you’re building a closed or default private network, you can pick many, distinct cohorts to test with since they’re effectively walled off from each other. If you’re building an open or default public network, the first cohort matters more — seed it deliberately in character, size, and pace. This group will set early user behavior and culture, influence direction of growth, and give feedback that shapes the product.

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

Lesson #11 — Start building a growth engine before you need it

Урок №11 — Начните строить двигатель роста до того, как он вам понадобится

You don’t get to choose your growth rate. You can influence it or slow-drip it (e.g. gating early access), but the input-output relationship isn’t linear, and it takes time to figure out the formula too. Whether you onboard early users one by one or are fortunate enough to have viral growth, you will have to build a growth engine.

Вы не выбираете свой темп роста. Вы можете на него влиять или дозировать (например, ограничивая ранний доступ), но зависимость между входами и выходами не линейна, и на поиск формулы тоже нужно время. Независимо от того, онбордите ли вы первых пользователей по одному или вам повезло с вирусным ростом, вам придётся построить двигатель роста.

Start understanding how growth works for your product early so that when, not if, growth rate shifts (up or down), you know what your levers are and can quickly move into execution mode. Treat the growth engine as a set of “loops” (circuits that compound) rather than “funnels” (one-way channels that don’t compound).

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

Lesson #12 — Invest in your community-led growth flywheel

Урок №12 — Инвестируйте в маховик роста через сообщество

Traditional product-led growth (PLG) means building a great self-serve product that can basically acquire and retain users itself. This is a direct product-to-user sell and a “best product wins” approach. Community-led growth (CLG) engages the community in the process, enabling a “best recommendation wins” approach.

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

PLG may work best for products that are utility-based, can provide value on day 1 (e.g. without a network of users), or once a product is socially or culturally validated. CLG stands out when the product’s primary purpose isn’t utility (e.g. instead it’s entertainment, status, new social connections) and people may have lots of options — here a vibrant, vocal community can make a difference.

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

For instance, even a small group of early users that are community organizers or ‘network nodes’ can champion a product and informally acquire, onboard, and help retain users. The tradeoff with CLG of course is that it’s operational, hence it’s slower and likely harder to find great economies of scale. But, validated community-led approaches can also be built into product in creative ways!

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

Strategy & Operations

Стратегия и операции

Lesson #13 — Strategy is not doing everything

Урок №13 — Стратегия — это не делать всё подряд

Strategy is equally about defining what you want to do and what you don’t want to do. A good strategy can be written down in a one-pager. It’s actionable and measurable. It forces you to tackle distinct (or diverging) priorities in series instead of attempting them in parallel. It drives team alignment, hiring, and resource prioritization. A good strategy is communicated transparently and reiterated constantly inside the company and the essense of it shared to users too.

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

Most teams do start with a strategy. But, once a product launches, there’s no guarantee it’ll be used how you expect or want it to be. When you start to see multiple use cases and user segments form, it’s exciting, but it risks muddying your strategy (especially if one demands a change in your product roadmap). In times like this, you are forced to decide which directions fit your strategy or are a distraction — because doing everything isn’t a strategy.

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

Lesson #14 — Expand scope in good times, narrow it in the bad

Урок №14 — Расширяйте охват в хорошие времена, сужайте в плохие

Know when to push and when to pull back, but things should never be stagnant. When things are going well (e.g. the product is strong, growth is good, team is operating well, morale is high), expand the scope of work and experiment more. If things aren’t great, in one or more ways, revisit priorities and narrow scope. This is helpful at both a macro and micro level — for a company, team, or individual.

Знайте, когда давить, а когда отступать, но ничего не должно стоять на месте. Когда дела идут хорошо (продукт крепкий, рост стабильный, команда работает слаженно, боевой дух высок), расширяйте объём работ и больше экспериментируйте. Если дела идут не очень — в одном или нескольких отношениях — пересмотрите приоритеты и сузьте фокус. Это полезно как на макро-, так и на микроуровне — для компании, команды или отдельного человека.

Lesson #15 — Every team needs a strong operator

Урок №15 — Каждой команде нужен сильный операционист

Operations is not just a function, it’s also a skill. In the early days of a startup, you’re basically just one cross-functional team. One strong operator is enough. But as startups grow, you might set up independent teams for each function, and “operations” can get siloed. Or, you might set up several, distinct cross-functional teams that are each responsible for a business goal.

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

Regardless, make sure you still have a strong operator in every team — whether someone native to that team or by embedding a member of the operations team. Part of operating well is breaking down big challenges into actionable workplans, getting team alignment, then relentlessly executing on them. Make sure someone in every team has the skills, agency, and support to play this valuable role.

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

Lesson #16 — Know when and when not to measure ROI

Урок №16 — Знайте, когда стоит и когда не стоит измерять ROI

You can think about ROI on money or time (either your own, your team’s, or even the company’s). Consider this upfront before committing resources, but also when things have been done a certain way for a long time; there’s usually room to prioritize and focus further. Sometimes this can mean building operating models, and other times it’s a simple 80/20 exercise based on gut and team experience.

Можно думать о ROI в деньгах или во времени (собственном, команды или даже компании). Учитывайте это заранее, прежде чем выделять ресурсы, а также когда что-то делалось определённым образом долгое время — обычно есть пространство для дальнейшей приоритизации и фокусировки. Иногда это означает построение операционных моделей, а иногда — простое правило 80/20 на основе интуиции и опыта команды.

But sometimes ROI isn’t the best measure — often for sub-scale, experimental, or other creative initiatives. Resist the urge to believe that things without a clear cost-benefit equation today aren’t valuable. Instead, outline the objectives clearly and create a process to measure inputs vs. outputs, impact expected vs. delivered.

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

Building & Managing Teams

Создание и управление командами

Lesson #17 — Focus on skills, not functions

Урок №17 — Фокусируйтесь на навыках, а не на функциях

For early-stage and / or high-growth startups, traditional organizational functions are too rigidly defined. I’ve started to think in terms of skills instead.

Для стартапов на ранней стадии и/или в фазе бурного роста традиционные организационные функции определены слишком жёстко. Я стал мыслить в терминах навыков.

There are only 4 hard skills you might need to do any job — data, design, engineering, and operations. Every “job” requires a unique weighted average of these 4 skills. Being a product manager can be a heavily operational role. Being a marketer can be a data-oriented role. “Functions” tend to focus on the application of these skills with a defined objective and in a defined context. Functions don’t always translate across orgs; skills usually do — consider both when hiring.

Есть всего 4 профессиональных навыка, которые могут понадобиться для любой работы — данные, дизайн, инженерия и операции. Каждая «должность» требует уникального взвешенного среднего этих 4 навыков. Быть продакт-менеджером может означать преимущественно операционную роль. Быть маркетологом может означать работу, ориентированную на данные. «Функции» обычно фокусируются на применении этих навыков с определённой целью и в определённом контексте. Функции не всегда переносятся между организациями; навыки — обычно да. Учитывайте и то, и другое при найме.

With this framework as a starting point, you can better break down any role, understand skills required, and nature of day to day work. It can help hire more effectively, better structure and integrate teams, and help employees develop.

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

Lesson #18 — Teams shouldn’t be “upstream” or “downstream”

Урок №18 — Команды не должны быть «выше» или «ниже по потоку»

Simplistically, there are 3 top-level domains in most organizations — make, sell, and support. In a consumer tech startup for example, the product, design, and engineering teams might constitute the “make” domain. The “front of the house” teams may “sell” (e.g. marketing), and the “back of the house” teams may “support” (e.g. customer success). Importantly — don’t think of these domains as upstream or downstream of each other; think of them as collaborative!

Упрощённо, в большинстве организаций есть 3 верхнеуровневых домена — создание, продажа и поддержка. Например, в потребительском технологическом стартапе команды продукта, дизайна и инженерии могут составлять домен «создания». Команды «фронт-офиса» могут «продавать» (например, маркетинг), а команды «бэк-офиса» — «поддерживать» (например, успех клиентов). Важно — не думайте об этих доменах как о расположенных выше или ниже по потоку; думайте о них как о партнёрах!

It’s easy to forget to build strong yet flexible touch points between domains, especially as you scale. This is also true within sub-teams and sub-sub-teams (you get the idea). Make sure to build in timely cross-team communication, collaboration, and shared decision-making.

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

Lesson #19 — In hypergrowth, hire startup-stage chameleons

Урок №19 — В гиперросте нанимайте стартап-хамелеонов

Hypergrowth feels like you’re running a huge company with a tiny team, and like it happened overnight. Hiring yourself out of the imbalance is challenging. First, you should be reasonably confident that you have product-market fit so new hires will match the strategic direction. This is of course more critical for specialized and senior roles. Timing is also important because growing the team will paradoxically slow you down as you onboard, ramp up, and add layers.

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

New leadership hires should have 3 types of expertise: building processes and systems to scale, hiring and managing teams, and applying industry experience (ideally multiple reps at tackling similar challenges end-to-end). Bring on people who have this expertise and are extremely curious, use the product, want to talk to users, can run fast and lean, execute as an IC or manage people, and work cross-functionally. Yes, it’s a lot to ask. You want people who can build 0 to 1 and have built the 1 to n — i.e. they can play early or growth stage roles.

Новые руководители должны обладать 3 типами экспертизы: построение процессов и систем для масштабирования, найм и управление командами, а также применение отраслевого опыта (в идеале — несколько циклов решения аналогичных задач от начала до конца). Нанимайте людей, которые обладают этой экспертизой и при этом безумно любопытны, пользуются продуктом, хотят разговаривать с пользователями, умеют двигаться быстро и экономно, работать как индивидуальный контрибьютор или управлять людьми и действовать кросс-функционально. Да, это много требований. Вам нужны люди, которые способны строить с 0 до 1 и уже строили с 1 до n — то есть они могут играть роли и ранней, и стадии роста.

Lesson #20 — Communicate with optimism about the future but realism about the past

Урок №20 — Будьте оптимистичны о будущем, но реалистичны о прошлом

Optimism is very valuable but it’s only forward looking. When looking at the past, it’s important to reflect with a heavy dose of realism. Team retros are a great tool. Which hypotheses, decisions, outcomes were good? Which weren’t? Why?

Оптимизм очень ценен, но он направлен только в будущее. Оглядываясь на прошлое, важно осмысливать его с солидной долей реализма. Командные ретроспективы — отличный инструмент. Какие гипотезы, решения, результаты были хорошими? Какие нет? Почему?

It’s also critical to communicate what’s going well and what’s not. Teams are smart and they’ll know regardless, whether because they’re close to the data, talk to their teammates, spend time with users, or just use the product a lot themselves. Trust and morale aren’t based just on optimism or success; they’re built up by a consistent sense of transparency, alignment, and having a unified plan of action.

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

Lesson #21 — Company culture is built in DMs and 1:1s

Урок №21 — Корпоративная культура строится в личных сообщениях и на встречах один на один

It matters far less what you say in all-hands meetings or post in a #general slack channel than what happens the rest of the time! Behaviors demonstrate culture, and most behaviors — good and bad — happen behind the scenes, in the slack DMs and the 1:1 meetings that are far more frequent than any public gestures.

Гораздо менее важно, что вы говорите на общих собраниях или пишете в канале #general в Slack, чем то, что происходит всё остальное время! Поведение формирует культуру, а большинство проявлений — хороших и плохих — происходят за кулисами, в личных сообщениях в Slack и на встречах один на один, которые случаются гораздо чаще любых публичных жестов.

Keep this in mind when hiring too! The first 10-20 employees have an outsized impact on the culture and direction of a company, directly and indirectly. The people they hire, the team culture they set, and how they engage at all levels and in all channels will be hugely influential, so evaluate cultural fit holistically.

Помните об этом и при найме! Первые 10–20 сотрудников оказывают непропорционально большое влияние на культуру и направление компании — прямо и косвенно. Люди, которых они нанимают, командная культура, которую они задают, и то, как они взаимодействуют на всех уровнях и во всех каналах, будет иметь огромное значение, поэтому оценивайте культурное соответствие комплексно.

Working at a Startup

Работа в стартапе

Lesson #22 — Be a power user of your own product

Урок №22 — Будьте продвинутым пользователем собственного продукта

If talking to your users is important, being a user of your own product is just as critical. (Luckily in consumer tech you’re almost always a potential user.)

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

There are lots of reasons to do this: 1) it builds empathy for your users 2) it builds empathy for your team 3) it helps clarify user feedback and context-poor data 4) it can reveal new product ideas and, hence, 5) it improves your product judgment!

Есть множество причин для этого: 1) это развивает эмпатию к пользователям 2) это развивает эмпатию к команде 3) помогает прояснять отзывы пользователей и данные без контекста 4) может раскрыть новые продуктовые идеи и, следовательно, 5) улучшает ваше продуктовое чутьё!

Pro tip: know your own usage patterns and those of your team. Find the power users across your team and draw on them for insights. Keep track of how usage changes, with or without product changes, and understand why. Product and user-facing teams in particular need to be immersed to keep learning.

Совет профи: знайте свои собственные паттерны использования и паттерны вашей команды. Найдите продвинутых пользователей в команде и черпайте у них инсайты. Отслеживайте, как меняется использование — с изменениями продукта или без — и понимайте почему. Продуктовые и пользовательские команды, в частности, должны быть погружены в продукт, чтобы продолжать учиться.

Lesson #23 — Unblock yourself and everyone else

Урок №23 — Разблокируйте себя и всех остальных

Whenever possible, don’t rely on or wait for other people to remove an obstacle. Tangible obstacles are things like skills, information, access, or time. Intangible obstacles are often related to communication or a psychological barrier like lack of alignment or fear. Be proactive about recognizing and removing your own obstacles, communicating them transparently (see lesson #24), and making it very easy for others to help you when necessary. Take it one step further and try to help unblock others proactively.

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

Lesson #24 — Overcommunicate, don’t overpromise

Урок №24 — Перекоммуницируйте, но не переобещайте

If I had to give a single piece of advice to anyone working in a fast-paced, high ambiguity, cross-functional team environment, it’s this — overcommunicate. This applies to the macro and micro, to every level, and on every day. Examples:

Если бы мне нужно было дать один совет каждому, кто работает в быстро меняющейся, высоко неопределённой, кросс-функциональной командной среде, это — перекоммуницируйте. Это применимо к макро- и микроуровню, к каждому уровню и каждый день. Примеры:

Будьте отзывчивы к запросам и задавайте контекст, даже если не сможете выполнить их быстро или вообще (читай: не переобещайте).Держите людей в курсе статуса вашей работы. Например, делитесь еженедельными обновлениями о прогрессе в легко усваиваемой форме. Дайте ссылку на центральное место, где можно углубиться в релевантную работу или наверстать прогресс в любое время.Не просите разрешения, просите прощения, но предупреждайте заранее. Делитесь ходом мыслей и планом действий, оставляя место для дискуссии или несогласия. Обычно вы просто получите подтверждение и избежите неприятных сюрпризов.Давайте конструктивную обратную связь каждому (не только подчинённым) и просите её в ответ. Делайте это для хорошего и плохого, через регулярные промежутки.Устанавливайте границы для защиты своего здоровья, отношений и целей. Само собой, они должны быть разумными; затем сообщайте о них!

Lesson #25 — Know which lane you want to be in

Урок №25 — Знайте, на какой полосе вы хотите быть

As I pondered leaving Clubhouse in recent months, I talked with mentors and friends in the company and externally. They all echoed a version of the same questions. “What do you want to spend your days doing?” “Which direction do you want to take your career?” “What’s important short-term vs. long-term?”

Размышляя об уходе из Clubhouse в последние месяцы, я разговаривал с менторами и друзьями внутри и за пределами компании. Все они повторяли варианты одних и тех же вопросов. «Чем вы хотите заниматься каждый день?» «В каком направлении хотите развивать карьеру?» «Что важно в краткосрочной и долгосрочной перспективе?»

A common framework for startup career paths emerged – founder, executive, or investor. There’s no hierarchy because they are fundamentally different lanes, but it’s important to know which lane you’re in right now and which you want to be in. Some people stay in one lane; others zig and zag between them.

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

I’ve also found it clarifying to think about energy. People often ask how energized you are about your role; I like to ask how energized you are about the idea of doing anything else. Relative energy is just as impactful as absolute.

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

Once you know what you want, make sure you’re 1) building the relevant skills 2) being direct about your goals 3) tracking your own progress 4) regularly zooming out to think big picture and 5) finding a community of like-minded people. My two cents – no matter what you want to do, do it with intention and energy!

Когда вы поймёте, чего хотите, убедитесь, что вы 1) развиваете соответствующие навыки 2) прямо говорите о своих целях 3) отслеживаете собственный прогресс 4) регулярно отступаете назад, чтобы мыслить масштабно, и 5) находите сообщество единомышленников. Моё мнение — чем бы вы ни хотели заниматься, делайте это осознанно и с энергией!

A huge thank you to everyone that I had the pleasure of working alongside and learning so much from. 💛 And, for those reading — if any of these lessons resonate strongly with you, let me know!

Огромная благодарность всем, с кем мне посчастливилось работать бок о бок и у кого я так многому научился. 💛 А тем, кто читает, — если какой-то из этих уроков вам особенно откликнулся, дайте знать!