Linear has set the bar when it comes to modern software development, delivering a product that's beautiful, reliable, and effective at supporting winning outcomes. The project management industry is crowded with legacy players and few tools are beloved - Linear is changing that narrative. They're constantly winning new customers of all sizes and across all markets (OpenAI, Ramp, Cursor, and Substack are just a few examples), and their competitors' users long to switch. A recent survey of tech industry professionals by Lenny Rachitsky revealed that Linear is the tool most respondents would switch to if they could, making it an excellent case study in product development. The following is an in depth, evidence based guide to how Linear builds its product.

Subscribe now

Core Principles

The Speed-Quality Connection

Linear challenges the common belief that speed and quality are inherently at odds. As their Head of Product Nan Yu explains: "People talk about this as if there were a trade-off because when they think about speed, they over-index on rushing or being sloppy. What they should be indexing on is being really competent."

How to Apply This:

- Get working prototypes in users' hands within the first 10% of development time

- Focus on building expertise that enables rapid, high-quality execution

- Create tight feedback loops that enable quick iteration without sacrificing quality

Deep Customer Understanding

From Nan Yu: "I want to feel as bad as our customers do." This foundational statement reveals Linear's uncommonly deep approach to customer empathy. Yu elaborates, "They come to us with a request, 'Hey, we want X,' and there's something motivating it... What is the actual emotional valence that is motivating whatever you're telling me? My job is to convince our customers that there's a better, more efficient way to get their work done." This quote highlights how Linear balances deep empathy with opinionated product direction – they don't just solve problems as presented, but dig deeper to find better solutions. Linear's sales team has noted that this distinctive approach to customer conversations, where he "keeps digging and digging" until he reaches genuine insights, is a key asset in building relationships with customers. This persistence in questioning is key to their product development process.

From CEO Karri Saarinen: "We do things well or we don't do them at all." This commitment to quality extends to customer understanding – superficial user research isn't enough. Linear invests the time to truly understand user needs before building solutions.

Interview Technique:

Yu approaches customer conversations with a unique methodology focused on emotional discovery:

1. Start with the surface request ("Hey, we want X")

2. Look beyond analytical frameworks like "five whys" or standard personas

3. Probe for emotional context ("How do you feel about this?")

4. Continue the conversation until you understand the actual moments of friction

5. Identify the specific situations where users felt bad or frustrated

6. See if you can get them to be real with you (“This week I made this mistake…”)

A Real Example from Linear:

When discussing project dates, a customer initially requested more date fields. Through deeper conversation, Yu uncovered the real story: "I had this thing happen where I marked the ship date of this project as December 30th because it's a Q4 project... and then my marketing team lost their mind because they're like 'We can't ship something on December 30th. Everyone's on vacation.'" This revealed the true emotional pain point – feeling bad about miscommunication and date precision.

The solution wasn't more date fields, but rather allowing flexible date specificity – users can now specify "December project," "Q4 project," or "second half of 2024" based on their comfort level with committing to specific dates.

Key Principles for Customer Interviews:

1. Look Past Initial Requests

- Surface-level asks often mask deeper needs

- The first request is rarely the real problem

- Keep asking questions until you find emotional triggers

2. Find the Bad Feelings

- Identify moments where users felt frustrated or disappointed

- Look for patterns in emotional responses

- Understand the context that creates negative experiences

3. Seek Specific Stories

- Ask for concrete examples of problems

- Get details about actual situations

- Understand the full context of challenges

4. Build Solutions for Emotions

- Design features that prevent bad feelings

- Focus on emotional outcomes, not just functional ones

- Validate solutions against emotional success criteria

Practical Application:

When Linear's customers asked for custom fields (a common feature request), deeper investigation revealed that 40% of cases were about tracking customer requests. Instead of adding complex customization that would burden users, they built an integrated customer request system that automatically captures and connects customer context – solving the emotional need (feeling confident about customer relationships) without creating new friction.

Focus and Prioritization

