A company is a Silicon Valley technology startup that enables organizations to make more informed and confident decisions based on coherent data. The focus is on major financial institutions and banks, helping them in risk management by providing the ability to verify internal prices against independent third-party sources and delivering more insights based on their data.
In order to maintain system operations before full automation, people referred to as 'operators' were responsible for managing the system.
TL;DR
A product was growing, but all the capacity was directed towards client-facing features. The operational side was developed based on a leftover principle. When a new product owner joined the team, we decided to instigate changes. We conducted a study to understand who the operators are and what their tasks involve. This allowed us to prepare and validate our new vision for the product's operational side.
From an informational standpoint, the study was a success as we learned a lot. However, unfortunately, we didn't garner buy-in for development. Nevertheless, as the company continues to grow, updating the operational side for operators will become inevitable. And when that time comes, we'll be ready.
The company was young and in attempt to get clients was putting all the effort into client-facing features. But with the growth of the product operations features become increasingly cumbersome. More and more often we’ve heard:
“Ah, this feature will make the operator’s life even more difficult? Well, they’ll manage.“
— I've heard every release
Furthermore, all existing operator features were developed without consulting any real operators. At the time, they were all employees of our partner company.
Adding to the complexity was the intricate domain. We lacked access not only to operators but also to users.
Complex domain. All previous decisions were made based on assumptions
No access to real operators. And no other SME who would guide us
Two things happened simultaneously - we’ve got a few new people: a product owner who was keen to set up a user research process and a few subject matter experts in the domain. These SMEs helped us better understand our customers' world.
Collaborating with the product owner, we began brainstorming ideas for improving the operator experience.
We couldn’t follow any specific process as we had to do everything at once and resources were limited. We wanted:
Establish a connection with operators
Gain insights into the domain
Understand operators' tasks
Validate our hypothesis for both users and operators
Assess the current state of the system
And all of it in parallel with building client-facing features. In collaboration with the product owner, we started brainstorming what we could do.
We couldn’t do everything so we prioritized:
We’ll focus on operator’s work specifically. We won’t dive into the intricacies of the domain.
We will validate our hypothesis by building a quick flow where we’ll put all our knowledge and assumptions. By doing so we could learn about the operator’s work and test how suitable is our solution for them.
We've decided to take the chance and conduct a combined study: Interview first and usability testing second. It would allow us to uncover the operator's world in general and test our platform as well.
Based on our assumptions and what we knew about the current operator's workflow, we built a flow that would cover most of the pain points. Now operator had control over the data, everything was in one place, and the displayed data was relevant, actually allowing operators to make informed decisions (at least we hoped so).
The results were great. As planned, we were able to validate our understanding of the operator's flow. We understood the organizational structure, which helped us to figure out how external entities interact with our system. It also gave us an understanding of the people involved in decision-making during a customer lifecycle.
User testing confirmed that our assumptions were mostly correct. The new flow proved to be more efficient for operators, potentially boosting their productivity. Additionally, as more products were added to the platform, the need for this new flow became increasingly apparent.
Unfortunately, despite the proven efficiency of our new flow, the company decided not to invest time into the operator's side at that moment. Client-facing features, which potentially promised significant gains, were given higher priority
However, with the company's growth, updating the operator's side will become inevitable. And when that time comes, we'll be ready.
At the early stage of the company's existence, there might not be many investments in supporting features. That's okay, but we still have to bear in mind that as the company grows, the need arises, and the system should be scalable enough to accommodate these features.
We should take a change when we have an opportunity to do so. Even though the feature I built was not developed, we still learned a lot of valuable into that allowed us to make better informed decisions for other features.
Ksenia Gorobuk
Warsaw, Poland