What I Learned About Growth Creating Complexity
Growth is often treated as a linear reward, but it is actually a phase shift that introduces systemic complexity. Here is how I learned to filter feedback and protect product simplicity.
Growth is not a linear progression of the same activities; it is a phase shift that introduces systemic friction. When I was building Postly, I initially viewed every new user and every feature request as a sign of momentum. I eventually realized that growth, left unmanaged, is the primary architect of product complexity. If you do not actively filter the demands that come with a growing user base, the product eventually becomes a negotiation between incompatible desires rather than a cohesive solution.
The fundamental lesson I learned is that growth creates complexity by default, while simplicity must be maintained by design. This realization didn't come from a strategy meeting; it came from the hundreds of hours I spent in support windows, realizing that the more we grew, the more we were being pulled away from the very simplicity that made us successful in the first place.
The Support Trap
In the early years, proximity to users was my greatest advantage. I didn't have a buffer between myself and the people using the software. I saw the bugs, the confusion, and the moments of delight in real-time. But support also reveals a hidden danger: it is the primary source of complexity-inducing feedback. Support is where users stop being abstract and start being demanding.
When you are in the valley between validation and scale, the temptation is to say yes to every request to keep churn low. However, I learned that support reveals product truth faster than any strategy deck. It shows you where your onboarding fails and where your UX creates hesitation. More importantly, it reveals that not all customers deserve equal weight in your product roadmap. Treating every request as representative of your entire market is a fast track to a bloated, unusable product.
The Hidden Cost of the "Yes"
Every time we said "yes" to a feature that satisfied one vocal user's edge case, we were saying "yes" to a permanent maintenance burden. This is the "leadership tax" of building a product over a long time horizon. Complexity isn't just about code; it's about the cognitive load on the user and the emotional debt on the founder. When the product becomes too complex, the founder often begins to break before the product does. You can read more about this in my essay on what I learned about the founder breaking before the product.
I learned that one user might want flexibility while another wants simplicity. One wants more settings, while another wants the interface protected from exactly that kind of friction. If you try to satisfy both, you satisfy neither. The product loses its "opinion," and a product without an opinion is a product without a future.
A Framework for Filtering Complexity
To survive the middle of the journey, we had to stop being obedient and start being interpretive. We developed a sequence of questions to filter feedback. This system was not technical; it was editorial. It allowed us to decide which customer truths belonged in the product’s long-term identity and which were merely noise.
- Is this a pattern or a single person's frustration? We stopped reacting to the loudest voice and started looking for the quietest consensus.
- Does it align with the kind of product we are trying to build? Growth can pull you into markets you never intended to serve.
- Will it create clarity or complexity? If a feature requires a new documentation page just to explain how to turn it on, it is likely a complexity trap.
- Does it strengthen the system or satisfy an emotional moment? Many requests are born of temporary frustration rather than structural necessity.
- If we say yes, what future maintenance burden are we also saying yes to? Every feature is a promise of future work.
Healthy Growth vs. Complex Growth
Not all growth is created equal. Some users teach you how to grow, while others only teach you how to react. The following table illustrates the difference between growth that scales and growth that complicates.
| Growth Signal | Healthy Growth (Simplicity) | Complex Growth (Friction) |
|---|---|---|
| User Requests | Patterns that solve core problems for the majority. | One-off edge cases for high-touch, low-value users. |
| Feature Scope | Strengthens the existing system architecture. | Requires new toggles, settings, and nested menus. |
| Support Volume | Decreases relative to user count as UI improves. | Increases as users need help navigating "flexibility." |
| Revenue Quality | High-trust users who value the core promise. | Demanding users who pay little but cost much in time. |
Failure Modes of Unmanaged Complexity
When you ignore the complexity tax of growth, you usually fall into one of three traps:
- The Swiss Army Knife Trap: The product tries to do everything for everyone and ends up doing nothing well for anyone. The UI becomes a graveyard of buttons that 90% of users never click.
- The Support Debt Spiral: You spend so much time explaining complex features to confused users that you no longer have time to build the features that would actually reduce confusion.
- The Identity Crisis: You lose the ability to describe what the product is in a single sentence. When your marketing becomes a list of features rather than a solution to a problem, complexity has won.
Field Notes for Builders
If you are currently feeling the weight of a growing product, start by auditing your recent "yes" decisions. Complexity is often the result of small, well-intentioned concessions made over a long period of time. In my manuscript for The Long Build, which I discuss further at GrowthDiary, I emphasize that the founder's job is not to obey feedback, but to interpret it.
Maximum signups are not the same thing as maximum ROI. High activity is not the same thing as healthy fit. To arrive at growth that is sustainable, you must become comfortable with saying no to the wrong kind of expansion. Paradoxically, the best way to respect your customers is to hear what their requests reveal and then decide whether that truth actually belongs in your product’s soul. Simplicity is a strategy, but it is also a daily discipline of rejection.
Follow via RSS: latest articles · full article archive