Linear's success stems from an unwavering commitment to focus. As CEO Karri Saarinen emphasizes: "Almost nothing else really matters, especially in the beginning. You need to build something that people want. That's what you should focus on."

Opinionated Development

Linear maintains strong opinions about what makes good software. As Yu notes: "Decisions are driven by taste and opinions rather than endless A/B tests."

Key Practices:

- Take clear stances on product decisions

- Focus on solving core problems exceptionally well

- Be willing to say no to features that would compromise the product's vision

Share

Development Practices

Early Product Development

Linear's approach to early product development emphasizes careful user selection and gradual scaling. As Saarinen describes their early days: "We knew that the software doesn't work for all kinds of companies... we use that waitlist as a way to find the right kind of users."

Initial Development Strategy:

1. Start With Core Functionality

- Focus on basic, essential features

- Build an MVP that's immediately usable

- Prioritize professional-grade UI from day one

2. Controlled Growth

- Use a waitlist to manage early access

- Personally onboard initial users

- Iterate based on direct feedback

3. Price Testing

Linear used an innovative approach to early pricing: "Early on we let people choose the price that they want to pay for the product." This helped validate willingness to pay and identify appropriate price points.

Staged Release Process

Linear has developed a sophisticated yet practical approach to shipping new features. As Saarinen describes their process:

1. Internal Testing: "After you have some designs in place or some design ideas, just put it into the app and ship it to production. It's only visible to us so we internally can test it out."

2. Early Access: "The next stage is we look for a customer that could be interested in this feature or we just ask people to opt in to some beta program."

3. Refinement: During early access, "the experience can be a little janky or it's not that polished, but we're okay with it because we are saying 'It's not finished. We just want to get your feedback early so we can make it better.'"

4. General Release: "Once we get to the full general release, then we pay more attention to the actual polish or the craft."

This staged approach allows Linear to:

- Validate concepts quickly

- Get real user feedback early

- Maintain quality standards

- Build confidence in features before wide release

For major features, they often work directly with specific customers. As Saarinen notes: "We usually try to find a large company because sometimes it's hard to imagine these things, how they should work. It's better if someone is willing to work with us."

Implementation Steps:

1. Break features into testable components

2. Build minimal working versions rapidly

3. Test with internal users first

4. Expand to beta users gradually

5. Refine based on real usage

Feature Decision Framework

Linear takes a strong stance on prioritizing individual contributors (ICs) over management-focused features.

Why They Focus on ICs:

When evaluating feature requests, particularly around customization and reporting, Linear identifies fundamental misalignments of incentives:

- Middle managers often request customization features to make reporting easier

- These features typically come at the cost of making IC workflows worse

- ICs, who are measured on code contributions, not ticket updates, will disengage from processes that create friction

- When ICs disengage, the data becomes unreliable, making even the reporting features ineffective

As Yu explains: "This is the exact kind of thing that leads to this bloatedness that makes ICs hate their lives... If it fits that description, we're just saying 'No.' There's no debate."

The Core Belief:

Linear's stance isn't just about saying no to middle managers. It's about understanding that:

1. ICs don't have to use any specific tool - they get measured on code output, not process adherence

2. When forced to use cumbersome tools, ICs will do the minimum possible

3. This leads to poor data quality, making even manager-focused features ineffective

4. The only way to succeed is to make the tool something ICs actively want to use

Example in Practice:

When customers asked for custom fields for tracking customer requests, Linear identified that this would add complexity for ICs. Instead of adding customization, they built an integrated customer request system that automatically captures and connects customer context—solving the business need without creating friction.

Lessons for Product Managers:

1. Identify True Incentives

- Look beyond the immediate feature request

- Understand how different user groups are measured and motivated

- Find where incentives conflict between user groups

2. Choose Your Core User

- Be willing to optimize for one user group over others

- Understand the downstream effects of your choices

- Build conviction around these hard trade-offs

3. Find Win-Win Solutions

- Look for ways to solve management needs without compromising IC experience

