“A buddy of mine” has been building a dating app, so I’ve been thinking a lot about services which connect people.

In an abstract sense a lot of the companies today are services which connect people in some context. For example

• Tinder / Dating Apps : Connecting people in the context of dating
• LinkedIn / Other Job Service Portals : Connecting people in the context of job finding
• Facebook / Twitter / Social Media : Connecting people in a generalized context [Often manifested as information sharing, community organizing etc.]

There are also services such as

• Uber / Other Ride Hailing Companies : Connecting people in the context of transport
• Food Delivery Companies : Connecting people in the context of food

But these services connect people as a means to an end for the job to be done, which would mean that if it made economic sense for these jobs it would be done without connecting people. In essence the people aspect of these services are fairly undifferentiated or another way of putting it is that the job aspect of these services are fairly standardized.

That is not the case with companies like Tinder, LinkedIn. People come to Tinder/Dating apps with an explicit intention of meeting people and connecting with other people, that’s the same case with LinkedIn/Other Job service portals since if those jobs could’ve been done without people they wouldn’t have been there in the first case.

In essence the defining characteristic of these services which connect multiple parties is the much longer time duration or the much higher commitment of the connection, which in turns brings forth the uncertainty of the future match and fit which I explore below.

The term “connect” the way I’m using it here means any form of relationship between two parties. These parties can be individuals or any entity such as a company or a firm. So in the case of dating apps “connecting” could mean having an actual human to human relationship, in the case of job searching apps “connecting” could mean an employment relationship between an individual and a firm and so on. I’ll also be overloading the term entity to refer to the party seeking/initiating the connection and individual to refer to the party who is interested in connecting. So depending on the context it could mean either an organization or an individual.

This post is an exploration of how people generally connect to each other and how services which are primarily built for that use case facilitate them. I’ll also look at what are the commonality between these services with a focus on what new services coming up in this area can learn from them. A lot of the content in this post might seem like over generalization but it’s done to extract the common elements between services in different domains.

Finding Connections 🔗

From the perspective of an entity who wants to connect to another individual, the general steps taken are

1. Find prospective individuals who are interested

2. Filter from prospective individuals based on some matching criteria

3. Connect with the matched individuals for a duration of time

   a. If it “works out”

   • You are done, you’ve found the entity who you would like to spend time with.

   b. If it doesn’t “work out"

   • Try again from 1

Usually this whole process is repeated parallely, such as in the case of organizations who may have the need to connect with multiple entities simultaneously.

Thus the services which facilitate connecting people have to make all of these steps possible. We’ll look at how each of these are usually handled by the interacting parties and how the services can possibly help them.

1. Finding prospective individuals 🔗

It turns out most often when entities want to connect to other individuals, they don’t have a specific person in mind (because if they did they wouldn’t be performing this search in the first place and instead would be connecting with that person). But instead have some sort of filtering criteria. This filtering criteria is a spectrum between anyone and everyone (as is the case with blind dates) to being as rudimentary ( such as “I want someone nice” as is often the case when people go on dating) or as complex (such as “I want someone who knows Golang’s scheduler”) as the entity wants. In sufficiently complex organizations coming up with this filter itself could become an arm of the organization.

And this is the first main use case that is solved by the service, they aggregate sufficiently large amounts of people such that any filtering criteria from any entity would ideally return >0 individuals.

Having a lot of people on a service for connecting people is more important the more general your use case is. For example if your service is used for general job searching than it extremely important that it has people who can do all kinds of jobs and it is more likely you’ll have people who can do all kinds of jobs the more people you have on your service.

There is clearly an element of network effect with these services in that once people realize a particular service can help them connect to an individual the more individuals who want to get connected would join the service which in turn increases the belief that you’ll find people you want to connect to on the service and so on.

This is one of the most common problems for budding services in this space and one of the biggest selling points for existing incumbents.

But all is not lost, since unlike traditional “winner takes all” situations, most people have no cost of being on another service which markets itself in connecting them to their filtering criteria. In fact they are incentivized to be on as many services as possible to increase their chances of getting connected. This is usually the argument made by a lot of new services entering into these spaces.

