In 1982, social scientists James Q. Wilson and George L. Kelling published an essay with a simple observation: a building with one broken window, left unrepaired, will soon have all its windows broken. Not because disorder is inevitable, but because an unrepaired window sends the signal that no one is watching, that no one cares and that norms are negotiable. In this framing, disorder reflects neglect while also allowing permission for more of it.
The theory was derived from an experiment in Newark, New Jersey, where police presence and attention to small visible signs of disorder produced measurable changes in how communities experienced safety and normalcy. The mechanism was environmental, not punitive: fix the signal, and the behavior around it changes.
What Wilson and Kelling never anticipated was that their framework could also apply to something that had nothing to do with urban crime. Their Broken Window Effect can partly explain how digital products decay, compound dysfunction, and collapse under the weight of their own unaddressed disorder when organizations try to scale them.
Think about the last time your team shipped a feature knowing something was off. Think of a shortcut in the data model, a UX flow that "works but isn't quite right," a deprecated API wrapper nobody had time to refactor. The feature shipped, the sprint closed, and the ticket was marked as done. And that was your first broken window.
Now ask yourself: what did that decision communicate to everyone on your team? Not the intention, but the signal. When a team sees that "good enough" has shipped, the implicit permission structure shifts. Standards become negotiable, and next shortcuts are easier and easier to justify. Signals are what shape culture, not intentions.
According to Morning Consult, 80% of enterprises say technical debt stifles their ability to innovate. Moreover, the 2024 Stack Overflow Developer Survey found that over 60% of devs cite technical debt as a major source of frustration, with almost 80% even reporting that time spent on legacy systems and accumulated shortcuts actively damages team morale.
Just as Wilson and Kelling's neighborhood, the environment of a digital product (whether it's the codebase, UX, architecture, or internal tooling) either enforces standards or erodes them, with no neutral ground. And in B2B contexts, the stakes compound. As you're building for organizations whose operations depend on what you ship, a broken window in an enterprise product is a contract risk.
80% of enterprises say technical debt stifles their ability to innovate, and over 60% of developers feel technical debt is a major source of frustration.
There is a seductive logic to the growth phase of a product: revenue is climbing, and new clients are signing on. And this new sight makes leaders feel tempted to pour resources into acquisition, onboarding, and feature velocity—to outrun the technical and experiential debt that accumulated during the scrappy early days.
The working assumption is that scale will eventually generate the organizational weight needed to address the underlying issues. But it does the opposite. Here is the uncomfortable truth: scaling does not fix broken windows; it just multiplies them.
With a weak foundation, scaling only multiplies broken windows.
Teams with high levels of technical debt report spending nearly 50% more time on bug fixing and understanding existing code, and organizations with high technical debt even deliver those features 25-50% slower than their competitors.
The Consortium for Information & Software Quality also estimated that poor software quality costs the US economy at least $2.41T annually, driven by the slow accumulation of decisions that seemed acceptable in the moment.
When you scale a product with unresolved structural debt, you're also scaling the disorder embedded in it. Every new customer onboarded to a broken flow makes it harder to redesign. Every hire who builds on a fragile architecture inherits its constraints and habits. Every feature added to a UX that lacks internal consistency introduces more incoherence.
The broken windows multiply faster than you can repair them, and your product begins to communicate that disorder is the norm here. And that's why so many B2B products that achieve product-market fit still fail to cross the line into enterprise readiness.
When you scale a product with unresolved structural debt, you're also scaling the disorder embedded in it.
While early markets rewarded speed and iteration, enterprise markets reward coherence, reliability, and the signal that someone has thought carefully about what they are building and why. This signal is impossible to transmit from a product full of broken windows.
Gartner's Global Software Buying Trends Report found that 60% (three in five!) of businesses regret a technology purchase made in the past 12 to 18 months. But there's only a handful of times when that regret is about missing features—it's often about encountering a product that seemed coherent and revealed broken windows after signing the contract.
A pervasive form of broken-window thinking in digital products is feature accumulation. Teams under pressure to grow respond by adding functionality, expanding scope, and shipping more. Each feature feels like progress, yet collectively, they are often the opposite.
Standish Group's research states that nearly two-thirds (64%) of all developed software features are rarely or never used by users or customers. The work that's being shipped isn't delivering value: it's increasing complexity, creating maintenance burdens, and communicating to users that no one fully thought through what they needed before building.
Unused features signal to users that no one really thought about them, their needs, or the tasks they needed to complete before building.
Features built without a clear understanding of what they solve are structural liabilities: they introduce UX complexity that trains users to expect confusion, increase surface area without adding coherent value, and create dependencies that make future changes harder. All these outcomes signal that teams optimize for activity and not understanding.
The consequences are evident, as research shows that over 60% of US organizations confirm that poor UX leads to customer churn, and churn costs US businesses an estimated $136B annually. More specifically, nearly 70% of new B2B SaaS users stop using the software within the first three months.
The broken windows were always there: the scale just made them visible. Features built without a clear understanding of the problem they solve are structural liabilities.
In retrospect, B2B product leaders do recognize this pattern. In the painful post-mortem of a failed enterprise deal, in the escalating cost of customer success as clients struggle with a product whose logic they cannot follow, and in the engineering team's growing resistance to change because every change has unpredictable ripple effects. The accumulated disorder was always communicating something. The organization just was not listening.
We were blind to unforeseen circumstances / We learned the right steps to different dances / And fell victim to interlopers' glances — Taylor Swift, How Did It End?
Wilson and Kelling's prescriptive argument was not about punishment but environmental design. Rather than removing what breaks windows, it focused on designing environments where broken windows get fixed before they become the norm. For product teams, this clarity-driven reframe is the most important cognitive shift available.
A team that runs consistent reviews before every sprint shows that coherence matters from the start. A team that doesn't treat UX inconsistencies as cosmetic issues to address "later" shows that the user experience is part of the product's structural integrity. A team that insists on understanding the problem before estimating the solution shows that building the right product matters more than building things fast.
As a leader, ask yourself: What does our environment tell about what we value? Does it enforce the standards we claim to hold?
In B2B development, tech-savvy enterprise buyers can tell the difference between a product that maintains consistent standards and one whose team has been running to fix windows. Every interaction tells something about who built this, why, and with how much care, and they make decisions based on what they feel. As 98% of buyers read reviews before purchasing, the product's coherence (or lack of it) becomes the review before the review.
These are cultural decisions expressed through process. The process is the environment. The environment is the signal. The signal shapes what is normal.
The antidote to the broken window effect is more deliberate development: a way of working that treats discovery and delivery not as sequential phases but as a continuous, interlocked system where understanding accumulates rather than features accumulate. And Shaped Clarity™ makes this approach structurally possible.
Capicua's framework recognizes something that the broken window analogy makes clear: disorder compounds in the absence of active, designed-in standards. The "move-fast-and-break-things" mentality was always more like a permission structure for broken windows, or a cultural signal that fragmentation was acceptable as long as velocity numbers looked good.
Shaped Clarity™ replaces the permission structure with an evidence-based operating lens that answers the questions left unanswered: What are we learning from what we are building? When do we diverge and experiment, and when do we converge and ship? What does success look like in a way that everyone on the team can see?
When discovery and delivery operate as two expressions of the same system, broken windows do not accumulate, because the system itself is designed to catch them. By compounding learning into value, every iteration becomes an opportunity to assess whether the product is becoming more coherent, more aligned with user reality, and more capable of signaling to every person that someone thought carefully about what was built and why.
Understanding accumulation over feature accumulation is a structural defense against the broken window effect, built into how work is organized rather than bolted on afterward.
The Broken Window Theory ends with a simple observation: neglect is not passive; it's a default decision that shapes its environment. Every broken window left unrepaired is a design choice ≠for disorder, for permissiveness, for the normalization of decay.
In digital product development, those choices are made in planning rooms, sprint reviews, and the quiet moments when a team lead decides whether to flag a concern or let it slide. They're made in how roadmaps are constructed, in what gets treated as a bug versus a backlog item, and in whether teams are given space to understand before they build.
The most sophisticated product organizations are the ones that have built environments where standards are embedded in the work itself. Clarity is not a destination to be reached after the chaos, but a lens applied from the start.
Every window you leave broken is a signal. And signals, at scale, become culture. Culture, at scale, becomes product. And in B2B, the product becomes the thing your clients decide to trust. The choice was always about what you choose to communicate, and whether you are paying attention to what your product is already saying.
This article was written for forward-thinking decision-makers who want to build clatity-driven products that preserve core value. If you want to take the next step, let's start a conversation.
In 1982, social scientists James Q. Wilson and George L. Kelling published an essay with a simple observation: a building with one broken window, left unrepaired, will soon have all its windows broken. Not because disorder is inevitable, but because an unrepaired window sends the signal that no one is watching, that no one cares and that norms are negotiable. In this framing, disorder reflects neglect while also allowing permission for more of it.
The theory was derived from an experiment in Newark, New Jersey, where police presence and attention to small visible signs of disorder produced measurable changes in how communities experienced safety and normalcy. The mechanism was environmental, not punitive: fix the signal, and the behavior around it changes.
What Wilson and Kelling never anticipated was that their framework could also apply to something that had nothing to do with urban crime. Their Broken Window Effect can partly explain how digital products decay, compound dysfunction, and collapse under the weight of their own unaddressed disorder when organizations try to scale them.
Think about the last time your team shipped a feature knowing something was off. Think of a shortcut in the data model, a UX flow that "works but isn't quite right," a deprecated API wrapper nobody had time to refactor. The feature shipped, the sprint closed, and the ticket was marked as done. And that was your first broken window.
Now ask yourself: what did that decision communicate to everyone on your team? Not the intention, but the signal. When a team sees that "good enough" has shipped, the implicit permission structure shifts. Standards become negotiable, and next shortcuts are easier and easier to justify. Signals are what shape culture, not intentions.
According to Morning Consult, 80% of enterprises say technical debt stifles their ability to innovate. Moreover, the 2024 Stack Overflow Developer Survey found that over 60% of devs cite technical debt as a major source of frustration, with almost 80% even reporting that time spent on legacy systems and accumulated shortcuts actively damages team morale.
Just as Wilson and Kelling's neighborhood, the environment of a digital product (whether it's the codebase, UX, architecture, or internal tooling) either enforces standards or erodes them, with no neutral ground. And in B2B contexts, the stakes compound. As you're building for organizations whose operations depend on what you ship, a broken window in an enterprise product is a contract risk.
80% of enterprises say technical debt stifles their ability to innovate, and over 60% of developers feel technical debt is a major source of frustration.
There is a seductive logic to the growth phase of a product: revenue is climbing, and new clients are signing on. And this new sight makes leaders feel tempted to pour resources into acquisition, onboarding, and feature velocity—to outrun the technical and experiential debt that accumulated during the scrappy early days.
The working assumption is that scale will eventually generate the organizational weight needed to address the underlying issues. But it does the opposite. Here is the uncomfortable truth: scaling does not fix broken windows; it just multiplies them.
With a weak foundation, scaling only multiplies broken windows.
Teams with high levels of technical debt report spending nearly 50% more time on bug fixing and understanding existing code, and organizations with high technical debt even deliver those features 25-50% slower than their competitors.
The Consortium for Information & Software Quality also estimated that poor software quality costs the US economy at least $2.41T annually, driven by the slow accumulation of decisions that seemed acceptable in the moment.
When you scale a product with unresolved structural debt, you're also scaling the disorder embedded in it. Every new customer onboarded to a broken flow makes it harder to redesign. Every hire who builds on a fragile architecture inherits its constraints and habits. Every feature added to a UX that lacks internal consistency introduces more incoherence.
The broken windows multiply faster than you can repair them, and your product begins to communicate that disorder is the norm here. And that's why so many B2B products that achieve product-market fit still fail to cross the line into enterprise readiness.
When you scale a product with unresolved structural debt, you're also scaling the disorder embedded in it.
While early markets rewarded speed and iteration, enterprise markets reward coherence, reliability, and the signal that someone has thought carefully about what they are building and why. This signal is impossible to transmit from a product full of broken windows.
Gartner's Global Software Buying Trends Report found that 60% (three in five!) of businesses regret a technology purchase made in the past 12 to 18 months. But there's only a handful of times when that regret is about missing features—it's often about encountering a product that seemed coherent and revealed broken windows after signing the contract.
A pervasive form of broken-window thinking in digital products is feature accumulation. Teams under pressure to grow respond by adding functionality, expanding scope, and shipping more. Each feature feels like progress, yet collectively, they are often the opposite.
Standish Group's research states that nearly two-thirds (64%) of all developed software features are rarely or never used by users or customers. The work that's being shipped isn't delivering value: it's increasing complexity, creating maintenance burdens, and communicating to users that no one fully thought through what they needed before building.
Unused features signal to users that no one really thought about them, their needs, or the tasks they needed to complete before building.
Features built without a clear understanding of what they solve are structural liabilities: they introduce UX complexity that trains users to expect confusion, increase surface area without adding coherent value, and create dependencies that make future changes harder. All these outcomes signal that teams optimize for activity and not understanding.
The consequences are evident, as research shows that over 60% of US organizations confirm that poor UX leads to customer churn, and churn costs US businesses an estimated $136B annually. More specifically, nearly 70% of new B2B SaaS users stop using the software within the first three months.
The broken windows were always there: the scale just made them visible. Features built without a clear understanding of the problem they solve are structural liabilities.
In retrospect, B2B product leaders do recognize this pattern. In the painful post-mortem of a failed enterprise deal, in the escalating cost of customer success as clients struggle with a product whose logic they cannot follow, and in the engineering team's growing resistance to change because every change has unpredictable ripple effects. The accumulated disorder was always communicating something. The organization just was not listening.
We were blind to unforeseen circumstances / We learned the right steps to different dances / And fell victim to interlopers' glances — Taylor Swift, How Did It End?
Wilson and Kelling's prescriptive argument was not about punishment but environmental design. Rather than removing what breaks windows, it focused on designing environments where broken windows get fixed before they become the norm. For product teams, this clarity-driven reframe is the most important cognitive shift available.
A team that runs consistent reviews before every sprint shows that coherence matters from the start. A team that doesn't treat UX inconsistencies as cosmetic issues to address "later" shows that the user experience is part of the product's structural integrity. A team that insists on understanding the problem before estimating the solution shows that building the right product matters more than building things fast.
As a leader, ask yourself: What does our environment tell about what we value? Does it enforce the standards we claim to hold?
In B2B development, tech-savvy enterprise buyers can tell the difference between a product that maintains consistent standards and one whose team has been running to fix windows. Every interaction tells something about who built this, why, and with how much care, and they make decisions based on what they feel. As 98% of buyers read reviews before purchasing, the product's coherence (or lack of it) becomes the review before the review.
These are cultural decisions expressed through process. The process is the environment. The environment is the signal. The signal shapes what is normal.
The antidote to the broken window effect is more deliberate development: a way of working that treats discovery and delivery not as sequential phases but as a continuous, interlocked system where understanding accumulates rather than features accumulate. And Shaped Clarity™ makes this approach structurally possible.
Capicua's framework recognizes something that the broken window analogy makes clear: disorder compounds in the absence of active, designed-in standards. The "move-fast-and-break-things" mentality was always more like a permission structure for broken windows, or a cultural signal that fragmentation was acceptable as long as velocity numbers looked good.
Shaped Clarity™ replaces the permission structure with an evidence-based operating lens that answers the questions left unanswered: What are we learning from what we are building? When do we diverge and experiment, and when do we converge and ship? What does success look like in a way that everyone on the team can see?
When discovery and delivery operate as two expressions of the same system, broken windows do not accumulate, because the system itself is designed to catch them. By compounding learning into value, every iteration becomes an opportunity to assess whether the product is becoming more coherent, more aligned with user reality, and more capable of signaling to every person that someone thought carefully about what was built and why.
Understanding accumulation over feature accumulation is a structural defense against the broken window effect, built into how work is organized rather than bolted on afterward.
The Broken Window Theory ends with a simple observation: neglect is not passive; it's a default decision that shapes its environment. Every broken window left unrepaired is a design choice ≠for disorder, for permissiveness, for the normalization of decay.
In digital product development, those choices are made in planning rooms, sprint reviews, and the quiet moments when a team lead decides whether to flag a concern or let it slide. They're made in how roadmaps are constructed, in what gets treated as a bug versus a backlog item, and in whether teams are given space to understand before they build.
The most sophisticated product organizations are the ones that have built environments where standards are embedded in the work itself. Clarity is not a destination to be reached after the chaos, but a lens applied from the start.
Every window you leave broken is a signal. And signals, at scale, become culture. Culture, at scale, becomes product. And in B2B, the product becomes the thing your clients decide to trust. The choice was always about what you choose to communicate, and whether you are paying attention to what your product is already saying.
This article was written for forward-thinking decision-makers who want to build clatity-driven products that preserve core value. If you want to take the next step, let's start a conversation.
