How to Tie Every Feature to a Named Customer (2027 Guide)

Most B2B roadmaps contain features nobody can trace to a real customer. This guide from the BuildBetter team shows you how to fix that with a shared spreadsheet, one accountable owner, and a weekly review. You can start this week with no budget. The method comes from Chapter 12 of Customer-Led Development, and it closes with an honest test for when manual tracking stops scaling.

What Named-Customer Traceability Means (and Why Your Roadmap Probably Fails It)

Your roadmap is probably full of features nobody can trace back to a real customer. When one of them ships, nobody knows who to tell. Nobody can say whether it worked either.

Named-customer traceability is the practice of attaching the specific customer names (account and person) and the supporting evidence to every roadmap item, so the team knows who it is building for, can tell those customers when it ships, and can check whether it worked for them.

A name means “Acme Corp” or “Sarah at BigBrand.” A name is not a persona, a segment, “enterprise users,” “power users,” or “our ICP.” The practical test: if you can't phone or email them, it isn't a name.

For any proposed feature, ask one question: “Which customers?” If the answer is a persona or a segment, you are looking at internal opinion dressed up as customer insight.

The stakes are concrete. As cited in Customer-Led Development (ch. 12), roughly 80% of features are rarely or never used. An older Standish Group figure, presented at the XP 2002 conference, put “never used” at 45% and “rarely used” at 19%. Critics have pointed out that it was based on a small set of internal custom applications, so treat both numbers as directional. The direction is still clear: teams spend a large share of engineering time building for nobody. Names are the cheapest guard against that.

This practice adds to Agile. It does not replace it. Sprints, standups, retros, and your Definition of Done stay where they are. The Agile Manifesto values “customer collaboration over contract negotiation,” but it never asks you to record which customer a piece of work is for. As a result, Agile never answered who you built a feature for, why, whether they knew it shipped, or whether it worked for them.

Why Features Lose Their Names: What Actually Breaks

Features lose their names at every handoff between the customer and the sprint. No single person deletes the name. It gets worn away step by step.

• Requests get abstracted on the way in. “Acme needs SSO audit logs” turns into “enterprise wants better security” by the time it reaches planning. The name is gone, and so is the specific job to be done.
• Sales promises live in reps' heads and email threads. The sequence runs from “We'll have that next quarter” to “It's on the roadmap” to “We're prioritizing other things.” The customer hears none of it.
• Support becomes a black hole. Tickets get resolved one at a time. The pattern never reaches product, so product never learns which accounts hit the problem.
• Counts replace names. “Requested by 47 customers” helps with priority. It gives you nobody to call when the feature ships.
• HiPPO features enter with no customer at all. They borrow credibility from phrases like “customers have been asking.”
• Agile ends at deployment. When the definition of done is “shipped,” nobody owns telling the requester or checking whether it worked.

The result is a roadmap that cannot answer four basic questions:

• Who is it for?
• Why did we build it?
• Did they know we built it?
• Did it work for them?

Melissa Perri calls this the “build trap” in Escaping the Build Trap. Teams measure output because outcomes were never tied to anyone in particular. Names are what turn the four questions into checkable facts.

The Method: Attach Names and Evidence to Every Roadmap Item (Spreadsheet Version)

This method comes from Chapter 12 of Customer-Led Development by Spencer Shulem, and its governing rule is: “Every feature should trace to a specific customer name.” Everything below runs on a shared spreadsheet. You don't need any software.

Step 1. Appoint one Customer Truth Owner

Pick exactly one person. This can be a Product Ops lead, a senior PM, or the CEO at an early-stage company. They validate attribution on every roadmap item and flag promises at risk of being forgotten. Reps, CSMs, and PMs all add rows, but one person owns the integrity of the sheet. The title matters less than the fact that there is only one owner.

Step 2. Build the traceability sheet

Use one row per roadmap item with these columns:

Step 3. Define the evidence bar

A name only counts if it comes with a direct quote or a linkable source. “Rep says Acme wants it” with no record is a lead, not evidence. Record the customer's wording verbatim. Paraphrase is where abstraction creeps in. “We need to export audit logs for our SOC 2 auditor every quarter” becomes “better security” within two handoffs. Use conditional formatting to turn any name without a link yellow.

Step 4. Audit every existing item

Ask “Which customers?” of each roadmap item and sort it into one of three buckets:

• Named + evidenced: ready
• Named, no evidence: needs proof
• No names: fails

Step 5. Apply the no-name rule

