Finding Automation on the Path of Least Resistance

What is it about startups that have captivated our attention over the last twenty years?

While everyone talks about the money to be made, I would suggest for many the opportunity to solve problems from a blank slate without lots of existing bureaucracy is an equal part of the allure.

Starting fresh has obvious pros and cons. One drawback might be the lack of capital. One benefit might be the opportunity to rethink common wisdom of a problem. With those kinds of restraints, how do startups overcome the lack of capital and freely create? Historically, the Concierge Minimum Viable Product has proven a successful model.

If you are unfamiliar, the Concierge MVP might be boiled down to this: rapid testing with humans as proxies for software. With little access to capital and plenty of access to entry-level or unemployed workers, the Concierge MVP was a brilliant model a decade ago when unemployment swelled.

Mapping Ambiguity

But what about now, when unemployment is at historic lows? The Concierge MVP still makes a strong argument whenever there are high levels of ambiguity.

The Tesla Model 3 is a perfect case study of the importance of humans determining organizational patterns. After the early production failures of the Model 3, Elon Musk candidly admitted to CBS that he automated too soon and suffered as a result.

“Humans are underrated,” Musk wryly concluded.

In truth, humans are vastly underrated at turning ambiguity into heuristics and those very heuristics into a navigable process. In startup culture, Paul Graham’s mantra “do things that don’t scale” is famous. If that is true, then so is the inverse;

DON’T do things that DO scale.

So how do you determine scalable things? And how do you know when it’s right to NOT do them? Automation may take many forms, but looking for repetition is the key.

Once you start identifying valuable tasks your team is performing repeatedly, that’s when automation should become a consideration.

Rinse and Repeat

Why? The risk of stagnation rises precipitously once features and process become clearly defined without accompanying automation.

In 2020, existential risk comes to businesses when that process turns into work for more than two, three, seven, or one-hundred and thirty nine people and never gets automated. Sometimes these processes become so commonplace, it becomes a challenge to even spot the waste.

At that moment, there are two concurrent things happening on any team supporting a product. First, the product team is taking defined processes and automating them; more than likely this is happening through software engineering. Second, humans are freed up to navigate new non-scalable (yet!) processes.

Don’t Default Your Decisions

If we tighten our focus a bit, what happens in similar circumstances when this problem occurs exclusively for a team of software engineers?

During concurrent software development decisions must be made … but when? To answer the question Mary and Tom Poppendieck coined the term the Last Responsible Moment, which states:

“Concurrent software development means starting development when only partial requirements are known and developing in short iterations that provide the feedback that causes the system to emerge. Concurrent development makes it possible to delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative.“

Sound familiar? Partial requirements are like product team ambiguity. Development already underway is like an operational (albeit early) product. Concurrent development is like a combination of processes or people to accomplish a given task.

So then what happens when the Last Responsible Moment has passed?

“If commitments are delayed beyond the last responsible moment, then decisions are made by default, which is generally not a good approach to making decisions.”

Defaulting decisions simply means being forced into them. While this applies to digital product engineers, I think it can just as easily be applied to larger product teams too.

What happens when software engineering can’t keep up with the needs of the larger product team? Decisions default.

What do those defaulted decisions look like? Other teams like Sales Engineers, Professional Services, or Customer Success get tasked with more work: on-boarding new clients see delays unless a Sales Engineer steps in, frustration with the product might trigger free services for customers, unattended bugs spike the number of help requests for Customer Success to handle.

In the end a disruptive product suffers as more and more decisions start defaulting to human work.

• Unable to see opportunities for automation, product team members default into hiring in non-engineering capacities
• In hiring more non-engineers, the product team defaults into missing more automation and scaling opportunities
• Then missed scaling opportunities default the product to the exact same model as industry giants the startup sought to disrupt
• Next, customers default back to the more traditional product with better economies of scale
• Now with insufficient customers, the product defaults on their financial obligations

Take Me to the River

As I see it, the course new product teams should take is similar to that of a river. Product is an ever collecting confluence of people, processes, features, and data.

Initial surface runoff or small artesian aquifers are hard to distinguish as water courses, but as flows follow gravity they join and make larger and larger waterways. Streams and rivers start to cut deeper courses into the ground. Courses can change, but massive external influences become increasingly important to alter the product the further it progresses.

So how should product teams work through the lessons they learn by early iteration and apply it to automation?

1. Implement the Concierge MVP
2. Early customer feedback informs team learning and adaption
3. Product team feedback informs scaling and hardening through automation
4. Automation frees humans to assess new ambiguities through expanded scope

Which brings the team back to the start all over again.

So now that we understand the problem and the framework now what? The rest of this article will outline some signals of potential automation as well as ways which non-engineering team members can pioneer digital processes for the engineers who will follow along behind.

User Requests Are Hints, Not Noise

New products with new users will forever be hitting the bounds of what a product is capable of and for which it was intended. So when users ask about the lack of a feature, or are confused by a process in the system, or report a bug … how should a product team respond to them? Do you add human effort to fill in the gaps? Initially, of course. But when users keep hitting the same boundary over and over it is time to start documenting the process, and logging requests.

Ever heard the phrase water finds the lowest point?

