Key Takeaways

  • Linear hosts optional, company-wide meetings called Feature Roasts before releasing any new product feature.
  • Anyone in the company can join to point out confusing workflows, rough animations, or broken edge cases without softening their critique.
  • Feature teams question reviewers in real time to discover why a flow felt unintuitive to someone seeing it for the first time.
  • Repeated critique sessions teach engineers and designers what colleagues care about, raising quality standards across future builds.
  • Saarinen relies on the Linear's Feature Roast Framework to turn raw internal reactions into concrete bug tickets.

The Linear's Feature Roast Framework

Most software teams test features in private silos. A product manager tests the happy path, an engineer tests the code branches, and the feature ships straight to users who immediately trip over basic onboarding gaps.

Linear runs a different ritual. As Saarinen explained, “Anyone in a company can join the team who is building the feature.” Instead of a polite demo, the session is an open critique where colleagues attack the work from every angle.

Here is how Linear structures the process:

  • Step 1: Open Feature Roast Session: Host an optional company-wide meeting led by the team building the feature, inviting fresh eyes from across the organization to test it.
  • Step 2: Raw and Nitpicky Feedback: Encourage attendees to submit uncensored, non-personal critiques detailing every point of confusion, friction, or visual imperfection.
  • Step 3: Interactive Q&A: The feature team questions reviewers in real time to uncover why specific flows felt unintuitive, simulating first-time customer reactions.
  • Step 4: Synthesis into Actionable Issues: The feature lead groups the feedback themes and converts them into concrete bug and enhancement tickets to resolve prior to release.

Saarinen points out that the real value lies in the safety of direct feedback: “What they ask people to do is just critique the whole feature. You can be as nitpicky or confused or whatever you want. You just put your raw feedback and it's not personal.” When a coworker gets stuck in a flow, it reveals what real users will experience: “It's likely that the users are confused too.”

Over time, these meetings build shared intuition across the company. As Saarinen noted: “You remember one of these discussions and you know that person always cares about the onboarding or they care about this animation, so I should check into that and remember to do it so I don't get that feedback.”

When This Works (and When It Doesn't)

This framework works when applied to pre-launch features to uncover usability hurdles and build shared taste across cross-functional team members. It shines in companies that value high visual craft and smooth user experience, where catching micro-interactions and confusing copy early saves weeks of public embarrassment.

It fails if your company culture confuses critique with personal attack. If junior engineers feel targeted when their work gets picked apart, people stop sharing early builds. It also breaks if the feature lead treats every piece of nitpicky feedback as a mandatory blocker. The lead must separate real usability blockers from individual design preferences.

What to Do With This

Take the major feature your team plans to release next week. Instead of a standard slide demo, schedule a 45-minute Roast session on your calendar for Thursday.

Post the build link in your team chat 10 minutes before the call. Tell everyone from sales, support, and engineering to click around and dump every single point of friction into a shared doc in real time. Have the feature builder sit quietly, observe where people get stuck, and ask: "What did you expect to happen when you clicked that button?" Before the call ends, convert the top five points of confusion directly into issue tickets.