December 30, 2022

Understanding Systems at Work

This is a topic that will forever stay at work in progress stage. So, I thought you and I could benefit by sharing it out in the open. I am hoping to get some feedback from you.

Background

My primary mode of operations is understanding the systems at play in whichever domain I dabble. In a previous post describing the logistics node , I went on to describe the challenge of building product in sectors like logistics.

The number of workflows that are invovled in logistics is mind bogling. Building a product that would accommodate all the possible workflows of each stakeholder becomes a test of understanding the business and domain in depth before setting out building a product. This has been my biggest learning as a startup founder with Pipehaul. We had to rework the core architecture of product multiple times. The additional complexity as we increased our fulfilment operations.

At present, when working with product problems in domains like agri and logistics. I tend to break them into workflows made up of simple(individual) components.

Workflows : Defining its context

The Wikipedia definition is an interesting place to start.

A workflow consists of an orchestrated and repeatable pattern of activity, …. From a more abstract or higher-level perspective, workflow may be considered a view or representation of real work. The flow being described may refer to a document, service, or product that is being transferred from one step to another.

Every activity can be part of a workflow at work. Whether that being an order management system or a airport check-in process.

The more we think about it. The more encompassing the definition ends up. This is the messy part of this terminology which sounds obvious but hard to contextualise.

SAP is a tool that helps companies build their customised workflows to run their businesses. It’s a multibillion business because people in business like to create their own workflows.

Modern product development in sectors like B2B supply chains and marketplaces in agri-space are specialised nature of general tools like SAP. They are more customised and native to the sector and more intuitive for the people working in the sector.

Importance of Workflows

So, when you are the person tasked with building a modern product in these sectors.

• First, you will have to understand the overarching business.
• Second, you map the system of workflows functioning.
• Third and last, you will dissect these workflows in to components and derive the problem that can be solved with product.

See, we wrote a workflow ourselves. Let’s title it product building workflow. We will come back to it at the end.

The messy and tricky part is when you try to put it in action. Most people I have read or met can’t visualise and dissect product building into these 3 steps.

One of the recent examples of people who actually know their stuff comes in the form of 4 part series talking about logistics business, workflows and the problem to solve in this recent series by Jonah Mcintire . It was engaging and informative for me as a fellow operator in the space but I am unsure if the general readers can get much out of his posts.

Step 1 of Product Building Workflow: Business

Before we move to the main topic of our post. I would like to take a small detour about the aspect of understanding business where you are operating. This recent post by Ben Evans where he uses the analogy of Tractors and Rocketships is a nice explainer talking about it.

In other words, if you’re on a rocket ship, and it’s going up very fast, don’t argue about the thrust-to-weight ratio. The thrust-to-weight ratio is ‘lots’. Your aim is to keep it pointed roughly upwards and make sure you don’t blow up - you can worry about the revenue model once you get into orbit.

However, there are other companies that are not rocket ships, but instead look more like tractors towing a heavy set of equipment across a muddy field. ….. This is also another way to look at the recurring question ‘is that a tech company?’, which can also mean ‘is that a software company?’ or, really, ‘does that have the scope for a 50x return?’ Software companies tend to be high gross margin companies - in the 1980s they sold you a couple of pieces of plastic in a cardboard box for $500, which is one reason Bill Gates became the richest man in the world. Pure software companies can have very high leverage on success.

In logistics and Agri-space, most businesses are tractor businesses because you are in the business of trade of services or commodities. These are not software companies to begin with in the first place. They are using software as a tool to become more productive in their functioning. I will write more about it in a subsequent post.

Step 2 of product building workflow: Mapping

The work of Atul Gawande was really instrumental for helping me frame a construct around it. In operation theatre, many mistakes could be avoided if there is pre-operation checklist that accounted for all the tools required for the operation. He wrote a book called Checklist Manifesto, distilling the real use of checklists.

There is also a very good summary by Derek Sivers on the book which gets to the meat of it very quick and lays out the main point.

We could translate it for workflows as well. We have simple, complicated and complex workflows.

The canvas of how I see workflows play out is illustrated below.

The simple and complicated workflow are dependant solely on internal factors. People, business logic and systems developed from single component(activity) within an organisation.

Complex workflows are dependant on an another factor, domain (overarching business) within which these workflows exist.

Step 3 of product building workflow: Unpacking

A common workflow represented like a house is made of 5 components.

Simple Workflows : Individual components

To unpack the above workflow, we can use a simple component and re-create this house again. Once you can break a workflow into simple components, you can start thinking of making a product.

Most process workflows like Order Management system are simple workflows if you just follow the process(sequence of steps) part of it. If you are on the product team, this can easily help you build a product to re-construct the process and enhance it.

For example, if the order was dispatched after a lag of 4 hours due to reliance on printed out packing list. You come into create an integrated order management system. You would just create a packing list interoperable with the dispatch software.

Complicated Workflow: The seen and the unseen parts

In complicated workflows, people are involved. The relational rules between people which factors the org chart, people’s irrationality and traditional practices.

They are an amalgamation of simple components and people diktats that are hard to divide into simpler components.

Most products that are changing complicated workflows find it hard to succeed.

The people building the product are expected to succeed once they unpack the process flow alone. It’s the easy and seen part. The unseen part is the people aspect which is often missed. This is where the skills of the product lead tasked with bringing the change needs to engage and empathise with the people involved in the workflow.

Most times, it makes logical sense to adopt a better product. But habit and system incentivises the people involved to stick to pre-product workflow. The critical function to making them change is to help them see progress that the product could deliver and doing it emphatically. In most times, it changes how people interact in the workflow.

Going back to the same example of packing list. The person who is loading the dispatch doesn’t have the provision of using the phone. This may be because on the floor no cell phones allowed. Then what do you do? It is usually these things that are unseen and related to people that are hard to navigate.

In the end for the product to succeed, we need to factor the change and advocate for it while building the process workflow with simpler components.

Complex Workflow : Adding Uncertainty

One good and relevant workflow change that originated with a better product is mobile boarding pass.

With web check-in and mobile boarding passes, the entire process of needing the printed boarding pass only changed. Yet, the contents of the boarding pass remains the same even today. The same barcode is scanned. But, by building a product they changed how people interact with it which resulted in solving a pain point of the passenger of standing in line for check-in.

The complex workflow in this case would be the entire boarding process in an airport. The mobile boarding pass was not sufficient for boarding until all the airport had barcode readers to scan the boarding passes at security check. This entire workflow changed but the factor of change didn’t rest with one airline or airport. It had to be adopted industry wide for it become successful.

When the first mobile boarding pass started, the product person would have been uncertain about the evolution of the product and overall adoption.

Product Development approach: Become a change agent

In sectors like logistics and agriculture which are filled with complex workflows. The critical skill of the product person comes from doing step 1(business/domain) and step 2(recognising the workflow) in product building workflow mentioned earlier. It helps in providing the right optionality before moving to the final step 3(product development).

A good product changes the workflow and engagement of people in the workflow. The product lead acts and operates as a change agent advocating about the progress for the people involved while executing their own workflow.

Singing off till next time,

Vivek V.S, unpacking complex workflows.