How to Master Intent-Oriented Software Consulting: From Chaos to Clarity!

Recently, I was reading about intents and transactions in blockchains. Basically a transaction is a complex object where you have to worry about a lot of things with regards to having the right inputs, right outputs, right delegation to internal transactions, calling a smart contract from the other smart contract, and many other things including nonce management to make sure that the same transaction is not being called twice. There could be a lot of complexity when a user is sending a transaction to a blockchain. Some of that complexity is abstracted away by applications and wallets, but not all of it. On the other hand, there is the concept of intents. An intent is basically a description of an outcome that the user wants. For example, they might want to do something with a blockchain that produces a specific outcome - annual APY of a target percentage, or swapping tokens at a target exchange rate, and so on. So essentially, an intent is a much more simple and abstract version of execution details of (one or more) transactions. An intent tells you what the outcome is, a transaction tells you what the process is. Now there is a lot of debate going on in the crypto world whether we should have more of intent oriented architectures or transaction oriented architecture. But let’s leave it to that.

Here in this blog post I want to talk about a related topic, but in the broader context of software consulting or solution design.

Understanding The Intent

In my career so far, most of my time has been spent in talking to customers - understanding their business requirements and translating those into detailed technical solutions. And one thing that I’ve understood is the customer is always expecting us, and rightly so, to be the expert in solving problems using technology. The customer is not the expert. They cannot tell you the details or the internals of a system. These are for us to figure out. What the customer can actually tell us is their intent.

When we are tasked with solution consulting, where we interface with a customer and try to solve their problem, most of the time we look at it only from a solutioning perspective. Another way of looking at it could be from an intent perspective - understanding what the customer is actually trying to achieve, what could be enabled if this problem is solved. Having that clarity about the end goal, becomes extremely important when you’re trying to figure out where your solution fits in the bigger picture. If we don’t go from an intent oriented mindset, but an implementation oriented one, we have already lost half the battle. That’s when we have already given up on understanding the bigger picture. This is a mistake a lot of us make in order to find a solution quickly. We try to get into the details too quickly and that doesn’t help with understanding the bigger picture and the goal.

But if you have understood the intent, then you can solve the current problem and many more, if you have the visibility and clarity about the bigger picture. So having an intent oriented mindset not only helps with solving the problem at hand, but also helps in getting repeat business from the customer.

Intent vs. Solution

Let’s take an example. Let’s say you are working with a customer in the supply chain domain. They have multiple services and solutions deployed to serve their needs, but they are facing issues with data reconciliation. They are failing to understand why the data is not reconciled across different vendors and different processes when they have everything in place. And they called you to solve this problem. You are in a meeting with this customer and you are considered an expert in the supply chain domain. You have worked on building services and solutions to interact with and onboard supply chain processes. What would be your first question to this customer?

Will you be asking about what are the solutions/systems they have in place and how do they work?

Or

Will you be asking what are the problems they have and what they want to achieve?

It’s the latter that gives confidence to the customer that you are trying to look into their concerns instead of what they already have as a solution. So ideally, what you would start with is “hey, let’s understand what problem you are facing and what you expect as an outcome”. The next step would be to understand what they have in place that doesn’t work. Confirm if you have understood the problem correctly or not. Sometimes there is no existing solution, and you have to build it from scratch. Then you will have to come up with a different approach. But let’s say if there’s something in place, then you might want to understand that. Your takeaway from this meeting would be - what is the intent, and what is the existing solution. After that, you take a step back, look at the bigger picture and try to come up with a solution. Now would be the time to dive deep into technology and come up with something that achieves the intent of the customer.

Path Of Least Resistance

Next, the most important thing is that you’re not proposing too much of change in your solution. No matter how big an organization is, everybody is resistant to change. If you are asking them to redeploy everything, if you are asking them to change things too much, well, you’re not solving the problem. You are making the problem even bigger. So the first thing is coming up with a solution that does not create more than the required amount of change. If it requires something to be built from scratch, that is fine, but if it requires something that only needs a new component, we should only be looking at that new component. This is also a way of gaining the trust of the customer. If you are trying to sell too much in the first instance itself, you will be marked as a salesman and not as a technical expert. That is not what you want. Put yourself in the shoes of the customer and understand what would be the path of least resistance, and how can you make it work with the solution you are proposing.

Once you’ve figured out a solution that solves the problem, think about the optimizations that can be done on top of it. That would be the second iteration of the solution. There could be some updates/additions which could require more effort. This is for achieving the intent but in a more optimized and more cost-saving manner over the long term.

Presenting With Intent

And finally, you create a presentation about these two solutions with potentially two different stories. Option one that solves the intent, but is less optimized, is faster to deploy and faster to market. Option two - more optimized, achieves the intent in a cleaner way, has more cost savings, but has a little longer time to market. And finally, you should present a reasonable and sensible path to upgrade from option one to option two. Explain how you are going to deploy the less optimized solution to achieve the intent quickly, and then iteratively move towards deploying the more optimized solution.

You should have full clarity on how you want to explain it to the customer. If you go into too much technical detail, the customer could lose interest. If you go into too high-level or abstract stuff, they could get the impression that you are selling vaporware. So you need to have the right amount of detail while presenting your solution. And for that, you need to understand who is going to be there in the room. Reading the room is extremely important when you are presenting a solution to a customer, or for any other meeting. If it’s the CTO and his team you are presenting to, and there are less of the business people present, then you can take a little bit more nuanced approach to explain the solution in detail. On the other hand, if the room has more of business people, then you cannot go into too much detail of the technical solution. You have to show them the big picture - what they already have, what you are proposing, how it is going to work together, and how it is going to solve the problem. Try to do that with the least amount of technical jargon.

Summing It Up

There is always a difference between how a problem is going to be solved, and what is the expected outcome. As a technical expert, as a person who’s representing the technology side of things to solve problems, you must focus on understanding the intent first. And then you should design and propose the solution to achieve that outcome. Try not to ask or talk about the solution before understanding the big picture. Keep in mind that when you are being invited to a technical discussion with a customer, internal or external, you are expected to be the expert, not the other way around. Have the empathy about the customer bringing their problem to you. If they had the solution already, they would solve it themselves. So understand the problem, understand the desired outcome, and then propose a solution. The intent of the customer should act as the vision for your solution.