experiences

experiences

Since 2013, I have worked on a number of challenging problems with some truly inspiring people and amazing technologies. Most of these attempts didn’t work out. Some were taken very seriously, some weren’t. Here are the stories of what we created, who we reached, how we delivered, and what finally happened.

Upward Messaging Summer 2015 – Fall 2016

Upward was going to allow professionals to collaborate better by replacing their email accounts and professional text messages with a free B2C messaging app.

Professionals worldwide send almost 110 million emails every day, despite the availability of vastly more productive alternatives for day-to-day communication like Slack and Google Hangouts. The resulting lost productivity is a problem for individual professionals, businesses, and society at large.

We knew from personal experience that email is still so prevalent professionally partly because switching to a tool like Slack requires building substantial momentum within teams: someone on a team had to become convinced that the new communication system would dramatically improve productivity for everyone; then she would need to sell the rest of the team on it; and then, finally, the team would need to commit to switching all of their internal communication from email to the new system. And even if all of this happened, team members would still have to send emails to communicate with people outside of the team.

We realized that a B2C messaging app for professionals (one where individuals, rather than teams, made the decision to join) which also supported sending emails to people who did not have accounts would solve all of these problems. Individual professionals could switch on their own, without requiring the entire team to buy in. And just as Facebook Messenger makes sending messages to your best friends as easy as messaging someone you just met, individual-centered professional messaging would allow communication with close teammates to happen in the same place as communication with clients, lawyers, and other people external to the team.

So we reached out to hundreds of potential users from investment bankers to Hollywood producers to talk about the ways they communicated professionally. And, over the course of a year, we developed and launched an MVP which featured core messaging technology (sending and receiving text messages, links, and documents in real-time over multiple devices with push notifications), instant search over all messages including attached files and linked webpages, and a compatibility layer for both email and SMS.

While the users we contacted were enthusiastic about our solution, and while we did see some growing use after launch, we ran into an ultimately fatal market limitation stemming from our B2C approach. Almost all potential users were incredibly reluctant to start using a new technology for their core communications because of concerns about privacy and reliability without approval from IT departments or higher management. (In our experience, the only exceptions to this rule were employees of tech-savvy startups who were already using Slack.) Those users who did begin to use Upward only did so after getting buy-in from their team lead or IT department. This meant that instead of the viral, individual-led growth that powers a typical B2C app, we were seeing unit-by-unit growth typical of B2B—but without any of the benefits (i.e., immediate revenue). And so our initial hypothesis, that switching costs from email to messaging could be substantially reduced through a B2C solution, was shown to be incorrect. Faced with the choice of either pivoting into a B2B solution, and thereby competing head-on-head with Slack, or shutting down, we chose the latter.

infrastructure technologies

Docker NPM GitLab GitLab CI AWS ElasticBeanstalk Atlas

backend technologies

Node.JS ES6+Babel Socket.IO Elasticsearch Mongo REST Google Analytics

frontend technologies

React Webpack ES6+Babel Swift Socket.IO Stylus jQuery Animate Google Analytics

RealityStep Spring 2014 – Fall 2015

RealityStep helped underperforming high school students achieve higher education by providing information about the college application process.

There is overwhelming statistical evidence that achieving higher education is important for individual outcomes and societal success. (As a telling example, the unemployment rate for non-college grads is about twice as high as the unemployment rate for college grads.) And there is also overwhelming evidence that achieving higher education is the most difficult for low-income students: the percentage of low-income students who attend university is about 30% lower than the national average.

While there are many forces driving this disparity, including cultural factors and parity gaps in primary educations, a key element is information: while wealthier students often have family members and guidance counselors to help them through the enormously complex process of standardized testing, college selection, financial aid applications, and college applications, low-income students are generally left to fend for themselves. And without quality information about the process, it is impossible for students to successfully navigate it.

