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

The Jira-Burdened PM

A product manager or engineering team lead at a software company who runs sprints in Jira. They did not set up the Jira instance they work in — it was configured by someone who left 18 months ago, and the workflow has accumulated technical debt as surely as the codebase has. They know what they need Jira to do. Getting it to do that is a separate problem.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about ticket statuses that don't map to how engineering actually works in two weeks.”

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 Jira Engineering Manager

An engineering manager leading a team of 5–15 developers. They use Jira because the company chose it years ago and migration would be worse than staying. They plan sprints, groom backlogs, and build the reports their VP needs for quarterly reviews. They know Jira's power but resent its complexity. They've customized their board exactly once and now they're afraid to touch it. They protect their team from Jira overhead by doing most of the admin work themselves.

“The shift was quiet.”

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 Photoshop Production Designer

A graphic designer — in-house or agency — who uses Photoshop as their primary production tool for image work. They've been in Photoshop for 5–15 years and work with the efficiency of someone who knows exactly where everything is and what everything does. They don't explore menus. They use shortcuts. Their workspace is a system they've tuned. Photoshop is slow sometimes and they've learned to work around it the way you work around a colleague's habits — with patience and workarounds they've stopped noticing.

“The shift was quiet.”

The Coda Doc Builder

A team lead, ops manager, or product manager who uses Coda to build interactive documents that are half-doc, half-app. They've built meeting note trackers with automated action items, sprint planning boards with voting buttons, and OKR trackers with progress rollups — all inside Coda docs. They chose Coda because Notion didn't have formulas and Airtable didn't have documents. They love that everything lives in one place. They worry that they've built something only they understand.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about formula complexity escalates quickly — what starts as a simple lookup becomes a nested formula chain in two weeks.”

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 Miro Remote Facilitator

A UX designer, product strategist, design researcher, or Agile coach who uses Miro as their workshop room. They've run retrospectives, journey mapping sessions, design sprints, and ideation workshops — all on Miro, all remote. They are good at facilitation. They have strong opinions about how a Miro board should be structured. They've also learned that a beautifully structured board means nothing if participants don't know how to use sticky notes.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about new participants who spend the first 10 minutes learning Miro instead of the topic in two weeks.”

The Cal.com Developer Scheduler

A developer, indie maker, or privacy-conscious professional who uses Cal.com because they either self-host it or value that they can. They were on Calendly and either hit a pricing ceiling, wanted customization Calendly doesn't allow, or made a deliberate decision about data ownership. Cal.com is open source. They can read the code. They can modify it if they need to. The fact that this is possible — even if they never do it — matters to them in a way that influences their tooling choices.

“It happened mid-workflow — they're building a product that includes embedded scheduling — customers can book time with their su.”

The Monday.com Team Lead

A team lead or department manager at a 30–200 person company who chose Monday.com because it looked simple enough that their team would actually use it. They set up the boards, configured the automations, and built the views. Now they spend 20 minutes every morning making sure the board reflects reality. They are the bridge between the team's actual work and the executive's need for status updates. They don't love project management tools, but they love knowing where things stand.

“It happened mid-workflow — the team lead sets up a sprint board with automations: when a task moves to "In Review," it notifies the reviewer and updates the deadline.”

The Basecamp Small Agency Owner

A small agency owner, studio founder, or remote team lead with 3–20 people who chose Basecamp because they were tired of configuring project management tools. Basecamp's opinionated structure — message boards, to-dos, schedules, docs, campfire — is not a limitation to them. It's the point. They didn't want to design a system. They wanted to use one. They've been on Basecamp for 2–6 years. They've recommended it to other agency owners who are drowning in Notion setups and Jira configurations. Some of them listened.

“A client project kicks off Monday.”

The Clerk Authentication Developer

A full-stack developer at a startup who chose Clerk because building authentication from scratch — login, signup, email verification, OAuth, MFA, session management — is 2 months of work that adds zero product differentiation. They integrate Clerk's pre-built components, customize the flows, and manage users through the dashboard. They appreciate that auth "just works" but they've also hit moments where Clerk's opinionated approach conflicts with their product's specific needs. They are a developer who decided that auth is infrastructure, not a feature worth building themselves.

“The developer is building a new SaaS product.”

The FullStory Digital Experience Analyst

A product analyst or UX researcher at a digital product company who uses FullStory as their lens into the user experience. They don't just look at funnels and conversion rates — they watch sessions, identify frustration signals (rage clicks, dead clicks, error clicks), and correlate behavioral patterns with business outcomes. They've learned to find the story in the data: why conversions dropped, where users get confused, what makes the checkout feel broken. They are the translator between raw user behavior and product decisions.

“The product team sees a 15% drop in checkout completion after a recent redesign.”

The Typeform Survey Designer

A UX researcher, product manager, or marketer who chooses Typeform over Google Forms because the survey experience matters. They've learned that completion rate is the most important metric for a survey, and completion rate is a design problem. They craft surveys that feel like conversations: one question at a time, conditional logic, thoughtful copy. They spend as much time on the question experience as they do on the question content. They are the person who says "we can't just send a Google Form — that sends a message about how much we value their feedback."

“The shift was quiet.”

The Sentry Error Wrangler

A developer — usually mid-level to senior — who has become the de facto owner of error tracking on their team. They set up Sentry, configured the alerts, and now they're the person who triages the error feed every morning. They know the difference between a real bug and a noisy exception. They've learned to read stack traces the way a doctor reads X-rays — quickly, looking for the thing that's actually wrong. They carry the mental burden of knowing exactly how many errors are happening in production at any given moment.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about grouping algorithms that split one bug into multiple issues or merge different bugs into one in two weeks.”

The Miro Workshop Facilitator

A product designer, agile coach, or team lead who facilitates remote workshops in Miro. They don't just draw on a whiteboard — they design participatory experiences: timed exercises, voting rounds, structured templates, and breakout activities. They've learned that the tool is 30% of a good workshop; the other 70% is facilitation design. They are the person who spends 2 hours preparing a Miro board so that a 1-hour workshop runs smoothly for 20 people.

“The facilitator is running a design sprint kickoff with 15 people.”

The Slack Workspace Architect

An IT admin, department head, or operations lead responsible for how their company uses Slack. They set up the workspace when it was 20 people and now it's 200. They created the channel naming conventions that nobody follows. They are the person people DM when they can't find something, when a channel needs to be archived, or when someone needs to be added to a private channel they shouldn't have access to.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about channel sprawl — 400 channels, half are dead, nobody wants to archive them in two weeks.”