This brings us into the question on how do you find prospective individuals to join your service. This is the classic bootstrap, chicken/egg, cold start or whatever you wanna call it problem. Before you solve this problem you need to decide which way you want to go.

You can either be an aggregator where you would bring in all the individuals yourself and reap all the benefits of connecting people yourself or you can be a platform which outsources the bringing in the individuals to other entities on your platform.

If you choose to be an aggregator you need to actually solve the bootstrap problem yourself. I’m not going to go into details of how to do this ¹. But a common method which is in vogue is to create an artificial scarcity and drum up demand for that, playing to people’s classic fear of missing out.

With platforms you don’t have to worry too much about bringing the individuals yourself so you can focus on building tooling/common pieces, but you need to share the benefits of connecting people between you and the entities on your platform who bring in the individuals.

Specificity Guarantees 🔗

If entities have relatively specific filtering criteria, then they prefer services which provide guarantees that they have individuals which match that criteria over general purpose services. This is usually because there is a cost of matching discussed below as well as the more specific service ideally would have solved the problem specific to the filtering criteria. This is why Matrimonial sites can exist even though there is Tinder, LinkedIn can exist even though there is Facebook, and why TripleByte can exist even though there is LinkedIn and so on.

As an aside the more specific guarantee you can provide and deliver the more value you can deliver to everyone, since it saves time and benefits everyone.

This specific guarantee property implies you can start a service of connecting people which fulfills an extremely niche filtering criteria and if you deliver on the guarantee while solving specific problems in that niche it would still be valuable for the people who care about that filtering criteria.

This is in line with the standard startup advice of starting with a sufficiently small niche of the market which you can monopolize.

2. Filter from prospective individuals 🔗

Most often the filtering criteria entities apply are lower bounds/bare minimum to find as many individuals they can. This could be intentional in some domains but even if it’s not intentional the filtering criteria is usually loose for a variety of reasons such as

• The entity might not know what is the “best/ideal” individual for their requirement.
• It is impossible to exactly specify which individual would meet any sufficiently complex requirement.
• The individual might be a perfect fit for the entity’s requirement but not vice versa.
• Most often entities have tolerances built into them and as long as an individual is within the tolerance and gets the requirement done that’s okay.

Even if the entity does end up specifying a sufficiently strong filtering criteria there would be multiple people who match that criteria in a sufficiently large population.

I’ll be mentioning matching a bunch of times below. It makes sense to formalize it a bit. At the risk of overgeneralizing, I propose each individual or an entity has two functions

1. Requirement function which will encompass all that the individual/entity needs. This will be a function of possibly many different things but generalizing again it would be a function of time and environment. An example of a requirement function would be a firm’s need for Java, a person’s need for a companion who lives in Lisbon etc.
2. Production function which will encompass all that the individual/entity can provide. Similar to above we’ll generalize this as a function of time and environment. An example of a production function would be an individual who can write Java 8, a person who can move to Australia etc.

With these defined, we can define matching between two entities i, j as an activity of minimizing R_i - P_j + R_j - P_i over the time of engagement. I’ll call this the matching function. And the best connections as those which have the above minimized.

The thing that becomes immediately obvious is that it is impossible to find exactly the future values for requirements and productions of an individual or entity. But in most cases it could be estimated to a fairly good extent at least on a sufficiently small time scale.

In the most ideal case you would want to do a complete run of the function of R_i - P_j + R_j - P_i from time 0 to infinity with each individual who matches your filtering criteria and pick the individual who minimizes that value. But that is not just possible and generally there will be opportunity costs which manifests itself as a constraint on time. In the extreme case where the time constraint is too high the usual approach taken is to find the first individual which matches the filtering criteria and connect with them. This is often the case with seasonal jobs which have a certain peak around a particular time and an organization has tremendous incentive to fill it with any worker who can do those jobs.

But assuming there is some amount of time and incentive to get the matching right, most entities and individuals use a variety of heuristics to estimate the matching function.

