pm tools & workflows

Here is the uncomfortable truth about PM tools: your company will not buy you the ones you want. The engineering team gets Datadog. Sales gets Salesforce. Marketing gets HubSpot. You get a Google Sheet and a prayer.

This page is not a product review. I am not going to list 47 tools with feature comparisons. Instead, I will tell you which tool to use for which job, what the real workflows look like in Indian companies, and where most PMs waste time on tooling instead of doing actual product work.

The tool stack that actually matters

Every PM needs exactly four categories of tools. Not twelve. Four.

1. A place to write specs. Where your PRDs, briefs, and one-pagers live.

2. A place to track work. Where engineering tickets, bugs, and sprint commitments are visible.

3. A place to see data. Where you answer “how are users actually behaving?”

4. A place to think visually. Where wireframes, flows, and journey maps take shape.

Everything else — the Miro boards, the Loom recordings, the Notion databases with fourteen linked views — is optional. Get the four right first.

Specs and documentation

My recommendation: Confluence if your team uses Jira. Notion if they do not.

Here is why. Confluence integrates natively with Jira — you can embed Jira tickets directly inside a PRD, and when the ticket status changes, the PRD updates. This sounds minor. It is not. When your PRD reflects live engineering status, you stop having “where are we on this?” meetings.

If your company does not use Atlassian, use Notion. Its database features let you build a product knowledge base that connects specs to research to launch plans. The block-based editor is faster for writing than Confluence. And its free tier is generous enough that you can start without procurement approval — which, in Indian companies, can take longer than building the feature.

What about Google Docs? Fine for one-off documents. Terrible for a product knowledge base. You will end up with hundreds of untitled docs in a shared drive, and six months later nobody can find anything. Google Docs has no structure. You need structure.

The workflow that works:

1. Start every feature with a one-pager in your chosen tool. Not a full PRD — a one-page problem statement, proposed solution, and success metric.
2. Link the one-pager to the epic or parent ticket in your tracker.
3. Expand into a full spec only if the feature survives prioritization.
4. After launch, update the doc with actual outcomes. This is the step everyone skips, and it is the step that builds institutional memory.

Work tracking

The honest answer: use whatever your engineering team already uses.

If they use Jira, you use Jira. If they use Linear, you use Linear. If they use GitHub Issues, you use GitHub Issues. The worst thing a PM can do is introduce a separate tracking tool “for the product side” and create a translation layer between two systems. You will spend half your week keeping them in sync.

Jira specifics for PMs. Jira is the default in most Indian tech companies — startups and enterprises alike. A few things I have learned from years of using it:

• Epics are your unit of product work. One epic per feature. The epic description is where your spec summary lives. User stories break down the epic into testable behaviors. Do not create tickets smaller than what a developer can ship in two days, and do not create ones larger than a week.
• Custom workflows matter. The default Jira workflow (To Do → In Progress → Done) is too simple for any real product. Add at least: In Review, QA, and Blocked. The “Blocked” state is the most important — it makes invisible dependencies visible.
• Filters are your dashboard. Build saved filters for: all tickets assigned to your team in the current sprint, all bugs reported this week, all tickets blocked for more than two days. Check these daily. This takes five minutes and replaces a thirty-minute standup.

Linear, if you have the choice. Linear is faster, cleaner, and designed for product teams rather than IT service desks. If you are at a startup or a company where you can influence tooling decisions, push for Linear. Its keyboard shortcuts alone save hours per week. The cycle-based planning model fits product work better than Jira’s sprint model. And it does not have the configuration bloat that makes every Jira instance feel like a different product.

Product analytics

This is where most PMs are under-equipped. You need to understand data. More importantly, you need to know which tool gives you which kind of answer.

Google Analytics is for marketing — acquisition channels, traffic sources, landing page performance. It was designed for marketers. Product managers have been torturing it to answer product questions for years. If you only have GA, you can survive, but you are working harder than you need to.

Amplitude or Mixpanel is for product behavior — feature adoption, user flows, retention cohorts, funnel analysis. These tools are designed for the questions PMs actually ask: “Which features do retained users engage with in their first week?” or “Where exactly do users drop off in the onboarding flow?”

My recommendation between the two: Amplitude. It was built with product managers as the primary user. Mixpanel has more power but requires more technical setup. If your engineering team will configure the events properly and maintain them, Mixpanel is excellent. If the PM needs to self-serve most analysis — which is the reality in most Indian startups — Amplitude is more forgiving.

CleverTap and WebEngage are engagement platforms with analytics bolted on. If your company uses them for push notifications and campaigns, use their analytics for engagement metrics. But do not rely on them as your primary product analytics tool. They see the world through a marketing lens.