- Focus on automated solutions over manual processes

- Build features that naturally generate the data managers need

4. Maintain Clear Principles

- Develop clear criteria for feature decisions

- Be willing to say no to revenue if it compromises core principles

- Build organizational alignment around these choices

Communication and Documentation

PRD Structure

Linear uses a three-section format:

1. Context

- Core motivation

- Marketing rationale

- Success metrics

2. Usage Scenarios

- Real user stories

- Specific use cases

- Expected outcomes

3. Milestones

- Development phases

- Testing points

- Release criteria

Product-Sales Integration

Linear views product management as both building and selling. Yu emphasizes: "Product management is as much a selling function as it is a building function."

Actions for PMs:

- Join sales calls regularly

- Help craft product messaging

- Contribute to marketing content

- Bridge the gap between technical capabilities and market needs

Product Communication Principles

Linear takes a disciplined approach to product messaging, focusing on capabilities and benefits rather than comparative claims. As Yu explains: "Comparative descriptors like 'faster, better, more, easier, simpler' are, for the most part, banned from our product messaging."

Core Framework:

1. Capabilities: Binary statements about what the product can do

2. Benefits: Concrete results users experience

3. Emotional Resonance: The lasting impact on users' lives

Yu emphasizes: "The best product features are those that have emotional resonance with users. The feature here is not 'longer battery life' or even 'all day battery' – it's 'leave your charger at home.'"

Implementation Guidelines:

1. Avoid Comparative Language

- Remove terms like "faster," "better," "more," "easier"

- Focus on concrete capabilities instead of relative improvements

- Describe what users can do, not how it compares

2. Highlight Clear Capabilities

- Use binary, definitive statements

- Create clear before-and-after scenarios

- Focus on what's newly possible

3. Emphasize User Benefits

- Connect features to emotional outcomes

- Describe the impact on daily life

- Focus on memorable, shareable benefits

This approach helps create product messaging that resonates more deeply with users and is more likely to be shared. As Yu notes, "Capabilities draw a stark before-and-after story, and benefits emotionally connect with the customer. If all goes well, these are the things that customers will remember and tell each other."

Quality Control

Zero-Bug Philosophy

Linear implements a strict zero-bug policy through several key practices:

Goalie Rotation System

- Two engineers rotate weekly as "goalies"

- Primary responsibility: address all incoming customer reports

- Goalies actively monitor support channels for direct customer interaction

- Issues are either fixed directly or assigned to appropriate team members

- Focus on rapid response: sometimes fixing and deploying within hours

Response Time Goals

- Official SLA: One week for bug resolution

- Unofficial internal target: 24-hour resolution

- Engineers start each day by addressing outstanding issues before product work

- Weekly reviews of SLA performance

- Target: Maximum two ongoing issues per engineer

Quality Metrics

- Track resolution time for customer-reported issues

- Monitor bug frequency per feature area

- Review bug patterns in weekly team meetings

- Use data to identify areas needing systematic improvement

Implementation Strategy:

1. Initial Clean-up

- Acknowledge that transitioning to zero-bug requires initial investment

- Potentially pause feature work to clear existing backlog

- Create sustainable processes for ongoing maintenance

2. Prioritization Framework

- Customer-impacting bugs take precedence over new features

- As Yu explains: "When you're building a new product, you're building something that the customer hasn't seen yet. Prioritizing that over something that the customer uses and doesn't work doesn't make sense."

3. Judgment Calls

- Empower engineers to use judgment on bug severity

- Some reported issues may be marked "Won't Do":

- Cannot be reproduced

- Affect very few users

- Cost/benefit doesn't justify fix

Deadline Management

Linear takes a unique approach to deadlines, treating them as extreme priorities when used. As Head of Product Nan Yu explains: "The only way to make deadlines real is to take them so seriously that they are basically like a P0 problem, and everything else has to not matter in comparison."

Key Principles:

1. Selective Use

- Use deadlines sparingly

- Reserve primarily for major marketing launches