Being led to the natural paths to automation is similar. Just like that ditch between two rolling meadows is a clue about where water courses during rainstorms; that repeated request is the point where user feedback groundwater turns into product tributaries. No one expects a product team to understand after the first, fifth, or maybe even the tenth time … but somewhere, those water courses are cutting deeper and the right answer becomes evident.

The billion dollar question then is: what do you do about automation before software engineers can handle it once you are sure you have the right answer?

Elon Musk was too early to automate manufacturing of the Model 3 and it cost Tesla dearly. But once the answer is clear do you take the time to begin the automation of that burdensome process which users keep bringing up?

While running out of cash is one of the most cited reasons for startups failing, I would argue that if many of those same startups looked deeper it was because they violated the core principle of the Last Responsible Moment, thereby defaulting into actions.

So why do teams do this? Competition for talent, access to capital, explosions of user requests … there’s a lot of reasons. But product teams who don’t adopt an engineer’s mindset are particularly at risk because …

Adding Humans is Linear

Keep in mind I said an “engineer’s mindset”, NOT “is an engineer.” Applying concepts like the Last Responsible Moment, leveraging the power of abstraction over the long-term, or internalizing the Three Virtues are the kinds of evidences of a team who have adopted an engineering mindset.

Let’s play out an operational business example.

Imagine we have a growing SaaS company. Every month our user-base is rising and we haven’t done much in the way of automating processes in finance, sales, and most importantly for this example, customer success.

Now let’s say we have five customer support representatives and they can handle about 80 support requests a day. By simple math we know that if we add two more reps we could increase capacity to roughly 112 similar requests per day, but at the cost of two entry-level salaries for our market. But what if we start to abstract the requests that are coming in? What if we classify and taxonomy the (now up to 100!!) daily support requests?

We might find that:

• 25% of the customer success team’s time is spent helping users navigate four particularly complex parts of the application
• 34% of the time logged by the team is focused on a complex new customer on-boarding procedure

Using engineering time solves the problem whether we have 100 or 1000 customers. As customers grow, if we’re solely hiring support folks to handle the requests, we’ll be hiring linearly with growth. Fixing the underlying issues through automation breaks that cycle.

Let me be clear, automation does not always mean coding. In this case, applying automation at first can be simple and becomes more elaborate later on. For example:

1. On the four user requests taking up a quarter of the team’s time, get the correct answer out of the Customer Success Representatives’ heads and into a knowledge repository with change tracking for the team. Then team members can use it to copy-paste answers, or as a means to educate new team members, or for others in the organization (required teams: Customer Success)
2. According to Zendesk, most users prefer to navigate online options first. Start to build out a Help Site for users with the work-arounds in order to cut down requests in the first place (required teams: Customer Success, Website)
3. Add this knowledge into a Zendesk playbook for support requests so that users can access answers from a chatbot before even contacting a team member (required teams: Customer Success, Operations)
4. Discuss prioritization of work-arounds into the product backlog (required teams: Customer Success, Software Engineering)

Well that takes care of the first set of issues, but what about the 34% of time assigned to customer on-boarding?

Improving the on-boarding process might be something where engineering help is immediately required to fix anything, but even the simple gathering of documentation (screen shots, sample files, etc.) ahead of an engineering team’s work will streamline the process. The more data and documentation the engineers have at their hands initially, the quicker they can fix the problem.

Once those items are tackled, we’ll incrementally gain about half of our Customer Success team’s time back to work on the next biggest set of non-automation offenders, thereby getting us out of the (defaulting) vicious cycle and into the virtuous cycle of making decisions ahead of the Last Responsible Moment.

Pursue Less to Do More

Like any up-front investment, mustering the resources to make all the automation changes we outlined above is the challenge, but over time the value could be re-applied to the strategic areas of where the product team needs to grow.

Lately, I have been trying to apply Greg McKeown’s book Essentialism to my work. In his book, McKeown doesn’t teach new systems of organization, but challenges us to stop reacting (defaulting decisions) and create space in our work by saying no and focusing on the big picture first.

To discern what is truly essential we need space to think, time to look and listen, permission to play, wisdom to sleep, and the discipline to apply highly selective criteria to the choices we make.

Greg McKeown

So how do we go back to our teams with this mindset to look for opportunities for automation?

In order to stop defaulting decisions, we need to get ahead of the Last Responsible Moment. To get ahead of the Last Responsible Moment, we need space to think, prioritize, look for patterns and collaborate with others to find those deepening tributary streams of potential automation.

Finding the Path to Automation

First, create space. Whether it is blocked time, an out of office half-day retreat. There are lots of ways to accomplish this. This step is all too often glossed over and teams suffer as a result.

Second, find ways to brainstorm and enumerate all the possible ways to, even marginally, improve the product. Facilitate your team to identify opportunities to make their jobs take less time.

Third, review and categorize user requests in order to uncover patterns. Begin to quantify the value to the organization of addressing them.

Fourth, prioritize items and start picking off some of the lowest hanging fruit before taking on the more complex items. Through some smaller and valuable projects the process the team will be able to build familiarity with this practice and see early momentum before taking on difficult tasks.

Lastly, use some of your team’s newly found time to go back to the beginning to look for more opportunities to delight the customer through the Concierge MVP process.

Initially, it can be hard to pick up the trail of this process, but once your team does it will be transformative. Following this model will lead to us better valuing of our time, of our work, of our teams, and ultimately of our products.