Speed Is a Symptom of Competence: How Linear Builds Beloved B2B Software

Lenny opens with survey results from his newsletter: when subscribers were asked which tool they wished they could switch to if IT allowed it, the number one answer by far was switching from Jira to Linear (5:21). He reads quotes describing Linear as a joy to use, simple yet powerful, and an industry benchmark whose speed is a productivity boost. Nan says the quotes are good to hear because they reflect what Linear is trying to do.

Nan traces Linear’s origin to Karri, who watched people at Coinbase and Airbnb struggle with incumbent tools and saw how those tools made daily work feel worse (5:54). People entered technology because building things was fun—many started with MySpace pages and side projects—and then encountered speed bumps in the workflow. Linear was started to bust through that.

Lenny calls Linear an inspirational business because “build a much better version” often fails: people do not switch, and there are barriers beyond product quality (7:00). Linear is an example of building an excellent product and succeeding, with more to learn about how the company operates. To Lenny, people being sad they cannot use a B2B enterprise product is the ultimate sign of product-market fit.

Nan rejects the usual speed-versus-quality trade-off because people over-index on speed as rushing or sloppiness, when they should index on competence and expertise (8:07). At the pinnacle of any craft—cooking, programming, building houses—fast work by an expert is often a signal that the output will be good. Software quality depends heavily on how many iterations a team can complete, and rapid iteration is how teams feel out variations.

In practice, speed means setting a rough time budget and producing something workable after about 10% of that time has elapsed (9:41). After week one, the team should have something that tests a key hypothesis internally, rather than waiting until the halfway point or 80% mark to learn that an assumption was wrong. Waiting too long pushes out deadlines and creates downstream pain.

What enables this is talent and intent: Linear hires engineers who do not get blocked by every small design choice and who can make something workable even if they are not comfortable with the particular solution (10:47). The team does not expect the first version to be great; it treats V1 as the best guess in the general direction of the eventual ship. No one has to be a perfectionist or sand every detail down, because the first job is to validate or invalidate the major assumptions.

Lenny cites Patrick Collison’s tweet that “good, cheap, fast—choose two” is misinformation spread by the slow, and Nan agrees, adding that slow and expensive usually go together and that elite chess players like Magnus Carlsen and Hikaru Nakamura can win while moving unusually fast (11:51). The concrete advice is to accept the controlled risk that the first version will not be perfect, which makes early work cheaper: no pixel-perfect design and no need to solve every small UI bug (12:53). What matters is working software that people can interact with and use to judge whether it solves the core problem. Linear then widens the circle from internal users to early-access customers and finally GA, provided the release will not corrupt data or look hideous (14:00).

Lenny raises the common criticism that Linear will eventually become bloated like other enterprise software, forced to check boxes for IT and buyers; Nan says candidates ask this question often because history is littered with startups that failed in the category (15:42). Linear examines which feature requests can be debated and which must be refused outright. The refused category is specific: customization requested by middle managers to make reporting slightly easier at the cost of making IC workflows worse.

If a request fits that description, Linear says no without debate because taking a single step down that path would break one of the core promises of the product (16:46). Nan acknowledges the pressure: PMs often talk to buyers, sales pushes for a feature that will make reporting nicer, and a director may promise a buying decision based on it. Linear tries to convince them that the premise is a false trade-off.

The reason is that making the IC experience worse causes engineers to disengage; their performance reviews are based on code contribution, not on filling in tickets correctly (17:52). They will update tickets sporadically or pick a random option from a required dropdown with nine choices they do not understand. The reporting then becomes wrong because the underlying data is sparse and unreliable, so the apparent win for managers destroys the data they wanted.

Nan distinguishes this from basic scaling work like SAML and SCIM, which Linear will build to keep the lights on (20:05). For business-logic features, buyers usually have a laundry list but admit only the first few items really matter; Linear tries to solve those top needs natively better than any customization workaround. Enterprise growth has been leading other segments, and Nan says Linear has reached a brand tipping point where large companies that want to act like startups feel the product is “for us” (22:16). A “no” often means “not now,” because budget, change management, or an executive attachment can change, so Linear keeps those prospects in CRM and follows up (23:21).