- Recognize each missed marketing window is permanently lost

2. Total Commitment

- When a deadline is set, it becomes the absolute priority

- Engineers focus exclusively on deadline work

- No context-switching or parallel projects

- Product managers ruthlessly cut scope to ensure delivery

3. Early Preparation

- Start shipping working versions in first 10% of timeline

- Focus on having a shippable (though possibly limited) product

- Create space for iterations and polish

- Enable real yes/no shipping decisions

Implementation Approach:

1. Scope Management

- Continuously evaluate what's essential vs. nice-to-have

- Be willing to cut features to maintain quality

- Focus on having something shippable, even if minimal

2. Team Alignment

- Ensure everyone understands deadline significance

- Create clear priorities

- Eliminate distractions and competing priorities

3. Quality Standards

- Maintain core quality requirements even under deadline

- Focus on shipping something smaller but excellent

- Never compromise on fundamental user experience

Release Date Communication

The Linear product team maintains two separate release dates to ensure communication clarity. The engineering team has their own dev complete target date. This date reflects when the team expects the feature to be ready to go in to production. Then, a rollout date is set for 1 to 2 weeks after the dev complete date. This date is shared with the GTM team, and is the date the feature would actually be turned on in production for whichever group of users are being targeted in the release.

Organizational Philosophy

Individual Contributor Focus

Linear's organizational structure reflects their product philosophy. As Saarinen explains: "We have this very individual contributor focus, which means that instead of having lots of managers and a lot of layers of managers, we have maybe one person with the manager title in the company."

Key Principles:

1. Empower Builders

- Give control to those doing the work

- Trust engineers and designers to shape the product

- Minimize management layers

2. Learn Through Building

Saarinen emphasizes: "When you're actually building something, you see a lot of opportunities, how it could be better... When you give that kind of control or autonomy to the team who actually building it, the results can be much better."

3. Focus on Execution

- Prioritize doing over managing

- Expect everyone to fix problems

- Maintain flat structure

Practical Implementation

For New Features

1. Start with extreme versions

- Build the fastest possible solution

- Build the safest possible solution

- Find the right balance through testing

2. Release Strategy

- Internal testing first

- Expand to beta users

- Gradual rollout to all users

For Product Decisions

1. Identify misaligned incentives

- Look for conflicts between different user groups

- Find win-win solutions where possible

- Make clear choices when trade-offs are necessary

2. Validate Through Usage

- Monitor early adoption

- Track engagement patterns

- Gather qualitative feedback

Key Takeaways for Product Managers

1. Speed Through Expertise

- Invest in building deep domain knowledge

- Create processes that enable rapid iteration

- Focus on learning quickly rather than building perfectly

2. Customer Empathy

- Dig for emotional context in user feedback

- Look beyond feature requests to understand root causes

- Build solutions that transform workflows

- Don’t just talk to customers in discovery interviews, join sales calls as well

3. Clear Decision Making

- Maintain strong opinions about what makes good software

- Be willing to say no to features that compromise vision

- Focus on solving core problems exceptionally well

4. Quality Focus

- Implement clear quality standards

- Create processes for maintaining quality at speed

- Never compromise on core user experience

Remember: Linear's success comes from the careful integration of these principles. The goal isn't to copy their approach exactly, but to understand and adapt these practices to your specific context and needs.

Sources

1. #21 Product Design - Karri Saarinen (Linear) | Builders' Studio: a Founder School by Slush

2. #9: Nan Yu (Head of Product at Linear)

3. Config 2024: The heirloom tomato org chart (Nan Yu, Head of Product, Linear) | Figma

4. Future of Product Management From the Era of AI | Linear Karri Saarinen

5. @thenanyu "I generally write about product..." x.com

6. A Design Reset (Part I)

7. How We Redesigned the Linear UI (Part II)

8. Lenny’s Newsletter: How Linear Builds Product

9. Karri Saarinen (Linear) – Conversations on Quality (Episode 02)

