Time To Magic

My friend Jerry Harrison introduced me to the phrase “time to magic” as the critical signal for onboarding. But in the process of onboarding, “activation” is not the same as “magic.” 

Activation in a self-serve SaaS context is getting the client “onboarded” to the point where they can create and realize value for themselves. The trick is that as technologists, we often want one path to get our users to the state that we consider “activated.” This solitary route feels like it respects the engineering principle of “DRY” - don’t repeat yourself. So architecting the one path that helps a broad swath of people feels like a worthy engineering challenge! 

Except the customer doesn’t care. The customer wants the value contextual to their situation and problem. The customer doesn’t care that the engineering is “DRY.” They do care that they can depend upon the product. It must solve their problem. They do not want to jump through your hoops or watch your videos. They usually don’t like to learn about your product at all. Education is a price they pay to reach their value. 

The customer wants “magic.” Magic solves their problem with far less work than they previously thought possible. Or magic could be when they get the emotional high of seeing the beginnings of the solution. But the key is that magic is about them and not whatever the founder/engineer had in mind. 

So many businesses promise magic. The neologistic adverb “automagically” seems to show up everywhere in SaaS offerings. But instead of magic, the user finds training. At the end of that training, they still have work to do. That experience is drudgery - the opposite of magic. 

At one level, the solution seems obvious: automate more! So much of what we do involves other systems. Make the machine do more heavy lifting, so the customer is along for a pleasant ride rather than being asked to do things or learn things. We can all agree this is good in principle. Where it breaks down is the desire to serve a broad audience. I hear, “we can’t do that for everyone” because of edge cases, different sub-market needs, and the like. The fear is making per-market investments that have a more-than-linear effect on complexity and codebase. Put another way, the beautifully DRY code gets wet. 

How to solve this? Can you be universal and automate the onboarding? Can you radically cut the time to magic? Sadly, the answer is probably not - and it’s the “universal” that needs to go.

In no universe is one serving all possible customers at the beginning. Customers are a river, coming in to use one’s material. Identify the segment that is 1) likely to be early and 2) easy to radically automate. Focus on them. They will realize high value - magic. Only then add more targets. Later - if at all - open to a DIY onboarding. The trigger is when the market value of one’s offering is so evident that customers are willing to deal with their edge cases with labor. This latter could even be a “software with a service” opportunity! 

Wes Bush writes that onboarding should be like “bumper bowling” - easy. I suggest that the shorter the lane, and the more I am the player releasing the ball rather than the ball itself, the more I as a customer will get outsized value for a ridiculously trivial time investment. 

For some customers, this is not possible. For others, it is expensive. But determining which sub-market can be delighted with minimal or no work on their part will create value and a relationship that drives economics. Put a different way: 

Magic. 

Photo by Almos Bechtold on Unsplash