Inside Out

Notes on seeking wisdom and crafting software

Understanding product signups

Table of contents

Signup and onboarding are the front door for an app. An inclusive and welcoming entry sets the stage for an engaging journey ahead. Recently I was part of a team hacking the signup flow for an enterprise subscription based product. We created a working prototype and ran a customer validation with more than 100 customer interviews.

My observations ranged all the way from being humbled to see the customer struggle to the moments of excitement seeing them derive value from the new experience. We learned at the end that customers are 2x more likely to actually use the product after completing signup in our prototype flow! 1.

This post is part of the series on lessons learned from the above exercise. Here are all the posts.

  1. Understanding product signups (this post)
  2. Fixing product signups
  3. Language models in signup
  4. Lessons in customer validation

We use Signup to mean choosing a product, making a purchase and creating an account. Onboarding is the set of steps leading to you discovering the capabilities and actually using the purchased product.

Our customers are small and medium businesses. Some of them already have an IT department and others have leaders who act as (accidental?) administrators. We targeted businesses in India for this exercise. The service provider (Company) works in the enterprise space. It builds several subscription based products.

Creating complexity

The world’s best signup flow is one that doesn’t exist. E.g., just lets you draw right away, that’s it.

Every step we add in between the landing page and actual app takes the Customer one step far from the product. Why do we add any step at all? Let’s walk backwards from the purchase.

Company is selling a high value product. Trial is available only if the customer provides a card. We will need a payment step for all signups. This involves bunch of bookkeeping - save billing details, Tax information, and there are regional trade laws which determine who can purchase a product. All of that fits in this step of how to make a purchase.

Now a payment is always associated with an identity. We need an account to learn who can use the product. With an account comes the complexity of preferences, history, recovery of credentials etc. We need to support these too.

We also need details of what the customer is purchasing. It could be one product or a bundled plan.

A product, account and payment is usually all that is required to make a purchase. E.g., take Netflix or Hotstar, you can create an account with “phone number”, choose a plan that works for you and pay. You start binge-watching in the next minute.

Since we’re set out to create complexity, let’s step up a bit more 🙈.

Depending on the region Customer belongs to, the plans offered by the Company could change. This can be inferred from the location information, or we could ask the Customer explicitly. Additionally, where also decides a set of promotions etc. for the later purchase part.

What plans to purchase can be complex enough to require a separate workflow to choose one. I come to purchase an email service, and now I get to decide if I need those collaboration features too! Company may treat this as a way to make Customers aware of the greatest and best features. As a customer, I get drowned in decision paralysis.

Company needs to keep abusers away. Let’s add prove you’re a human to the Who part.

Now we have a conceptual model to work on.

Complex signup flow
Conceptual model for signup consists of various steps indicated by WHERE, WHAT etc. we discussed above. Last three rows indicate the requirements on the flow by the three players - customer, company and compliance

Can we simplify this flow? Before that, what does success look like?

Success is faster value for everyone

How do we measure success of a signup and onboarding flow?

  1. Completion rate: # of customers who complete the signup vs those who started it. Higher is better.
  2. Time to value (i.e., using the product). Lesser is better.
  3. Trial to paid conversion: how many customers pay after trial period. Higher is better. Signup and onboarding indirectly affect this long term metric. A customer who could never use the product will never pay.

I learned that a higher (1) widens the funnel, but if you widen it too much it affects (3) negatively since the denominator becomes larger. A trial customer who never pays is a sunk cost to the company. A better (2) hooks the customer early and they stick around longer.

Seeking more info is a problem

Now, let’s dive into the challenges with the complexity we just created.

  • Large drop-offs and less completion rate
    • Do we need all the steps?
    • Are we asking more info than required? Are we inclusive to enable customers doing business on their phone (WhatsApp)?
    • Do we need to optimize for the market? E.g., do we support the local payment methods?
  • Higher than expected cancellations
    • Are customers choosing the right plan?
    • Are they cancelling because they end up paying for features they never need?
    • Are we providing enough guidance through the process?
  • Delay in using the product
    • Are we leading the customer to value?
    • Do they know where and how to use the products?
    • Are the customers not sticking with us because they can’t derive immediate value?

Solving for minimalism

”Simplicity is the ultimate sophistication.”

  • Leonardo da Vinci

In principle, our ideal flow should be as close as possible to the 3-step operation: product, account and payment. We tried to streamline the flow while keeping in mind the Customer, Company and Compliance perspectives.

  1. Product - bring in an optional simplified plan chooser into signup. Offer this as a LLM powered chat agent too. Educate the customer with onboarding content during the long pauses between steps, e.g., while provisioning the service. Show a personalized product portfolio with top use cases immediately after payment to allow discovery of value.
  2. Account - ask only the information required, defer it to as late as possible. E.g., use one of email or phone. Reuse first and last names in payment info or billing details.
  3. Payment - consolidate payment from multiple steps to a single unified step. Now, this had one unavoidable gotcha, govt requires mandatory OTP based authorization of the provided credit card.

To those configuring systems, accidentally

Our target customers are small businesses who get things done on a phone. They’re not trained to be IT administrators, rather they’re just wearing the IT hat only for unblocking their day job. How can we make their lives simpler?

  1. Guidance everywhere: our customer’s day job is not configuring services. They’re acting as a system administrator only for an hour. We created a friendly chat agent to guide them through the process. They also have the choice to talk to a human at any time.
  2. Phone for the win: small businesses operate from a phone using WhatsApp or similar tools. Our vision is to replace email with a phone number given the latter is ambient and much more accessible. E.g., can we make email optional? Can phone be the payment system? Or, your sign-in credentials? We partially met this in the prototype.
  3. Value first: focus on faster value and education. Post payment steps in the signup flow involves provisioning the product (side effect: longer waiting times for the Customer). We decided to utilize this pause for educating the customer on how to use the products in their chosen plan. We also brought in goal driven product showcase after the provisioning is complete.

Designing the prototype was an interesting thought exercise in eliminating the non-critical.

We prototyped few streamlined experiences and learned the trade-offs for some others. E.g., for a customer signing a Trial, should we ask for payment information? Maybe not. But there’s a catch: the metric “trial-to-paid conversion” is no less important than “higher signup completion”. Removing payment step will increase the latter at the cost of the former.

That’s all for this one!

In the next part of this series, we will focus on architecture for the prototype. See you there.


  1. The prototype never shipped. This series is fictional since it is just one person’s myopic view. Building the prototype was hard work of several individuals, and I’m grateful to have been part of an awesome team. Intent of this post is to share the learnings.