From the beginning my cofounder, Paul, and I were braced for the technical challenge of building and scaling our first Web application. I use “we” loosely, as Paul jumped into the role of CTO and has shouldered the load of teaching himself back- and front-end web development. We knew it wouldn’t be easy to build the infrastructure. But, in building and testing prototypes, we’ve found the social issues to be even more nuanced and challenging than the technical hurdles.
One advantage of our technical inexperience (probably the only one) is that we’ve avoided a trap more technically savvy teams are susceptible to. Many can be myopic in the way they solve problems, focusing simply on the tools in their belt. It’s the oft-quoted saying, “When you’re a hammer, everything looks like a nail.” Certainly it would have been nice if Paul or I had “Web development” skills at the outset. The upside is that when starting Treatings, we had to vet features before coding them because we didn’t have the time, money or know-how to build everything we envisioned.
If we’d had all available Web and mobile technology at our fingertips, we likely would have entered coding bunkers obsessively focused on leveraging the newest technology to facilitate informational meetings. The most efficient way to connect two people face-to-face – and that is indeed what our professional networking platform, Treatings, aims to do – might’ve been through a mobile app that notified users when they’re in close proximity to individuals of interest (there are apps that do this).
But, we aren’t building Treatings in a vacuum. There are social norms that we must conform to, or at least consider.
Before coding, we spent time talking to potential members to gauge what they would feel comfortable with. In customer interviews, most people expressed that they wouldn’t feel comfortable approaching, or being approached by, strangers in-person. The individuals we spoke with wanted to browse profiles at their leisure and only commit to offline conversations after communicating online and determining whether or not the meeting would be worth taking.
A lot of our quandaries around technology are not what to use but what not to use. We’ve borrowed a lot from online dating sites given that we also facilitate online-to-offline interactions between strangers. We’ve noticed that most dating sites incorporate speed bumps into their framework. Even Tinder, the relatively frictionless mobile dating app where you can browse user profiles with the swipe of a finger, has constraints in place such as the requirement that both parties opt in before either can exchange messages.
Research has been conducted evaluating whether online dating leads to better romantic outcomes than typical offline dating. One of the findings was that “being able to communicate with potential partners safely and conveniently offers an attractive precursor to face-to-face encounters with complete strangers,” making online dating superior in this aspect to traditional offline dating. On the downside, the authors point to a danger of communicating online for too long thereby building outsized expectations for the potential relationship. Finding the appropriate balance between communicating online before taking the conversation offline is one of the many social-based issues we’ve dealt with in building Treatings.
Founders are inundated with rhetoric from experienced entrepreneurs and investors on the importance of perseverance. There are many celebrated stories of resolute entrepreneurs refusing to quit and banging their heads against the wall until finally busting through. The challenge becomes how to value this doggedness on a micro level. For every individual product decision, we’re often deciding between trying to change, or create a new, behavior in our members vs. yielding to the status quo that members are comfortable with.
One of the most fundamental aspects of our information marketplace is the fact that there is no separation of supply/demand. Information seekers can also be information suppliers. In a previous iteration of our site, we relied on people proactively offering specific meetings that others could request. This was problematic for two main reasons. First, although many people are willing to talk about their work, it’s not such a problem that they’ll think to offer meetings on a regular basis.
Second, many of us don’t believe we have insights anyone would be interested in. Hosting a form of office hours felt presumptuous to many members. In this case, we listened to user feedback and reversed the framework to more closely resemble an online dating site, where everyone is open to meeting new people without proactively offering meetings.
One social norm we’re still trying to overcome is something anyone who schedules a lot of meetings is familiar with. Most email requests for someone’s time are too long and end with, “I’d love to grab coffee. Let me know when and where works for you.” Displaying scheduling flexibility like this can seem like the polite thing to do. The problem is that it puts the onus on the receiver to schedule everything.
Our initial solution: when proposing a coffee meeting on Treatings, your message is character limited and you’re asked to suggest a date/location. The logistics can be changed, but it gives the receiver an anchor to work from. This cuts down on the back and forth communications.
We’ve hoped that creating a rigid framework within which to operate will make people more comfortable sacrificing formality in favor of efficiency because fellow members understand the etiquette. With a few exceptions, people have appreciated the character limitations in messages. It is less daunting for the sender and easier to parse for the receiver.
We’ve had more pushback on requiring the sender to suggest a time/location before a meeting has been accepted. Those who send meeting requests don’t want to appear presumptuous. We’ve tried various methods to help people feel more comfortable suggesting meeting logistics. Members select preferred venues on their profile and we will allow them to say what times of the week are most convenient.
The question is how long do we go against the grain in search of a more efficient framework before yielding and implementing a model that more closely resembles existing behavior?
Seriously . . . any ideas?
This is the 11th installment of a PandoDaily weekly series that chronicles the experiences of a young entrepreneur as he bootstraps his startup.
Come back next Sunday to read the next installment.
[Image via Treatings]