10. Linear: move fast with little process (with first Engineering Manager Sabin Roman)

11. Inside Linear: Building with taste, craft, and focus | Karri Saarinen (co-founder, designer, CEO)

12. Linear’s secret to building beloved B2B products | Nan Yu (Head of Product)

The feedback so far has focused on two main points:

• "Why can't I type more tasks into the box?"

• "I really need to add more than three tasks!"

The core philosophy behind Did You Do It differs from traditional todo apps. I believe a truly productive day isn't about writing down 20 tasks and completing 8 of them. It's about identifying your few most important priorities and actually completing them all.

I could be wrong about this. Users might disagree, and I'm open to pivoting if needed. But before abandoning the three-task limit, I want to give this core hypothesis a proper test.

Looking deeper into the feedback, I've noticed two patterns:

1. Users don't realize there's a three-task limit, leading to confusion when they can't enter more text

2. There's a misunderstanding about the app's purpose - it's not meant to be an exhaustive list of daily tasks

Version 1.0.3 tackles these issues by revamping the text entry experience. I've updated both the placeholder text and instruction field to be clearer. The text entry field is now dynamic - when users hit the three-task limit, it clearly explains why they can't add more.

While I believe in the three-task limit as a key to productivity, what matters most is what users will embrace and use. The coming weeks will show how this plays out.

Recent user feedback suggested adding voice-to-text for task entry - a reasonable request that would improve accessibility. This seemed like a straightforward feature to implement since iOS has built-in voice-to-text capabilities, and the user experience design would be fairly standard.

Diving In

I started by following the AI's implementation instructions:

• Add specific declarations to the info.plist file

• Create a new SpeechRecognizer.swift file with the necessary code

• Integrate the SpeechRecognizer throughout the existing codebase

The initial implementation went smoothly - no errors appeared when saving the code, and the build process completed successfully. However, when testing on my device, the app crashed with this message:

This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSSpeechRecognitionUsageDescription key with a string value explaining to the user how the app uses this data.

Despite the error message pointing to the Info.plist file, my configuration appears correct. I even double-checked by having both ChatGPT and Claude provide complete XML configurations, but implementing their solutions didn't resolve the issue.

In my day job managing other apps, when I encounter crashes like this, they're often resolved by deleting and reinstalling the app to clear any conflicts between test and production versions. I tried that here, but no luck - same crash, same error.

A Cry for Help

So here I am, stuck on implementing voice-to-text. If anyone reading this spots what I'm doing wrong, please reach out! I have some other features I'm successfully implementing for my next release, so progress definitely hasn't ground to a halt. But, for now, I'll need to allocate some debugging time during each release cycle until I can crack this one.

Update 1: Drag and drop task cards

This is the most requested feature, and it makes sense! People add cards in a given order, but then want to reorder them in some way. At the minute, I’m not designing a feature to accommodate why they want to reorder, I just want to allow them to do it.

The question of why they want to reorder is an interesting one though. Right now, I can think of three reasons:

• To arrange tasks in order of execution

• To arrange tasks by priority

• To arrange tasks by effort required

I’d be interested to know if there are others. And maybe one day, if there is an overwhelming reason why people want to reorder, I’ll iterate on the feature with that in mind.

Update 2: Clarity in onboarding

One thing I’ve heard from users so far is that they would like to be able to add more tasks. As I’ve asked more, it seems they want to be able to map out their whole day, instead of just the most important things they want to achieve that day.

While I understand this sentiment, and may one day build towards that, right now the intention of the app is to encourage users to accomplish the most important things in their day. Recently, I heard the CRO at my company say that every morning he asks his team to name the one thing that they must do to make their day a success. I really like this sentiment. Stephen Covey Jalen Hurts said it best: “You gotta keep the main thing the main thing.”

This is the philosophy behind Did You Do It. Yes, we start our days with a million things to do, and accumulate even more as the day progresses. But when we begin each day, there are typically just one to three things that, if accomplished, would make that day successful.

