“Prefer” Postmortem: 6 Lessons Learned From A Network Of Independent Professionals
By: Scott Belsky
Tags: Startup

I’ve received over a dozen emails and calls in the past year asking about lessons learned from Prefer, a team I helped gather and advise that ultimately shut down. Among all the ideas and new teams I’ve encountered, Prefer is still one of those products that I believe needs to exist. I get excited when I come across other entrepreneurs seeking to solve this problem so I figured I’d share some take-aways for the benefit of others exploring the space.

Prefer started as an idea I shared with a few other entrepreneurs I respect, just as I started my stint as a full-time VC and before I returned to building products/teams at Adobe. The original idea was based on a few insights about customer preferences for services and the growing economy of independent service providers — from massage therapists and personal trainers to chefs, tutors, and accountants (aka “Soloists”), specifically:

Customers prefer a trusted referral from friends over four stars from strangers any day of the week.

Soloists (independent service professionals of all kinds) routinely get their best new clients via referrals from existing clients, and prefer referrals over paying for leads, placing ads, and gaming search engines.

By 2020, the Freelancer’s Union estimates that over 40% of the American workforce will be independent service professionals.

Given lack of access to “back office” tools for payments, scheduling, insurance, and a steady stream of new clients, the independent services provided by Soloists are becoming commoditized by on-demand networks, “middle-men” headhunters, and the traditional firm/agency structure. In the age of apps, marketplaces, and professional networks, we can do better.

The original idea was to build a “Consumer App” for clients to find and book services they need via referrals from friends, while onboarding and referring their favorite Soloists to their network of friends. And for Soloists, the team built a “Provider App” to get a steady stream of new clients and gradually grow and manage their business. We imagined Prefer becoming a new superpower for anyone to find any service provider as a trusted referral from friends, and for Soloists to vastly expand their business in the very best way possible (via referrals).

Prefer was able to assemble a group of stellar engineers, designers, and operators I would certainly work with again, and the product went through at least three major pivots and many more evolutions (perhaps too many and too quickly in retrospect) and endured some critical learnings that may have happened too late. As I reflect on the experience and debriefed with a few members of the team, here is a list of lessons learned based on what worked and didn’t work in the journey to empower the careers of independent service professionals and enable customers to find the service professionals they need from their friends.

6 Lessons Learned From Prefer

Marketplace Building: Vertical vs. Horizontal

Traditional marketplace building starts with liquidity. Can you gather enough “supply” and “demand” to ensure that buyers and sellers are able to find each other and be satisfied with little effort. For this reason, most marketplaces start with a narrow (vertical) focus on specific services, whether it be massage therapists, drivers, or babysitters. If you can build enough supply while also pacing the demand — all while keeping the cost of acquiring both sides in check with some form of viral loop — you can achieve the elusive “flywheel” that has unleashed some of the greatest marketplaces of our time. But for a referral marketplace like Prefer that would require Soloists to bring their own clients onto the platform (and for clients to keep coming back for new services), the team knew that we needed to take a horizontal approach instead. After all, why would massage therapists introduce a network of other massage therapists to their own clients? So we needed to accommodate many forms of Soloists from day one. As the saying goes, “when you try to do something for everyone, you don’t get it right for any one.” When it came to tools for scheduling, booking, etc, the lowest common denominator was a common trap to avoid. Should we have avoided all of these tools out of the gate and focus simply on discovery? Or should we have forced ourselves to focus on a more limited set of verticals, from both a product and go-to-market perspective?

Don’t Go Against The Grain Of Communication Preferences

