It is well understood that no product is perfect and small issues will always exist. Without an ongoing mechanism to fix those issues, not only do they not get fixed, they pile up.

Having a clear Lexicon and Taxonomy is critical to getting large numbers of people moving forward towards a vision. Having the lexicon be composed of terms that make logical sense, disambiguate, and are memorable is important.

Over the years of building many hardware and software products I’ve developed a lexicon and taxonomy for categorizing the issues that exist in products and identifies the mechanisms required to ensure they get the appropriate amount of focus by teams:

• Bugs – These are behaviors in code or hardware that are discovered either through quality assurance mechanisms or by customers. Bugs may be discovered before a product is released (best) or after (always bad, but common). Synonymous with Defect. Typical mechanisms: Backlog reviews, Bug triage, Bug severity and priority, monitoring and alarms.
• Improvements – These are ideas to change product behavior by adding new functionality or changing existing behavior to improve it for customers or increase operational excellence. Typical mechanisms: Backlog reviews, usage telemetry, customer interviews, surveys.
• Technical Debt – Technical Debt describes the parts of technical implementation where shortcuts were taken to get a product to market in a timely matter. Tradeoffs always need to be made across these dimensions. I found this blog post to be a great primer on Technical Debt and the mechanisms teams can use to manage and pay down technical debt. Typical mechanisms: Technical Debt Backlog, Allocating % of every sprint to Tech Debt, Architecture reviews, Principal Engineering Community.
• Broken Windows – A bug, defect, or missing feature directly impacting the customer experience that won’t normally get fixed due to resource constraints. The best examples of Broken Windows are things “we’ve known about forever, but just kept pushing down the priority list.” Broken Windows exist in products, code, packaging, documentation, our bug database, our knowledge management system, etc. Typical mechanisms: Broken Window Goals & Reviews.

I’m writing this today because I’ve recently discovered that I have ignored my own biases when it comes to picking lexicon. When I joined Control4 in 2018 I knew the products I would be responsible for had tons of little, annoying issues. That was not a surprise given they were built by a quickly growing company over many years. What surprised me, however, was the lack focus on continually fixing those issues. Not only had our customers become numb to many of these issues, team members had pretty much given up lobbying to fix them. I made it a priority to change the culture to one where these issues got regular focus and teams were not only allowed to fix them but took pride in doing so.

I defined a mechanism, gave it a pithy name (Broken Windows Mechanism) evangelized it, and then drove adoption of it hard. Each quarter I run a review with our teams where I ask, “show me the broken windows you’ve fixed this quarter”. I started small, asking each team to try to fix just three a quarter; by the end of 2019 we fixed over 300 of these issues across all of our products. Some of these fixes are in code. Some are in documentation. Some are in packaging. But collectively, they add up higher quality products across the board, and a better experience for you. Regular audits of the mechanism and customer feedback show it is working and now, in 2020, we’re well on our way to doubling the number of broken windows we fixed last year. We have more work to do, but these issues no longer get ignored, and the team culture has clearly changed in a positive way.

I started using the term “Broken Windows” in this way while leading the Windows Home Server team in 2007. I believe I was influenced by this blog post by Jeff Atwood (Coding Horror): https://blog.codinghorror.com/the-broken-window-theory/, but I also remember reading about the Broken Window Theory in other places. The image in my mind, when thinking about the “real world” concept of broken windows was a lilly-white neighborhood with pretty little single-family homes, white picket fences, and green grass lawns. This is where I failed, and where I’m now embarrassed to admit how skewed my own worldview is, based on my upbringing. I’ve never lived in a big city. I’ve never lived in the type of neighborhood described in the original research that led to the Broken Window Theory. Until a SnapAV employee pointed it out earlier this week, it did not occur to me this term was contentious and that my use of as a metaphor for a product development mechanism was a bad idea.

I created a situation where I led my company with mechanism that is clearly working to raise the quality of our products by fixing tons of those small issues. But I did so with a “pithy phrase” that not only uses a bad analogy but is highly offensive to some.

From end customers and dealers, SnapAV knows there is significant work to do on meeting core expectations from our existing offerings. Customers often tell us our products are not reliable and have failure points. Partners complain about complex time-consuming installations and flaky solutions. Our products must be even simpler to use, simpler to install, performant, and reliable. This requires investment in identifying more bugs and potential improvements. We’ve been using the term “First Mile” for this effort broadly. For our organization, our First Mile goals compel us to build products that are excellent. Excellent products only come from continual improvements, paying attention to everything, even the little things, that contribute to the overall experience.

Thus, I’m going to ask the team to help change the Lexicon used to describe these product issues to something relatable to “First Mile”. For example, “how do you walk a mile?” You start by taking a first step. Or, “How do you ensure your fitness is good enough to run a mile?” You engage in fitness regularly. What ideas do you have for a new term for “Broken Window” that aligns with First Mile strategic imperative?

This sentence is that last I will write where I use the term “Broken Window” as an analogy for the little issues in products that need regular attention; I’ll let you know what the new term is once the team helps pick one.