Product Principles for Large Scale Operations

There is a lot of content out there on Product Management and Product Managers. But not enough content to talk about building different kinds of products. Just like how different businesses work in different manners, building products also differ significantly from one function to another. Building SAAS is not the same as B2C and building for Fintech is not the same as building for e-commerce. In this post, I will try to address specific approaches in building Large scale Products for Operations in Emerging markets. Yes, this is pretty specific but a lot of principles can be reused across. This is based on my experience in building Products for Supply and Operations over the years.

In most B2C companies, Operations is the last focus for Product Management team. We tend to build solid products for consumers before moving out of Google Sheets and Whatsapp for Operations. This is logical and there are a few reasons we do that.

1. Operations is internal. We have better control over process. We can manage with rudimentary tools and by putting people at the problem
2. We have tools to start operations with. Google sheets, Google Forms, Whatsapp, Google Maps have been very helpful for any operations team to work efficiently.
3. You move from People to Process to Product. Changes in Operations are more frequent than for consumers. The business is run for consumers, any changes there should be tread carefully. Changes in operations is a matter of efficiency improvement.

Eventually, the business comes to a stage where you cannot work without any product support. And then you build something. In this post, we will talk about some basic principles on how building for operations is different from building for consumers.

Optimize for repeat usage

Unlike consumers, users here use the product probably 10s or 100s of times a day. Take Swiggy where a delivery agent uses the app continuously for 8 hours a day. Or a Car service station where the manager follows the same process for every car that comes for service. After a point in time, all these will be muscle memory. The thing to notice here is to ensure the process is as simple and straightforward as possible. Every second wasted in switching tabs and clicking buttons leads to inefficiency. Any detail difficult to comprehend will lead to inefficiency. Eg., a reject/cancel option might be given a lower prominence to a consumer. While for operations, you might give it with equal prominence in Red. Help them follow their SOP (Standard Operating Procedure — simply the process flow) without much difficulty.

Use visual, audio cues and haptic feedback

When you do the same thing over and over again, you do not read texts. Add other cues so people know what it is and can identify faster. Texts are indeed important for new users and for additional explanation. Add other cues along with that. For people who cook, think of your kitchen cabinet. When you look for an item, you mostly identify it by knowing where it is, the size of the jar, the type of the jar etc. You are less likely to read the label on them. Another example would be a switch box. Labelling switches is good but colouring them also is much better.

Add diagnostic information

Unlike consumers, we tend to have direct line of communication with Operation teams. You get screenshots, video recordings, or even a better description of issues faced from operations team. Display the necessary information you need to debug issues faster. Eg., it is a good practice to show agent_id, order_id, timestamp, clear error messages on the screen so debug can be made easier. Saves a lot of time. A good example of this is Google Chat web tool. It has a Send Diagnostic Information option that takes a screenshot with all the necessary information so debug can be made faster.

Build for Process changes

One fundamental principle in building for Ops is that you always account for process changes. No matter where you are, the only way to improve efficiency is to constantly tweak your process. This means, product should easily support most process changes that can happen on the ground. Build capabilities such that the Operations teams can themselves experiment with the process changes they want without making changes to product. Eg., Let’s take warehouse operations. Instead of having perishable items in the front, we would like to move them to the back of the warehouse to save the items from a lot of heat. Or instead of stocking 50 units at a time, we want to configure different quantities for each item based on the demand. Operations should be able to do all of these without being constrained by product.

Understand Operations Metrics

Most operations work on a variation of the following metrics.

1. Inflow Volume
2. TAT or Efficiency
3. Quality
4. Variety
5. Cost

While building the product, you can keep these in mind. Does your product solve for the above?

Inflow:

What is the peak volume you expect? Is your system capable of handling such a scale? This is not just from Engineering infra POV, it also depends on how easy it is for Ops managers to manage such volume. Eg., Let’s say you are building a product for Customer Support which gets 1000s of tickets a day. Do we provide capabilities where it is easy for a manager to segment users based on product, time of task creation, escalation, membership type, product type, issue type etc?

This will help her in playing with her team structure to identify the most efficient format.

TAT or Efficiency:

This forms the core of any system. How much time does it take for an Ops agent to complete one unit of work? This depends on how the tool shows the right information at the right point. In the same example, does the agent have all the relevant information in the ticketing tool? Eg., if the customer has complained about the billing for an order, I would need to show the following information.

1. Customer information (Phone no, last contact, no of contacts in the last x days)
2. Order information (Item, type, order value, discount, charges, payment method, paid amount etc)
3. Relevant FAQs
4. Other tickets regarding the same order + from the same customer

The lesser information you have, the more they tend to have supporting tools, switch tabs and lose efficiency. At the same time, be cautious about showing unnecessary information. Very few tools and orgs do this right. This directly ties into optimising for repeat usage, adding cues etc.

Quality

Whenever operations teams try to increase efficiency, the first thing that will be hit is quality. But it doesn’t have to. A right product can deliver great efficiency at the best quality possible. Harder to do this without the right product. Identify your quality metric and create a feedback loop for the team to know their quality of work. Give realtime or periodic feedback.

Variety

How many different kinds of processes do you need to support? Let’s say you have a process of people picking up parcels from one or more places and delivering it somewhere (Think Dunzo or Gojek). How do you manage different processes for multiple pickups, multiple drops, size of the parcels, restricted items etc while using the same workforce? Using a common pool of workforce increases your utilisation except in cases where there is a need for a specific skill.

Your product should be able to accommodate slight tweak in process flows for different segments and ensure all of these can work in parallel.

Cost

Cost mostly will fall into the core operations. But it will be directly impacted by the other 4 elements described above.

Plan for Training

User education via overlays and other strategies might not work very well here. Users don’t read texts and instructions especially when building for blue-collars. There are a few ways of solving this.

1. Use audio, visual and haptic feedbacks as described above
2. Create an elaborate training initiative where every user is trained by the managers/training teams
3. Make the user complete a sample unit of work in a tightly controlled environment. Tightly controlled = Right and wrong is known very clearly and user is guided through it step by step.
4. Add relevant training videos and share it with the users.

Users are very smart, they figure out new ways of using the product that we haven’t thought of. If we do not guide them through the right ways of using it, might take a lot of lead time to correct it. This is especially true of new products and their adoption.

Hopefully, this provides some guiding principles for building operations products. In the next post, we will get one level down and look at how to go about building your product from scratch.

You should also read this, this and this if you are interested in related content.