Since it’s traditionally believed that most individuals are creatures of habit, one of the most common ideas in evaluating future fit is to look at past requirements and past productions. We see a lot of application of this in the heuristics people apply to estimate the matching function.

Some of the well known heuristics for estimating matching functions are

• Resume/Profile screening based on past information

• Qualitative Interviews

  • This is the formal process most often employed by companies where there is a qualitative assessment of the individuals fit for the future requirement. Most often this provides some clarity on the production of the individual and the requirement of the company, but rarely gives insight on the production of the company and the requirement of the individual.

• Skill Based Assessments

  • This is usually the preferred mode of estimating matches if the requirements are undifferentiated and could be standardized and tested

• Trial Runs

  • In the relationship domain these are often referred to as dating where you perform some of the tasks you would normally would have and see how well that works out. In ceertain jobs these are often implemented as internship.

When most entities and individuals try to estimate the value of the matching function they do so by using some heuristics and they do this parallely with multiple individuals. This might not necessarily lead to the best connection, but given the tolerances of an entity/individual and the constraints on time most have converged on this approach.

Since production and requirements of individuals are so multidimensional and it’s hard to exhaustively capture the past values of these let alone the future values, most services offer very little to solve this problem for their users. The most common thing provided by these service are rudimentary tools for filtering based on captured past values of production (which usually is self reported) on some dimensions (such as education experience, taste in music) and self reported future requirements on some dimensions (such as expected salary). Services do offer some mechanism to run some of the heuristics the entity/ individuals would run but this is often only possible if the heuristic measurements itself are standardized (Such as skill based assesment based filtering). There might still be some innovation here on either capturing and finding future requirements and productions of individuals or even in the heuristics that are employed to estimate them. But it turns out on the user side also they would rather perform this evaluation themselves (atleast have a final say) then let the service perform this, as such if you have sufficiently good mechanisms for filtering the prospective individuals to a manageable number the users might not care.²

Due to all of these reasons most often the services offload the work of finding the effectiveness of the match onto the users itself and instead focus on providing tooling and mechanism for effectively handling parallel heuristic evaluation of multiple individuals.

So if you are building services in this space, for this use case you don’t need to focus much on the matching aspect of it as long as you offer a sufficiently manageable number of individuals and then most importantly build tooling for handling and keeping track of multiple interactions.

Manageable number and tooling required to manage multiple interactions totally depends on the domain. For example in the case of dating apps, a manageable number might be 10-15 and the tooling could be something as simple as preventing the user from keeping open messaging with more than 15 other individuals and forcing the user to close the conversation with someone until you start the next one. For entities trying to find individuals to work in a company, manageable numbers could be 100-1000 and tooling could be auto repliers etc.

3. Connect with the matched individuals for a duration of time 🔗

Most entities/individuals almost always progressively ramp up interactions and this almost always happens outside the service which connected them. This is usually done for a one last risk free back off from deeper involvement in the event of an imperfect match, especially if the cost of deeper involvement is high.

If the service is a generalized service for connecting people, the services rarely facilitate the ramp up of interactions since the actual job to be done between the connecting parties would often be very diverse and it’s impossible for a service which connects people to do all of it.

But if the service is a more specialized service with a specific guarantee than that service can at least provide transitory ramps to connect after matching. For example it’s easy to see why dating apps can also venture into trip planning since it’s a transitory ramp into the individuals connecting to do the job of being in a relationship³, or why some matrimonial sites offer wedding planning. But it’s unclear what could be offered by facebook unless it builds off transitory ramps case by case taking the specific job of a group into concern, which seems both hard to do from a product perspective and operationally challenging for a large number of jobs.

The only piece of muddled signal that the service gets about the connection during this phase is whether the match went well or not. It is muddled since if someone doesn’t return to the platform it’s unclear if they didn’t return if the connection worked out vs if the connection didn’t work out and they have become dissatisfied with the service. But if both the individuals do return to the service looking for the same criteria it’s usually a sign that the connection didn’t work out. This is usually perceived by many services to be a data point to optimize on future matches. It could very well be, but as we have seen earlier it would be unclear on why the connection didn’t work out due to the multidimensionality of both the parties requirements and production and this needs to be further teased out.

