Skip to content

The magic of a product hub and radically transparent communication

How Nylas powered their near-perfect launch

The product team at Nylas set their eyes on an ambitious goal for the year: launch the next version of their API. This would be a rework of the entire platform. After missing their first target launch date, they knew they were going to need support. They made their first product operations hire, Holly Holbrook, to help them succeed.

The first thing Holly did was figure out what was currently being worked on. Their roadmapping tool didn’t have clear answers. As she talked to people across the organization, she realized something profound: “Not one person could tell me what has been done with API v3, what still needed to be done, and what was live.”

Holly began piecing a picture together. She realized that being responsible for centralizing this information wasn’t sustainable. She set a goal to automate herself out of the product updates role.

An image of the product hub. The left column has "releases" highlighted with sub-sections for current and past releases. On the main screen there are columns for each of the release versions and cards inside each column with the individual features. Each feature has status tags on it.
The product hub can break features out by release version so everyone knows what’s planned and prepared for each release.

Last minute communication leads to last minute launches

Nylas had been growing rapidly, but its  communication infrastructure didn’t grow with the team. As a result, work started falling through the cracks. PMs didn’t know what other PMs were working on; sales tried selling what they had been told was coming, but didn’t always get it right. Marketing sometimes published things that weren’t ready for prime time. 

This put a lot of stress on their product launches. Go-to-market (GTM) teams didn’t know much about new initiatives until the last minute. This shortened lead time made it harder to prepare for smooth launches.

I’ve seen this at a number of companies – the company starts with all the product managers being able to understand what the team is working on. Then the team grows. The product leader acts as a hub and keeps everyone informed. Nobody worries about documentation because the system is working. But then things get busy, and the product leader can’t keep an eye on everything. With subpar systems in place to document everyone’s work, the information gets lost.

Once nobody knows exactly what’s happening, delivery gets hard. Teams start duplicating efforts or building on top of each other – eroding trust between teams. Morale drops as trust falls. Communication slows down even further and the problems compound. Product teams stop wanting to share information with GTM teams, afraid that another wrong thing will get communicated to customers. It’s critical that any team in this loop try to address it as soon as possible.

Don’t be afraid of transparency

It’s surprisingly common for fast-growing companies to fall into this cycle of mistrust.

The better cure is to give them more information. Instead of just sharing a bit of what’s planned and when it might launch, share the details with context. What do you know, what are open questions, and what is okay to mention to customers or partners.

Companies with good transparency generally have some kind of product communications site that anyone can access. I’ve seen this both with clients and via conversations I’ve had with product ops professionals across the globe. Whether a wiki, a dashboard, or a tool, create a space for coworkers to go and find the information they need.

Holly did exactly this – she used Jira Product Discovery to create the “ProductHub”. It is used by both the product development teams and partners. Product development can quickly understand launch readiness, and GTM teams can see what’s coming up that they need to prepare for.

A view of feature requests inside the hub. The navigation column highlights "unread feature requests" and the content includes a list of feature requests and the ability to "create an idea".
Feature requests are tracked in the product hub, and then categorized into statuses so the requestor can know what the status is of their idea. Those ideas can then also be attached to particular features.

Creating your own ProductHub

Holly used a classic product development process to develop the ProductHub. To begin, she asked engineers to document what features they were working on and when they shipped. The team updated this manually for six weeks as they learned what information was useful and to whom. 

Even with this minimal setup, the ProductHub started showing its  value. People across the company appreciated knowing the most recent changes and what had shipped.

Holly began automating these updates, connecting the activity in their ticket tracker to this dashboard. As coworkers requested more information, she layered it in. Once she learned more about her colleague’s needs, she created dashboards at different zoom levels. Everyone could see high-level summaries or zoom into the details as they needed.

We started to automate things and we created a lot of trust with each other, ideating and understanding the use cases. Now, it is this trusted source of truth for all of our engineers, for all of product marketing. And it has grown beyond what I ever expected it to.

She continued gathering feedback as she built the tool out. Product management provided their thoughts in the weekly team meeting. Other departments brought up new ideas or requests in weekly cross-functional calls.

Balancing this has been a desire to make sure things don’t become over-featured:

I’ve found myself having to be very mindful of our goal and vision for each dashboard because if you lose sight of that you risk that dashboard growing into something it was never meant to be. You can certainly grow a dashboard endlessly, but that’s not what you want with a dashboard, so being intentional and thoughtful about what you put in there will help keep it clean and usable.

All told, it took nearly a year to iterate into its current form. Throughout this time, she stayed focused on her product operations strategy, understanding that fixing this would have multiple benefits to the company.

A chart that shows the upcoming releases on the x-axis and the statuses "to-do", "in-progress", and "done" on the y-axis. Each release has marked the number of features in that status bucket for that release.
The data in the product hub can be displayed in different ways, depending on user needs. This view shows the status of work for all upcoming releases.

The launch went too smoothly

Nylas launched API v3 last month and it’s gone smoothly. As Holly put it, maybe too smoothly:

We’re all kind of sitting around waiting for something to happen, a good thing, a bad thing, a fire. And nothing’s happening. It’s working as it should and it’s kind of alarming. We’re all anticipating something, but it’s not coming. It’s just working.

Obviously, nobody is truly complaining about a smooth major product launch.

Nor have they complained about the other changes to their culture that this transparency has brought. Fewer, more productive meetings. Status meetings for product updates have nearly disappeared, replaced by conversations to coordinate, share concerns, and moving work forward. This has freed up time on calendars across the board.

We have transformed the way that product works and how everybody else works with product. It is a night and day difference.

I’ve seen the same patterns with my own clients – strong communication is the bedrock on which the company succeeds. It’s the path to moving faster, collaborating more, and making the best use of everyone’s time. Building out the right infrastructure for your company takes time, but once it begins lifting the burden off of teams’ shoulders, it’s worth every second.

Thank you so much to Holly for sharing her story. As well, thank you to Alicia Echagarruga, Julian Cheah and Matt Willman for their suggestions and edits.