If you can't name the customers, you can't build the feature. Give each unnamed item a fixed validation window, usually one planning cycle. During that window, look for real names in calls, the ticket queue, and sales conversations. If no names turn up, cut the item or park it. Guesses go back to validation. They do not go into a sprint.

Step 6. Track promises through five statuses

Promises move through Captured → Validated → Building → Delivered → Confirmed. Any “we can do that” from sales gets a row the day it is said. Delivered is not the end state. Confirmed means the named requester knows the feature exists and has validated it.

Step 7. Make names a prerequisite with customer story mapping

This step adapts Jeff Patton's user story mapping. Replace the generic “As a user…” with real names. Every backlog story carries named customers, their direct quotes, the specific value expected, and a follow-up commitment that names who closes the loop.

Step 8. Close the loop when it ships

The loop owner sends a direct note to every named customer. A generic release note does not count. The script from the book is short: “You asked for X. We built it. Here it is.” Bug reporters get notified when the fix lands.

Step 9. Validate with the requesters

Shipping isn't done until the customer knows and validates. Check two things within a set window, such as 30–60 days:

• Adoption: more than 80% of named requesters actively use the feature. If adoption is lower, you probably built the wrong thing.
• Satisfaction: more than 80% of requesters say you got it right.

Step 10. Review weekly

Each week, the Customer Truth Owner reports three lists: items without names, promises stuck in one status, and loops still open. Pair this with a short Learning Loop Review that asks what customers taught you this week and what it changed. Teresa Torres argues for weekly customer touchpoints in Continuous Discovery Habits. Discovery produces the names, and this review keeps them from getting lost.

Cost: The first audit of a typical roadmap takes an afternoon. After that, maintenance is a few minutes per new item plus the weekly review.

Worked Example: Auditing One Quarter's Roadmap Line by Line

The example below is illustrative: a hypothetical B2B SaaS team, not a real case study. The numbers are there to show the decision logic.

The team starts the quarter with 18 roadmap items. The Customer Truth Owner runs Step 4 over one afternoon.

One row in full. Item: Bulk CSV export for audit reports.

• Named customers: 3 accounts, each with a person contact
• Evidence: 2 support tickets and 1 call note with a direct quote
• Sales promise: yes, made to one account; status Validated
• Loop owner: the CSM on that account

The 5 “named, no evidence” items. The PM and reps spend a week getting confirmation calls or written requests. Three confirm with quotes and move to ready. Two fall apart because the customer had described a different problem. Those two are rewritten to describe the actual problem, with the actual names attached.

The 6 “no names” items. These get a two-week validation window. Two find real names, one through the ticket queue and one through a churned-account review, and they stay on the roadmap. Four find no one. Three are cut. One leadership item is parked with an explicit “no customer evidence” tag, so the disagreement is on the record instead of hidden. Jeff Bezos's 2015 shareholder letter describes a similar split at AWS: 90–95% of what it builds comes from what customers say they want, and the rest is invention on their behalf. The tag lets you place a bet like that knowingly.

Outcome. The roadmap drops from 18 items to 14: 12 ready and 2 rewritten. Every surviving item has a named list for closing the loop at ship. The 3 cut items free up engineering time for evidenced work.

At ship. The CSV export goes out, and three direct notes go to the three named contacts. Two customers adopt it within the follow-up window. One replies that it is missing a field. That reply becomes a new row with a name already attached.

The audit removes features, but its larger effect is this: it turns “who should we tell?” from an unanswerable question into a column in a spreadsheet.

Common Mistakes When Tying Features to Customers

Most traceability failures come from discipline, not from tooling. These are the ones that show up most often.

• Accepting segments as names. “Mid-market fintechs” feels specific and still fails the method. If you can't phone them, it isn't a name.
• Name-stuffing. Teams backfill a friendly account name onto a feature they already wanted to build. Requiring a quote or source link is the defense.
• Treating the count as the evidence. “47 requests” without names gives you a priority and no one to close the loop with. Store the names and derive the count from them, never the reverse.
• Logging sales promises only when it's convenient. The promise board is only as honest as the reps who feed it.
• Stopping at Delivered. Teams ship, post a release note, and never reach Confirmed with the requester.
• No single owner. When attribution is everyone's job, nobody validates new roadmap items.
• Letting the HiPPO bypass the rule. If leadership items skip the “Which customers?” question, the whole system starts to look optional.

No software fixes several of these, including ours. A tool can surface names and draft loop-closing emails. It cannot make a rep log a promise they'd rather forget, stop an executive from overriding the no-name rule, or make a team send the follow-up and read the reply. Those depend on habits and on leadership backing the rule.

When the Spreadsheet Stops Working, and the Tools That Help

