The Middle-Manager Reporting Veto
Automatically say no to customization features that ease manager reporting at the cost of IC workflow
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 3
- Confidence
- 95%
Linear pre-classifies feature requests into two buckets: those worth debating and those that get an automatic no. The automatic-no category is narrowly defined — customization features requested by middle managers to make reporting easier at the expense of the individual contributor's workflow. Saying yes to these is what bloats enterprise software, because ICs quietly disengage from the extra data-entry burden, which in turn corrupts the very reporting the manager wanted.
Origin
Nan Yu's account of Linear's product-prioritization policy and its core promise not to make the IC-versus-manager trade-off.
Core principles
- 01Sort feature requests into 'debatable' and 'absolute no' before any specific request arrives
- 02The absolute-no category is specific: customization for manager reporting that degrades IC experience
- 03When ICs are forced into data entry that does not serve their actual job, they skip it or fill it randomly, making the resulting reports wrong anyway
- 04The buyer's real goal is a more effective team, not the reporting feature — so you can navigate them away from the request
- 05Holding this line is a core, non-negotiable promise, not a case-by-case debate
How to run it
- 1
Pre-decide the automatic-no category
Define, before requests arrive, the exact shape of feature you will never build: customization requested by middle managers to make reporting easier at the cost of making the IC workflow worse. Because it is decided in advance, there is no debate when it shows up.
Pro tip Naming the category precisely is what lets you decline instantly without re-litigating each time.
Watch out PMs find these easy to say yes to because the request comes from buyers/gatekeepers with sales pressure behind them — that pressure is exactly what the pre-decision protects against.
- 2
Expose the false trade-off to the buyer
When a buyer insists a reporting/customization feature will drive their purchase, show them the premise is wrong: the moment IC experience degrades, ICs disengage, data becomes sparse and random, and the reporting they wanted becomes unreliable.
Pro tip Tie it to the buyer's actual motivation — they are buying because they want their team more effective, and this feature undermines that.
- 3
Rank the buyer's real priorities and solve the top few natively
When a buyer brings a laundry list of ten asks, get them to admit only the first three truly matter. Solve those three far better than anyone else as native features, and negotiate away the rest.
Pro tip Native depth beats letting users self-serve via visual/customization programming, which never reaches the quality level you can deliver natively.
Watch out Still do the neutral scaling work (SAML, SCIM) — those keep-the-lights-on requests are separate from the bloat category.
In the wild
Users kept asking for fully customizable fields. Digging in, ~40% actually wanted to track which customer (e.g. Walmart) asked for a feature so CSMs had evidence of work done. Rather than add custom fields that ICs would have to fill manually, Linear built a 'customer requests' concept that hooks into support tools and CRMs, auto-tags escalated feature requests with the requesting customer, and surfaces the real email context to engineers.
→ Managers still get their reporting and ICs' lives get easier — they see exactly who asked and why, with zero extra manual tagging.
Common mistakes
Saying yes to close a deal
Adding a middle-manager customization feature to win a specific sale starts you down the path to bloatedness and breaks the core promise that makes ICs love the product.
Taking the request literally instead of finding the real job
Building the custom field the buyer literally asked for solves the surface request while creating the IC data-entry burden that ultimately corrupts the data.
Is it for you?
Best for
B2B PMs and product leaders facing constant buyer/gatekeeper feature pressure who want a durable anti-bloat prioritization policy
Not ideal for
Products where the manager/admin IS the primary user, or genuine keep-the-lights-on enterprise requirements like SSO/SAML/SCIM
From the transcript
“it's customization features requested by middle managers in order to make reporting a little bit easier at the cost of making IC workflow is worse…”
“we kind of look at what kind of feature requests can we debate and what kind of feature requests do we absolutely have to say…”
“the moment you start going down this path and you make um you make the IC user experience worse they're just going to disengage right”
“the first three are the things that really matter to us if we solve the first three then the other stuff we can negotiate on…”
From the episode
Linear’s secret to building beloved B2B products
Nan Yu (Head of Product)