It Starts with the Product
Before you write a line of code, before you pick a database, before you choose a framework: define who this is for, what it does, and why it matters. Everything downstream depends on this.
~10 minute read
Why Product First, Not Code First
The instinct for a technical founder is to start building. Pick a framework, scaffold a project, write some endpoints. This instinct is wrong when working with AI coding agents, and here is why.
AI agents do exactly what you tell them. If you tell them "build a deal pipeline," they will build something. It will have tables and routes and maybe a UI. But it will not be built for your specific user, your specific market position, or your specific product strategy. It will be a generic implementation of a vague idea.
The quality of AI-generated code is directly proportional to the quality of the constraints you give it. Vague constraints produce generic code. Specific constraints produce specific code. The first job, then, is not to write code. It is to produce a set of documents that constrain every downstream decision with enough specificity that the AI agent cannot make the wrong choice.
This chapter covers three foundation documents that must exist before anything else: the Company Overview, the Product Outlines (one per app or module), and the Pricing and Tier structure. Together, they answer the three questions every downstream document needs: Who is the user? What can they do? What are the boundaries?
The Company Overview
The Company Overview is a 5-10 page document that establishes context for every PRD, every phase plan, and every execution spec. It is not a pitch deck. It is not a business plan. It is a reference document that answers: "If I am writing a PRD for feature X, how do I know whether it serves our user, fits our positioning, and belongs in our product?"
What It Contains
The Company Overview has five sections:
1. The problem statement (quantified). Not "project management is broken." That is a slogan. The problem statement quantifies the pain in dollars, hours, or failure rates. What does the current situation cost the target customer? What is the alternative they use today? What specifically fails about it?
2. The positioning. What makes this product different? Not "better." Different. What does this product believe that competitors do not? This belief drives every design decision, every feature prioritization, and every UX choice.
3. The product architecture. If the product has multiple apps, modules, or surfaces: how are they organized? What is the relationship between them? This is the sub-brand architecture. A single app with tabs is different from a suite of connected tools.
4. The competitive landscape. Not a feature matrix. A positioning map. Who are the alternatives (including "do nothing" and "spreadsheets"), where does this product sit relative to them, and what is the wedge (the initial reason a customer switches).
5. The go-to-market sketch. How does the product reach customers? Self-serve or sales-led? Freemium or free trial? Bottom-up (individual users adopt, then team buys) or top-down (decision maker buys, team uses)? This affects every UI decision: onboarding flow, collaboration features, admin controls, billing surfaces.
Problem (quantified)
Engineering teams at startups (10-200 engineers) lose 4-6 hours per developer per week to project management overhead. Jira is the incumbent with 75%+ market share, but satisfaction scores among developers are consistently below 30%. The core complaint: Jira is designed for managers who want reports, not engineers who want to ship. Every workflow requires 3-5 clicks. Search is slow. The UI is cluttered with fields nobody fills in. Context switching between Jira and the IDE costs an additional 15-20 minutes per transition.
Positioning
Linear believes project management should feel like using a well-designed developer tool, not an enterprise admin panel. Speed is a feature. Keyboard navigation is primary. The interface shows what matters (status, assignee, priority) and hides everything else until needed. Linear is the tool engineers actually want to open.
Product Architecture
Single application with six modules: Issues (core), Projects (group issues into deliverables), Cycles (time-boxed sprints), Roadmaps (long-term planning), Inbox (notifications and requests), Settings (workspace, team, integration config). Each module is accessible via sidebar and command palette.
Competitive Landscape
Jira (enterprise, feature-heavy, slow). Asana (PM-focused, not developer-native). Shortcut (similar positioning but less polished). GitHub Issues (free but limited). Notion (flexible but no workflow engine). Linear's wedge: speed and developer experience. Teams try Linear because a developer on the team says "this is so much faster."
Go-to-Market
Bottom-up. Free tier for small teams. Individual developer tries it, invites the team, team adopts, engineering manager sees the value, company upgrades to paid plan. Self-serve pricing. No sales team required until enterprise tier.
The Process for Creating It
The Company Overview is created through a structured brainstorming session with AI. The founder brings domain expertise and market knowledge. The AI brings structure, probing questions, and the discipline to quantify claims.
Step 1: Start with the problem. The AI asks: "Who has this problem? How many of them are there? What do they spend today on the alternative? What is the cost of the status quo in hours, dollars, or error rates?" The founder answers. The AI pushes back if answers are vague. "You said 'a lot of time.' How much time? Can you estimate hours per week?"
Step 2: Move to positioning. "What does your product believe that Jira does not believe? If you could only change one thing about how people manage engineering projects, what would it be?" This is not a feature question. It is a philosophy question. The answer drives everything.
Step 3: Define the architecture. "Is this one app with multiple sections, or multiple connected apps? Can a user accomplish their core task without leaving one screen?" Draw the map of modules and how they relate.
Step 4: Map the competition. "Name every alternative your customer considers, including doing nothing. For each: what are they good at? What do they lack? Why would someone switch from them to you?"
Step 5: Sketch the go-to-market. "Does the buyer use the product, or do they buy it for someone else? How does the first user discover this? What triggers the upgrade from free to paid?"
The output is a document. Not bullet points in a chat. A document that gets saved, referenced, and updated as the product evolves.
ICP Definition
The Ideal Customer Profile defines the company, not the person. It answers: "If we could only sell to one type of company, what type would that be?"
The Three Dimensions
Company characteristics: Size (employees, revenue, funding stage), industry vertical, geography, technology stack. "Series A to Series C startups with 10-200 engineers, building SaaS products, headquartered in English-speaking markets."
Pain characteristics: What problem do they have that your product solves? How acute is the pain? Are they actively looking for a solution, or do they need to be educated? "Engineering teams that have outgrown GitHub Issues but find Jira too heavy. They tried Jira, used 10% of its features, and their developers complain weekly."
Budget characteristics: What do they spend today on the alternative? What is their budget for this category? What is the ROI math? "Currently paying $7-15 per user per month for Jira. Would pay $8-10 per user per month for a better experience. ROI: 4-6 hours saved per developer per week at $75-150/hour fully loaded cost."
Company: VC-backed startups, Series A through Series C. 10-200 engineers. Building software products (SaaS, consumer apps, developer tools). English-speaking markets (US, UK, EU, AU). Using modern tech stacks (React, TypeScript, cloud-native).
Pain: Adopted Jira early because "everyone uses Jira." Developers now resist using it. Sprint ceremonies feel bureaucratic. Ticket creation takes too long. Search is unreliable. The PM and the engineer have different views of the same project, and neither is complete. Context switching between Jira and VS Code kills focus.
Budget: Paying $7.75-15.25/user/month for Jira. 50 engineers = $4,650-9,150/year. Productivity loss: 5 hours/week/developer at $100/hour = $1.3M/year for a 50-person team. Linear at $8/user/month = $4,800/year. If Linear saves even 1 hour/week/developer, the ROI is 27x.
Personas
Personas define the 2-4 types of people who use the product. Not fictional characters with names and hobbies. Functional profiles: what is their role, what do they need from the product, and what does "success" look like for them?
Persona Structure
Each persona has five fields:
- Role: Job title or function. "Senior Software Engineer," "Engineering Manager," "Product Manager."
- Goal: What they are trying to accomplish with the product. One sentence.
- Key workflows: The 3-5 things they do most often. These become user journey scenarios in PRDs.
- Pain points: What frustrates them about the current solution.
- Success metric: How they judge whether the product is working for them.
Persona 1: Senior Software Engineer (IC)
Goal: Get assigned work done with minimal process overhead.
Key workflows: Morning triage (what is assigned to me, what is blocked), move issues through stages, link PRs to issues, search for related issues, file bugs from code.
Pain points: Too many clicks to update status. Can not find issues by code reference. Context switching between IDE and project tool breaks flow.
Success metric: "I open Linear once in the morning, know exactly what to work on, and update status without leaving my keyboard."
Persona 2: Engineering Manager
Goal: Understand team velocity and remove blockers without micromanaging.
Key workflows: Weekly cycle review (what shipped, what slipped, why), project progress tracking, assign and prioritize incoming requests, sprint planning.
Pain points: Can not get an accurate picture without asking each engineer. Reports require manual aggregation. Cycle velocity is unreliable because half the team forgets to update Jira.
Success metric: "I can see what my team shipped this week and what is at risk in under 60 seconds, without asking anyone."
Persona 3: Team Lead / Tech Lead
Goal: Coordinate cross-team work and maintain technical direction.
Key workflows: Create and manage projects that span multiple teams, track dependencies between issues, write technical specs and link to issues, review and triage incoming bugs.
Pain points: Dependencies are invisible until something breaks. Cannot see which teams are blocked on which. Project status is scattered across multiple boards.
Success metric: "I can see the full dependency graph for my project and know exactly which team is blocking which deliverable."
Product Outlines
A Product Outline is a feature inventory for one app or module. It lists every capability, grouped by area, with a one-line description. It is not a spec. It is not a PRD. It is the raw material from which the Master PRD Index (Part 4) is built.
What an Outline Contains
For each app or module:
- Purpose: One paragraph on what this module does and why it exists.
- Core entities: The data objects this module owns. Issues, Projects, Cycles, Labels, etc.
- Capability inventory: Every feature the user can perform, grouped by area. Each item is a candidate unit for the Master Index.
- User workflows: The 3-5 most common sequences of actions. "Morning triage: open inbox, review assigned issues, update status, close inbox."
- Integration points: How this module connects to other modules. "Issues appear in Projects. Cycles contain Issues. Roadmaps reference Projects."
The Level of Detail
Each capability is one line. Enough to understand the scope, not enough to implement. Implementation details come later in the PRD and phase plan.
Purpose
The Issues module is the core of Linear. An issue represents a unit of work: a bug, a feature, a task, or a sub-task. Issues flow through customizable workflow states (Backlog, Todo, In Progress, Done, Cancelled). Every other module (Projects, Cycles, Roadmaps) references issues.
Core Entities
Issue, Comment, Activity, Label, Priority, Status (workflow state), Relation (blocks, is blocked by, related to, duplicate of), Attachment, Sub-issue.
Capability Inventory
| Area | Capability |
|---|---|
| Views | List view with sortable columns (status, priority, assignee, date, estimate) |
| Views | Board view (kanban) with drag-and-drop between status columns |
| Views | Saved views with persistent filter + sort + grouping configuration |
| Views | Table view with inline editing |
| CRUD | Create issue (title, description, status, priority, assignee, labels, estimate, project, cycle) |
| CRUD | Bulk actions (assign, set priority, set status, add label, move to project, delete) |
| CRUD | Issue detail page with tabbed sections (activity, comments, relations, attachments) |
| CRUD | Sub-issues (nested hierarchy, up to 3 levels) |
| Search | Global search across all issues (full-text, filters by team/status/assignee) |
| Search | Filter bar with combinable filters (status, assignee, label, priority, date range, project) |
| Relations | Issue relations (blocks, is blocked by, related to, duplicate of) |
| Relations | GitHub PR linking (auto-detect from branch name or manual link) |
| Workflow | Custom workflow states per team (add, remove, reorder statuses) |
| Workflow | Auto-close issues when linked PR merges |
| Import | Import from Jira, Asana, GitHub Issues, Shortcut, CSV |
| Notifications | Inbox notifications for assigned, mentioned, subscribed issues |
| Keyboard | Full keyboard navigation (j/k to move, x to select, b for bulk, c for create) |
| Keyboard | Command palette (Cmd+K) for all actions |
Key Workflows
Morning triage: Open Linear > Inbox shows new assignments and mentions > Review each, update status or snooze > Switch to "My Issues" view > Drag top priority to In Progress.
Bug filing: Cmd+K > "Create issue" > Select team > Title + description > Set priority "Urgent" > Assign to self > Link to GitHub branch > Submit.
Sprint planning: Open team board > Review Backlog column > Drag issues into Todo > Assign owners > Set estimates > Add to current cycle.
Integration Points
Issues belong to exactly one Team. Issues can be added to one Project. Issues can be added to one Cycle. Labels are shared across the workspace. Priorities are workspace-global. Roadmaps reference Projects which reference Issues.
Create one outline per module. For a product like Linear, that is 6 outlines: Issues, Projects, Cycles, Roadmaps, Inbox, Settings. For a simpler product with 2-3 modules, that is 2-3 outlines. Each one takes 1-2 hours of focused brainstorming.
Pricing and Tier Structure
Pricing structure affects every PRD. Every feature needs a tier assignment. Every UI needs to handle the moment when a user hits a tier limit. Every backend needs metering logic. Define pricing early, even if the exact dollar amounts change later.
What to Define
- Tier names and positioning. Not just "Free, Pro, Enterprise." What does each tier represent? Who is it for? What is the upgrade trigger?
- Feature gates per tier. Which features are available at each level? This drives metering logic in the codebase.
- Usage limits per tier. Storage, API calls, seats, records, AI operations. Each limit needs a user-facing experience when hit.
- The upgrade trigger. What specific moment makes a user want to upgrade? "Team grows beyond 10 members" or "Needs custom workflows" or "Wants SSO."
| Tier | Price | Target | Upgrade Trigger |
|---|---|---|---|
| Free | $0 | Small teams (up to 10 members) | Team grows past 10 or needs guest access |
| Standard | $8/user/month | Growing startups (10-50 members) | Needs project timelines, custom workflows |
| Plus | $14/user/month | Scaling teams (50-200 members) | Needs advanced analytics, SLA tracking |
| Enterprise | Custom | Large organizations (200+) | Needs SSO/SAML, audit logs, data residency |
Key feature gates: Free: basic issues + board view. Standard: custom workflows + projects + cycles + integrations. Plus: roadmaps + advanced views + analytics. Enterprise: SSO + audit log + priority support + SLA.
Usage limits: Free: 10 members, 1GB file storage, 5 teams. Standard: unlimited members, 10GB storage, unlimited teams. Plus: unlimited everything + 100GB storage. Enterprise: unlimited + custom retention + data residency.
What You Leave With
After completing this step, you have three documents:
| Document | Size | Key Output |
|---|---|---|
| Company Overview | 5-10 pages | Quantified problem, positioning, architecture, competition, GTM |
| Product Outlines (per module) | 3-5 pages each | Capability inventory, core entities, workflows, integration points |
| Pricing and Tiers | 1-2 pages | Tier structure, feature gates, usage limits, upgrade triggers |
These documents are referenced by every PRD, every phase plan, and every spec. They answer the recurring questions: "Who is this for?" (Company Overview, Personas), "What can they do?" (Product Outlines), and "What are the limits?" (Pricing and Tiers).
Next, these product decisions meet technical reality. Part 2 covers the architecture decisions that cannot be undone: database, auth, multi-tenancy, AI pipeline, and everything else that forms the infrastructure layer.