What taking a product from zero to one taught me
A three-month reflection on launching a recruiting platform across 26 offices.
I stepped into a senior product role at ION in July, and this recruiting platform was the first thing I've owned here from zero to one. We had no existing playbook to lean on, just a growth problem and a lot to figure out.
Three months later, the platform is supporting recruiting across 26 offices. It's still early, and there's plenty I don't have right yet, but watching interviews reach district managers across the company has made the scale of that initial idea much more tangible.
The reason for building it was simple. A solar company can grow by getting more from its current reps or by adding more reps. We needed a better way to solve the second problem.
The platform helps recruiters screen candidates for door-to-door sales roles and send interviews to district managers. My job was to define the need, talk with district managers, figure out what the product needed to do, and make the case for the revenue that more recruiting capacity could produce.
Starting with the growth problem
I liked that this started with a growth problem instead of a feature list. Recruiting capacity was holding back our ability to add more reps, and that made the stakes feel higher than a typical feature request. Knowing the potential impact helped me get more passionate about the build.
I wanted to understand what district managers needed from an interview pipeline, but I also had to keep the larger goal in view. Recruiters needed to create enough interview volume to support growth. That tension shaped almost every decision we made.
Standardizing the first screen
A lot of district managers wanted the initial screening handled a specific way for their office. Their requests made sense. They know their teams, they know the type of candidate who'll be a good fit, and they wanted to weed out bad fits as early as they could.
But we were building a central process for 26 offices. If every office had its own screening process, recruiters would've had a ton of variations to manage during those calls.
These recruiters are doing 10 to 15 minute calls, back to back, all day. Wildly different interview processes for each candidate would've slowed them down fast, so I chose to standardize that first recruiter screen.
It wasn't an easy call. District managers still interview the people who make it through, while the platform and recruiters handle the first pass and schedule in-person interviews. I thought the local interview was the right place to keep local input.
Launching for every office
We launched for all offices instead of starting with a narrow group. It was messy, but it got us up and running much faster. District managers saw interviews coming in without having to do anything to make that happen, which made the launch feel possible.
At the same time, I don't think I have the balance completely right. Standardization makes the recruiter side much more manageable and lets recruiters send through higher volume. It doesn't automatically make district managers confident in the interviews they're receiving, and I worry that we're sacrificing quality for quantity.
What I need to focus on next
The next step is understanding that quality-versus-quantity balance better. Where do district managers need more control? Where do they need better screening? Which manager requests would make the process better, and which ones would bring back the complexity we were trying to avoid?
I'm glad I spent time with district managers before deciding how the platform should work. I also still think standardizing the process was the right call instead of trying to satisfy every office before launching.
Three months in, I'm proud that something which started as a growth problem and an early idea is now being used across the company. I can also see the hard part more clearly. The work doesn't stop once the product is live. I need to keep deciding what belongs in the central process, stay close to the people using it, and change it when the handoff isn't working. Next time, I want to get to that clarity faster and build a tighter feedback loop from the beginning.