For most on-the-go Soloists with varying levels of technology savvy, with clients of all ages, the easiest way to coordinate new appointments and build relationships is text message. It was always a challenge to reconcile what happens in-the-app vs. via text message. When building a network requires unnatural motions (communicating in a new way, paying in a new way, scheduling in a new way, etc), you’re in an uphill battle for adoption in an already uphill battle for awareness! Lesson reinforced: You can only force a new behavior for network participants when it is 10x better. Perhaps we should have doubled-down on discovery and one element of the relationship at the start, and eliminated any in-app messaging? Or perhaps the lack of calendar-sync and other functionalities at the start rendered the in-app messaging inconvenient at best. I believe we failed to make the inner-workings of the app itself 10x better than the normal ways a Soloist-Client relationship was managed. One important thing to note: when a Soloist and his or her client DID connect on the app and start working together, they often continued to do so. They also started to invite others to the platform on both sides — and at one point these “working pairs” exhibited very promising growth potential for the network. But there weren’t enough pairs getting to this point without a ton of non-scalable hand-holding. When it came to the “productivity tools” of the app itself, it was clear they were not a driver to adoption, but could potentially lead to retention/engagement over time.

“Wow moments” must have frequency to have gravity.

Great consumer products bring a superpower or elusive “wow” moment to customers with some degree of frequency. In Prefer’s case the two “wow” moments happened when (1) a customer was looking for a new service professional and instantly found that professional through a recommendation from a friend, and (2) “Soloists” on the platform got a trusted referral from a new client automagically. Unfortunately, the acute need for the consumer was not frequent and happened probably once a quarter or once a month at most (think about it, how many times per year do you look for a NEW service professional?). As a result, there wasn’t enough urgency for a consumer to download the app and go through the work of adding/referring their service providers to their friends…and when they did, there wasn’t enough frequency to come back to the app. This directly inhibited the frequency of “wow” moments and the flywheel of growth required for the first version of Prefer to work.

You can’t obsess enough about the top-of-the-funnel.

The more time the Prefer team spent with different Soloists and Clients, the more we realized how many different value propositions there were for first-time users. We learned that some clients just wanted the ability to discover services, some Soloists only cared about referrals while others only sought a better way to serve existing clients, while other pairs of Soloists and Clients just valued things like easy billing and automatic notifications for appointments. With such variance of preferences, the “first mile” of the customer experience either didn’t evolve fast enough or failed to serve a broad enough set of users. This experience emboldened my observation that most product teams only spend the final mile of their experience building the product thinking about (and testing) the first mile of the customer’s experience using the product. It should often be the opposite.

The thirst for community and collaboration among Soloists is real.

While there were many things we failed to figure out, the team nailed some things incredibly well. One of these things was the member-led community we called the “Soloist Collective” which is still growing organically despite the product’s demise. Among independent professionals, there is a need for peer support and best practice exchange, informal referral networks, and periodic gatherings. One of Prefer’s slogans was “you may work on your own, but you’re not alone.” Indeed, being a Soloist can be lonely and there is a lot of inefficiency and frustration in figuring out everything on your own. The world needs more structured communities for these professionals, and we encountered great demand on this front.

Too many iterations too quickly cause a team fatigue that carries over.

For all the talk of “pivots” in the world of start-ups, the truth is that a new version of a product by the same team is not really a “fresh start.” While a pivot can capture the benefits of starting with a great culture and team of experts from day one, you undeniably carry an extra dose of doubt and fatigue from the previous iteration. The Prefer team had a high bar for the growth levers needed to continue along a path. As a result, there were at least three pivots (major re-directions of the company), and there was noticeably less energy and patience after the third. I’ve always believed that one of the greatest competitive advantages for a start-up is simply sticking together long enough to figure it out. And, when you have to throw away all your code and design and plans multiple times, there is a wear and tear that is hard to overcome — even among the best teams out there.

In Closing…

There were many other lessons learned, and the leadership team would be in a far better position than I to share those details. But these are the initial thoughts I would share with anyone considering a new product in this space. At scale, having access to the trusted professionals your friends recommend would be a game-changer, but the engagement and network density obstacles need to be solved first. Much like LinkedIn needed the contact importer and Facebook needed the “friends you may know” section, there is a jumpstart innovation yet to be found. I have no doubt, with the right team and level of patience and determination to nail the product, there is an incredible problem to be solved.

Especially at a time when so much of labor is being commoditized or automated, relationship-driven services will become more crucial to our economy and everyday lives. Are you an entrepreneur with passion for this problem, a deep care for design and crafting product experiences, and appreciation for the “ground game” operations to make this work? If so, hit me up. Happy to share more of what I observed and learned from Prefer round one.