Defining OCUS’ Product and Tech Operating Principles

I originally wrote this post for the OCUS "the dot" blog and I'm also sharing this and posting this here.

Enjoy!

I would love to get your feedback - drop me an email!

Jeremy (he/him)

www.jeremybrown.tech
Don't ignore your dreams, don't work too much, say what you think, cultivate friendships, be happy.

Defining OCUS’ Product and Tech Operating Principles

Strong communities require three ingredients – shared purpose, aligned values and a common language.

At OCUS we strive for just that. We’ve developed a clear purpose and mission. We have also worked on our virtues which are:

1. Radical Responsibility
2. Radical Transparency
3. Radical Curiosity
4. Creative Engineering
5. Drive for Excellence
6. Teamplay

We recently wrote about our work to establish a common language at OCUS.

This gives us a very solid foundation as a community of diverse people.
Within our engineering team, which is composed of product and tech, we have also been thinking about how we can codify how we want to build our products together.

Our target outcome for how we want to work together

Benoit, the CPO at OCUS, and I have been thinking about this a lot and we decided to try to define the target outcome we are working towards with our team. If we could condense everything that we are hoping to achieve with the team in a sentence, we would say:

“Engaged product teams continuously create impactful outcomes by learning and making decisions through their weekly interactions with users.”

Let us try to expand this out a bit:

• Engaged – We want our team to believe in and feel energized by OCUS’ mission and vision and that their work directly impacts our mission. We want our team to enjoy what they do and the people they work with. Of course, it goes without saying that psychological safety, respect, and trust, are the foundations to build on.
• Product teams – Our Engineering organization is made up of smaller cross-functional teams who own a product – Product Managers, Designers, Engineers, alongside supporting roles such as research, test automation, and docs. The goal is to have many small teams with the needed skill sets to build products autonomously and with zero dependencies on other teams. When there is a dependency on external elements, we reduce our ability to continuously create impactful outcomes for our users.
• Continuously creating impactful outcomes – To create impactful outcomes, we need to achieve a continuous flow of value for our users. We are big fans of the book “Outcomes Over Output: Why customer behavior is the key metric for business success” by Josh Seiden. In it, he defines an outcome as “a change in human behavior that impacts business results.” This is the type of outcome we are trying to create – a change in our users’ behavior that has a direct impact on the top and bottom line of OCUS results.
• Learning and making decisions through their weekly interactions with users – As a team, we make decisions every day. Our goal is to make decisions based on as much user input as possible. If you are only talking and interacting with users monthly, then we are making a month’s worth of decisions without user input.

Our Engineering Operating Principles

How do we achieve this ambitious target for our team? We needed to define how we work by codifying our behaviors and rituals.

This is why we have introduced the concept of our Engineering Operating Principles.

You can think of operating principles as a layer below the OCUS virtues. OCUS virtues define the global behavior of how we will work together as humans. The operating principles define in a bit more detail how we will build our products, our organization and our processes.

We proposed and agreed on the following principles, and we expect to refine and evolve them over time.

User-centric – The user is at the center of our world.

Our purpose is to serve our users. At OCUS, we have multiple users, including but not limited to our community of photographers and our clients. We want to talk to our users every day to learn from them, test, and deliver results. We want to co-develop our product with them and not for them. And at the end of the day, service is everything; our team will go the extra mile to create delight.

Focus on outcomes, not output.

We value outcomes over outputs. We measure the impact of our features based on the impact we have on our users and the growth and sustainability of OCUS. When a team collectively takes ownership of outcomes, we start to break down the walls of “build the right thing” (Product) and “build it right” (Tech).

Collaboration – Product development should be a no-handoff, collaborative process. We should reject proxies.

The most efficient way to work is through collaboration. With teams composed of various needed skill sets, having access to internal information or direct contact with users is essential to success. There is no place for siloed information, siloed skills, and competition in knowledge work. Proxies only remove information or context from the flow. Through this model, we’re able to make the most informed decisions.

