Product-led growth from the start

I’m turning my side project into a small application, applying product-led growth oriented tactics.

In the previous post I spoke about tracking user behavior. I built a single page website which checks SSL certificates for expiration.

Over the past few weeks I decided to take haveibeenexpired.com to the next stage. Instead of helping users every time they visit the website, I want to build an app. The app will constantly monitor SSL certificates, and alert users towards upcoming expirations.

This time I want to focus on how I introduced growth-oriented features. While there’s nothing jaw-dropping about my app, I can still make a strong impression. I want to have a very steep ratio between how little users need to ‘give’ to the app, versus how much they get in return.

The currency of cost and value

User cost is mental energy. Every bit of text, every checkbox or button — all require mental energy. By paying attention to my app, users are already investing in me. I don’t want to take this investment lightly.

User value is about the problems the app is solving. What do they look like before and after the app does its thing. For example, think about Calendly. Before — back-and-forth emails to schedule a meeting. After — a single link and a single attempt to set the right time for both parties.

Types of product-led growth hacks

Before I built the app, the website was already providing value to some users. The user cost was to understand what the site is about, and where to type the hostname they are after. The value was a one-time report on the expiration of the SSL certificate of the host. This is very transactional — you come for a query, you get the value, that’s it. More value requires more user cost, and I don’t think users would come back that often.

Exponential value over time

Moving from the simple website to an app, I gain the time dimension. The app keeps track of the hosts you’re after. Mention them just once, and get value from the app indefinitely. This is a compounding effect, but it is linear with time. The app would only monitor the hosts it was given, day after day. I want to make it exponential, but how?

There is something inherent in my problem domain that has an exponential quality to it. Every single SSL certificate can lead to many others via its subject alternative names. Every single domain can expose a bunch of SSL certificates issued for its hosts. I took advantage of this quality, explaining it in the previous post. I also used it to engage in wider marketing activities from the start.

Now is the time to bind this force and increase the user value I’m providing. With just a couple of domains added by the user, the app can discover relevant hosts in these domains. I am not asking the user to feed the app with every hostname that interests them. Moreover, I’m future-proofing the problem! The app will continuously pick up any new relevant host that gets a public SSL certificate issued for it. One important aspect here is to avoid clutter. The app will only add newly discovered hosts as long as they belong to one of the domains the user is interested in.

This is where I go from linear to exponential compounding of value over time. The app learns about what interests the user, providing more value with every passing day. All this without asking for more user input!

Guessing the users’ intent

The other side of the coin in these transactions is user cost. A way to reduce it is to ask the user for less, giving them less decisions to make, and guessing their intent. In the previous post I described adding URL parsing to the hostname field. That’s one example of reducing cost. What more can I add in the app to reduce cost from the user perspective?

Here are several examples of what I wanted to have in my app from the start:

• Upon sign up, the domain of the user’s email is being added as a relevant domain for scanning. Yes, perhaps gmail.com and the like would be superfluous. But if you sign up with your company email address, I’ll spare you the need to tell me your company domain.
• When checking hosts as an anonymous user, I keep track of the last search term in the user’s session. Once the user decides to sign up, the app would add the last searched host to the account. This again spares the user of the need to repeat themselves.
• Domains and hosts serve different purposes in my app, but they have some overlap of meaning. I want to spare the user from saying the same thing twice. When the user is adding somesite.com as a domain, it is automatically added as a host as well. The domain is used to discover more hosts, and the host is used to monitor its own SSL certificate.
• Intent is not only geared towards adding data. Sometimes you want to ask the app to do less for you, and it shouldn’t be hard. When a user deletes a domain from their account, the app will also delete all the hosts belonging to this domain. The implied intent is this — if somesite.com doesn’t interest me as a domain any more, neither do the hosts in this domain.
• The relations between domains and hosts in the app should not be restricting to the user. A user may add a host that doesn’t belong to any existing domain, and have it monitored. However, newly discovered hosts within the same domain will not be added to the account. No need for input validation flows that will introduce friction for the user.

These simplifications rest on assumptions which will not be true 100% of the time. Some users may be annoyed at how the app guesses their intent. Others would prefer more strictness than simplicity. This doesn’t deter me from taking these risks. Making no decisions to keep all users equally happy also means keeping all users equally unhappy. I’d rather start several experiments in an attempt to focus on the users who would value my app more, and adjust course as I go. After all, everything mentioned above is just a few lines of code, and can be reversed or deleted very easily. Tracking engagement is key for these experiments, and I’m only getting started.

What’s next?

I still have quite a long list of todo’s that would be valuable to the app . API endpoints, granular notification settings and more. The urge to keep on building is strong, and resisting it requires some focus. I believe I have a viable v1.0 of the app, and I want to focus on marketing it to see the acquisition and engagement I can get. Better let users guide me towards what’s needed, rather than keep going within my own mind.

I have a strong starting point for user acquisition. I have a two-months-old AdWords campaign, which saw some tuning. I adjusted geographies and negated some irrelevant search terms. I’m now seeing 10% CTR — for every 1,000 times the ad is shown, 100 users click and land on my site. Furthermore, ~50% of users search for at least one host. That is, the funnel is 1000 ad views → 100 visits → 50 host checks. Let’s see how many of these users sign up!

As for engagement, a basic metric is the amount of domains and hosts added by a user. But since there is a lot of ‘intent automation’ around this, I want to go for something clearer. I’m looking for a user action that once taken, clearly indicates the high value my app provides to that user. What shall I use?

Notifications are the app’s main value offering. Informing the user about an upcoming expiration, allowing them to replace an old certificate with a new one. I decided to forego email notifications for now, and stick to a simple Slack integration. Hence, the ‘moment of activation’ would be enabling these notifications! The engagement metric I’d be after is the portion of users who go all the way to add the Slack integration to their account. Let’s see where

Lessons learnt

• Product-led growth hacking is about reducing user cost and increasing user value.
• Value compounds amazingly well over time. Maximize the mundane stuff your app can do for your users, don’t settle for linear growth over time.
• Reduction of user cost requires risk taking. No decision will work equally well for everyone.
• Tracking and measuring is key. A single metric for acquisition and another for engagement should be a good start.

I’ll be launching the app publicly soon. I want to devote as much time to marketing as I’ve devoted to engineering these past few weeks! Stay tuned for the next update, I’ll share how the decisions above have worked for me.