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.
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.
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.
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.
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.
Rachel uses the following framework to evaluate when to engage stakeholders and how to go about doing it.
“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.
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.”Learn more strategies to make your remote team more effective