S5 Bonus: Brian Singer, Nobl9

Episode Summary

Executive Summary: Brian Singer, co-founder and CPO of Noble 9, explains how a Google-inspired need to make SLOs and error budgets usable for ordinary enterprises became a product opportunity. The conversation covers the company’s origin, its UX-first product evolution, technical architecture, team-building philosophy, scalability decisions, and lessons learned from customer feedback and market assumptions.

Main Topics: Origin of Noble 9 (Priority: 5/5): Brian’s experience at Google exposed him to SLOs and error budgets as powerful but underused reliability concepts. Seeing their enterprise adoption blocked by complexity and organizational friction inspired Noble 9. What SLOs and error budgets solve (Priority: 5/5): The discussion explains how SLOs measure customer-centric reliability and how error budgets guide tradeoffs between shipping features and fixing reliability issues. Product development and UX iteration (Priority: 5/5): The team built an MVP in roughly a year, but early UX was confusing. Customer feedback and Alex Hidalgo’s input led to a redesigned interface that better matched users’ mental models. Roadmap and customer feedback loops (Priority: 4/5): Brian emphasizes onboarding, observation, and repeated customer interviews as the main inputs for prioritizing features, improving setup, and simplifying integrations. Team and culture (Priority: 4/5): Noble 9 prioritizes transparency, entrepreneurial drive, and leadership experience. Brian values people who act on problems without waiting for permission. Scalability and deployment strategy (Priority: 4/5): The system was designed to scale to the company’s expected early needs using modular services, Kafka, Kubernetes, and multiple deployment models including on-prem and single-tenant. Founder lessons and market assumptions (Priority: 5/5): Brian reflects on underestimating the maturity and unmet demand for SLOs across larger companies, and advises founders to validate pain points through extensive customer interviews.

Key Arguments: SLOs are more meaningful than generic infrastructure metrics because they measure whether customers can actually complete important tasks successfully. Error budgets provide a practical policy tool for deciding when to pause feature work and prioritize reliability. Enterprise adoption of SLOs is hard not because the concept is complicated, but because of silos, access issues, and institutional inertia. A strong UX is essential for technical products, especially when users need to understand abstract reliability concepts quickly. Customer onboarding friction and setup complexity are critical signals that the product is not yet ready for broad adoption. Startup teams should hire people who show ownership, transparency, and the ability to solve problems independently. Founders should challenge early assumptions about market maturity and validate demand through direct user interviews rather than building in a vacuum.

Data Points: Time to first beta: 9-10 months - Brian says Noble 9 shipped its first beta to a customer about nine to ten months after founding. Hands-on keyboard to MMVP: About 4 months - Once the team began active development, it took around four months to produce something customer-ready. Time to GA: About 1.5 years - The product reached general availability roughly a year and a half after work began. Engineering org size: 15-20 services - The platform is composed of about 15 to 20 independent, composable services designed to fail and scale separately. Target reliability example: 99% within 2 hours - Brian gives an SLO example where data freshness should meet the threshold 99% of the time within two hours. Customer interviews: About 75 interviews - Brian cites an MIT Delta V team that evolved its idea after conducting around 75 interviews with target users.

Pivotal Quotes: "there's some other ways that we could represent this...we realized we really missed the mark with the first version that we built" — Brian Singer: On the initial error-budget UI and the realization that customer confusion meant the design needed to be rethought. "SLOs let me basically establish that baseline and say, okay, you know what, 99% of the time, the data is going to be fresh within two hours" — Brian Singer: Explaining how SLOs help product teams define customer-facing reliability expectations. "Get your product in front of as many people that are in your target demographic as possible" — Brian Singer: His final advice to young founders about validating pain points and avoiding building in isolation.

Implications: The interview shows that reliability tooling wins when it is customer-centered, easy to adopt, and backed by real workflow integration. For founders, the lesson is to validate pain early, simplify setup, and design for mental models, not internal assumptions.