Visualization of our work – Show not tell

We believe that the best way to think is by mapping what we know visually and that conveying our work through storytelling is much more impactful than just spoken communication.When this context-oriented visualization and mapping are done together, there is greater alignment in the team and less need for rigid specs and stories written by Product for Tech to implement. This is why we have every team showing what they have learned, decided, and built during our weekly Wednesday demos to the whole company.

Creative Engineering – Think like a creative scientist (also one of the OCUS virtues)

We think and talk in terms of hypotheses and work on experiments to validate these assumptions. For example, we are trying to switch from saying “we are building feature X” to “we are testing our assumption that X will create a Y outcome for Z user.”We are not trying to build a feature factory. We identify our assumptions, gather evidence (or data), and build a culture of experimentation. The smaller and faster we run experiments, the better.

Continuous and rapid feedback is the core of our way of working. We make a small change, deliver the result into our users’ hands, get feedback, then adjust what we do based on that feedback. That cycle is as short as possible—minutes, hours, occasionally a few days—not weeks. This inspect-and-adapt loop applies to both process improvement and product development.

The changes we deliver are high quality. We expect to change, or even discard, everything we build, from products to organizations and processes. We take a test and learn approach to ALL of our work – everything is an experiment.

Continuous – We are continuously learning and building our products

Projects have a start and end. In contrast, a digital product’s lifecycle consists of one continuous evolution. When building a feature and with this continuous product mindset, discovery is not something we do at the beginning of a project. Rather, we infuse it into our development process. We want to make sure we build something that our users want and delight in. To do that we need to be able to quickly test our hypothesis at every step of the build process. Continuous is about fast feedback loops. The most effective organizations are learning organizations. Learning and discovering about both the products we produce and how we produce them should be continuous. Learning is not just a normal work activity; it is the work.

Hyperspeed – Move fast and break things, but don’t forget to step back and reflect regularly

At OCUS’ growth stage, we must move incredibly fast, which sometimes results in making mistakes. However, the benefits of moving quickly have a much more significant impact on our business that outweigh the mistakes we could avoid by going slower. Only a few of the decisions we need to make are irreversible and long-lasting, which of course, we take more time with. We believe that the most important ritual in Agile is the retrospective. Regularly, we must take the time to step back and look at the big picture so that we can review the decisions we have taken and learn from them to improve making the best decisions in the quickest time possible.

Where are we now and where next?

As a remote-friendly distributed team, we meet every quarter for an engineering offsite, which we aim to do in person over two days. In January, we met together remotely (thanks, Omicron!) and agreed on these as our operating principles.

We are currently working to operationalize these principles into how we work. We don’t just want some very nice words on a page somewhere. We have to embed these into the fabric of our work.

One of the first things we have done is level up the weekly demos we give to the whole company. Today our teams aim to show the work they have done in the previous week to the whole company and explain what they have learned from users and what has been decided based on those interactions. We have also started to give our users a voice by putting quotes from our interactions with them in our slides.

We have more to do, and I hope to write more about our journey as a team in future blog posts.

Thank you for making it this far. If you like what you have read perhaps you would like to come and work with us at OCUS?

Postscript

You will recognize many of the ideas and even quotes from these books and resources that have helped us and informed our thinking:

• “Outcomes Over Output: Why customer behavior is the key metric for business success” by Josh Seiden
• “Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value” by Teresa Torres
• Heuristics for Effective Software Development Organizations: A continuously evolving list.* by Allen Holub
• The Open Practice Library that I (Jeremy) built with my former team, Red Hat’s Open Innovation Labs. This is a collection of practices placed around the Mobius Loop. Our approach was an attempt to capture the set of practices that would enable the principles that we have outlined above. The goal was to provide a framework that enabled continuous discovery and delivery (the two sides of the loop) in teams in all sorts of organizations.
• Should PdMs “Write Tickets”? by John Cutler (who continues to heavily influence Benoit and I).