For product managers
Read your own logs, your own CSVs, your own configs.
Most PM blockers don't need a meeting. They need a grep. When the support team flags a strange error, when a CSV from analytics has duplicate rows, when a config file is what's gating that experiment — the answer is in a file on a server, and engineering already has it open. learn-terminal teaches you to open it too, without asking, and to read what you see when you do.
Why this changes the way you ship
You won't be running deploys at 2am. You'll be doing the things you already wanted to do this morning: searching a log for the error a customer pasted, eyeballing a feature-flag config before pinging an engineer, cleaning a CSV before pasting it into a doc. The shell is the path between you and the data your team already has. Cutting one ticket per week from your backlog is a real productivity gain — and most of those tickets dissolve the second you can grep your own logs.
It also teaches you to read. The next time an engineer drops a one-line command into a thread, you'll know what it does before you run it. That's the part that actually changes how you work — not the typing, the reading. A PM who can read a command is a PM whose questions land better, whose RFCs hold up under engineering review, and whose roadmap survives contact with the actual codebase.
What you can do by the end
Search a support log for an error message
tty/example · product managers $ grep -i "payment declined" support-2026-05.log 2026-05-03 14:02 user=u_3781 "payment declined: rate_limited" 2026-05-08 09:41 user=u_4920 "payment declined: generic" $ grep -ic "payment declined" support-2026-05.log 2
grep finds matching lines; -i makes it case-insensitive; -c counts hits. Two hits in May. Now you can decide if it's worth a Linear ticket, with the evidence right there.
Count uniques from a CSV column
tty/example · product managers $ cut -d, -f3 signups.csv | sort -u | wc -l 417
Take column three (the email), deduplicate, count the lines. Four hundred seventeen unique customers in this campaign. No spreadsheet required, no pivot table to set up, no analyst to schedule.
Peek at a feature-flag config
tty/example · product managers $ grep -A2 "checkout_v2" config/flags.yaml checkout_v2: enabled: true rollout: 0.5
grep with -A2 prints the two lines after each match. You see the value without opening the whole config or guessing at YAML indentation. Stakeholder asks if it is 50%, you have the answer in one command.
Read an engineer-provided script before running it
tty/example · product managers $ cat cleanup.sh #!/bin/bash rm -rf /tmp/cache-* echo "cleared cache directories" $ bash cleanup.sh cleared cache directories
Always cat a script before you run it. You learn to spot rm -rf on paths that are not /tmp — and to ask before you run them. The whole verify-first habit is one of the course's spine modules.
Tail a log while a teammate reproduces a bug
tty/example · product managers $ tail -f api-requests.log 2026-05-11 11:02 POST /checkout 200 2026-05-11 11:02 POST /checkout 500 stripe_timeout
tail -f streams new lines as they are written. While support clicks through the bug, you watch the request hit the server in real time. You go from 'I think we have a problem' to 'we have a problem at the Stripe callback' in seconds.
What you'll be able to do
By the time you finish the course, you will be able to:
- Search any log or CSV your team has without opening a ticket.
- Read engineering's commands before you run them.
- Confirm a flag rollout or config value without a Slack DM.
- Use grep, cut, sort, and wc well enough to answer most data questions.
- Stop being the PM who only sees what dashboards tell you.
Lessons PMs tend to start with
Start with lesson 1
The first lesson takes about five minutes and runs entirely in your browser. No install, no signup, nothing to break. You will close the tab knowing where you are, what a command looks like, and what to read next.