The Vision Hierarchy

Product vision works at four levels of abstraction, each translating the level above into more concrete and actionable terms:

1. Mission (Why we exist): A timeless statement of purpose that does not change with product evolution. Example: "To make financial services accessible to every Indian business, regardless of size or location." This is your North Star — every product decision should pass the "does this serve our mission?" test.
2. 3-Year Vision (Where we are going): A vivid picture of what success looks like in 3 years. Not a metric — a narrative. "By 2028, we are the trusted financial operating system for 50,000 Indian SMBs, managing their invoicing, payments, credit, and compliance in one unified platform." Write it as if it has already happened.
3. Annual Goals (What we will achieve this year): 3–5 measurable outcomes for the year that move toward the 3-year vision. Example: "Reach ₹5 Cr ARR, launch GST filing automation module, achieve NPS of 50+ across active users."
4. Quarterly OKRs (What we'll do next 90 days): 2–3 Objectives with 3–5 measurable Key Results each. OKRs bridge vision and execution — they are ambitious (70% achievement is considered success) but time-bound and measurable.

The Three-Level Backlog Structure

Structuring your backlog in a clear hierarchy prevents the most common early-stage PM failure: a flat list of 200 random items with no organising logic. The three levels:

• Epic: A large body of work that cannot be completed in a single sprint and represents a significant product capability. Example: "GST Filing Integration." Epics typically take 4–12 weeks and map directly to a strategic objective or OKR. A well-managed backlog has 5–15 active epics at any time.
• Story (User Story): A specific user need that can be delivered in a single sprint (1–2 weeks). Written from the user's perspective: "As a [user type], I want [capability] so that [benefit]." Example: "As an accountant, I want to auto-populate GSTR-1 from my invoices so that I do not have to enter data manually each month." Stories should be independently deliverable and testable.
• Task: A specific engineering, design, or QA action required to deliver a story. Tasks are 4–8 hours of work, assigned to a specific person, and tracked at the sprint level. Example: "Build GSTN API integration for invoice data pull." Tasks should not be visible to business stakeholders — they are the implementation detail that engineers manage.

Backlog Health Indicators

• Every story in the "ready for sprint" queue has an acceptance criterion — without this, "done" is undefined
• No story in the ready queue is more than 4 weeks old without having been started — old items accumulate like debt and signal poor refinement discipline
• The top 10 stories are estimated (in story points or days) before sprint planning — unestimated items cannot be committed to a sprint
• The backlog has a regular refinement session (30–45 minutes per week) where the team discusses, estimates, and clarifies upcoming stories

Outcome-Based Roadmap

Organised around measurable outcomes rather than features — "Q1: Reduce onboarding drop-off by 40%" rather than "Q1: Rebuild onboarding flow." This is the most modern PM approach and is increasingly expected by sophisticated investors. The advantage: the team has freedom to discover the best solution to each outcome, rather than being locked to a pre-decided feature before the problem is fully understood. Best for: Series A+ companies with dedicated PM function and strong product analytics.

Feature-Based Roadmap

The most common early-stage format — a list of features organised by approximate quarter with effort and owner. Simple to communicate with customers, investors, and the engineering team. The risk: it implies commitment to specific solutions before those solutions have been validated. Best for: pre-seed and seed stage teams that need a simple, shareable artefact for customer conversations and investor updates.

Timeline Roadmap

A Gantt-chart style roadmap with specific delivery dates for each feature or milestone. Communicates precision and planning maturity, but is frequently inaccurate (software estimates are notoriously unreliable) and creates implicit customer commitments that are difficult to walk back. Best for: specific customer contractual commitments (enterprise pilots with delivery date SLAs) or fundraising milestone tracking — not for general product planning.

1-Week vs 2-Week Sprints

The most common debate in early-stage PM. The right answer depends on your team's maturity and product phase:

• 1-week sprints: Higher overhead (sprint ceremonies every week), but faster feedback loops. Best for pre-PMF startups iterating rapidly on core product hypotheses. The cost of planning every week is worth it when you are still discovering what to build.
• 2-week sprints: Industry standard — enough time for meaningful feature delivery while maintaining regular cadence. Best for post-PMF startups executing a known roadmap. Reduces ceremony overhead by 50% vs weekly sprints.
• India context: Many Indian startups informally run 2-week sprints that function as 3-week sprints due to holiday density (Diwali, Dussehra, regional festivals). Build a realistic sprint calendar for the year, accounting for Indian public holidays and team leaves, before committing to sprint velocity targets.

Sprint Ceremonies

• Sprint Planning (2 hours, start of sprint): Select stories from the top of the backlog, confirm they have acceptance criteria, estimate effort, assign to engineers, define the sprint goal
• Daily Standup (15 minutes, daily): What did I do yesterday? What am I doing today? What is blocking me? — No solutions discussed in standup; blockers are resolved separately
• Sprint Review (1 hour, end of sprint): Demo completed stories to stakeholders. Only stories meeting the definition of done are demonstrated — partially complete work is not shown.
• Sprint Retrospective (1 hour, end of sprint): What went well? What did not? What will we change next sprint? — The most important ceremony for team improvement; do not skip it.

Velocity Tracking

Velocity is the number of story points (or stories) completed per sprint. Track it for 4+ sprints before using it for planning — early velocity is unreliable due to team ramp-up and estimation calibration. In India, plan for 20% velocity reduction in Q4 (Oct–Nov — Diwali and festival season) and for the first sprint after any significant team addition.

The User Story Format

A well-formed user story has three components: "As a [specific user type], I want [specific capability] so that [specific benefit or outcome]." The most common mistakes:

• "As a user" — too vague. Which user? An admin, an end user, a viewer? The user type changes the entire design.
• "I want a dashboard" — too broad. What specific information or capability does this user need on the dashboard? One story should describe one capability.
• "So that it's useful" — no outcome. The "so that" clause is the most important part — it anchors the story to a real user need and prevents gold-plating.

The INVEST Criteria

Every story in your "ready for sprint" queue should satisfy the INVEST criteria:

• I — Independent: Can be built and shipped without depending on another story being done first
• N — Negotiable: The how is flexible — only the outcome is fixed. Engineers should have creative latitude on implementation.
• V — Valuable: Delivers user or business value on its own, even if other stories are not done
• E — Estimable: The team can estimate the effort. If not, it needs more breakdown or clarification.
• S — Small: Can be completed in less than one sprint (2 weeks). Stories larger than a sprint are candidates for splitting.
• T — Testable: Has clear acceptance criteria that define when the story is "done." If you cannot write a test for it, the story is too vague.

Writing Acceptance Criteria

Use the Given/When/Then format: "Given [precondition], when [user action], then [expected outcome]." Example for a GST invoice upload story:

• Given a logged-in user with at least one GST-registered business, when they upload a PDF invoice, then the system extracts GSTIN, invoice number, date, and total amount with 95%+ accuracy.
• Given an uploaded invoice with a GSTIN that does not match the GST portal, when the system validates, then an error message displays the specific mismatch with a "Check GSTIN" call to action.
• Given a successfully validated invoice, when the user clicks "File to GSTR-1," then the system queues the invoice for the current month's return and confirms with a success toast notification.

Engagement Metrics

• DAU/MAU (Daily/Monthly Active Users): The ratio (DAU/MAU × 100%) is your stickiness score — above 20% is strong for most B2B SaaS; above 50% for consumer daily-use apps. Segment by cohort and user type to identify which segments are most engaged.
• Feature adoption rate: % of active users who have used a specific feature at least once in the last 30 days. Low adoption on a recently shipped feature signals discoverability or value problems, not just engineering quality.
• Activation rate: % of new signups who complete the "aha moment" action within their first session or first 7 days. Defining your aha moment is the most important product analysis task for a new startup. For Corpfy Customer Success, it was "first ticket resolved." For Corpfy Banking & Treasury, it was "first successful payment processed."

Retention Metrics

• Week 1 / Week 4 / Day 90 retention: What % of new users return on or after each of these dates without being prompted? Industry benchmarks for India SaaS: Week 1 > 40%, Day 30 > 25%, Day 90 > 15% is considered healthy for early-stage B2B SaaS.
• Net Revenue Retention (NRR): The most important metric for a SaaS company — measures revenue retained and expanded from existing customers. NRR above 100% means expansion revenue from existing customers exceeds churn. Indian SaaS benchmark: Series A startups targeting NRR of 105%+, Series B targeting 110%+.

Time-to-Value and NPS

• Time-to-value (TtV): How long from signup to the moment the user receives meaningful value from the product. Every hour reduction in TtV improves activation rate and reduces churn. Measure it end-to-end — from account creation through every step of onboarding to first value moment.
• NPS (Net Promoter Score): "On a scale of 0–10, how likely are you to recommend this product to a friend or colleague?" Survey quarterly. Benchmark: NPS above 40 is excellent for Indian SaaS; above 60 is world-class. More important than the score is tracking the trend and reading verbatim responses for product insight.

Corpfy Product Management is a natively built Jira-equivalent — backlog, issue tracking, bug management, feature status workflow, and OKR-linked vision — built directly into the platform. No separate tool subscription required; your control evidence tickets, feature specs, and product decisions all live in the same system as your compliance and financials.

What you get in the dashboard