Acast’s tech team is committed to being outcome-driven in our product development, and we’re growing quickly—bringing on new product managers, designers and engineers. There’s a great energy you can even sense virtually, as we have remote-first US technology teams.

But onboarding and starting new product teams isn’t light work. My team at Acast, Audience Growth, was started a few months ago, and we wanted to share the perspective, tools and learnings that have helped us so far.

Shared team vision

You need an elevator pitch. This is easier with a new team, since you need to share who you are across an organization regardless. For anyone joining an established team, it’s also key that they’re able to not only understand the vision, but question it and mold it to something that reflects reality.

Product teams want to move fast and bring value to users. Pausing to question the “why,” is important, as it helps focus future work. This should include all members of the team, not just product managers.

We did this through a simple Google deck, breaking it down into the team’s purpose for the company and for our users.

These team visions should also be shared with the stakeholders you’ll interact with regularly.

What happened once we had a shared team vision?

• We onboarded new colleagues more quickly.
• Goal planning and metrics conversations were more focused.
• We had clear conversation starters for others in the organization around the work our team does.

Opportunity mapping

A product development team solves problems. That’s very traditional in Agile, and nearly every individual that joins Acast has this type of mentality. Put simply, they want to help podcasters.

What’s important to instill in a product development team is not just a focus to solve problems, but a team awareness of how we get to decisions about what problems to solve. How does the team evaluate the next steps? What criteria do we use? Are those criteria clear to everyone?

A product resource we’re experimenting with is opportunity solution trees, thanks to Product Talk.

One of our products is the Acast embed player, which allows podcasters to embed an episode or a full podcast across different platforms. We love this product, and we want to increase the number of times users hit play when they come across it in the wild.

Instead of jumping to different implementation ideas, we took a step back, and made sure that we knew what opportunities any solutions were solving. If we wanted to pursue a specific solution, did it map back to an opportunity? If it didn’t, why were we picking it? For Example:

A sample opportunity tree that the team could use.

Once we had a few solutions identified, we thought about bite-sized experiments we could run to see if the solution was effective. If something can’t be broken down into less than two weeks of work, we’re pursuing discovery activities to try to do so, as it’s important for us to deliver work in small pieces.

What happened once we started opportunity mapping?

• In planning, we realized we had some solutions that actually weren’t solving the problem we were focused on for the quarter. We deprioritized them.
• Our conversations became focused on the experiments we could run to achieve an opportunity. This gave us space to fail gracefully, learn and adapt.
• We now have solutions that span from new features to improving the performance of existing features. This type of thinking both gives us focus and allows for creativity.

Shared analytics understanding

Not every member of the team is an analytics expert, but every member of the team should know how to track the performance of their product changes.

Our team relies heavily on Google Analytics, paired with Acast’s in-house business intelligence tools, user research and surveys. I have calendar reminders to pause and review performance on a regular basis, and then we discuss in Slack.

With podcasting being an open ecosystem, analytics can get complicated — so we make sure all colleagues understand the nuances of IAB measurement and other industry-specific metrics.

What happened once we had a shared understanding of analytics?

• The team realized the places where we didn’t have tracking and backlogged tickets to add that information.
• When we’ve had to triage a problem, we could more swiftly understand the impact by diving into details on mobile device usage, iOS versions, and so on.
• Planning for future quarters’ goals became easier. We know where we’ve been, where we want to go, and what other metrics we might want to impact.

The fun

During onboarding, we love to have colleagues complete a “User Manual of Me” that talks about their working style and preferences, and shares some fun, random information.

Putting these types of documents in writing — in a Google Doc or in Github — also helps new colleagues get to know their team members really quickly. We’ll also update these manuals to keep them fresh with our lives and perspectives.

Being a Swedish company, we love to schedule a fika — even virtually — for new colleagues and their team members to relax and get to know each other.

What happened once we started leaving space for fun?

• Leaving space for these get-to-know-you activities allowed us to communicate better in the meetings where we were focused on business. Human connection matters, and it takes effort to cultivate that in a remote-first environment.
• We laughed and enjoyed ourselves. Work remains fun — and that’s when good work happens.