From customer feedback to shipped feature

Cloudflare’s product roadmap is shaped by a steady stream of customer feedback, funneled through Customer Success Managers into Feature Requests that Product and Engineering teams review. The loop is a deliberate one: account teams collect input during Quarterly Business Reviews and other touchpoints, then route it through an internal process designed to connect real-world use cases with the engineering backlog.

The process works like this:

  • A Feature Request is logged in the internal CRM on behalf of a customer, with a description, desired solution, current workarounds, and urgency level.
  • Solutions Engineering Subject Matter Experts review each request for completeness and proper classification.
  • Product Managers evaluate the request and link it to internal tracking systems.
  • When needed, Product teams meet directly with customers to clarify use cases before development begins.

Many requested features are already on the roadmap, but customer input influences both timing and design. Priority decisions can depend on how critical a request is, how many customers ask for it, existing partnership commitments, and strategic direction from leadership.

A concrete example: Secondary DNS Override

The process is best understood through a real deployment. A large financial institution, referred to here as Customer A, was using Cloudflare for Secondary DNS — a configuration where DNS records are synchronized across multiple providers for redundancy. The catch: with standard Secondary DNS, all nameservers return the same answers. That prevents a customer from also using the same provider for HTTP proxy services like Layer 7 DDoS mitigation, WAF, or CDN, since those services require answering DNS queries with the provider’s own IP space.

Customer A wanted both. They were exploring a multi-vendor setup that would use Cloudflare as a Secondary DNS provider and, for some applications, as a proxy in front of their web traffic. Another customer (Customer B) had on-premise DNS servers with automated record updates. They wanted a single Secondary DNS provider that could accept those transfers and serve queries at scale, while still letting them choose which records to proxy — without re-architecting their full DNS infrastructure.

Both requests were filed as Feature Requests, and Cloudflare’s DNS team followed up with each customer to understand the details before building.

How the feature works

The resulting feature, Secondary DNS Override, lets a customer instruct Cloudflare — acting as the Secondary DNS provider — to respond to certain queries with Cloudflare’s own IP space. That response is what enables HTTP proxy services to be used alongside Secondary DNS.

For Customer A, this meant web applications could sit behind Cloudflare’s security and performance services even with Secondary DNS already in place, and end-users receiving DNS responses from Cloudflare would benefit from those services. Customer B set up their on-premise infrastructure as a “hidden primary” and enabled automatic zone file transfers, immediately using proxy services without a broader migration.

During development, the DNS team and account teams kept both customers updated throughout. The feature shipped API-only in November 2019, with UI parity following the next quarter. Customers could use the API right away and continued providing input on what they expected from the interface.

Secondary DNS Override is one example among many of how a customer-driven request became a shipped product. Most such requests arrive through Quarterly Business Reviews — part of the Premium Success offering — or the annual health check included with Standard Success.