Topic 13 — The PM toolbox

Goal: Recognize the everyday tools a PM uses and what each is for.

Lesson 13.1 — The screen that scared Maya (for about an hour)

On her first morning at Lumi, someone added Maya to six different apps before she'd finished her coffee. Jira. Notion. Figma. Amplitude. Slack. A shared Google Sheet with a name she couldn't decode. Every one of them opened to a wall of menus, tabs, and someone else's half-finished work.

She felt the familiar career-changer panic. Everyone here already knows how to drive these. I don't even know what they're for.

By lunch, the panic was gone. Not because she'd mastered anything. Because a teammate said the one thing that makes the whole toolbox click: nobody got hired for knowing Jira.

The tools don't make you a good PM. Your judgment, your communication, and your understanding of users do the real work — the tools just hold it and pass it around. A backlog app doesn't decide what to build. A spec app doesn't write a clear spec. They're where the thinking lives once you've done it.

That's the reassuring part of this whole topic. These apps were built for non-engineers, and you can learn the basics of any single one in an afternoon. So don't sit here trying to memorize buttons. Learn what each kind of tool is for. That knowledge moves with you, no matter which specific app a company hands you.

Lesson 13.2 — Six boxes, and a whole job inside them

A year before Maya joined, Lumi ran its backlog in Trello and tracked metrics in Mixpanel. By her first week it was Jira and Amplitude. The apps had swapped; the work hadn't. That's the part worth holding onto: specific products come and go, but what stays stable is the category — the problem the tool solves. Learn the six categories and you can pick up any specific product fast.

• Roadmap and backlog — where the team tracks what to build and where each thing stands. Jira is the most common, and the one most tied to Scrum and sprints; Linear and Trello are simpler alternatives. Your user stories and backlog from Topics 7–8 live here.
• Documentation and specs — where PRDs, notes, and decisions get written down. Confluence, Notion, and Google Docs are typical. If you can write clearly, you can use these.
• Design and prototyping — Figma is the industry standard. PMs don't design in it. You view the designs, leave comments, and click through prototypes to feel how a flow works.
• Analytics — where you read the product metrics from Topic 9. Google Analytics, Amplitude, Mixpanel, and PostHog are common. You read dashboards and funnels; you don't build them from scratch.
• Communication — Slack for chat, Zoom or Google Meet for calls. Most coordination actually happens here.
• User feedback and research — surveys and feedback tools like Typeform and Hotjar, plus support tools like Zendesk, so you can hear from users at scale.

Read those six boxes back as a week of work and they line up with everything a PM actually does: deciding what to build, writing the spec, checking how it looks, seeing whether it worked, talking to the team, listening to users.

Six boxes, and your whole week fits inside them.

Lesson 13.3 — The tool nobody brags about, and everybody opens

Maya's second week, Dan from sales dropped a request in her lap: customers kept asking Lumi for an "Excel export," and he wanted to know if it was worth building. Big tool, fancy framework? No. Maya opened a spreadsheet (Excel or Google Sheets — same idea) and started a quick Value/Effort table, the kind from Topic 6.

The humble spreadsheet is the universal PM tool, and getting comfortable with it pays off again and again. PMs reach for it to:

• Score priorities — a Value/Effort or RICE table, like the one Maya was building.
• Track metrics and run simple analysis or charts, the Topic 9 numbers.
• Make quick lists and plans when a dedicated tool would be overkill.
• Pull data together from a few sources for a one-off look.

You don't need to be a spreadsheet wizard. Basic formulas (sums, averages, percentages, sorting, a simple chart) plus pivot tables will carry you a long way, and all of it is very learnable. Early on, a well-built sheet can stand in for almost any fancier tool. When in doubt, Maya's instinct is the right one: open a spreadsheet first.

Lesson 13.4 — The assistant in the room now

The CEO of Lumi had a vague, big idea floating around: an "AI assistant" inside the budgeting app. Maya wasn't sure about that one yet. But she was already using AI for her own work, every day, and so should you.

AI assistants like ChatGPT and Claude are part of the modern PM's kit now, and using them well is increasingly expected. PMs use them to:

• Draft and refine specs, user stories, emails, and announcements faster.
• Summarize a pile of user feedback or research down into clear themes.
• Brainstorm options, edge cases, and questions worth asking.
• Turn rough notes into structured writing.

Two cautions, and they're not optional. AI can be confidently, fluently wrong. It will state a made-up fact with total certainty, so verify anything that matters before you act on it or send it. And never paste sensitive or confidential data into a tool unless you know it's safe to. Customer records, unreleased plans, anything private: check first.

Used right, AI doesn't think for you. It clears the routine drafting and summarizing off your plate so you spend more of your day on the judgment that's actually yours. You're learning on an AI-built platform this very moment, so you're already more fluent here than you think.

Lesson 13.5 — Tool-aware, not tool-obsessed

So should Maya spend the weekend before an interview cramming Jira tutorials?

No. And neither should you. Be tool-aware, not tool-obsessed. Knowing a tool doesn't make you a PM, and not knowing one won't sink you. Companies hire for the thinking — discovery, prioritization, communication, judgment, the whole craft this course has been building. They fully expect you to learn their specific stack on the job, and you will, in a matter of days.

Walk in knowing the six categories. Add solid spreadsheet basics and real comfort with AI assistants. That's a complete answer. A PM who's sharp on the thinking and rough on the tools will thrive and catch up fast. A PM who's slick with every app but weak on judgment won't last.

The tools serve the craft. The craft is the point.

Worked example — Maya's first week, tool by tool

Roll back to that first morning. Six apps, none of which Maya had touched before, and that flash of panic.

Here's how the rest of her week actually went, because she knew the categories.

She found the backlog in Jira, where the user stories live, and read herself into what the team was building. She opened the latest spec in Notion, the docs box. She clicked through the current designs in Figma, leaving a comment where a flow felt confusing, exactly what a PM does in a design tool. She pulled up the key funnel dashboard in Amplitude to see how the product was doing, reading the numbers rather than building them.

Then Dan's "Excel export" question landed. Maya dropped the candidate features into a spreadsheet with a simple Value/Effort table. After a long planning meeting, she fed her messy notes to an AI assistant, got a clean summary back, and checked the details before sharing it.

By Friday she was useful. Not because she'd memorized a single tool in advance — because she understood what each category was for, and let that carry her into the specifics.