Your Customer's Goal

Your product is successful when your customers are successful.

I have spent months discussing "activation" with investors, founders - and their customers. The first two struggle to figure out the right metric for measuring or defining activation metrics. But their customers have a more straightforward definition: today, am I further on my journey to my goal than yesterday?

"Concentrate on the customer" seems obvious, but how do we do it? More importantly, how can we make our operations into a system that focuses on the progress of our customers?

A few decades ago, Eliyahu Goldratt wrote The Goal, in which he discusses a similar quarrel between operators looking at process metrics and customer-facing innovators focused on outcomes. This book, authored in the 1980s, does not speak directly about software or customer adoption of technology products. But it can teach us much about both.

In a previous generation of manufacturing management organizations, one would be responsible for one part of a shop floor. Supervisors manage success on uptime, output, and measure of "utilization" - for how much of the day is the equipment in motion? 

But this only worked in a well-designed factory that was facing stable, usually growing demand. But things change. Machines wear out better technology replaces them. Fitting new devices on the floor makes the layout more complicated. Markets change too; the specifications for the As the floor mutated with time and the market conditions changed, compounding alterations created inefficiencies rapidly. Old assumptions about "good" metrics became void. 

Goldratt points out that turning on a machine - activation - is a standard metric for productivity. You have lots of uptime on your machines! Hooray! But this is not necessarily related to its contribution to company profit. After all, if the machine's output has to sit in front of a bottleneck process, running it more or better didn't save anything. 

If anything, activation drove up expenses in labor, energy, and likely maintenance debt. At best, running the machine generates intermediate parts that go into inventory. Adding to inventory can look like a win to an accountant since inventory is technically an asset. In reality, excess inventory of unfinished goods and parts drives up costs: warehousing, transport, and upkeep, so they don't rot. Also, even though they might get booked as an asset, they are hard to turn into revenue. Intermediate parts are usually only usable in the company's manufacturing process - selling them outside the company does not usually work.  

Utilization, on the other hand, is when operating an asset contributes value to the organization. Counterintuitively, making a machine contribute better to the system might involve running it less. That way, it creates the intermediate parts in the quantity usable by the bottlenecks, but not more - no more business-destroying inventory. Then the machine can stay quiet, and we start to ask important questions. Do we assign teams to secondary jobs when the big hunk of steel is not running? What does this mean for our overall staffing needs - and costs?

Making money by creating valuable products for the customer is "the goal." The goal is about the whole organization rather than individual or squad performance. No tool or team is an island. Different parts of the system might contribute more or less based on how and when they operate. The links and signaling between them become crucial. 

In a noisy, dangerous factory, simple signals work best. In the Toyota Production System that Goldratt praises in his book, "kanban" cards get passed up and down the line to indicate the relative capacity of downstream machines. Based on cards in hand, upstream crews know how much to turn their efforts up or down to maintain flow. When I have more cards, I can ship more to the next step. 

This discussion of 1980s manufacturing can feel very far away from modern software. But there are lessons here. Let us apply the utilization/activation insight to user onboarding. Instead of viewing the factory as a parallel to internal operations, let's think of it as the customer's journey to generate their desired outcome. In this framework, we sell or operate one of the machines in the customer's factory. 

"Activation" is often about the use of our machine. For example, the measured behavior might be the user creating their first project or finishing a profile. But relative to the customer journey, these are arbitrary, like measuring the uptime of a given tool on the factory floor. Not irrelevant, but often not crucial. Where is the real bottleneck holding back the customer?

The answer can be scary because sometimes the answer is "not here." The product we are offering is not the key to their success. In this case, we should be unsurprised that they do not "activate" in the manner we might hope. 

If this is the case, we have options. One might apply the service to a different customer whose solution is in that critical path - put the machine in another factory. One might decide to use our knowledge at a higher level and manage other tools in the factory - move up the stack. Or we could change our offering to serve a more critical-path need: a product pivot. 

We should see our jobs as connecting our customers with value. Once we are sure we are crucial to their journey, we can ask how our onboarding brings them toward their "job to be done." 

If one is an app-building system, getting them to build their first app is not genuine "activation:" shipping is. Have our customers made the app available to their target customers? If not, why not? We need to understand how our service contributes to that goal. If they do not reach the goal, they will churn out, regardless of how well our internal metrics say our product "worked." 

There is a gray zone where we see an active user who wants to succeed but has not yet achieved their goal. And this is where things get interesting - we might not want them "active." Mere use or hacking around might not be on the path to utilization. In which case, just like on the manufacturing floor, we want to facilitate their "away time" instead of engagement. What do we do to ease their standby window? The win is that they are still in the factory heading toward the end of the line - whether or not they are engaging with our particular machine. 

This all matters even more because of how equity value works for a software-as-a-service business. The value is in the lifetime of the subscription: how long does the customer keep it? You don't care as much about the first month of use - you want the years of staying onboard. This long-term relationship requires that they achieve their goals. In general, there is more value in being part of a success story than being at the center of an unsuccessful one. Success comes from their goals. 

For the app builder in the previous example, getting the client to shipping means that the deployed application has some dependency on your platform. Continuing from that point creates recurring value to the customer without demanding more of their time. The easy path is to keep that bill flowing. And longer lifetime means the present value of that customer relationship goes up. 

The objection I sometimes hear is that one's product is "for lots of people," and so the company remains neutral about how it gets used. As a matter of permission, that's fine. But permission is not the problem - enablement is. They have a goal they have not reached on day 1 of their trial. Provide excellent service, connect with the other parts of their process, and take ownership of the customer's success. 

When the customer reaches their "goal," you will achieve yours.  

I am grateful to the community at foster.co for editorial feedback on a draft of this essay. All errors are, as always, my own.

Photo by carlos aranda on Unsplash