Skip to content

PATTERN Cited by 1 source

Customer-Driven Feature Prioritization

A product-development practice: feature selection and ordering are driven directly by customer requests, not by internal roadmap speculation. S3's team reports it as their default posture. Andy Warfield (2025):

"Almost everything we do, and certainly all of the most popular features that we've launched, have been in direct response to requests from S3 customers."

(Source: sources/2025-03-14-allthingsdistributed-s3-simplicity-is-table-stakes)

Mechanisms the S3 post describes

  • Deep engineering conversations with customer builders. S3 team members spend time with infrastructure-services teams (Netflix, Pinterest, Snowflake, Smugmug and, more recently, startups like Turbopuffer). Those conversations surface gaps earlier than internal ideation.
  • Watching for customer "probing" behaviour. Before a new REST verb is launched, the S3 team often sees traffic to the new endpoint in dashboards — customers guessing at feature names and hitting them hourly. That traffic is treated as signal about what customers want. "The team is surprised that the dashboard starts posting traffic as soon as it's up, even before the feature launches."
  • Monitoring "What's new" consumption. Turbopuffer's CEO runs an hourly script monitoring S3 "What's new" posts and sending notifications. This is cited not as a curiosity but as a feedback channel: customers care enough to poll a changelog.
  • Explicit retrospective re-framing. A sharp-edge complaint ("100 buckets is weird") is not treated as a cap-raising ticket but as a framing-shift request: customers are telling us buckets should be a programmatic resource, not a human one. That reframing drives the scope of the fix (systems/metabucket rewrite, paged ListBuckets, console-rendering cross-service campaign).

Contrast with product-roadmap driven approaches

  • Roadmap-first risks optimising for the platform's model of the world; customers' sharp edges go unfixed because they're invisible to internal planning.
  • Customer-driven risks chasing the loudest customer at the expense of harder, slower architectural work. The S3 post's counterweight is patterns/pr-faq-writing — the PR/FAQ doc forces the team to articulate the position, tenets, and limits of a service, which stabilises scope even as customer requests flow in.

What distinguishes the "listening" here

Three specific traits in Warfield's telling:

  1. Listening to engineers, not just PMs — the feedback channel is peer-level technical conversations.
  2. Listening to infrastructure-on-top-of-S3 customers in particular (databases, file systems, vector stores) because they're the first to hit limits and have opinions about them.
  3. Treating unreleased-feature probe traffic as a legitimate demand signal, not just a curiosity.

Failure modes

  • Availability bias — loudest/largest customers dominate. Mitigated by tenets / PR/FAQ that pin the target use case.
  • Fragmentation — many small feature requests fragment the API; simplicity erodes. S3 hits this: the simplicity/velocity tension (concepts/simplicity-vs-velocity) is partly a function of customer-driven growth.

Seen in

Last updated · 200 distilled / 1,178 read