What I Learned at Clubhouse 📓
Theory #6
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.
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.
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.
Product
Lesson #1 — Earn the right to build the next thing
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.
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
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.
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.
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.
Lesson #3 — Product judgment is more skill than talent
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:
experience your product (so much so that you can even anticipate how various target user segments would react to changes in your product)
experience other products (know the evolving socio-cultural trends and understand the products that may compete to serve similar needs)
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.
Lesson #4 — Beware of complexity creep
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
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.
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.