Getting your customer identifier right from day one.
Avoiding this one common startup mistake
This joint is really for founders and PMs who work in early stage software:
Steve Blank (my former instructor and professor at UC Berkeley) famously said that a startup is an organization searching for a repeatable business model. With an emphasis on ‘searching’ — meaning that startups should optimize for opinionated flexibility. In service of this ethos, a lot of the scale advice for startups in the last five years has been admonishment to do some things manually and defer scale until they find that optimum product market fit — you nail it and then you scale it.
I agree with this advice with a caveat. If you can nail it right off the bat, pls do so. I understand that a lot of first year code can/will be rewritten as we know more about the problem we’re solving and the customers we’re solving it for. However, I think some of the best companies make some good early decisions that allow them to keep moving quickly. I know many fast-charging companies that made bad architectural decisions that haunted them for years. And for some, those foundational mistakes took them off the chess board. Having a critical one of these errors can be a real drag on innovation, hiring talent and competitive velocity.
One such problem I have seen happen in recurring fashion, across multiple startups now, is the choice of a primary identifying key for your customers. A lot of companies use email as the primary identifier for customers. Thus customers use email to login and identify themselves. In many cases, they can only have that one email at a time, connected as an ID. Good examples off the top of my head is Atlassian, Amazon and many many other business tools you use and love.
Don’t do it. I don’t care how many bootstrap frameworks work like this. Don’t.
I have experienced three massive companies you know and love, work for months and years to move away from this kind of rigid identifying system at great cost. Most of the time, the reason is that they need more flexibility and the identity framework underpins everything. In B2B SaaS specifically, a lot of customers use their company email as an ID. As they move to different companies, they take good tools with them. But because company email is the ID, they have to ditch their old account and sign up with a new email at the next job. As a result, the customer loses their history and personal customizations* of the software. The product company also loses a way to connect/communicate with the customer and influence their retention during this delicate interregnum where they could always discover/choose a competitor.
The other anti-pattern I have seen is that in general, people have multiple email addresses and numbers. Some of these IDs are backed with real data that can and should be connected to your software to deliver a better service. Accepting only one of these as an ID can be sub-optimal for a software company and its products.
You should design customer ID systems to maximize these and other opportunities for your software and your product funnel.
Here’s my suggestion — the best way to construct an ID system for your customers is by using a unique unguessable** random number. We generally call these globally unique ids or GUIDs. You can now attach all kinds of other identifiers to this GUID to create a flexible system of identification. Multiple emails, phone numbers and even other GUIDs can be associated with AND dissociated from the primary GUID. Your customer doesn’t even need to now their GUID or interact with it in any way! They can just use any of the associated IDs to login and configure the software to their liking.
Join a different company? — you’re still you, just with a new email you can attach to your identity, jettisoning the old one. Have no email at all? — you can login with your phone number. If you don’t have either, no problem, you can ID yourself via your name and 2 other factors only you could know.
Here is what it could look like (among other possible schemes):
In this example, you have three emails connected to an account. Two can be used to login, the third cannot***. If the product uses calendar or email data or can send email on behalf of customer, it’s trivial to use the data represented by any of the email ids to deliver on the customer promise even though the customer uses only one of those to login; without creating different separate email fields for your customer.
This is not rocket science but I still see so many companies make this error. Don’t. Thank me later.
— — — — -
*Obviously, they should not have access to corporate data across accounts if they change jobs
** Unguessable by machines / computers not just humans.
*** For good security practice only one identifier should be able to be used as a login at any given time.