We attacked this information problem with the development of three separate products. The first was a free, public, and accessible collection of articles providing simple explanations of the complex process mentioned above. We launched this with both print and web editions, and called it RealityStep Curriculum. (Over 50 volunteers contributed to researching, writing and editing the articles.) The second was a support team, accessible by phone or email, for students who had read articles but still needed explanations and assistance, called RealityStep Allies. And the third was a team of volunteers that worked with local NYC schools to provide guidance counseling directly in classrooms, called RealityStep Classroom.

All three products were successful. Thousands of students read articles on Curriculum, with low bounce rates and high share rates. And the RealityStep Classroom and Allies programs launched with multiple schools and demonstrated quantified improvement in student outcomes.

In Fall 2016, RealityStep was merged into a much larger Columbia-based outreach group. The Classroom and Allies teams are now part of outreach efforts across three NYC boroughs. And while the online Curriculum was shut down for being too far out of scope, the articles in print format are still being used by hundreds of students.

backend technologies

Github Github Pages GitBook Jekyll Algolia

frontend technologies

jQuery SCSS Foundation Algolia

Upward Finance Spring 2015

Upward Finance was going to be an online platform connecting borrowers seeking personal loans to a true crowd of investors seeking to profitably finance dreams.

As a peer-to-peer debt marketplace, Upward Finance was an attempt to solve two different problems for the two different sides of our market.

We wanted to help borrowers access previously unattainable credit for personal loans at below-market rates. Unlike loan applications at traditional banks or older peer-to-peer lending platforms like Lending Club, Upward loan applications would not be judged creditworthy on purely on quantitative measures (like credit history and demographics) but would also be empowered to tell potential investors their qualitative story. Whether talking about the unavoidable but still crippling medical debts requiring refinancing, or the beautiful house that could be the cornerstone of a new family, or the college education needed to fulfill early promise, Upward wanted to give borrowers a platform to speak.

And investors would have used the platform to profitably finance dreams. Based on both traditional quantitative measures and the qualitative factors expressed in the borrower’s story, investors would be enabled to directly impact the borrower’s life by chipping in to the tune of twenty or twenty-five dollars. In addition to the philanthropic returns, we believed that through careful borrower screening we could enable the vast majority of investors to also make positive aggregate fiscal returns on their investments through Upward.

While building out the technical and financial platforms, we ran into two serious issues. First, we saw that because of the financial crisis and ensuing global savings glut, interest rates for traditional, credit-worthy personal borrowers were already very low which meant that there was not much room for downward competition on rates, so our USP for borrowers was in jeopardy. (Other peer-to-peer investors like Lending Club and Prosper have experienced unbalanced marketplaces as a result.) Then, we realized that risk assessments for creditworthiness were incredibly complex, proprietary systems that would be tough to replicate and impossible, without star financial talent, to improve upon. This meant that our goal of enabling profitable lending to investors was also jeopardized. Unsure of how to overcome these challenges while maintaining the spirit of the project, we decided to shelve Upward Finance.

WriteOrange Winter 2014

WriteOrange was an online, fully-versioned WYSIWYG editor designed to make Markdown publishing acessible to everyone.

Markdown is a simple programming language for writing text content. When content written by different people needs to be delivered in standardized layouts, or on the Web, using Markdown instead of Word or Google Docs is useful because formatting information (like margins, fonts, and colors) is not included in the document and instead can be set by a designer during publication. Additionally, its widespread support by popular publication platforms makes it easy to use with third-party tooling. However, its reliance on plain text documents and special characters to indicate modes can be challenging for non-technical writers used to WYSIWYG editors like Microsoft Word. (At RealityStep, we ran into this exact problem while building out our Curriculum product.)

WriteOrange was an online text editor designed to enable publishers to enjoy the benefits of Markdown while allowing writers to use a more familiar WYSIWYG environment. The interface used idioms similar to Word for bolding and italicizing text, as well specifying headings, ordered lists, unordered lists, and normal paragraphs. Behind the scenes, however, users were actually creating a Markdown AST, which could be trivially exported to Markdown.

Over the course of the project, several technical challenges were overcome: eventually, we had to re-implement text input, cursor selection, copy-and-paste, and version history in JavaScript to work around buggy HTML5 implementations and to ensure rock-solid support for both iOS and modern browsers.

