How Dropbox’s Product Marketing Team Influenced the Roadmap To 3x Enterprise Revenue

The Urgent Need to Influence the Roadmap

Dropbox started off as a consumer product. Over time, we started to focus on business budgets. We saw an opportunity to compete and win deals against Box and Microsoft. Our strategy to get into businesses followed the classic (product-led growth) PLG model of getting end users to adopt first, and then having your sales team sell enterprise accounts to those organizations.

Yet, unfortunately, that model was not working for us. We became the poster child for Shadow IT, meaning users would bring in tools behind IT teams’ backs, and try to use them. Ultimately, this led to IT teams cracking down and removing tools that were not approved for security reasons. We wanted to win against Box and Microsoft, but we needed to be viewed as a competitive alternative. When we achieved traction on an enterprise deal, we couldn’t close.

Our product marketing team recognized this urgent problem. It became apparent that we needed to relay the product gap we were seeing in the market in a way that enabled the product team to respond. I joined Dropbox after this problem was identified, and as Dropbox was trying to solve it.

Key Goals

Our goals were to:

1. Focus on an IT buyer persona.

2. Roll out enterprise features with the right messaging that leads to sales deals.

3. Win competitive deals against Box and Microsoft.

4. Increase enterprise revenue.

Framework

Take Time to Build Trust

When it comes to building trust with the product team, my three pillars were to engage early, to model transparency, and to encourage inclusion in challenges:

Engage Early: Right from the start, I made a conscious effort to understand the product team's perspective. I asked questions, listened intently, and showed genuine interest in their work. This early engagement demonstrated my commitment and willingness to collaborate, laying a solid foundation for trust.

I created a Market Requirements Document (MRD) template to guide the initial questions I asked my product team, which covered:

• Market Sizing: The category or space we were the best fit for, relative growth rates of the category, and trends.

• Market Segment: What segment of the market we had the best product market fit for.

• Competitive Offerings: The market landscape, who were considered competitors, and what other offerings and capabilities were out in the market that would make another solution more compelling.

• Risk and Success Factors: Where the product could run into risk, and what specific features/variables needed to be considered to be successful.

• User Personas/Problems/Goals: The primary segments or personas that the product would be assessed by, their day in the life, and how they would like to achieve their goals.

• Product Requirements: These are based on the problems discovered and talked about above. New products should focus on the current business problems customers are facing and how to fix them. Focus on existing products should include any issues that need fixing to help customers solve business problems.

• Out-of-Scope Requirements: Requirements that are currently out of scope and too difficult or unreasonable to take on at the given moment for this product area.

Diagram: MRD Suggested Template

Model Transparency: I maintained an open line of communication with the product team, sharing all relevant information from a marketing and sales standpoint. Whether it was updates about an event or details about a launch, I made sure they were in the loop. This transparency reassured them that I valued their input and saw them as essential partners in our joint initiatives.

Encourage Inclusion in Challenges: I encouraged the product team to share their challenges with me, particularly those related to engineering. For instance, when they were struggling to finish a sprint due to internal issues or a bug in the code, they didn't hesitate to keep me informed. By including me in these discussions, they felt more comfortable collaborating with me, and it allowed me to better understand the product's intricacies. Many product marketers shy away from this because they are worried the issues are too technical. It's important to make an effort and try to learn. Ask questions, make sure you understand what the technical terms mean, and try to understand what is industry standard vs. internal requirements.

Building trust doesn't happen overnight. It requires consistent effort, open communication, and a lot of understanding and empathy. 

Diagram: Take Time to Build Trust

Your Customer Feedback Is Not The Whole Picture

One common mistake I've seen product marketers make when trying to influence the roadmap revolves around an overreliance on research. Many marketers come in convinced they have all the answers, demanding that the product team build what they suggest based on their research. But research is just part of the picture. Real-life scenarios and technical limitations often play a huge role in what can and cannot be done. Sometimes customers ask for things that negatively impact their own security or user experience. In other scenarios, there are technical limitations that may keep us from being able to deliver on customer requests.

Another common mistake is over-prioritizing customer feedback from a particularly vocal or high-revenue customer. While it's tempting to cater to these customers, it's crucial to maintain objectivity and prioritize based on the broader customer base and the product's overall vision. Failing to do so can lead to a never-ending cycle of feature-building that doesn't necessarily lead to a better product.

Understand “Why” Product is Building What They’re Building

My key point of view on influencing the roadmap is to remain open and attentive to what the product team has already built and why. It's not about blindly following customer feedback or insisting on what you think is best. It's about understanding the product team's intentions and bringing your outside perspective to enhance that. This two-pronged approach of understanding and enhancing has been the most powerful way for me to influence the roadmap.

So remember, always stay curious, listen more than you speak, and build a relationship based on trust and mutual respect with your product team. This approach will not only allow you to influence the roadmap more effectively, but also foster a healthier and more productive working relationship with your product team.

4-Step Process to Influencing the Roadmap

1. Identify the Product Gap: Conduct surveys with existing customers, and work with analyst firms to understand the decision-making criteria for companies interested in purchasing in the space or companies that have purchased competitive products. Analyze competitive offerings, and analyze upgrade behavior.

2. Determine the MVP: Work with Product to share the research with the team, understand the roadmap’s resourcing, and align the story with the narrative.

3. Work with Product as They Build the MVP: Work closely with the product team to adjust the narrative as the product is being built, and determine the initial pricing and packaging.

4. Make the Go/No-Go Decision: Prepare for GA (general availability) by assessing product readiness, assessing market readiness, and then, determining product announcement timing.

Diagram: 4-Step Process to Influencing the Roadmap