Who actually uses these products,
and what made them stay.

The Linear Product Manager

A product manager at a 20–200 person startup who moved to Linear because Jira was too heavy and Notion boards weren't structured enough. They work at the initiative and project level while their engineers work at the issue level. They need to see the forest while the team sees the trees. They love Linear's speed and keyboard shortcuts but struggle to get the strategic views they need without building custom views for every stakeholder meeting.

“It happened mid-workflow — the CEO asks "are we on track for the Q2 launch?" The PM opens Linear, checks 4 projects across 2 teams, counts completed vs.”

The Linear Startup Engineer

A software engineer at a startup of 10–100 people who has used Jira and has Opinions. They switched to Linear — or advocated for switching — because it's fast, opinionated, and built for people who care about the work rather than the process around it. They use Linear every day to track their own work, manage issues, and follow the work of their small team. The keyboard shortcuts aren't optional to them — they're the point.

“They're back from a two-day sprint on a difficult bug.”

The Linear Engineering Manager

An engineering manager or head of engineering at a startup of 20–150 engineers who uses Linear at the issue level to track work and at the Projects level to communicate progress. The ICs live in issues and cycles. The EM lives in projects and the roadmap view. They're the translation layer between "what the team is building" and "what the company thinks we're building" — and Linear Projects is the interface they use to close that gap.

“It happened mid-workflow — it's Thursday.”

The Height Engineering Team Lead

An engineering team lead or technical PM at a company of 20–150 people who evaluated Linear and wanted more — more project hierarchy, more cross-functional visibility, more flexibility for non-engineering teams to work alongside engineering in the same tool. They chose Height. They're building their system in it. They like that it feels like a tool built by people who understand engineering workflows, not a project management tool that engineering is expected to tolerate. They're still learning the edges of it.

“It happened mid-workflow — sprint planning is Monday.”

The Logseq Local-First Knowledge Builder

A researcher, developer, writer, or privacy-conscious knowledge worker who chose Logseq because their notes are plain `.md` files in a folder they control — not in a proprietary database, not in someone else's cloud. They care about data ownership in a specific way: not paranoia, but principle. They've watched tools sunset, pricing change, and export options degrade. Their Logseq graph syncs to iCloud or a private git repository. It will exist regardless of Logseq's future. They've also genuinely internalized the outliner-first paradigm. They think in bullets that can be linked and referenced anywhere else in the graph.

“They're synthesizing research for a paper.”

The Make Power Automator

An operations lead, automation specialist, or technical non-developer who moved to Make (formerly Integromat) after hitting the ceiling on Zapier. They know what they wanted to build and Zapier's linear trigger-action model couldn't do it: conditional branches, iterators, error handlers, multi-route flows. Make could. They learned Make. They have built things in Make that non-technical people would describe as software and technical people would describe as creative. They exist in the middle of the developer-to-non-developer spectrum and they've built a practice there.

“A client needs a system: when a new deal is created in HubSpot above a certain value, create a proje.”

The Logseq Academic Researcher

An academic researcher, PhD student, or independent scholar who uses Logseq as their research knowledge base. They take notes on papers, link concepts across disciplines, and use the graph view to see how ideas connect in ways linear note-taking never revealed. They chose Logseq because it's local-first (their research data stays on their machine), uses an outliner format that matches how they think, and builds a knowledge graph without forcing a predetermined structure. They are building a second brain for their research, and they expect it to outlast their current institution.

“The shift was quiet.”

The Height Autonomous Project Tracker

A product team lead or engineering manager at a startup who chose Height because it promised what every PM secretly wants: a project tracker that maintains itself. They use Height's AI features to auto-triage bug reports, suggest task labels, and identify duplicate issues. They still do the strategic work — prioritization, sprint planning, roadmap decisions — but the administrative overhead of keeping the tracker clean is lower than with Jira or Linear. They are cautiously optimistic about AI in project management — it works 75% of the time, and the 25% it doesn't requires less effort to fix than doing it all manually.

“A teammate asked how they managed reduce the time spent on task triage, labeling, and organization by 50% with AI assistance.”

The Raycast Power User

A developer, designer, or technical knowledge worker on Mac who replaced Spotlight with Raycast and then spent three weekends making it the center of their computing workflow. They open Raycast more than any other application. They open it for things they didn't know a launcher could do. They've written or installed extensions for their most repetitive tasks. They mention Raycast in the same breath as mechanical keyboards and monitor setups — tools that are invisible when they work and felt intensely when they don't.

“It's 9am.”

The Spline 3D Web Designer

A web designer or creative developer who uses Spline to add 3D to their web projects without the learning curve of Blender or Cinema 4D. They create 3D hero sections, interactive product visualizations, animated icons, and immersive landing pages. They are a designer who crossed into the third dimension. They appreciate that Spline runs in the browser, exports to the web natively, and feels like a design tool rather than a 3D modeling application. They are the person making websites feel like they have depth.

“A SaaS company wants a landing page that stands out.”

The Salesforce Admin

A business analyst, operations manager, or former power user who became the Salesforce admin because they were the person who understood the data best. They don't write code — they build Flows, create reports, manage permissions, and configure the org to match how the business actually works. They have 3–5 Trailhead certifications and a bookmark folder of Salesforce Help articles they reference weekly. They are simultaneously the most important and most under-appreciated person in the revenue organization.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about flow Builder that's powerful but crashes on complex flows and has limited debugging in two weeks.”

The GitLab DevOps Engineer

A DevOps engineer, platform engineer, or senior developer at a company that chose GitLab — often for self-hosting, compliance, or all-in-one platform reasons. They maintain the GitLab instance or the pipeline configurations that all other engineers depend on. They think in pipelines, stages, and artifacts. They've written `.gitlab-ci.yml` files that are 300 lines long and know every YAML key by memory. They've debugged a pipeline failure on a Friday evening. They have strong opinions about GitHub Actions versus GitLab CI that they will share if asked.

“The shift was quiet.”