How teams work: JobGet’s product team

Leading a team, especially a distributed or growing one, can be hard. Oftentimes the best advice and ideas come from other teams just like yours. That’s why we launched Lead Time: How Teams Work. This blog series profiles real teams, how they’re structured, and how they communicate through meetings and other touchpoints. Plus, each article features a top-notch leader who's got proven tips and real stories to learn from.

Meet Rachel Neasham, VP of Product, JobGet

Rachel oversees JobGet’s product team — a fully remote group of product managers and designers who work remotely across locations and time zones. JobGet’s a startup, so things move quickly and the team is constantly looking for new ways to allow for nimble, collaborative product development that actually work on a remote team.

We sat down with Rachel to learn about her approach to product development and leadership at a remote startup.

How the team works

Team structure

The JobGet product team consists of two product managers and two designers who ladder up to Rachel. They work closely with a 12-person engineering team, which reports to Rachel’s counterpart, the CTO. Some of the engineering team works in North America and the rest in India, so time zones have a big impact on how the team works together.

Team meetings and communication cadence

Here’s a look at the typical meetings and async touchpoints on Rachel’s team's calendar.

Daily: Rachel’s team combines daily standups with Slack updates to make it easy for the whole team to follow along, no matter what time zone they’re working in.

• Standups:
  • Product standup: A 30-minute morning meeting where product team members report on what they did yesterday and what they’re doing today, and then discuss blockers or decision points. It’s attended by all designers, all product managers, and some of the engineers (depending on time zone).
  • Eng standups: The CTO runs two separate standups for the engineering team: one for full-time engineers, located in India, and one for contracted engineers. These take place late in the evenings, to accommodate for the time difference.
  • Slack: Important updates from all the standups are posted in a designated Slack channel so that folks who don’t attend have visibility into what’s going on.
    
• Feature-specific Slack channels: Rachel’s team uses designated Slack channels for each new feature they work on to make it easy for stakeholders to get a sense for what’s going on and decisions being made. In the channel, they post updates and impact after a feature is launched, too. If conversation about a feature is happening elsewhere, Rachel encourages the team to move it back into the feature channel instead.

Weekly:

• Friday all-hands: The entire company gathers to share major updates. Once a month, the team uses this time to report on progress towards their KPIs.

Rachel’s top tips for remote product development

1. Create a template for stakeholder engagement

Product development should be a highly collaborative process — but this can be challenging when you’re dealing with multiple sets of stakeholders spread across multiple time zones. To smooth out the process, Rachel’s found it helpful to get really thoughtful about engaging stakeholders in the place and time.

“I was just writing our stakeholder engagement strategy. My vision is that all the teams outside of Product feel seen, heard, and understood,” explains Rachel. “That might look different for different teams — maybe we talk to Customer Support once a month. For Sales, maybe we engage with them twice a month — once synchronously and once asynchronously. There’s not an exact formula.”

Rachel recommends using the questions above to define a loose template for engagement, and then allow it to evolve over time as you learn more and collect feedback about what works best.

2. Embrace a more agile product development process

The product development lifecycle is something Rachel spends a lot of time thinking about, and lately, her focus has been on honing her team’s documentation processes.

“I'm thinking: How can we stay agile? How can we think about more than one solution throughout the product development life cycle?” says Rachel.

Right now, the team uses a one-pager to lay out new feature concepts, and then a product requirement doc (PRD) to flesh everything out.

“When you move to the PRD, you want a tech perspective, a design perspective, and a product perspective. You need to work together, and talk about things and figure out all the details and edge cases,” explains Rachel.

“But instead, sometimes this waterfall type of process can happen where one group works on the PRD and then passes it along to the next. When you do it that way, you end up boxing yourself in,” she adds. "Take design for instance: I don't want to box my designers in with a rigid PRD. I want them to be able to think of multiple, different ways we could design an experience.”

So instead of focusing on finalizing the PRD before starting the work, Rachel has been encouraging her team to make it a more dynamic, fluid process. Their PRDs are in a constant state of evolution, getting more and more accurate until the moment they ship the new feature.

“There are always conversations that happen during the build period where things come up that we didn’t know about going in,” says Rachel.

Their new process better accommodates that.

Embracing a more agile PRD process has also helped Rachel’s team keep their documentation more accurate and up-to-date too. Since it’s constantly being updated, the PRD is less likely to become stale and create confusion or issues with misalignment.

“The end user experience isn't going to be figured out until we ship it — that’s the expectation I like to set,” says Rachel. “That way, we can stay flexible throughout the process.”