Over the last few weeks, I have had some time to reflect on my most recent experiences and more specifically, the kind of work I really like to do. In nearly every role I've played in my career, I have most enjoyed the circumstances where I was designing, building and launching something new. The process can be time consuming and nerve wracking, particularly because of the inherent second guessing and uncertainty that accompanies building something new. But, I wouldn't want it any other way.

I recently began a Coursera course in Design, to get some academic insights into improving my process. The course - Karl Ulrich's "Design: Creation of Artifacts in Society" at University of Pennsylvania - is worth a try, as its only 6 weeks long, and the project work is quite straight forward and practical. For those who are curious, I am working on defining physical storefront-type space for the modern consumer. In later posts, I'll share my thoughts and some of my doodles for your perusal.

In the meantime, I wanted to share some insights from some work I did about 12 years ago with a Cornell Hillel. I recently came across some of the materials for this project and figured it was a good time to reflect. In 2005, I helped launch a large-scale program at Cornell Hillel called iJew. At the time, I sat on the board and found our regular reports from campus to be filled with lovely anecdotes about a particular student showing interest in a particular activity, or the response from a University leader to a particular program, but no tangible, meaty analysis on the success of the organization in reaching students and engaging them.

At the time, the prevailing wisdom was surveys, which rarely had good response rates, regardless of the incentive. What I wanted to see was the raw data - Who was coming to events? Were they new faces or regulars? What patterns emerged in the data to help predict a path to more engagement and/or student leadership? Ultimately, what activities, groups, and focus areas were worth funding further, and which were not? What we needed was GPS on a smartphone with Foursquare, only they wouldn't be mainstream for another 4.5 years.

While chatting with the executive director, Rabbi Ed Rosenthal, I happened to be looking at the keys on my desk and noticed all those plastic loyalty barcode tags on my keyring - CVS, Duane Reade, Blockbuster Video, and the New York Public Library. The barcode scans at the Point of Sale were incredibly easy, and were fairly effortless at this point.

  1. Could we create a similar concept at Cornell Hillel, where students would scan in/out at events?
  2. How could we get the students to carry it with them and use it regularly?
  3. How could we get buy-in and train the staff and student leaders to implement this?

For the concept, we quickly researched the technology required to create a simple barcode system - it was a fairly old technology that was perfected by folks like Symbol and others. Getting plastic barcode tags was quite cheap and easy, and the barcode scanners were getting smaller and could handle more and more memory. Organizing the data (e.g. event name, date, time), capturing it (the mainstream scanners didn't have wifi or bluetooth at the time - they used memory cards), and ultimately connecting it into disparate accounting, donor, and student databases would take time, but we could do it in phases to make it easier to handle. This was workable and I agreed to fund the development.

For student incentives, we brainstormed a few concepts, namely giving money to charity for each swipe, or running a raffle each month where the tickets were given for each unique swipe. We ultimately launched with the latter, with a new iPod being offered each month for the first year, then (with student guidance) moved to the charity model (which was more affordable and sustainable long-term). Model generally worked as promised, but clearly social standing alone (think Foursquare Mayorships) might have drawn similar engagement for far lower upfront cost.

From a design perspective, it was important that the tag was 'cool' and something people would be comfortable displaying openly to friends on campus. The design for the keytag ultimately was developed by the staff, to accompany the iPod giveaway with the iJew tag.

As it turns out, the tag became somewhat of a fashion item on campus, but the plastic used was not designed for heavy use. It was common for some students to lose/break these tags a few times each semester. Better quality testing would have helped from the get-go.

Buy-in would be the biggest challenge, as we had a fairly lean staff and the mechanics of scanning the barcodes would require more volunteers. In addition, as we found out in the first year, even with the best of intentions, the scanners we could afford were not designed for portability, long battery life, or large storage capacity. We would constantly run into issues here.

In addition, the administrative staff's computer expertise was fairly limited, and they struggled to learn new software and processes. We were pushing the envelope from a development perspective at the time, but the handoff to our mortal staff left a lot to be desired. Always align the project with a team that can execute it - reinforce where needed.

Regarding the tech build out, we vastly underestimated the work that would be required to build an Uber-system capable of the full insights package we wanted. After all, we were using multiple systems for accounting, donors, student tracking, email, etc that all fit into the traditional CRM universe. These systems did not work with one another in any real way.. We decided to try to start with just spreadsheets, but that became cumbersome quite quickly. The disparate systems were equally difficult, because they weren't designed for massive data import/export, and the tools were being stretched beyond what they were known for. Hence, in 2006, we decided to start a migration of all our data systems to Salesforce.com, which was both eager to help the non-profit community, and had a fairly robust, secure, and flexible infrastructure.

With Salesforce in tow, we worked with Blue Wolf to customize it for our needs - the scope seemed straight forward to start with, but quickly became fairly complex. To be fair, we were a very early implementation of such a system on Salesforce, and they had limited infrastructure designed for the non-profit world. Tech timelines can be extended quite easily, and technology vendors like to 'sell' stuff they don't always have, particularly in the enterprise.

The project had its challenges, but turned out to be a good first step into adding a level of depth to our tracking of student involvement and engagement. Over time, components of our effort were adopted on other campuses and at Hillel International.