So for now, dear user, you’re stuck with three tasks. But to help future users to understand this concept, I tweaked the design of the second onboarding screen slightly to try to drive home the app’s ethos towards productivity a bit more clearly.

Update 3: Display today’s date and other main screen UI improvements

Pretty simple here. I added the date to the main screen. It serves as a simple reminder to the user that it’s all about today. It also adds a nice amount of extra content to the screen to fill it out a little.

I also made some accessibility improvements. Placeholder text is a little darker to increase the contrast ratio and the borders around some of the elements are a little bit sharper.

So there you have it. Did You Do It wasn’t just a one time thing. I actually released, got users, and iterated. If you want to help develop Did You Do It even further, be sure to head over and download it in the app store!

It's called "Did You Do It" - a radically simple task manager that embraces the idea that getting stuff done doesn't need to be complicated. You can download it from the App Store here: Did You Do It

Do I really think the world needs yet another productivity app? Absolutely not. But it strikes me that this is a pretty simple concept to get started with. And, if I’m being totally honest, part of the reason I personally have never really liked any of the productivity apps out there is that I think they all overcomplicate it. The memes really are right: Apple Notes is generally all you need.

So I asked myself: What's the absolute minimum you need to get stuff done?

The answer is surprisingly simple:

1. Decide what you're going to do

2. Do it

3. Acknowledge whether you did it or not

4. Move on

That's it. That's the app.

"Did You Do It" strips away all the complexity of traditional task managers. You can only have three tasks at a time (because if everything is important, nothing is), and there are no complicated features to get in your way. Just honest accountability and a focus on what really matters.

I can’t say I’m rushing to show off technical implementation, and I’d be horrified if the engineers I work with saw the codebase, but it works. It’s a monolithic product with code written entirely by AI. My influence came on the UX side. I defined how the app should look, feel, and behave, and I defined what the copy should say. I’ll write about this in a different post, but I came away impressed by how effective the AI coding really was.

In the end, this took about 9 hours to build over Thanksgiving weekend. To my surprise, the submission to Apple was the easiest part and they approved it on the first try!

I really want to start iterating, but I need to hear from users first. So here is the download link one more time. Get in there and hit the feedback button to help shape the future of “Did You Do It’’! Oh, and make sure to leave a 5 star review in the App Store, even if you hate it

And let me reiterate: I have no idea how to code. In fact, I'm so bad at it that I need to Google the correct way to write print("Hello, World!") every single time. So hopefully this journey will be fun, insightful, inspiring, and not too personally embarrassing for me.

Why build an app?

I'm a Product Manager at a tech company where I work with two different teams. One team builds a web application, while the other builds the iOS and Android mobile versions of that same application. I entered tech product management from outside the industry, and have very limited technical knowledge.

While I've been in tech for a decent amount of time now, I feel like I need to do more to empathize with my teams. So I thought I would do what they do (well, sort of... they actually write their own code). I want to understand the cathartic experience of seeing something you built work for the first time, to feel the frustration of debugging an error, and to experience the satisfaction that comes from closing your laptop after a productive building session.

I chose an iOS app because it seems like the most straightforward path to distribution. I don't need to pay for a web domain, I can release through the App Store (though "easily" might be stretching it), and I don't need to account for users on multiple interfaces.

But my intent goes beyond simple empathy. The advent of AI tools has unleashed capabilities I never had before. I use AI constantly in my role to be more efficient and insightful. I see tech influencers everywhere talking about how easy it is to build products with AI. So, I'm going to put that to the test and see if I can evolve from being a PM empowered by AI to becoming a fully technical builder.

Finally, building an iOS app just seems fun. You get to release something, hear what people think of it, and solve new problems. Best of all, you decide the goals and metrics, you choose when the work gets done, and you get to deal with all the tech debt!

So here we go!

Who knows where this app will end up. I might not even make it to the App Store. But you better believe we're going to try. Make sure you subscribe to keep up to date with my progress and find out what it is I am actually building.