A year doing Product Operations at Ontruck
“I’m not sure what the tech team is doing. We requested that new feature two months ago, and this is all they have built so far”
“We spent three sprints building that feature that the operations team requested and they are not using it”
Do such statements sound familiar to you? They are examples of a frequent type of conflict between the Product-Tech and the Business (Sales, Operations, Finance, Legal…) teams in product-driven companies. It is a natural consequence of the team’s different working rhythms (sprint-based vs calendar cycles), ways to work (strongly focused on the topics selected for the sprint vs reacting to customer demands or operational incidences), and often even different kinds of personalities (nerds vs free spirits).
At Ontruck we have been working on bringing alignment at a company-wide level for some time now. About three years ago, we started using quarterly OKRs in the Product team. These OKRs are aligned with the Business managers and then used as a silver lining to define priorities and weekly sprints. We have also been working on our company culture, reviewing our core values, and implementing cross-company initiatives that help to build a company-wide, united team (such as creating a Diversity, Inclusion, and Belonging committee, or internal training sessions where managers from all departments are brought to work together).
And yet, we are no stranger to conversations such as the ones at the header of this article.
A year ago we decided to take one more step forwards to strengthen the relationship between our Product-Tech and our Business teams and founded a Product Operations team. Reporting directly to the Chief Product Officer, Product Ops serves as a facilitator in the communications between Product-Tech and Business.
The Product Ops team
We are Lari and Eli. Nice to meet you! 👋🏼
We both joined Ontruck a little over three years ago. Lari used to be part of our Live Traffic team, following all our ongoing orders and attending to shipper and carrier requests. Thanks to this experience, she has a deep and detailed understanding of our operations’ bits and tricks and knows all the shiny and all the hidden bolts of our products. I myself joined Ontruck as a Process Manager, documenting, measuring, and improving our operational processes. This helped me not only to acquire an overall understanding of how our products are used, and what the needs of our internal and external users are but also to build fluent relationships with key members in all other teams. All of this is of central importance to our function.
As you can see, neither of us has a technical background (if you are curious, please feel free to visit our LinkedIn profiles here and here). But we are both tech-friendly, understand and enjoy the work methodologies of the Product-Tech team. At the same time, we both have worked on the operational side, at Ontruck and other companies. So one could say that we speak both the product and the business languages.
Responsibilities under Product Ops
Of course, when we started a year ago, our idea of what Product Ops should do was not 100% clear. Instead, we had a general mission: to improve the collaboration and communication between the Product and the Business areas. And, as we usually do at Ontruck, we decided to get on with it, learn, and iterate fast. One year later we have a much more clear definition of our responsibilities, which can be grouped under a few headlines.
Usage of our products
Our goal is to serve as advocates of the Business teams in relation to the products and tools that we provide them to work with. In this sense, we partner with Product Managers and Designers to discover how our products are being used and what needs are not yet covered. At the same time, we nudge the Business teams to use the tools we have built for them.
Here is an example: On certain occasions, our Sales teams come to special price agreements with specific shipping companies. We needed a way to build those non-standard prices into our systems, to ensure that all orders were billed correctly. So our product teams developed an MVP and released it to the business teams.
From Product Ops we helped with training the Sales teams on how to use the new feature. After a couple of weeks, it became clear that the new feature was not being used as much as we had anticipated. So we conducted an extensive review of all accounts with each of our sales managers, helping them enter their agreements, and identifying pain points and use cases that were not covered by the MVP. We also spotted those agreements which had been logged into the system with typos or incomplete data, and bugs preventing the code to work as expected. In this way, working very closely with both the Business and the Product and Tech teams, we drove successive small iterations of the MVP. This feature now hosts dozens of agreements, for which we are creating accurate invoices without requiring manual adjustments from our Sales team.
Along these lines, we work closely with our Quality Assurance department by reviewing all bug reports, filtering out those reports arising from a lack of knowledge about our products, and triaging other reports to the most appropriate Tech team. On a monthly basis, we share key metrics of this bug report process with the whole company, both as a control measure to ensure that the Tech teams keep up their SLAs, and to de-subjectivize the stakeholder’s perception of how well we are dealing with bugs.
Process management
Being so close to the Business side of the company, while not having developers’ time at our disposal, another significant way to contribute is by reviewing the company’s business processes and helping the different teams make the most out of our tools as they are. In this sense, we also try to make progress in projects that are left out of the engineer’s roster for the present quarter.
As a recent example, looking at our internal process to collect PODs (the documentation that our carriers need to send us as proof of having delivered the goods) we noticed significant differences in the performance of each of our teams. So we defined some key metrics to represent this process performance, and on a regular basis, shared these metrics and derived insights with the managers and key internal stakeholders, to provide transparency about the situation and how it is evolving, and to motivate the teams to improve their performance. We also have researched the best-performing teams to learn about how they are achieving their good results and shared that info with the others. This is, by means of acknowledging and positively reinforcing the best practices, we are giving process management a flavor of competition. As a result, the teams are looking into how to improve their processes, the different processes are coming closer to standardization, and our POD backlogs are getting cleared!
In other cases, we take advantage of being a neutral party in processes that naturally bring out a conflict between different business departments. A clear case is our collections process. There we have, on the one hand, our Finance team wanting to collect all debts and to impose stricter guidelines onto those shipping companies who are not paying their invoices in time. On the other hand, our Sales team leans onto being as permissive towards our shippers as possible, looking to gaining more business. Conflict is served! How we have helped here is by listening to all parts involved, and mediating to reach an alignment. Along the way, we have also identified a number of major pain points that might be solved with iterations in our product features, and we have shared those insights with our product managers.
Knowledge sharing
Working at the frontier between Product and Business, Product Ops act as a central owner of knowledge over all our products. Whenever an internal user has a question about this or that feature, oftentimes they are not sure who is the best person to ask their question to, so they come to us. We either know the answer or go get it for them.
Keeping an agile mindset, we do not believe in writing extensive documentation for a product that will very soon be modified. However, we have built an internal wiki that we are continuously populating and updating with the minimum level of detail which is sufficient to conduct a crash course of new users or to refer to in case of doubts.
Challenges for 2021
So, here we are. A full year has passed since we started this Product Ops adventure. As we move forward, we continue to identify areas where we can make a positive impact in bringing the different teams at Ontruck closer together. Some initiatives that we are excited to explore and develop during 2021 are the following:
- Fostering knowledge exchange between our different regional units. We are testing our hand at creating different dynamics in the company (be it regular meetings or ad hoc get-togethers) to help the teams working in different markets to discuss with each other, share their best practices, their main pains, and the workarounds they have found to fight those pains. We expect this to have a positive impact on process standardization, and in building a stronger, global team.
- Centralizing user feedback. At Ontruck we have many sources of information about what is working, what should be improved, and what is missing in our products. All this information comes in different channels (email, slack, informal conversations, surveys, interviews, you name it) to our Product Managers, our Product Designers, and to Product Ops. And then it gets logged in different documents, lists, JIRA projects, etc. We want to explore how to build and maintain a central database of user feedback. Our goal would be to increase visibility, between our Product teams, and also towards our internal users. We would love for all Ontruckers to know what has been reported, what is being worked on when they can expect a solution and the reasons why.
- Advancing user research for our product managers and designers, helping them with topics that are relevant for the company, have not made it into the current quarterly OKRs, but our Product teams will probably want to tackle in the near future. This way we can prepare the grounds for when the big machines come in and start building.
And how do you solve these challenges at your company? Where do these responsibilities sit? How do you bridge the gap between Product-Tech and Business? We’d love to exchange points of view. Please do get in touch at elizabeth@ontruck.com.
