Aakash Gupta$1.25 billion Unicorn. Only 2 Product Managers. The Linear Method:
CHAPTERS
- 0:00 – 2:39
Why AI companies pick Linear: speed, directness, and low-friction workflows
Aakash opens with Linear’s rapid rise and why top AI labs (OpenAI, Perplexity, Cursor) standardize on it. Nan explains Linear’s obsession with speed—not just UI performance, but clarity and direct interactions that keep teams focused on building.
- •Linear’s core advantage is speed of operations end-to-end
- •Direct, obvious actions reduce cognitive load and tool “figuring out” time
- •Fast interaction design is tied to overall company execution speed
- •AI startups especially value minimal overhead and high velocity
- 2:39 – 3:53
A new generation tool stack: building for modern developer muscle memory
The conversation shifts to why Linear fits the “new stack” used by newer companies. Nan argues software teams now share baseline competencies (e.g., Git), enabling tools to assume expertise and optimize for flow rather than training wheels.
- •Tooling expectations have changed dramatically in modern teams
- •Linear assumes users already have core dev workflows mastered
- •Optimizing for experts allows faster, cleaner UX and primitives
- •“Rebasing” assumptions enables a new category of product design
- 3:53 – 6:32
What Linear actually is: project management primitives optimized for developers
Nan summarizes Linear as a project management tool purpose-built for software development. He highlights product details that remove daily friction (like default branch naming) by sanding down common rough edges in engineering workflows.
- •Linear is a project management tool tailored to dev teams
- •Workflow primitives are optimized for engineering habits
- •Small conveniences (e.g., branch naming) reduce constant context switching
- •Design goal: remove rough edges people tolerate every day
- 6:32 – 7:55
The Linear Method in one idea: “directness” over indirect process theater
Aakash tees up the Linear Method; Nan defines it as directness—avoiding overly mediated practices like rigid user-story formats. He frames this as an update to process norms that existed when stakeholders didn’t understand software, but are now often unnecessary.
- •Linear Method is both how Linear builds and how it enables customers to build
- •Directness replaces indirect scaffolding like formulaic user stories
- •Many legacy practices were compensating for low software literacy
- •Modern teams can make stronger baseline assumptions and simplify
- 7:55 – 9:02
Staying small on purpose: hiring fewer people and valuing efficiency
Nan contrasts Linear with older eras where company size was a status symbol. Linear intentionally asks how few people it can hire to accomplish goals effectively, reflecting both the funding climate and new tooling leverage.
- •Modern startups increasingly optimize for small teams
- •Linear repeatedly asks: how few hires are needed to execute well?
- •Cultural shift: size is no longer a bragging right
- •Tools and environment make lean execution more viable
- 9:02 – 10:46
Principles in practice: meaningful direction, momentum, and sustainable pace
Walking through the Linear Method principles page, Nan emphasizes two themes: direct problem-solving and maintaining momentum. He argues sustainable velocity matters because it keeps teams responsive to real-world feedback without burning out in exhausting sprint cycles.
- •Core principles aim for directness and speed
- •Build for real people and real problems (not internal preferences)
- •Momentum enables fast reaction to feedback from the wild
- •Avoid boom-bust sprint exhaustion that reduces adaptability
- 10:46 – 12:00
Speed vs quality is a false tradeoff: fix upstream so you don’t need hacks
Aakash probes the common tension between moving fast and building well. Nan reframes the issue: shortcuts typically indicate upstream problems like weak abstractions or poor code quality; strong foundations reduce the temptation to hack.
- •“Speed vs quality” often really means “don’t cut corners”
- •High-quality codebases and abstractions reduce hack pressure
- •If you’re tempted to shortcut, something upstream is wrong
- •Goal: engineer conditions where speed and quality coexist
- 12:00 – 13:18
Saying no to busywork: decisive, falsifiable bets instead of endless analysis
Nan explains busywork as a symptom of indecision and lack of clarity. Rather than hiding behind data collection and excessive testing, Linear favors aggressive, falsifiable action—build, observe reality’s response, and adjust quickly.
- •Busywork often comes from unclear goals and indecision
- •Prefer mental models + aggressive action that reality can falsify
- •Build to learn quickly instead of over-analyzing
- •Fast feedback loops replace “make-work” research cycles
- 13:18 – 16:27
Roadmaps without rigidity: intent, fast updates, and planning only a few quarters out
Nan supports roadmaps as alignment tools but warns against treating them as sacred. Linear plans roughly three quarters out with diminishing certainty, and expects the roadmap to change as new information arrives.
- •Roadmaps are useful as expressions of intent
- •Treat them as changeable—new info should reshape plans
- •Linear plans ~3 quarters out with decreasing confidence
- •Rigid roadmaps create problems when reality shifts
- 16:27 – 18:59
Always-on planning and an escalated idea backlog: discovery never “starts from zero”
Instead of month-long planning marathons, Linear continuously learns and refines priorities. Nan describes an accepted-ideas backlog (dozens of areas) and a mechanism where customer-facing teams escalate relevant signals back to product for deeper learning.
- •Large planning rituals assume zero knowledge—Linear avoids that trap
- •Continuous discovery and prototyping feed future quarters
- •Maintains an accepted-ideas backlog (~30–40 areas)
- •Customer conversations trigger escalation into product when ideas recur
- 18:59 – 24:24
OKRs are overused: use them for high-leverage, measurable orgs—not IC theater
Nan critiques OKRs as an indirect alignment method that’s often forced too far down the org. He argues they fit best for functions with inherently numeric outcomes and budget flexibility (growth, marketing, finance), but become meaningless when IC OKRs devolve into ‘do your job.’
- •OKRs can work, but are widely over-applied
- •They’re an indirect alignment tool with large error bars by design
- •Cascading OKRs to ICs often produces performative “deliver X” goals
- •Best suited for high-level owners of measurable outcomes and budgets
- 24:24 – 25:53
Goals for craft roles: points of view, falsifiability, and long-run hit rate
Aakash asks how to set incentives without OKRs, especially for designers and PMs. Nan emphasizes evaluating whether teams form strong, falsifiable points of view that resonate with customers, then assessing consistency and breadth over time rather than forcing financialized metrics.
- •For PMs/designers, focus on establishing a strong customer-relevant POV
- •Make the POV falsifiable via user response
- •Short-term evaluation: clarity on what you believe and what you need to learn
- •Long-run evaluation: consistency, exploration breadth, and “hit rate”
- 25:53 – 30:46
Craft and quality controls: ‘roasts,’ internal dogfooding, and incremental rollout
Nan details how Linear keeps quality high while preserving builder discretion. The team runs ‘roasts’ where everyone tries to break near-ready features, and relies on internal usage of the smallest viable version for months before beta—so big reversals happen early, not at launch time.
- •Quality is protected through lightweight but intense internal rituals
- •‘Roasts’: team-wide sessions to find bugs, usability issues, and blind spots
- •Feedback doesn’t mandate changes; builders decide based on POV
- •Incremental rollout starts with internal dogfooding to fail early
- 30:46 – 32:33
Shipping without ‘move fast and break things’: scope shrinking as the momentum engine
Aakash challenges whether this approach slows delivery under executive pressure. Nan explains Linear’s ‘one trick’: aggressively shrink scope to ship quickly with high quality, then expand iteratively as reality provides guidance.
- •Momentum comes from steady, predictable progress—not chaotic rushing
- •Aggressive scope reduction enables fast, high-quality shipping
- •Iterative expansion follows once the smallest subproblem is solved well
- •Reality-driven steering improves outcomes over time
- 32:33 – 34:07
Building in public (carefully): changelogs as accountability, marketing, and documentation
Nan explains Linear’s main ‘build in public’ mechanism: a changelog every 2–3 weeks. It creates internal accountability for momentum, provides a historical narrative of product evolution, and gives customers small, shareable artifacts to spread features.
- •Consistent changelogs every 2–3 weeks are a core ritual
- •Changelog keeps the team honest about momentum and output
- •Creates a natural documentation trail of product evolution
- •Gives customers shareable, bite-sized updates
- 34:07 – 38:05
Public roadmaps and enterprise asks: avoid anchoring, sell outcomes, ask more questions
Nan warns public roadmaps can distort incentives due to anchoring and pressure from loud customers. For sales roadmap conversations, he recommends careful probing: uncover underlying goals, avoid over-committing to dates, and help customers succeed through education and alternatives—not promises of single features.
- •Public roadmaps can create unhealthy social pressure to stick to plans
- •Loudest customers aren’t always the most important
- •Share selective roadmap context with key accounts when necessary
- •In sales calls: diagnose the real goal; customers rarely churn over one missing feature
- 38:05 – 40:36
Applying the Linear Method to AI agents: start with a clear model, learn fast, iterate
Nan walks through Linear’s AI agents approach: treat agents as users with the same primitives, then let the world validate the model. Early learnings included responsibility staying with humans, agents being too chatty for normal comments, and agents needing broad workspace context—insights that guide the next iterations.
- •Initial POV: agents are ‘just users’ and can do anything humans can
- •Ship a small, clear spec because nobody knows the long-term model yet
- •Learnings: humans retain responsibility; agents need a separate chat space
- •Agents benefit from workspace-wide visibility that humans can’t match
- 40:36 – 45:54
Why Linear built agents (not a generic chatbot): follow real workflows and avoid bloat
Nan explains the conviction came from observing users juggling multiple async agents—matching Linear’s core strength in managing distributed work. He generalizes the approach: prioritize real problems emerging in user workflows and resist flashy trends, using ‘take users seriously, not literally’ to prevent feature bloat.
- •Kernel insight: users started juggling multiple agents asynchronously
- •Linear fits as the coordination layer for async, team-based work
- •AI features should follow real emergent workflows—not trends
- •Prevent bloat by interpreting requests through underlying goals
- 45:54 – 53:30
Career and org design at Linear: work-trial hiring, PM/PMM structure, and PM efficiency
The discussion shifts to Nan’s path into Linear via a paid work trial after years of connection with the team. Nan shares advice for candidates (drop ego, be transparent), describes their small PM org where PM and product marketing report together, and reveals the unusually lean ratio: ~40 engineers with only two PMs including him.
- •Linear uses paid work trials; flexibility helps candidates with day jobs
- •Nan’s entry came from long-term relationships plus relevant domain fit
- •Interview advice: remove ego; let evaluators truly see how you work
- •Org choice: PM and product marketing in one reporting structure; ~40 engineers and ~2 PMs
- 53:30 – 1:00:20
From Everlane to B2B SaaS: margins, sales dynamics, and how to pivot industries
Nan answers questions about Everlane’s cost-plus model and contrasts B2C retail with B2B SaaS realities like working with sales and enterprise customers. He also outlines one practical pivot tactic: take a level/comp hit to ‘get in the door,’ then let a startup recognize and expand your scope based on demonstrated ability.
- •Everlane pricing reflects materials-heavy costs under cost-plus economics
- •B2B shift required learning sales motion and enterprise customer handling
- •B2C experience built strong storytelling/brand muscles valuable in SaaS
- •Industry pivot strategy: accept a step-down role to enter, then earn the shift internally
