It can be hard to know where to start when defining a strong organisational culture for a product business. One thing is for sure though, great product and tech businesses all share on thing in common: a culture that seeks to achieve product, engineering and operational excellence for its customers. Depending on what your teams do, these customers may be internal or external, but the goal is still the same: ensuring customer success.

If you’re fortunate enough, you may have (or have had) the opportunity to work in a team or organisation that’s shown you what excellence through a customer focused lens feels like, but also how elusive achieving it can be. This is to be expected – great cultures take time to instill and discipline to maintain. Ensuring that internal fiefdoms and focuses that distract from customers is also easy to drift into.

When given the opportunity to help shape a product organisation’s culture, I've found the best way to start is to work backwards from what you think is great. Here’s my definition of that for my teams.

Great Product teams are made up of strong owners who hold themselves and their teammates accountable for ensuring customers are satisfied using our product. They subscribe to a philosophy of Continuous Improvement that means they aim to always “Design it, Build it, Ship it, Own it” when creating features for customers.

• Teams each have a defined charter and set of users (internal or external). This documents why they exist, who their customers are, and how they serve them.

• Teams work backwards from users. They understand their key user metrics and what drives them (their inputs). They review them regularly with their product and engineering leaders (eg fortnightly/monthly). New features are defined with user input (qual) and usage data (quant).

• Teams are accountable for company goals or OKRs related to their customer domains, and also take additional bottom-up team level goals to drive priority for their own initiatives.

• Teams work within their leadership group (Product, Engineering, Design, Data + n) to plan their own roadmaps. They are responsible for prioritising their deliverables, and accountable to achieve both their top-down and bottom-up goals.

• Teams each own and are accountable for a set of features or experiences, along with the websites and services that power them.

  • They are responsible for the long term health of their system architecture, security and scalability.

  • They complete all maintenance tasks required by their systems (not already completed by SRE teams).

• Teams release their own software (where possible), minimising the blast radius of their changes.

• Teams are responsible for the care of the systems they own, including but not limited to:

  • Addressing bug fixes.

  • Patching of dependencies.

  • Security and operational fixes.

  • Planning annual infrastructure costs.

  • Addressing technical debt.

  • Continually improving the testing, release and support processes for their systems.

  • Regularly reviewing and improving the operational health of their systems.

• Teams support and protect customers using their systems at all times. Each have a defined oncall process for responding to customer facing events.

  • Trained team members rotate oncall responsibilities between them. Where single team oncall ownership is not possible, oncall rotations are shared between multiple teams.

  • Teams have 24/7 pager coverage of their services with escalation to operations or SRE teams, and management.