The harder debates at Linear come when the team decides whether to extend an existing native feature or add a new service (24:25). Nan says the key is identifying exactly who will use it and which real-life use cases exist—not a hypothetical Alice or Bob, but a first name, last name, and email address that the team can ask. Reality is sometimes ugly, and a beautiful, elegant solution that does not match reality will not have staying power even if people admire it (25:31).

Nan describes a “kneeling” process for early feedback: a feature goes into the wild, feedback shows that part of the team’s model did not fit reality, and the team asks whether it tested that aspect (26:06). In that case the volume of feedback matters less than whether the team thought about that part correctly. For large requests with many use cases, the team digs in to see whether there are concentrated pools of use cases worth solving first rather than building one giant feature for the long tail (27:11).

Linear’s Customer Requests feature came from repeated requests for fully customized fields (28:14). When the team asked what customers were trying to do, about 40% said they needed to track a customer like Walmart and report on what had been done for that account. Instead of adding 100 custom fields that would burden ICs, Linear connected to support tools and CRMs, automatically brought in feedback, analyzed the emails, and tagged escalated requests with the customer who asked (29:18).

The result is that ICs do not have to do extra tagging, but they can still see who asked for a feature and what the original email said, which makes them more confident when designing the details (29:48). Lenny notes how often teams would simply build the custom field when they hear the request, while Nan’s approach keeps digging until the underlying customer need is visible. This is the same pattern as the earlier rule: solve for the real person and the real workflow, not the literal request.

Nan says his goal on customer calls is to feel bad in the same way the customer feels bad, not merely to run five whys or map a persona to a goal (30:50). A request like “we want X” has an emotional valence behind it, and many customers will not answer “how do you feel?” directly, but a deep enough conversation can get them to level with you. The more they see that you see their perspective, the more they open up about the actual moment that hurt.

One example: a customer marked a project’s ship date as December 30 because it was a Q4 project, then marketing lost its mind because nobody ships on December 30 when everyone is on vacation (31:59). The customer’s real pain was the false precision and miscommunication that the date field forced on them. Linear solved it by letting projects specify a target date at whatever granularity the team is happy promising—a December project, a Q4 project, or a second-half-of-2024 project (33:36).

Nan argues that competitive industries have already picked the low-hanging goal-oriented insights because every PM asks about goals and jobs to be done (34:41). The underexplored angle is emotional hooks: where do people feel bad during their workday, even if they do not recognize it? He cites Paul Graham’s “schlep blindness” and gives the example of someone who hates Mondays because they must gather data for a report; a button that makes the report would reduce that hate (35:16).

Triage Management came from two bad feelings with the same root cause: some teams routed tickets by hand and felt underwater, while others threw tickets over the wall and had no idea what happened to them (36:22). Linear systemized the queue with notifications, rotations, and organized responses instead of asking people to manage it manually. A separate backlog of 20 or 30 product opportunities—such as capacity planning—is kept with up-to-date analysis so the team can accumulate understanding before committing to take on the whole problem (41:14).

Nan’s creativity method starts from the difficulty of extrapolation: people see what is in front of them but struggle to think two or three steps down the line (45:01). The team asks how extreme it can take a solution along some trait, similar to Brian Chesky’s “11-star experience” or a 10X version of an idea. The point is to throw away cost and practicality for a moment and explore the possibility space beyond the constraints people carry without realizing it (46:07).

The biggest risk in product decisions is not choosing the wrong option among three; it is never seeing the fourth option in the corner you did not look in (46:42). Building the extreme version fast lets the team feel that area of the product space and learn what the right actual answer is. Nan says the best solutions are obvious in hindsight, but you need an internal process to find your way there (53:50).

The draft-saving feature in Linear shows the process: the team first built the fastest draft experience, with no popup asking to save changes, and it felt unsafe when a user closed the window (48:24). Then they built the safest version, auto-saving every character, which did feel safe but left a paper trail of “Untitled” drafts and abandoned objects (49:57). The final design interrupts on a brand-new issue so the user can save or discard, but auto-saves changes to an existing draft because it is not creating a new object (51:02).

