The Story of Project Falcon

In early December, we held our first ever hack-day. Each product manager teamed up with one to two engineers for the day to think up and develop any idea that they wanted. At the end of hack-day, each team then presented their concepts, demoed the results, and explained how they thought their hack improved the application.

On the morning of hack-day, my partner Jeff Rand and I holed up in a corner of the office with a hearty breakfast of pancakes, bacon and eggs and quickly came up with a list of about 10-15 ideas, from improvements that we knew Members or our Sales team had asked for, to improvements to the codebase that we knew needed attention. We had two basic requirements:

  1. The feature could be built quickly on information we already had in the database, so we could do a live demo with our test environment.

  2. The feature encouraged our Members to respond to each other through Axial.

After a couple cups of coffee, we arrived at an idea that met both of these requirements:

We could show Members how responsive they are to others, and set their expectations on how likely they were to get a response from another Member that they’ve never interacted with before.


This was inspired by a feature on a popular dating site that helped people seeking romance decide who to message and who to respond to. If it works for romance, we thought it should certainly have the same effect for our network of entrepreneurs and investors. Members responding means Members making connections and talking to each other about the deals they’re sharing, which strengthens Axial’s network. We named our hack “Project Falcon” and set off by stating our basic requirements for our hack:

  1. We needed to look at some data on the interactions of our Members and find out the right range of responses to divide our Members into 4 ranges. This we would call their “responsiveness score.” We also wanted to be able to adjust these range definitions within the application without a release.

  2. We had to translate those ranges into a visual element in key areas of the application where Members typically reach out to one another, wether they were looking for an investor, evaluating an investment, or just looking to connect. In all these part of the application, we’d display a “badge” for every Member.

  3. We considered how this “responsiveness score” and its “badge” would be interpreted by Members when they saw it. Would they see this as another reason to reach out to someone who responded frequently? Would it prevent them from reaching out to someone that didn’t respond frequently, or would they consider it a mark of selectivity if a Member, like an well-known investor, only appeared to respond to a few deals that Members sent to it? We wanted to be prepared to discuss the merits of the idea when we presented it.

  4. How could we at Axial use the data that this tool exposed? Would it help us identify Members that should be more responsive? Would it help us encourage connectivity if Members knew other’s could see if they were responsive or not?

Taming the Falcon


We dug into MySQL and ran several queries, looking for response rates around key Member-to-Member interactions on Axial: companies and their advisors reaching out to investors, and investor interest and response-rate to company and advisor outreach. We looked over a wide range of time, but settled on measuring responsiveness for the trailing 30 days, divided the response rates up into 4 badge ranges.

While Jeff started coding, I started working on mockups of the badges and their placement in those key areas of the application where our Members connect, taking care to make sure it looked equally good on pages displaying 1 Member, and pages displaying 50. By the end of the morning we had finished implementing the code to get each Member’s response rate.

Shortly after lunch we were styling the badges, and inserting them everywhere Members connect on Axial. After adjusting the styling and tweaking the badge ranges, we made a few tweaks to accommodate older data in our test environment before spending the rest of the day working on a 5 minute presentation and demo we could present to the company. I branded the project by taking a Falcon, and photoshopping our logo and a responsiveness badge into its talons. We were set.

The next morning, people from across the company gathered to watch each hack team present their ideas and their demos. Each team had come up with some great ideas: internal tools to help our sales team demo and pitch Axial, a script that automatically resets the test database to a previous state, a tool to place investments on a map by location, and a framework for data visualization (a personal favorite of mine). At the end of the presentations, the audience then voted by secret ballot as to which hack was their favorite. Project Falcon won the vote. 

Presenting Project Falcon

Release the Falcon!

Within a couple of weeks of our Hack day, after some minor visual updates based on wider feedback, and a selective implementation of the locations it was shown, Project Falcon was released to all Members, and so far it seems to be driving conversations between our Member Success team and their Members on how to be more responsive to other Members on Axial. Jeff and I have worked on some additional improvements based on member feedback, and have also implemented a logging mechanism to help us track ALL of our individual member’s change in responsiveness score over time.

And it wasn’t just Project Falcon. At least one other of the hack day ideas has been refined and shipped, with a third one waiting in the wings. Hack day not only brought everyone on the corps of engineers and product teams closer, and was an overall great experience, but because we disrupted the pace of work up from our normal semi-monthly sprints, blitzes and product development cycles, we shipped member-facing impact that otherwise would likely might not have been considered or wouldn’t have ranked against larger product initiatives.

Live View