Easy come, easy go. There is a tendency to favor a quick on-boarding process for new software apps, especially with consumer oriented ones. We tend to fight the noise levels by lowering our patience thresholds for allowing new shiny objects to enter our digital lives. Maybe it’s an over-compensation, but it’s reality. Quick on-boarding is necessary in consumer apps, or you won’t even stand a chance, although the pursuit of real user engagement is equally important. Daily usage retention, seeing value (time “in” vs. value returned), being compelled to tell friends about it, and gradually increasing your dependence on it are all key factors in lasting stickiness. But in business applications, and even consumerized versions of enterprise apps, a fast on-boarding experience doesn’t always provide the stickiness required to reach a lasting value point. You will often need a longer on-boarding period in order to plant the seeds of value deep into an organization. However, it’s really about reaching the right balance, where the pain of insertion doesn’t come at the expense of a perceived high barrier to adoption. On-boarding a business app is more time consuming, but once it’s done, it won't be dislodged so easily. As a historical example, an extreme case of stickiness in enterprise apps is the ERP software “installation” (Enterprise Resource Planning). If you have been involved in one at a large company, you know how long it took to get it sold in the first place, to plan for it, establish an “implementation team”, change your processes as they didn’t fit the software process, integrate it (technically), deploy it, configure it, and finally train people and form an internal support group,- only to realize 3 months later that half the users weren’t still using it, and another third hated it. Try taking an ERP system out of an organization that has gone through that process, and it’s a non-starter of a conversation. ERP systems were the epitome of infinite and painful on-boarding. Today, SaaS has totally upset that balance, but SaaS apps still require on-boarding. And the degree of on-boarding will vary depending on whether the app is used for personal productivity where you don’t depend on anyone, or for departmental usage where you need a few people to use it, or a company-wide deployment where a lot of users are required to bubble-up the benefits. From an application point of view, deeper on-boarding can manifest itself along variables such as initial configuration by choosing from a list of existing choices, to a deeper integration across other existing systems like CRM, leads generation systems, or marketing automation solutions, as well as more formal people training. For a SaaS product, it's critical that your product becomes part of an internal process that answers the question, “this is how we do things around here.” Processes are the glue that binds organizations together. But how you gradually infiltrate the organization in order to cement your value is equally important. If you go for an all-out approach to on-boarding, it requires a great amount of mobilization from your part, as well as from the customer's side. If you are a startup, your resources are limited, so you will be limited by how many customers you can on-board using that method. Of course, you can compensate by having self-service tools, and that will work as long as they are easy to understand and use, or you will have another bottleneck, which is to train users. The worst situation you could be in is if you have a requirement to train people AND configure their systems for them, unless you have a lot of funding to hire a lot of people in customer support and training. But here’s the rub. Don't confuse a difficult product on-boarding process with a product that hasn’t reached