When Does a Product Become Too Complex to Understand?
by•
There’s a point where products stop being fully understandable.
Too many features
Too many dependencies
Too much history
And decisions start getting made with partial context.
Have you felt that moment?
When your product became “too big to fully understand”?
We think this is where new tools (like Athena) need to step in -
not just to manage, but to reconstruct understanding.
161 views
Replies
This resonates a bit too much 😅 There’s a moment where even small changes require asking 3 different people just to avoid breaking something. That’s usually when things start feeling fragile.
@susie_johns How do you actually “reconstruct understanding” without oversimplifying reality? Because every abstraction I’ve seen eventually hides something important.
@susie_johns @deangelo_hinkle Yeah, I’ve felt this before. At some point dashboards stop helping and just become decoration. You open them, but you’re not actually learning anything new from them
Athena
@lakeesha_weatherwax Crazy that this is the point we’ve reached. When was the last time you actually made a decision based on something new you learned from them?
Athena
@susie_johns @deangelo_hinkle This is exactly where Athena comes in, to take all that implicit, “spoken-only” knowledge and surface it in an automatic, structured, and understandable way.
Honestly, there’s no more reliable source of truth than real production incidents inside a company. The issue is that there’s almost never one person who both fully understands the entire codebase and deeply understands the business context.
Athena is built to solve that gap.
@susie_johns intresting framing, but I’m not fully convinced complexity is the real issue here. Sometimes it’s not “too big to understand” but “no one owns the understanding anymore.” Those are pretty different problems in practice.
@susie_johns @henry_lindsey How do you actually “reconstruct understanding” without oversimplifying reality? Because every abstraction I’ve seen eventually hides something important.
Athena
@susie_johns @henry_lindsey I completely agree! especially with you point for “no one owns the understanding anymore.”
Athena
@susie_johns Exactly the point!! It doesn’t make sense that we keep relying on people’s availability and their knowledge.
Tooling Studio
I’ve hit that point a few times. It usually starts when decisions live outside the product and context gets scattered.
What’s helped me:
- Keep a short “why this exists” close to each feature
- Capture decisions where the work happens
- Regularly remove things no one can explain anymore
AI can help, but only if it reflects what’s actually happening, not just what was planned.
Athena
@nick_kramer Totally agree.
Once decisions move outside the product, understanding starts to break. Keeping the “why” close is key- that context gets lost fast.
And +1 on AI , it only works if it reflects reality, not just the plan. That’s exactly the gap we’re trying to close with Athena.
Yes, I have. I think when we think as developers and not as marketers or as product users. We tend to add more features, more complexity, in an effort to make our products more appealing, better than the competition. And we miss the point.
Most users want ease of use.
So the best thing is - to always ask your users before you build the new feature that you think it will solve their problem :-)
Case in point. I am developing a few apps, and I tend to make them overcomplicated. Then I always remember my advice, as I caught myself saying - would that "THING" be nice? and I stop. Then I go back to communities and ask what they need, and I adjust.
My latest app, is so fine tuned to user's wants and needs that each time I try to add features, the testers push back.
Athena
@sal_georgiou1 I actually have a slightly different take on this. While I agree we shouldn't rush to build everything, I’ve found that users don’t always know what they want-simply because they don’t know what’s possible.
Some of our most successful features weren't even in the 'top 3 requests'-users didn't realize they were an option until they saw them.
I believe the real magic happens at the intersection of user feedback, intuition (and AI), and most importantly, a deep understanding of the system's core context and internal knowledge. It’s about building what they need, even if they haven't figured out how to ask for it yet.
I believe that product fails the moment it starts feeling like a task instead of a tool.
I’m dealing with this right now while building my app for car/moto drivers. The 'Android permission maze' was our first big wall, its a nightmare for UX . We realized that the real issue isnt just having too many features, but how much mental energy we steal from the user just to get things running, its insane.
There is no real fix for that, but generally we are obsessed with something we call Visual Silence. The tech under the hood is heavy (AI, edge triggers, state machines etc), but the UI stays ghostly.
The goal is to keep everything invisible until it’s absolutely necessary. If a feature doesn't help you make a split-second decision while driving, it’s just thrash. And yes, defining what essential function is a minefield ;-)
Athena
@noiselogic_io Love the 'Visual Silence' concept. To stay invisible, tech needs deep context to know exactly when to show up - that’s exactly what we’re building at Athena. Good luck with the app, designing for drivers is the ultimate UX test!
yes and the scary part is it happens gradually then suddenly. one day you realise nobody on the team has the full picture anymore, everyone just has their corner of it.
Eventually decisions get made on assumptions about how other parts work, those assumptions drift from reality, and six months later you're debugging something nobody fully understands anymore.
Athena
@varun_dhamija1 That “gradually then suddenly” moment is exactly the dangerous part.
What’s interesting is how quickly assumptions become infrastructure decisions without anyone noticing.
Feels like the real problem isn’t losing the full picture - it’s trusting the partial one as if it’s complete.
I was working for years in a huge product with a lot of legacy functionality, and I can tell that pretty much no one was able to make decisions that were based on a full understanding of the product, because, well, no one did :) The product was split into several relatively independent parts, so this approach worked quite well and didn't hurt too much
Athena
@sk_uxpin This is a really important distinction - at scale, full understanding becomes almost impossible and products turn modular by necessity.
The real challenge is still making good decisions without pretending you have full context.
That’s also the problem Athena is trying to solve - helping teams rebuild shared understanding across fragmented systems, so decisions don’t rely on local assumptions
Flavored Resume
This is an interesting question. In the past I was a product manager of ML models capturing fraud scores. Initially its pretty simple: the higher the score, the more likely the risk. However since we were selling to financial institutions we needed to dive in a lot more. Also, sellers needed to understand the product in order to sell it. Selling a product that is highly technical with no UI to demo in a highly regulated environment requires being able to tell the right story. Its answering questions like "why is this for me", "what's considered good vs bad", and "what kind of benefit will i see".
It comes from having discussions with customers and teams so you understand where they are coming from. Otherwise you're telling them benefits that aren't for them and you lose the opportunity.
Athena
@edward_g This is a really strong example. In your case it shows how complexity isn’t just about features, but also about context, audience, and storytelling.
Even something simple like a score becomes complex when you have to explain it across different stakeholders, especially in regulated environments.
And I think your point about grounding it in real customer conversations is key - without that, you risk optimizing for explanations that don’t actually match what users care about or understand.
Flavored Resume
@maya_elor The most common issue I see is solving for problems that are not significant or not speaking to the customer pain points. Empathy is what builds trust and drives sales. Asking questions, even simple ones, is crucial.
It usually happens when the team starts saying, just don't touch that part of the code/product.' That’s the red flag. When you’re afraid to fix one thing because you have no clue what else it might break, you’ve passed the point of no return. Understanding isn't just about features, it's about not being scared of your own tool
Athena
@naprich Yes - “don’t touch that part” is usually the first symptom, not the last stage.
And it’s not just fear of breaking things, it’s loss of mental ownership.
Once parts of the product become “untouchable”, understanding has already started to fragment.
Athena
@rvalenzjetti I like this framing - especially the “core dies if removed” test.
It basically forces you to ask whether something is truly additive or just historical baggage.
The hardest part is that complexity rarely shows up as one clear “yes”, it accumulates quietly until these questions suddenly become obvious.
honestly i feel its sometime easy to fall into this trap. As founders have the expert blindspot and you might think that the product you are building are solving an actual pain point, the more features you add, it gets more complicated for fresh users.
Athena
@roy_kek I think the real trap is that complexity often feels like progress from the inside.
Each feature usually solves something real in isolation, but together they slowly erode the clarity of the product for new users.
And the tricky part is that this doesn’t show up immediately - it only becomes obvious when someone fresh tries to understand it without all the internal context.