3a. If the Connection was successful 🔗

Great, your service was valuable.

If the service is of the type where the user can’t be part of another connection of the same kind (Such as a full time employment, monogamous marriage) you have just lost an user. As such these types of services are inherently deflationary in the number of users and it becomes even more important that you continuously find ways to gather new users.

This doesn’t mean you should continually keep your users in a perpetual matching cycle of almost good enough (I’m not sure if this is an incentive with some dating apps 😅), but rather make it easier for the users who exit successfully out of your service to promote your service and bring in more users. There is an element of this which happens naturally (the so called word of mouth) but there are ways to build this into the product. An example of this could be to provide visible artifacts such as traveling bags for couples who successfully match through your dating site. LinkedIn has recently added “I got this job via LinkedIn” to promote itself through successful exits which is also an example of this.

3b. If the Connection was unsuccessful 🔗

Then either you get the individuals back or they churn out. Neither of these are useful signals in the individual but slightly more useful in the aggregate.

As discussed above if the users are churning out it’s an unclear signal of your product failure vs. the product doing what is intended. Depending on the type of product you might extract some signal out of this (Such as if you are a job searching platform does the user return after N months)

But if in aggregate on a connection being unsuccessful people are returning back it usually means they didn’t perform the evaluation well. You really don’t have to do much here other than potentially gathering some new data points the user itself would be willing to give for future filtering.

Testing our generalization 🔗

We can evaluate how good our generalization is by applying the same process to another domain which connects people on a large scale, Advertising.

1. Finding prospective individuals 🔗

Sufficiently large organizations have marketing departments who solely focus on coming up with user segments.

These user segments are the filtering criteria which are applied in the marketing campaigns to entice users to connect with the company.

In terms of the service which facilitates this, they not only aggregate users via some means but they also need to collect some information on the requirements of the users. These collected information are presented as a mechanism to filter the users.

2. Filter from prospective individuals 🔗

This is slightly different from the how matching function is evaluated in job search or dating domain. In most software products, the matching function is entirely evaluated by the customer. The organizations on the other hand have functions entirely dedicated to make sure the organization’s production function matches the customers requirement function. And the only production that is expected out of the customer is that they provide something which can be converted into revenue.

One of the ways the service which provides advertising can help the organization in this step is to help them understand on an aggregate where and when users are dropping off, and this is the most common tooling provided by advertising services.

3. Connect with the matched individuals 🔗

This again usually happens outside the advertising service’s property and there isn’t much value added by generalized advertising services.

Regarding specific guarantees it’s easy to see why people who have newsletters targeted to engineers or podcasts specific to science can get higher CPM on the ads they display (the filtering criteria) compared to Google Ads.

Things to think about for new startups 🔗

So let’s summarize what are the things to look for when starting/evaluating a new service which connects people

• Under what context does your service connect people?
• How does it bring new people?
  • If it’s an aggregator, how do you plan to solve the bootstrap problem?
• Do you provide specific guarantees to users of your service?
  • What are they and How are they different from the other services for connecting people in the domain you are providing specific guarantees?
• What type of criteria do you accept for filtering?
  • Does your filtering mechanism solve for all the kinds of filtering someone in your domain might want to perform?
• How and what are the past requirements and production of individuals that you are capturing?
• How and what are the evaluation heuristics that you will provide for future requirement and production of individuals?
• What tooling would you provide to manage the number of matches and parallel evaluation of matching function?
• Do you have value capturing transitionary ramps for users graduating out of your service?
• If your service is deflationary how are you planning to manage that?

Note that I’m not mentioning that a startup venturing in this space needs to have all these figured out when they start out. But rather these are some points worth thinking through to understand on what dimension will your service differentiate.

P.S 🔗

While writing this blog I realised there isn’t a platform where people aggregate people they know so they can set up dating between them. There are platforms which provide opportunities for individuals to set up job boards (such as Pallet) and aggregate demand from their audience but I haven’t seen a similar setup for dating.