After completing the front-end, other projects and commitments started starving WriteOrange of time, and the back-end was never completed.

frontend technologies

jQuery HTML5 ContentEditable React Rangy

Eats Spring 2014 – Fall 2014

Eats sent users push notifications with crowdsourced reviews when they stood in front of a restaurant.

If you see a new restaurant that looks interesting, it is hard to know whether it will be good or not until you try it. Of course, you can always look for reviews on traditional publications or crowd-sourced reviews on Yelp—but we found that in practice, the friction of having to remember to look up reviews, getting out a phone, opening an app, and searching for the restaurant dissuaded all but the most tech-savvy eaters from accessing these resources. While Yelp and other crowd-sourced apps were very useful for gathering recommendations about where to eat, their interface was not optimal for the more simple question of should we eat here or not.

Eats was an attempt to make it radically easier for users to answer this second question by using smart location awareness and a notification-driven UI. After a user installed the Eats app on their phone, we monitored their location and locally cross-referenced it with a database of restaurant locations which used Yelp and Foursquare APIs. When we detected that they had stopped in front of a restaurant, we sent a notification to their phone which gave the restaurant a thumbs-up or thumbs-down in comparison to other nearby options. Near mealtimes or when the user was in a new city, we silently notified them when they walked by an outstanding restaurant even if they did not stop in front of it. And we allowed users to easily see the details of reviews, as well as more restaurant options, by swiping on the notification. This was a radical, user-centered simplification of restaurant reviews—and after showing potential users mockups and UI prototypes, Eats garnered an enthusiastic response.

However, as we began to develop Eats, we ran into a fatal technical barrier. In densely populated urban areas like midtown Manhattan, a low-powered GPS signal available for background-mode consumption on iOS only had an approximate one-block resolution. (We thoroughly explored workarounds including increasing the GPS signal strength, using direction data, and using smoothing regressions on location data, but could not find solutions that improved accuracy and maintained battery life.) That meant that while we could determine the closest 15 restaurants, we would not be able to notify the user with information specific to the restaurant she was actually in front of. Because we felt that this unacceptably compromised the user experience, we decided to halt development.

infrastructure technologies

Github Heroku

backend technologies

Flask Redis Yelp API Foursquare API NYC Healthcode API

frontend technologies

Objective-C LocationManager C

Instant Winter Break 2013

Instant was a threaded, picture-based social messaging service—like Snapchat, but with threads.

In Fall 2014, Snapchat was just starting to get big and most of the media attention was buzzword-fueled commentary on its expiring messages: it was popular, the story went, because it was a way to share that would not be stored forever; that was more like real-life; that was more private; et cetera. As freshmen in college, my co-founders and I were big Snapchat users, but we didn’t use it because of the expiring messages (although they were definitely handy for some messages). Instead, it was the incredibly easy-to-use photo editing and messaging that appealed to us: it seemed so much more natural to send selfies with words on them, or annotated shots of what we were doing, than to send plain text messages.

We thought that if other people were like us, this mismatch between Snapchat’s focus and what about the app actually attracted users presented a massive opportunity. Snapchat’s UI and one-to-many, thread-less messaging model made it confusing to have many kinds of conversations, especially within groups. If we could replicate the functionality of Snapchat using more traditional messaging interface idioms, we would be able to create something more attractive than Snapchat to us, to Snapchat’s users, and to traditional messaging users not yet using Snapchat.

Unfortunately, collaboration was difficult over our first college winter break, and for internal reasons development on the MVP was never completed.

Preblur Summer 2015 – Fall 2016

Preblur was a social network for people you didn’t already know but who liked the same things you liked.

infrastructure technologies

Github Heroku

backend technologies

Flask Redis PostgreSQL

frontend technologies

Angular jQuery SASS

Memnio Summer 2013 – Fall 2013

Memnio was an intelligent flashcard app that allowed students to memorize anything, anywhere.

infrastructure technologies

Github Heroku

backend technologies

Flask Redis

frontend technologies

HTML5 SASS jQuery CSS Animations