SYSTEM: ASHRITH_OS | MODULE: PRODUCT_PLAYBOOK.CFG
BUILD v5.2_STABLE | LOCAL TIME --:--:--
System Config // 7 Modules Loaded

My product playbook

The principles and frameworks I use to turn complexity into product decisions - before a single line of a PRD gets written. Click a module to expand.

MOD.01

Problem Framing

How I move from chaos to a usable problem statement - before proposing any solution.

  • Start with the workflow, not the feature request
  • Separate symptoms (complaints) from root cause (structural gaps)
  • Quantify the cost of the status quo before pitching change
  • Write the problem statement so a stranger could pressure-test it
MOD.02

Workflow-First Product Design

Why understanding the workflow matters more than collecting a feature wishlist.

  • Map the current-state process end-to-end before designing anything new
  • Identify where handoffs create delay, risk, or lost context
  • Design the future-state workflow first - features fall out of it, not the reverse
  • Validate the map with the people who actually do the work daily
MOD.03

Prioritization in Constrained Environments

How I choose what to fix first when everything feels broken and urgent.

  • Rank by blast radius: what breaks the most workflows if left unfixed?
  • Sequence for de-risking - tackle the highest-exposure item first, not the easiest
  • Separate "urgent to stakeholders" from "urgent to the business"
  • Make tradeoffs visible, not silent - write down what's explicitly not happening now
MOD.04

Adoption as Product Work

Why rollout, training, trust, and launch readiness are part of product - not "operations' problem."

  • Treat go-live like a feature with its own success criteria
  • Build training and UAT into the roadmap, not as an afterthought
  • Track adoption metrics as seriously as usage metrics
  • Design for trust: a system people avoid is a system that failed, regardless of specs
MOD.05

AI in Operational Products

How I identify where AI actually improves decisions and communication - not where it's just novel.

  • Scope AI to verifiable, bounded outputs in high-stakes workflows
  • Design for human-in-the-loop confirmation before automated action
  • Prioritize signal clarity over feature novelty
  • Be explicit about what the system does and doesn't claim to know
MOD.06

Governance Without Bureaucracy

How I balance speed, trust, and controls - especially in regulated or high-stakes environments.

  • Bake audit trails and reporting into the workflow, not bolted on after
  • Make compliance a design constraint from day one, not a final gate
  • Keep governance visible to the people it protects, not just to auditors
  • Optimize for "provably correct," not just "fast"
MOD.07

Live Product Teardown: Salesforce Flow Builder

Product sense isn't just retrospective - it's how I evaluate a product I don't own. Here's a real, unsolicited teardown of Salesforce Flow Builder, an enterprise workflow-automation tool, using the same lens from Module 02 and 04.

What it does well

Flow Builder gives admins a visual, no-code way to automate business processes across Salesforce objects - genuinely lowering the barrier for non-engineers to ship real automation, which is the right instinct for an enterprise platform.

Where it breaks workflow trust

Debugging a failed Flow in production is opaque - error messages point at symptoms, not root cause, and there's no built-in "replay with sample data" for admins to safely test edge cases. That is exactly the adoption-killer I flag in Module 04: a system people learn to route around, not trust, the moment it fails silently once.

How I'd scope a fix (v1)

Ship a "Flow Debugger Replay" mode: capture the exact record state that triggered a failure, let admins re-run the Flow step-by-step against that captured state in a sandboxed view, and surface the failing condition in plain language, not a stack-trace-style error. Success metric: reduction in support-ticket time-to-resolution for Flow failures, not just fewer failures.

The tradeoff I'd flag to leadership

Building deep replay tooling competes for the same engineering capacity as new Flow actions/connectors. I'd argue reliability tooling wins first: every enterprise workflow tool eventually loses trust to opacity before it loses trust to missing features - this is the same governance-over-speed tradeoff from Module 06, applied to a product I don't own.

This is an unsolicited, outside-in teardown based on public product experience - not confidential information from any employer.

Practice reps: product-sense case studies

Beyond the live teardown above, I regularly run myself through classic PM interview prompts as deliberate practice - the same way an engineer drills coding problems. These three are self-practiced exercises, not client deliverables, but they show the same reasoning muscle: structuring ambiguity, picking a lens, and being explicit about what I'm assuming. Full write-ups are downloadable below.

Corp Strategy / M&A

If Microsoft Had to Acquire One Company

Prompt: "What would it be if Microsoft had to acquire one company - and why?"

I anchored the analysis in Microsoft's actual mission - empowering people and organizations to achieve more - so the acquisition target had to earn its place by expanding real use cases for existing users, not just be a recognizable name. I scoped the analysis to a few major Microsoft business lines, deliberately left finance and regulatory diligence out of frame, and argued explicitly that the "best" target is not the most famous one - it's the one with the tightest strategic fit.

Download full write-up (.docx) ↓
Metrics & Analytics

A Metrics Framework for Spotify

Prompt: "As a PM, what metrics do you see for Spotify?"

I started by naming Spotify for what it actually is - a two-sided platform of listeners and creators, not just a listening app - then built a funnel-style metrics framework that tracks both sides in parallel instead of defaulting to a listener-only view. The write-up breaks metrics out by funnel stage, starting with acquisition (downloads, CAC, conversion to activation), and checks whether growth on one side is compounding growth on the other.

Download full write-up (.docx) ↓
Product Critique

A Product I Love (and Despise): Fitbod

Prompt: "Name a product you love and despise, and how would you improve it?"

I picked Fitbod deliberately because it's genuinely both for me - it removes workout-planning effort and personalizes programming around goals, equipment, and history, which makes it practical for a schedule that changes daily. But I hold real friction with it too, and the write-up walks through that tension in detail and where I'd take the product from there, rather than only listing praise.

Download full write-up (.docx) ↓