Two questions to ask when you build automation
It's easy to focus on the technical effort to complete an automation when asked, instead of stepping back to assess the benefit. Read: "Everything Starts Out Looking Like a Toy" #204
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: a developer built “trading cards” out of e-ink. It’s a hobby project, but makes you consider why e-ink displays haven’t shown up in as many consumer appliances as expected. The likely answer? People probably prefer displays with color and don’t optimize for low power consumption. Edition 204 of this newsletter is here - it’s June 24, 2024.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ Two questions to ask when you build automation
One of the first factors that emerge when you discuss building automations to make a team’s life easier is the potential time saved. You get there by multiplying the time saved by doing the task today multiplied by how often you do the task. This gives you a rough order of magnitude to estimate how much effort the solution might take to build before it’s not efficient.
When I fall into this line of thinking, two resources come immediately to mind. The first is this XKCD comic, which gives you a handy table to estimate time and effort:
The second is the Mythical Man Month by Fred Brooks - a classic example that adding more resources to a problem does not necessarily make it faster to complete.
Designing automation too often focuses on the time saved instead of other benefits. It assumes that resources (and compliant behavior and design) will be available to solve the problem in a way that makes sense.
Resource consumption and time saved miss this point: what’s the overall outcome of solving the problem?
When you need automation, ask these questions
Here are two ways to quantify the benefit of automation:
Is the value delivered by this solution significant? If we can’t quantify the benefit or if the value is uncertain, it’s hard to prioritize this solution even if it saves time or makes things easier.
Given what we know right now, how difficult is this to complete? The harder the effort to solve for this problem, the more benefit is required. And don’t forget that we might be missing some difficulty in the initial assessment.
A bonus question: don’t forget to ask why they want to do this.
With this in mind, many potential automations fall into a few buckets:
Yes, we should do that, and it’s hard to justify the effort
Yes, we want to do that, it makes sense from a value perspective, and we know how to do it
Maybe do it, if we can figure out how
Nope, not doing it, doesn’t make sense from value or cost standpoint
Applying this framework in practice
Using the 2x2 of difficulty (how hard is it to do) and utility (how much benefit does it deliver), we end up with a quick way to think about automations.
These are the most common buckets that show up.
Nope.
These items are high difficulty and low value delivered. When the team asks you to automate something they do in the browser that is difficult to script but relatively easy to do by following a few steps, it might fall into this bucket.
“Help me assess whether this prospect’s website has a staff page.”
Try not to do these things.
Why?
These items are low difficulty and low value delivered. However, there is often a hidden benefit in the proposal that needs to be uncovered to assess whether there is enough benefit or a low enough difficulty bar to approach this automation.
“I know this needs to be easier in Salesforce, because I do it a lot and it feels hard.”
Discovering the real story and diagnosing what needs to be done is important.
Possible.
These items are high difficulty and high value delivered. It’s usually easy to see that they will generate success if you can get them done in a reasonable amount of effort and time. I call these “possible” because they do not always make sense to complete even if they deliver value.
“I’d like to save time on this multiple-times-daily task because it will help me sell better and close more deals.”
One way to hedge your bets here is to find non-automated ways to improve this process and then automate it if the other benefits work (think of it as a prototype).
Yes!
These items are low difficulty and high value delivered. It would be great if everything fell into this bucket. They’re easy to do, so they get solved pretty quickly.
“When [an important thing happens], I’d like to get a message in Slack.”
One really good way to find new automation examples of this type? Ask yourself: is there a key event that’s easy to catch and has clear logic to follow when we find it? It might be simple to complete, but very high value to complete consistently.
What’s the takeaway? Ops teams can unlock significant value by pursuing automation. Your automation needs to solve important problems with the right amount of resources. By focusing on discovery, you’ll be able to identify the organizational benefits faster. (And hopefully, avoid building in the Why? and Nope. quadrants.)
Links for Reading and Sharing
These are links that caught my 👀
1/ Pricing as a lever - The team at Equals writes about finding pricing product-market fit through pricing changes. It’s a good case study of dramatic changes, which is not always how you think about changing pricing in a Saas company.
2/ Prompting is a language - Read this story of an experienced devops engineer and how he tried coding using AI tools to create a prototype using an unfamiliar language. When you see the prompts, you get insight into effective ways to use these tools. Specific prompts make better results.
3/ How much documentation? - Simply said, how much is enough? Kent Beck writes:
The question is not, “Do you have documentation?” but rather, “Do you communicate clearly?”
Well stated.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon
Love this! It's a bit of a variation of the PICK matrix, and that has helped me a ton in the past.