Linking by hand works for a small roadmap where evidence lives in one or two places. It breaks when evidence is spread across call recordings, support tickets, CRM notes, and Slack, because finding the quote for each name turns into a research project. These are judgment calls, not statistics, but here are the signals to watch for:

• The weekly review takes more than an hour.
• Reps stop logging because it feels like double entry.
• The same customer appears under three spellings.
• Nobody can find the source for a name added last month.
• Requests arrive from more systems than one person checks.

If none of these apply, stay on the spreadsheet. You don't need a tool to run the method.

1. BuildBetter

BuildBetter pulls calls, Slack, support tickets, surveys, and CRM data into one place through 100+ integrations, including Zoom, Slack, Jira, Salesforce, Zendesk, HubSpot, and Intercom. The names and quotes behind a request arrive attached to their evidence, so nobody has to hunt them down. Signals extracts each request with its account and verbatim wording. Tracked Objects follows commitments and requests through to release. Tickets and Documents draft Jira or Linear issues, PRDs, and loop-closing emails addressed to the named requesters. Honest limits: it is not built for large-scale enterprise survey distribution or for a dedicated research-repository tagging workflow, and it does not replace the human discipline described above.

2. A shared spreadsheet (Google Sheets or Excel)

Free, immediate, and enough for small roadmaps. It breaks down on manual evidence-hunting and duplicate customer entries.

3. Airtable

Linked records let one customer connect to many roadmap items and promises, and a filtered view can serve as the promise board. People still have to paste in the evidence.

4. Coda

The doc-plus-table format suits teams that want the traceability table, weekly review notes, and loop-closing templates in one place. Capture is still manual.

FAQ: Tying Features to Named Customers

What does it mean to tie a feature to a named customer?

Every roadmap item lists the specific customers (account and person) who need it, plus evidence of their request, such as a quote or a link to a call note, ticket, or email. The team then knows who it's building for, who to tell when it ships, and whose feedback decides whether it worked.

What should we do with a roadmap item that has no customer names?

Send it back to validation with a fixed deadline, typically one planning cycle. Look for real names in customer calls, the support queue, sales conversations, and churned-account reviews. If nobody can be named by then, cut it or park it with an explicit “no customer evidence” tag. The rule from Customer-Led Development is that if you can't name the customers, you can't build the feature.

Isn't a request count like “47 customers asked” good enough?

No. The count is useful for priority, but it gives you nobody to notify at ship and nobody to ask whether it worked. Store the names and derive the count from them.

How do we handle infrastructure or tech-debt work?

Trace it to the named customers it unblocks or protects, such as accounts hitting rate limits or customers whose SLAs depend on it. If no customer anyone can name benefits, question the work. Don't treat it as exempt from the rule.

Who should own named-customer traceability?

One Customer Truth Owner: Product Ops, a senior PM, or the CEO at an early-stage company. They validate attribution on every new roadmap item, run the weekly review, and flag stuck promises.

How do you tell customers when their requested feature ships?

Send a direct message to each named requester instead of a generic release note: “You asked for X. We built it. Here it is.” Then follow up to confirm it worked for them.

How do you know the traceability is working?

Track three numbers. Requester adoption of what they asked for should be above 80%. Requester satisfaction should be above 80%. Promise-to-delivery time should be under 30 days for most features.

Sources and Further Reading

• Spencer Shulem, Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything, Chapter 12 (source of the method, five statuses, roles, and metric targets).
• Jeff Bezos, 2015 Letter to Amazon Shareholders (AWS 90–95% customer-driven figure, the Aurora example, and the Chai Cart program: 31 cities, 37,200 cups of tea, 10,000+ sellers).
• Manifesto for Agile Software Development
• Wikipedia: Agile software development
• Wikipedia: Amazon Aurora
• Jeff Patton, User Story Mapping (O'Reilly, 2014)
• Teresa Torres, Continuous Discovery Habits (2021)
• Melissa Perri, Escaping the Build Trap (2018)

Make Churn Optional

The spreadsheet method works, and you should start with it. Once your evidence is scattered across calls, tickets, Slack, and your CRM, BuildBetter keeps every name, quote, and promise attached to the roadmap item it belongs to. It also drafts the “You asked for X” note for each requester when the feature ships.

Make churn optional. Book a demo

Further reading: Customer-Led Development

The method on this page comes from Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything by Spencer Shulem, BuildBetter's founder, drawn from more than 2,000 conversations with product leaders. It lays out the full system: how customer truth flows through a company, how every feature traces to a named customer, and how loops get closed.

Start with the overview: What is customer-led development?