Fixing a Funnel

Shift wasn’t a new startup when I arrived, but it was an entity that saw its business model destroyed when companies laid off millions of workers at the beginning of the pandemic. The dynamic company that I saw through old photos and podcast interviews was a mere shell of itself. Still, CEO Mike Slagh and the remaining skeleton crew rode out the storm and were keenly focused when I received the call in January 2021.

The company had a few different projects, but they all needed the data collected from the Candidate App.

While it worked, Candidate App was your typical start-up proof-of-concept tool.

There was part of a sign-up flow that would then push an applicant over to Google Forms with dozens of questions. It was difficult for users to finish and impossible for them to update. A proof-of-concept Airtable database was straining to keep up with the growing business demands. Finally, a small design system held things together in some areas but was ignored in others.

While a blank canvas holds few constraints, dead weight at a small company will halt any possible progress.

We had a lot of things to build, but there were technical constraints, and the team featured only two engineers. Luckily, both Lilly Simeonova and Alyssa Hope proved to be excellent collaborators.

The first order of business was simplifying the data collection flow for prospective candidates. Prior work by Mohammad Hassan and Dan Savage identified several funnel breaks where we lost most candidates. I won’t go into specific numbers here, but moving an application process from one platform to another causes significant leakage.

Without enough candidates each month, the company wouldn’t deliver on its promise to corporate clients explicitly seeking to hire top military talent. To avoid this issue, Shift employees spent significant time manually assisting applicants.

Complicating matters, the company had four programs that utilized parts of the application flow. At the time, each was an explicit flow, but anyone could tell there were shared aspects between the three flows.

Priority setting

One of the significant challenges for the company was the bottleneck in engineering. The only way to effectively work through a staffing issue is proper expectation setting and priority setting.

In this consulting role, I felt I was discovering new wrinkles in the company structure several weeks into my stay. Volunteering to run the monthly alignment meetings allowed me to zoom out and observe the organization’s different branches and hear stakeholder concerns.

When you have limited engineering bandwidth, someone is always waiting for their turn. Sensing that frustration, those secondary initiatives would become my focus for requirements gathering and discovery during this period as product can/should often run ahead of engineering when possible.

With the team aligned on the funnel, pulling apart the tangled mess of the application flow was up first.

Overall, everyone agreed that we had to get out of forms. Potential security risks and a hellish data experience with updating submissions drove the internal push.

Earlier I incorrectly described Shift as a blank canvas. It was not, and the application was a Jackson Pollock painting.

Determining what questions to ask, the order to ask, and of whom to ask would dominate stakeholder meetings during this period. In the wake of this effort, we improved our funnel leakage issue and the user onboarding experience while maximizing our limited engineering bandwidth.

Using data to guide support

Recognizing there were multiple ways to be a public ally of expanding our engineering efforts, I leaned into our customer service data and openly talked about the issues we would continue to have if we didn’t migrate our stack away from Airtable. Regardless how flawless our funnel became, if the user couldn’t update records afterward, then we were still going to drown in customer service calls.

Without the support of engineering, most product initiatives will fail. I look at data as a form of soft power and it is why research and discovery are so important to me as a product designer. Without data, it’s really just opinion. That doesn’t mean you always are successful, but you are forcing someone to directly choose to ignore the information provided if they choose to go another way.

Design systems scale faster

As we were successful in pitching the platform move (we went with Salesforce), that meant we were going to need to expand the team. Asked about the needs of design, I pointed to a greater need to expanded and utilize an updated design system. This one action would be far more impactful to the company than adding any designers to the team.

Over time, the product team expanded to nine without adding additional designers. This made my primary goal to overhaul and expand our design system so that it could be relied on to provide a common structure for all applications built on our platform. While I do augment the system from frequently, having eight other people on the team that look to the system as a guide means I have an empowered our entire team to move forward with confidence.

I actively challenge the team and myself to adhere to, rather than expand upon, the components that we’ve created to date. While I’m not always able to meet that goal, the engineers are aware of the effort which makes subsequent asks much easier to accomplish.

Beyond phase one

And how did we improve the user experience beyond the form update? The application process was finally responsive (o_O), and the user dashboard transformed beyond a place to sign up for a program.

A significant milestone at the time, the work shipped in phase one has significantly evolved in the years since.

None of the above would have been possible without leadership commitment to grow the product team threefold and significantly improve the underlying technical stack.

That level of growth is only possible when everyone is on the same page, pointing in the same direction.