Go-to-Market (GTM) Strategies – Customer Onboarding

#customeronboarding #gtm 

In this blog post, we will discuss the importance of customer onboarding.

We will especially talk about how it can negatively impact customer experience to the extent of losing a customer.

A recent story comes to mind when I was filling a Free Application for Federal Student Aid (FAFSA) form for my daughter’s recent college acceptance. The government form was so complex and I ran into issues at every stage including creating user id, setting up 2 factor authentication, getting Internal Revenue Service (IRS) returns and everything else. The process also involves waiting 2-3 days for them to confirm my details with IRS. It has been 5 days and I am yet to receive the confirmation that my account has been approved for next steps by FAFSA at the time of this blog post.

The above process certainly frustrated me. I felt like running away, if there were any other options available. Sadly, there are not any options for FAFSA.

But in reality consumers have many options for everything in their daily life. Does a company really want to lose customers because of their onboarding process ? 

Losing customers at onboarding is like customers walking away before entering your store. You lose a lot more as you don’t get to learn about them – their behaviors, their habits, their buying power, their preferences.

There are many reasons why customer onboarding may not be the best. This includes things like:

  1. Complex processes – when several backend organization involved, onboarding often gets slower
  2. Lengthy wait time – delays in account activation can prevent access to underlying services
  3. Lack of training – Not having proper training or documentation can create confusion
  4. Inadequate support – Customers can feel neglected due to this during onboarding
  5. Regulatory – Asking for Physically identifiable information (PII) can deter customers

These are just a few reasons, why onboarding becomes slower and painful.

Here are some characteristics of a great onboarding process:

  1. User centric – A great onboarding process is highly user centric teaching them what they need to know to get started
  2. Action-oriented – The best onboarding processes focus on minimizing the actions to enable users to complete onboarding tasks quickly
  3. Informed – A great experience during onboarding should focus on providing immediate value of the underlying product/service at the earliest
  4. Constantly evolving – It is critical to monitor and keep tweaking the onboarding processes to continuously enhance it
  5. Holistic – A great onboarding process does not just get the clients onboarded but also prepares them for experiences beyond

Think of a measuring customer onboarding time and track it for improvement. It can be used as a competitive differentiation. Do a before/after video and use it for marketing. Use analytics to go deeper where customers spend more time than needed. Identify and fix those gaps.


Lastly, go through the onboarding process yourself on behalf of the customer. If you are not happy, your customer will not be happy either. Tweak the process until you are fully satisfied.

See an example of how one company simulates this process for their sellers here : https://help.gumroad.com/article/62-testing-a-purchase . Here is the reason why they created that feature – “to see what your customers will experience when they buy from you. This is great for understanding your customers’ experience and will help you hone in on areas that perhaps need a little tweaking.”

Businesses are moving in the direction to provide better customer onboarding experience. It is high time, we do that with our products/services as well, or else we will be left behind.

If you are not currently subscribed and want to receive GTM tips, please sign up here : https://productmanagementclub.com/newsletter/ 

Is your Product leaving money on the table?

Is your Product leaving money on the table? The answer depends on “who” is driving your product.

If Engineers are driving your product, it becomes a highly customized product. Services companies are born out of this approach. This gets the lowest profit margins for your products.

If Architects are driving your product, it becomes a highly configurable product. Many enterprise-focussed companies are operating this way. This results in lower profit margin for your products.

If Product Managers are driving your product, then this will maximize the profits for you, as most of the intended functionality will be available out-of-the-box.

As an analogy, think about the CRM application and how it has evolved.

Traditionally, organizations were getting this built for themselves. As a result, many services companies flourished building this for their clients. A little later, Oracle/SAP started building these applications. These applications contained a lot of modules, that had to be integrated during deployment. Needless to say, this was driven by Architects at these companies. As a result, this deployment was complex and needed a lot of manpower,  eating the profit margins for these companies in these products. Later on, Salesforce came into the market with a product-driven approach.  Look at where it has gone with its out-of-the-box product capabilities.

Examples of this sort abound in every company. We just need to look carefully to understand.

How to identify who is driving your Product?

When the requirements of the Product are discussed, observe who leads the requirements related discussion. Is it your Product Manager, the Architect or the lead Engineer who has the final say? Who is the final go-to person in case there are conflicts between these three critical team members on how certain functionality is to be implemented?

I have personally seen cases, where the Product Manager (PdM) was not confident about certain things in the newer architecture (a cloud-native architecture) and deferred the decision to the Architect. Ideally, the PdM should have taken ownership and performed the research to guide the team and the product.

Can a driver change in the course of product development?

It does not take long for change to happen, even when the Product manager might be leading it today. Reasons may include a newer technology (like the example above) or changes in the Product Management team. The new Product Manager may rely on the expertise of the existing team and leverage it more without intending to do so.

What is the remedy?

The Management team is the key here. The Software Development Manager and the Manager of the Product Management team are the ones to have a handshake about who will drive the Product. Any exceptions that happen should be pointed out quickly to these two stakeholders. Any changes in any of these teams (ex. Development lead, Architect, Product Manager or Product Owner) should be carefully planned and a close watch should be kept on how the team is dealing within, to ensure that the right person (the Product Manager) is driving the product.

Who is driving your Product? Are you able to spot the changes happening? And more importantly, how much is it costing your company?