Just A Note: Camilla Velasquez on Coming in as Head of Product

I joined Justworks as Head of Product a few months ago. I’d previously been at Etsy, where I worked for almost four years, building out various teams and lines of businesses. Leaving was a difficult decision, not because I was attached to the work per se, but because I was attached to my team.

When I first joined Etsy, we were putting together a team to build a new payment system for the marketplace. For 3 years the Payments team worked together very closely, quickly expanding in scope and size. The product needed to work flawlessly – there isn’t room for error when you’re handling people’s money. For that to happen, we had to build a cross-functional team that checked their egos - doing whatever it took to get the job done even if it wasn’t in their job description - and also generate a tremendous amount of trust amongst us.

The months leading up to launch were some of the happiest of my career. Leaving Etsy, and the Payments team in particular, was a difficult decision, but I knew I wanted to recreate to that feeling of a close-knit team, working on high-stakes, complex, and valuable work.  That's where Justworks comes in.

Want to get to know more of the Justworks team? We spoke with Coral Edwards, our head of marketing, here.

Why I Joined Justworks

Joining Justworks was about 2 things:

• The core team

• The opportunity ahead

Isaac Oates, Justworks’ founder, and I worked closely on the Payments team at Etsy, and I admired his leadership style. What’s most important to him for a team is “everyone in position” - everyone doing their part, with clear responsibilities, but respecting the work each person contributes to the greater goal. 

Isaac’s view of “product” matches mine, which is to say that the entire end-to-end experience - everything from physical brand assets, application UI, performance, customer support, pricing, account management, vendor management, and operations - is what truly makes up a product. Product development isn’t just about your web app, it’s about building an identity.

What’s more, every person at the company has something to learn from the other, and no one person is more important than the overall team or our customers. Silos create not only inefficiencies, but barriers to empathy and trust.

The benefits, HR and payroll space is also tremendously complex and exciting. The product we build has the ability to power companies, but also make CEOs, CFOs, and COOs better at their jobs.

Coming In as Justworks' Product Lead

When I started working at Justworks, Isaac had been acting as both the head of Engineering and the head of Product, but knew it was time to bring in leaders for both those functions as the size of the company and customerbase continued growing quickly. Anyone joining a startup as the first “product person,” where the founder was previously acting in this capacity, knows this can be nerve-wracking. Amongst other anxieties that come with leaving a secure job for a startup, you have to grapple with how the team will handle a new leader. Will the transition be a smooth one? Of course, the second question is “of all the possible options, what should we work on?”

I knew, though, that the only way we could even begin to tackle the second question, was if we had a trusting and jelled team - so, managing that transition was critical.  We needed to loosen our reliance on our founder.

For that to happen, here are the three areas where I focused most heavily for my first six weeks.

• Getting to know the personalities on the engineering team.   We did a week-long off-site as soon as I started, and set out small goals for the week so we could celebrate some launches together and get to know our working styles. Mostly, the week served as a way to smooth out the transition to having a product lead, but in a low pressure environment. Communication is critical to building trust, and spending time in close quarters allowed us to feel each other’s styles, and then develop the ability to critique and speak our minds openly and constructively.

• Creating a set of guiding principles as guardrails. When you’re in fast growth mode, its easy to fall into the trap of getting something launched quickly and telling yourself you’ll revisit it later for those extra features. Probably not gonna happen though. But how do you know what should be in the V2 versus the V1, especially when you’re dealing with more blue sky features? We created a set of guiding principles for the product, that are aligned to our brand and our core customer. The principles help us ask, as we face scope creep, is this in or out? If it doesn’t squarely fall under one of the four product principles, it’s in V2 - to be revisited after launch, and then probably cut entirely. Every single member of the team should be openly calling out when we’re talking about features or tasks that aren’t true to our principles.  Product principles allow designers and developers to answer their own questions about a feature, and we loosened our reliance on our CEO and our own customers to answer questions about our product.

• Creating small working teams, with very clear responsibilities and assignments. When I arrived, there were a few very large projects in the pipeline, with almost the entire development team working together on each one. It meant some areas of the Justworks product were underserved, and that some talent was being under-utilized. It also made clear responsibilities harder to discern  - which then meant tickets or tasks could fall through the cracks. It was clear that there was opportunity for more than one project or feature to be developed at once, without necessarily sacrificing time to launch because each team member would feel, in fact, more ownership over their features. With tighter, smaller teams and a few individuals having clear ownership over projects, we were able to launch 3 features in quick succession that had been on backlog for a while. This framework will set the foundation for scaling the product development organization into teams (or “pods”) autonomously owning clearly set domains areas 

With a few wins under our belt, and confidence that our team is starting to jell, it’s been easier to define our roadmap – and do so as a team. With communication, trust, and ownership, we have a solid foundation on which to continue to develop our product.