Your Product Is Only As Good As The Standards You Set
Introduction
In the world of product development, there’s a simple but sometimes overlooked principle: your product will never rise above the standards and conventions established by your team and organization. Put more bluntly, you get what you tolerate. If your company tolerates sloppy code, unclear communication, or rushed timelines, don’t be surprised when your product reflects those very shortcomings.
In this post, we’ll explore how the rules, conventions, and standards within a company fundamentally shape the final product. We’ll look at what it means to enforce healthy engineering practices, transparent communication, and consistent quality criteria, and we’ll examine a few practical examples of how adjusting what you “tolerate” can immediately improve your product.
Setting the Right Engineering Standards
Define Clear Coding Conventions:
From the start, you need to ensure every developer understands the coding style guidelines—naming conventions, code formatting, and documentation standards. When such rules are unclear or inconsistently enforced, the codebase gradually devolves into a patchwork of styles, making it harder for new team members to contribute and increasing the likelihood of bugs slipping through.
Use Automated Quality Checks:
Enforcing coding standards through automated tools, such as linters or code analyzers, sets a baseline for quality. If the tool flags an issue and the team regularly ignores it, the codebase starts to accumulate technical debt. On the other hand, if the team fixes issues as they arise, the code stays cleaner, more maintainable, and easier to evolve.
Establishing Strong Communication Protocols
Regular, Focused Meetings:
If your stand-ups, sprint reviews, or planning sessions consistently run off the rails—turning into lengthy debates or tangents—your team will lose respect for these gatherings. Setting clear meeting agendas, enforcing time limits, and rotating facilitators are all ways to maintain productive communication norms. In turn, these disciplined meetings lead to more efficient decision-making and a smoother development cycle.
Transparent Reporting Tools:
Without a common platform for sharing progress, metrics, and blockers, you end up tolerating guesswork and misalignment. By setting a rule that every team member updates the project management board daily, everyone remains on the same page, bottlenecks are identified faster, and the product moves forward more predictably.
Holding the Team Accountable for Quality
Peer Code Reviews:
A crucial standard many successful teams uphold is the practice of mandatory peer reviews before merging new code. If a reviewer is consistently lenient—overlooking minor style issues or ignoring performance bottlenecks—those issues inevitably make their way into the product. By enforcing a culture where reviews are thorough, respectful, and constructive, you raise the overall quality bar.
Definition of Done (DoD):
A well-defined Definition of Done sets the minimum acceptable criteria for feature completion. It might include passing automated tests, writing user documentation, or receiving UI approval from a designer. When the team adheres strictly to this DoD, you ensure that no work is considered “complete” until it meets agreed-upon quality standards. If shortcuts are routinely tolerated, expect corresponding drops in quality and user satisfaction.
Real-World Example: Improved Onboarding Flow
Consider a team building a user onboarding flow for a mobile app. Initially, the team’s “standards” are vague. There’s no strict requirement for user testing before release, and the code is reviewed only when someone thinks it’s necessary. The result is a clunky onboarding process that confuses users and causes high drop-off rates.
After experiencing low user retention, the team decides to adopt stricter rules: all UI changes must be usability tested by at least three employees outside the development team, and all code changes must pass a structured review with a senior engineer. A few sprints later, the onboarding process is smoother, user satisfaction is up, and new customers are sticking around longer. By refusing to tolerate vague standards, the team elevated the product’s quality.
Conclusion
Your product is a direct reflection of what you, as a company, consider acceptable. The moment you let standards slip, you invite complexity, confusion, and lower quality into your product. Conversely, when you actively maintain well-defined rules and enforce them consistently, you create an environment where quality naturally thrives.
Simply put: Your product will only be as good as the standards and conventions you choose to uphold. When you expect excellence—and enforce it—it shows in the final product.