Linear rolled the extreme versions out to internal users and beta audiences: the fast version only went internal and everyone felt it was too unsafe, while the safe version showed how many drafts people were leaving behind (53:18). The final balance came from feeling both extremes and finding where they met. This is the same early-iteration logic as the 10% rule: build something extreme quickly, learn from it, and use that learning to shape the real product.

Nan argues that B2B software is not just a solution to a problem; it often encodes a process that a company invented and turned into a product (54:26). Adopting marketing software means adopting practices like campaigns, click-through measurement, and customer acquisition cost, whether or not the buyer knew those practices before. The buyer is effectively saying that the tool’s defaults set the baseline level of competency the organization will accept (55:28).

ERP adoption is the extreme example: companies endure deep surgery and redo internal processes because they believe the ERP represents a battle-tested way to manage resources (56:01). Linear’s opinionated approach is not arbitrary; Nan says the team looks for consensus among many high-performing teams and then asks whether it can give a team a button to start practicing that behavior (57:38). When Linear sees teams managing triage well but manually, it automates the practice so another company can adopt it without already knowing it (58:10).

Internally, Linear treats product management as partly a go-to-market discipline, not only one leg of the engineering-product-design triad (58:44). Nan describes a “double triangle”: the PM sits in the middle connecting engineering and product design on the building side to sales and marketing on the selling side (1:01:22). A full-time product marketer sits on the PM team, writes change logs and release notes, crafts language for upcoming releases, and works with sales to validate the message in the field (1:00:19).

The advice for PMs in B2B is to lean into the sell side, because many PMs already collaborate well with engineering and design and leave impact on the table by ignoring go-to-market (1:02:58). PMs should originate the words and emphasis that customers see, since their discovery work gives them a deep understanding of the customer’s native language (1:03:30). They do not need to own demand generation or channel strategy, but they can help marketing pick the right phrasing so the company sounds native to expert practitioners with sensitive BS detectors (59:48).

Nan’s job-search advice starts from the fact that PM roles are broad and hiring managers are trying to solve a burning problem (1:04:31). Candidates should put on their discovery hat and figure out the actual job to be done for the hiring manager, then make the case that they are the solution to that problem. That turns the decision into “hire the solution” versus “roll the dice on someone else,” instead of a generic contest of who claims to be great at everything (1:05:39). He recommends acting like you already work there: ask about the team’s OKRs this quarter, how someone can help achieve them, and whether you can speak with an engineering manager working on the same problem (1:06:49).

Nan’s deadline philosophy is to have few deadlines, but when one exists, treat it as a P0 (1:09:30). The engineer working on it does not get pulled onto anything else, and the PM’s job is to cut as much scope as possible so the team can reach a go/no-go moment with a real product. Deadlines usually come from external marketing moments, and Nan argues that launch opportunities are finite: 365 days, 12 months, roughly 50 weeks, or four quarters, and a missed message cannot be recovered (1:11:04). Linear does almost no estimating to hit deadlines; it ships as early as possible so the team can spend the rest of the time deciding whether to iterate or polish (1:13:12).

In the lightning round, Nan recommends Don Norman’s The Design of Everyday Things because it makes him see every door, pencil, and object as a designed product (1:14:19). He enjoyed The Diplomat on Netflix, though he found the second season more spy-thrillery than the first, and he likes the Sakura Micron pen—including an official “Bible Study Kit” package of four colors marketed around the pen’s no-bleed property (1:15:23). His life motto is “the correct amount is too much minus one,” which he connects to testing extremes: five slices of pizza may be too many, so four is probably right (1:16:59).

He also tells the story of Everlane’s Women’s Box-Cut Tee, which began with a batch of men’s T-shirts that were an inch and a half too short (1:18:05). Instead of writing off the inventory, the design and marketing teams cut another two inches, made it a cropped boxy silhouette for women, and sold out in a week; it now comes in about 20 colors. Nan says he witnessed the creation rather than directly leading it, and he can be found on X/Twitter as @thenanyu, where he welcomes feedback from Linear users (1:20:14).