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.