Raising capital for startups has never been easy, it involves cycles of rigorous searching and cold outreach. Hockeystick aims to simplify the process by giving startups a warm introduction directly to the funder through criteria matching and user preference.
My role for this project was to conceptualize and create the startup matchmaking experience.
Understanding the Problem
The goal of the matchmaking platform is to circumvent the discovery process by helping startups match with funders using preferences and company details that feed into a recommendation engine. The engine (ML) then provides a set of potential investors primed for introduction.
Who is this really for?
The product team initially hypothesized that an automated method of matchmaking would not be suitable for startups of all shapes and sizes, so we set out to understand their fundamental characteristics.
I began by interviewing several startup CEOs at random (including our very own!). We landed with the conclusion that startups can naturally fit into one of 3 segments, dreamers, idea-oriented, and disciplined. Each segment is represented by the level of fundraising experience, which ties into a set of attributes about the company.
We ended up focusing our attention on the dreamer and idea-oriented segments, as they are in need of immediate and fast funding. Their company characteristics also calls a unmet need of introductions, whereas disciplined segment already has multiple sources for connections.
Disciplined startups already are capable of fundraising, and have the tools to do so. They benefit little from another sourcing product.
Idea oriented startups focuses more on product success and are usually in need of funding, fast and efficiently.
Dreamer startups are less experienced in the realm of fundraising and require guidance during the process.
All startups are in need of funding at some point in their company's growth. It can occur at any stage, and may be repeated.
To brainstorm features for the matchmaking product, I created "How might we" statements using insights from the research.
Nature of recommendation based platforms
I also had another need that had to be considered. In a recommendation based platform, A platform's output value is directly related to the feedback that the user gives into the system. In our case, this proved to be challenging problem to solve. We needed to collect enough preferences and data points about the startup "before" the recommendation engine starts providing accurate matches. Ultimately it came down to the "cold start problem", where we needed to optimize for learning from the user before giving back to the user. This led to our final need and HMW.
Need: Users need to provide preferences to improve their perception of value
How might we motivate the user to provide more preferences to gain better value (recommendations)?
Encourage users to act upon their recommendations frequently such that their match quality improves over time
Provide guidance and education for less experienced user to make better and more accurate decisions about their matches
Create an interface for the user which optimizes for the efficiency needed to achieve immediate value
Designing the Experience
What it isn't
On its surface, it may be tempting for this platform to follow the paradigm of a dating app such as Tinder and Bumble. Their monumental success pays attribute to their swiping gesture interaction, which allowing users to effortlessly go through their matches while the platform is actively collecting preference feedback on every swipe. However, we ultimately felt that it was the wrong approach, even if it can guarantee preference collection.
Fundamentally, dating app's interaction revolves around efficiency rather than accuracy. Matches are performed in sequential order and are culled through quickly, often within seconds. Their massive volume also enables this type of interaction to be possible without leading the user into a dead end (rarely). This makes it very enticing to the user in a casual use case, as there are simply no repercussions to the user when they don't get a match, they simply try again later.
On the other hand, startup to funder matching is a professional affair with layers of constraints. We've seen through research that even though startups are willing to receive funding opportunities fast, they will still evaluate and perform analysis to determine if a match is compatible and worth their time. Our limited volume of funders also provides an imbalance that is not suitable for fast decision-making interactions. Therefore, building a platform revolving a swiping interaction would ultimately dilute the value of individual funders.
Conceptualizing the right approach
Despite the platform being unfit for the swipe user experience, there were still some merits that could be adopted for ease of use. I still wanted to retain a simple experience that made the matching process feel effortless yet detailed. After much debate, we decided to keep the card paradigm of showing funders for sake of simplicity, and present each card with a "Connect" or "Pass" option.
For user discovery, we felt the need to show enough initial value so that users are not restricted to seeing one funder at a time. The risk being that single card interactions may be too slow for startups to match to an appropriate funder (especially due to the cold start problem). Instead, we gravitated towards a grid layout that allowed free exploration to whatever catches the user's eyes. In the end, A card grid UI was chosen to be the primarily element of the experience.
Along with the main interface, several other pages were conceptualized and built in concert with focus on meeting the 3 goals.
Having an onboarding process allowed us to capture an initial set of details to generate the first set of recommendations. Users are likely readily available to be engaged right after sign up, but are also not opposed to drop off if they feel the process is too long. Several design choices have been made to mitigate this to keep the user engaged and guided.
In our user interview, we received strong signals that the majority of our users are desktop based judging from their workflow. so we proceeded to build a set of desktop pages instead of opting for mobile. A card grid UI was chosen to be the primarily element of the experience due to its freedom for exploration.
Funder Match Cards
The funder cards represented value on the platform. They were designed to contain enough information without overloading the user. Through A/B testing, I was able to determine a set of fields that are relevant to the startup in choosing their action.
The startup profile houses all the information about the company. When connected with a funder, the funder sees information that has been entered here. From the beginning, the profile design was intended to gain trust and incorporate guidance for the user. The goal was to use methods that encouraged frequent updates of the profile, and in doing so, lead to better recommendations.
Hockeystick shipped the first iteration of Matchmaking as a soft launch to a receptive audience. During this time, the product team and I captured feedback early and excessively to look for commonalities among the usage patterns that deviated from our initial intent.
Analyzed for dead spots and average fold
Analyzed for usage patterns and micro-interactions
Looked for general complaints and technical issues
Measured satisfaction of funder recommendations
Key Pain Points
1. The first set of recommendations were incompatible to what they were looking for.
2. Users did not "pass" on any recommendations or opened them as they weren't inclined or incentivized to action on funders they didn't care about.
3. Users were not aware that new recommendations are generated when current ones are responded to. Users had in their mind that it was duration based.
Understanding what went wrong
It was evident that showing a grid of recommendations gave users too many choices to consider and not enough reasons to provide negative feedback. Similar to how a user would rather watch watch the videos they want on YouTube, rather than spending the time to tell YouTube which videos they don't want to watch.
As such, we did not properly advise the user that their negative feedback (pressing pass) mattered, which gave them no incentive to ever click on funders they didn't like. This was our core issue to focus on, as our ML can only provide better value to the user with more interactions.
I began by simplifying the user experience by looking at one recommendation at a time as a way to increase value for each recommendation, it also subtly forces them to provide feedback in order to see the next. However, I realized that the "one-recommendation" experience may proved to be too restrictive if the ML is not optimally providing the right funders, so I had plans to retained some flexibility in allowing the user to browse through their recommendations. I took a radical step back to rethink the user flow and made several improvements to the main matchmaking experience.
Revising for V2
Small wins, one step at a time
The grid layout experience was well conceived initially, but it had its merits and its flaws. While it excelled at providing uncompromising discoverability to the user, it also meant that users were not obligated, nor guided into a linear experience for responding to all their matches. Therefore, I wanted to split the grid layout into different sections, dividing up the task that the user needed to perform.
I eventually settled on a concept called Weekly Top Picks, which prioritized matches with the highest confidence score to be shown separately. This leads the user to consider a smaller subset of matches that they are possibly more willing to interact with.
Guiding the user flow
Through heat maps and recordings, I could see that the user flow was disjointed and erratic purely based on the way the expanded match card was presented. Initially, users that wanted to see details of different cards were manually clicking in and out of the card modal, causing repetitive actions that were unnecessary and might've suppressed user's discoverability of all the cards.
The solution I came up with is to guide the user from the grid layout into a list layout. The advantages of doing so allows users to continue to freely choose their initial interest (through the grid and Weekly Top Picks), but then forces them into a linear workflow which they can quickly traverse through top to bottom. The goal of transitioning from one flow to another sacrifices no previous behaviours while guiding the user towards a queue-like experience.
Despite an onboarding explanation, the initial UI gave no other means for the user to understand how the matches were queued up until they've connected or passed. Not only did it confuse our users, the subtle visual indications were not clear enough to convey the urgency of the matches. For the second iteration, I've considered 4 mechanisms that helps bring clarity and value to a match response.
Showing weekly match expiration time
Prevent hoarding of matches and time boxing of decision making, keeping the user constantly engaged on a weekly cycle.
Weekly completion goals
Introducing gamification into the workflow encourages users to achieve 100% response rate. Users are made aware of the impact of doing so.
Trending characteristics are exposed through funder behaviour and ML confidence to give users another reason to respond in a timely manner.
Giving control and ownership back to the user
We've heard from multiple users that they like to use their own CRM to track matches after a connection request is sent, our original UI prevented that, leading our users to wait in the dark until a funder responds. I aimed to bring more transparency of the matching feature by incorporating 2 defining changes.
Users own the matches
Instead of taking a match away from the user after it's been actioned upon, matches are moved to another tab allowing users to keep track of their weekly transactions.
Saved matches / Actively fundraising status
A weekly refresh cycle may not fit every startup's schedule, and they might not even be actively fundraising. Adding a saved matches list and a fundraising status gives startups grace periods to respond to their matches instead of losing them.
Bringing it all together
At the end of the day. creating this full end-to-end experience proved to be challenging in many ways. The quantity of data we had along with the limited number of funders on the platform posed several design constraints along the way. However, our feedback capture loop proved to be conducive in determining pain points quickly and radically changing our initial interpretation of the user flow.
This also represented a learning opportunity in which the user experience is dependent on a multitude of factors outside the realm of product design, ranging from technical considerations to marketing. I was fortunate to have contributed to each of these thinkings culminating in the full experience.
Deal Submission Portal