Why Linear?
- Linear is the best engineering tracking software out there. I explored other alternatives like Plane (or even Notion) but they lack certain features (detailed issue tracking, milestone development, etc.) and have worse UX.
- Also Linear comes highly recommended from other startup founders I spoke to + Till so that’s enough to convince me also.
- Final reason to use Linear — HIPAA compliance has some weird requirements for issue + security tracking which are much easier to implement on Linear vs Notion.
The Linear Method
Principles
- Read the principles here (short)
- In general, have broad and lofty strategic initiatives which each project can be mapped to
- Build in manageable, short cycles and create momentum (don’t try to sprint with arbitrary timelines). Keep backlog manageable. Make sure bug fixes/general product improvement are part of each cycle.
- Write project specs that outline why, what, how
- Solve problems by understanding users, don’t just build features
- Scope issues/tasks to be as narrow as possible
Setting Direction
- Set direction in Linear by using initiatives. The summary:
- “The process of creating initiatives and mapping out a product journey forces you to articulate a vision and decide how to build toward it. The culminating product timeline sets a path of execution for the near future, slightly in front of you, and ideally a bit out of reach. Anyone in your company can look at the product initiatives to quickly understand what the most important streams of work are, why they matter, and how they are progressing.”
- Set goals that propel you forward in some measurable way. If you miss the goal, plan a path to reach the goal in the future.
- Prioritise enablers and blockers. Important to consider how timely something is to build. There will always be more to build than you have the resources to do so. Priotitise things that will create the most impact the quickest.
- Think of new features as additive enablers or removing blockers.
- *“*Enablers enable new functionality that usually makes the product more valuable or interesting. Blockers are gaps or friction that prevents a user/customer to use your product. Before building a feature, you should try to understand if the problem is truly preventing someone from using the product or a nice to have in their user experience.”
- For early startups - design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day.
- enables (1) shipping continuously (2) quick feedback
Building
- Generate Momentum: Startups rarely die because they made too much progress or because of a single bad decision, but they do die when they move too slow or give up.
- Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.
- Write Issues not User Stories: Basing product development on user stories are an obsolete way to do things and are a roundabout way to describe tasks
- User stories are complicated and difficult to scope because they bring what should be product-level details into the task level.
- Instead, write clear, simple issues that describe tasks in plain language.
- Discuss the user experience at the product and feature level, not the task level.
- Writing good issues (tasks)
- An issue should describe a task with a clear, defined outcome. This could be a piece of code, design, document, or action to be taken.
- Exceptions: “There will be exceptions to this rule. For example, before working on a feature you’ll spend time exploring the design and technical approach. You can create placeholder issues in these instances to break down later (e.g. Explore design) or frame it as a deliverable (e.g. Write project spec).”
- Write short and simple issue titles that directly state what the task is. The descriptions should be optional to read.
- When you can, write your own issues.
- Managing design projects
- Build with Users: Seek out users or potential users for feedback, iterate, and be flexible to meet the demands of your customers
- Vision vs Feedback: One of the hardest thing as a startup founder is to manage your broader vision against the direct requests of your customers. Too much vision and you miss market needs. Being too reacting to customers and you lose a clear purpose and flexibility.
- Solving the problem not the feature.
- Users will project their needs from the context of the product they currently see, not the product we’re trying to build.
- Make sure you direct conversations toward the pain point so you can explore multiple solutions to the problem and choose the one that makes the most sense with the company vision.
- Build for the right users
- “Incorporate the feedback and let it refine your product, but don’t let user feedback alone dictate what you build. You can become too reactive to user feedback. This is why it’s good to have strategic initiatives, that help you balance the needs of the users and the needs of the company.”
- Write Changelogs, build in public. This allows us, our customers, and our investors to see how much progress we’re making.
Important Linear Concepts