Tableau or Power BI is for custom reporting — when you need to combine product data with business data. Revenue per cohort, support tickets correlated with feature usage, operational metrics. You will not build these dashboards yourself. But you need to know they exist so you can ask your data team the right questions.

Design and prototyping

Figma for everything. This is one of the few areas where the answer is genuinely simple. Figma is the standard. It works in the browser. It is collaborative. Your designers already use it. Learn to navigate it, leave comments, and understand the basics of auto-layout — not to design, but to give precise feedback.

If you are at a very early stage startup with no designer, paper and pen beat any tool. I have shipped products sketched on dot-grid notebooks. A photo of a paper wireframe shared on WhatsApp gets faster feedback than a Figma prototype that took three days to build. Fidelity is the enemy of speed when you are validating concepts.

Balsamiq still has a place for PMs who need to create low-fidelity wireframes quickly. It deliberately looks hand-drawn, which prevents the “but can we make the button blue?” feedback that derails early-stage design discussions. When you want people to react to the flow and not the pixels, Balsamiq enforces that constraint.

Miro is for workshops — journey mapping, affinity diagrams, brainstorming sessions. It is not a daily tool. If you are spending time in Miro every day, you are workshopping too much and building too little.

AI tools: what is real, what is noise

Every PM tool now has “AI features.” Most of them are wrappers around the same LLMs doing the same autocomplete. Here is what actually changes your workflow in 2026:

Writing first drafts. Use an LLM (Claude, GPT-4) to generate the first draft of a PRD, competitive analysis, or user research summary. Then rewrite it. The value is not the output — it is that starting from a bad first draft is faster than starting from a blank page. The PM who writes the final version is still doing the thinking. The AI just eliminated the blank-page problem.

Summarizing research. If you have twenty user interview transcripts, an LLM can extract themes and patterns in minutes instead of days. But you still need to read the raw transcripts for the surprising insights — the ones that do not fit a pattern. AI is good at finding what is common. PMs need to find what is uncommon.

SQL and data queries. If your analytics setup requires SQL, tools like text-to-SQL are a genuine productivity multiplier. You describe the question in English, get the query, validate the output. This turns a “file a ticket with the data team and wait three days” into a ten-minute self-serve task.

What is not useful yet: AI-generated roadmaps, AI prioritization, AI “product strategy.” These require judgment and context that no model has. If you feed your backlog into an AI and ask it to prioritize, you will get a plausible-sounding answer that misses every political, strategic, and resource constraint that actually determines priority. Prioritization is a human job. Keep it that way.

The workflow, not the tool

The most productive PMs I have worked with follow a daily rhythm that has nothing to do with which tool they use:

Morning (15 minutes). Check blocked tickets. Check key metrics. Identify the one decision that needs to be made today.

Midday. Do the hard work — writing specs, talking to customers, reviewing designs, analyzing data. This is where the tools earn their keep.

End of day (10 minutes). Update ticket statuses. Write a one-line summary in the team channel: what moved forward, what is stuck, what needs a decision tomorrow.

That is it. No elaborate Notion dashboards updated hourly. No three-hour Jira grooming sessions. The discipline is in the rhythm, not the tooling.

The India-specific reality

A few things that are true in Indian tech companies and mostly absent from Silicon Valley PM advice:

Procurement is slow. Getting budget approval for a new tool can take months. Start with free tiers. Notion, Jira, Amplitude, Figma — all have free versions that are good enough for a team of five to ten. Prove the value before asking for budget.

WhatsApp is a tool. Whether you like it or not, critical product decisions happen on WhatsApp in Indian companies. Do not fight it. Instead, build a habit: any decision made on WhatsApp gets captured in your official tool within 24 hours. A screenshot in the Jira ticket is better than a decision that lives only in a chat thread that will get buried.

Excel is underrated. Indian PM culture runs on spreadsheets, and that is not a weakness. A well-structured Google Sheet for prioritization, resource planning, or metric tracking is more flexible than most purpose-built PM tools. The limitation is collaboration and version control — which is why you graduate to purpose-built tools as the team grows, not because sheets are bad.

Your engineering team’s maturity determines your tool ceiling. If your developers are not disciplined about updating Jira tickets, no amount of PM tooling will give you accurate project status. Fix the process first. The tool follows.

Test yourself

Where to go next

• Learn how to write the specs that live in these tools: Writing PRDs
• Understand the metrics your analytics tools should track: PM Competency Model
• See how tools fit into daily PM practice: A PM’s Day-to-Day
• Apply product thinking to tool selection decisions: Product Thinking