Plaid's 'Use Cases' nav item and dual CTA hierarchy reveals their sales vs. PLG tension

The Tactic

Plaid's top navigation tells you more about their business model than their pricing page. Three elements reveal the complete GTM picture: a "Use Cases" dropdown that maps to business outcomes rather than technical features, a "For Developers" menu item that creates a separate architectural entry point for technical evaluators, and a "Talk to team" primary CTA that signals enterprise-first motion.

The hierarchy is unmistakable. "Talk to team" sits in the primary CTA position — right-aligned, visually prominent. The developer path exists but is nested within the navigation rather than foregrounded. This is a company that sells to businesses and serves developers, not the other way around.

The Use Case Navigation Pattern

Most developer tools organize their navigation around features: "Products," "Platform," "Solutions." Plaid uses "Use Cases" — a subtle but meaningful distinction.

Feature-based navigation asks the visitor to understand the product's architecture and map their needs to capabilities. Use-case navigation does the mapping for them. A fintech startup looking to verify bank accounts doesn't need to know whether that's handled by Plaid's "Auth" or "Identity" product. They just need to find "Account verification" in the Use Cases menu.

This approach works particularly well for platform products with multiple capabilities. Plaid offers bank linking, payment initiation, identity verification, balance checks, and transaction data — all served through different APIs but all part of the same platform. Organizing by use case rather than API endpoint reduces the cognitive overhead of understanding which product they need.

The tradeoff is that developers — who think in terms of APIs, not use cases — may find this navigation less intuitive. That's why the "For Developers" item exists as a parallel path.

The CTA Hierarchy Tells the Story

The choice of "Talk to team" as the primary CTA over "Start building" or "Get API keys" is the clearest signal of Plaid's GTM motion. This is enterprise sales, not product-led growth.

In PLG companies (Stripe, Supabase, Vercel), the primary CTA drives directly to the product. In sales-led companies, the primary CTA drives to a human interaction. Plaid's choice tells you that their highest-value conversions happen through sales conversations, not self-serve signups.

This doesn't mean Plaid doesn't have a PLG motion — they do have developer documentation and a sandbox environment. But the navigation hierarchy tells you that self-serve developers are not the primary revenue driver. They're a discovery channel that feeds the sales pipeline.

For B2D companies, this CTA choice has downstream implications. When "Talk to team" is primary, the marketing site's job is to generate qualified leads, not free signups. Every page should build a case for why a conversation is worth the visitor's time. When "Start building" is primary, the site's job is to get developers into the product as fast as possible. The entire content strategy follows from this one CTA decision.

The Developer Door

Plaid's "For Developers" navigation item is architecturally significant. It creates a clear separation between the business-facing site and the developer-facing experience. Behind this menu item, developers find documentation, API references, quickstarts, and sandboxes — the standard developer experience toolkit.

The key insight is that this separation exists at the navigation level, not just the URL level. A developer arriving at plaid.com sees "For Developers" in the nav and immediately knows where to go. They don't have to parse use cases or talk to sales. They have their own door.

This pattern — creating a developer door in the navigation — is particularly valuable for companies that sell to business buyers but need developer adoption for implementation. The developer doesn't make the purchase decision, but they have veto power over the implementation. Giving them a direct path to technical evaluation (skipping the sales-oriented content) respects their role and reduces evaluation friction.

FAQ

When should a developer tool use 'Talk to sales' instead of 'Start building'?

When your median deal size exceeds $50K/year, your product requires significant integration work, or your buyers need compliance/security reviews before adoption. If most of your revenue comes from contracts negotiated with procurement teams rather than credit cards entered by individual developers, your CTA should route to a human.

Does having a sales-first CTA hurt developer adoption?

It can, if the developer path is hard to find. The mitigation is Plaid's approach: keep "Talk to team" as primary but make the developer entry point visible in the main navigation. Developers will self-select into the docs path regardless of CTA hierarchy, as long as it's findable within 2 clicks.

Should use-case navigation replace product-based navigation?

For platform products with 3+ distinct capabilities, use-case navigation is usually better for conversion. Visitors don't need to understand your product architecture to find what they need. But keep product-based organization in your developer documentation — developers do need to understand which API to call.