What is the Portfolio Goal Analysis?

The Portfolio Goal Analysis helps you answer a planning question: given our current bets, what’s the probability we hit each goal by its deadline? It combines your baseline forecasts with bet impact assumptions (including lag/ramp timing) and produces a probability of goal attainment, coverage diagnostics, and rebalancing suggestions.

This is not a guarantee. It’s decision-support: a transparent simulation that turns assumptions into a measurable “are we on track?” signal you can iterate on.

What Value It Gives

• Goal-level clarity – See which goals are likely to be hit vs. missed, with probability rather than vibes.
• Coverage diagnostics – Understand whether your current set of bets plausibly closes the gap (under/adequate/over coverage).
• Risk management – Track guardrails (e.g., churn, latency, CAC) as breach probabilities, not just point forecasts.
• Better allocation – Identify which bets most efficiently improve goal attainment probability per unit effort.
• Fewer false certainties – Use uncertainty bands and correlations so the plan reflects real variance and shared risk.

Common Use Cases

• Quarterly goal reviews – Answer “are we actually on track?” with P(hit), not just a point forecast.
• Planning coverage – Validate whether the current roadmap is enough to hit targets (or where you’re short).
• Rebalancing effort – Shift investment away from low-leverage bets and toward the ones that move P(hit).
• Guardrail safety checks – Ensure growth bets don’t push risk metrics over acceptable thresholds.
• Cross-team alignment – Make goal risk and trade-offs explicit so planning discussions converge faster.

Three Layers: Goals, Guardrails, Rebalancing

Goals (probability of attainment)

For each goal, Segflow estimates:

• P(hit): probability the metric lands at/above (or at/below) the target by the deadline (within tolerance)
• Landing range: p10 / p50 / p90 of the simulated landing value at the deadline
• Shortfall: how far behind (or ahead) you are on the median landing
• Coverage: whether your median bet impacts plausibly cover the baseline gap (the gap between baseline forecast and target, before any bets)

Guardrails (probability of breach)

For guardrails (metrics you must not violate), Segflow estimates:

• P(breach): probability you cross the guardrail threshold at any checkpoint before the deadline (uses sparse checkpoints at ~2%, 5%, 10%, 15%, 20%, 25%, 50%, 75%, 100% of the horizon; short-lived breaches between checkpoints may be missed)
• Risk level: safe / warning / danger based on breach probability

Rebalancing (marginal value per effort)

Segflow estimates which bets most efficiently improve goal attainment and suggests:

• Increase / maintain / decrease / stop recommendations per bet
• Suggested effort deltas (optionally constrained by team capacity and min/max effort bounds)

How Goal Probability Is Estimated

Portfolio Goal Analysis runs a Monte Carlo simulation: it repeatedly samples plausible futures and counts how often each goal is hit.

Under the hood (methodology)

1. Sample the baseline forecast at the goal deadline Each goal has a baseline time series forecast with p10, p50, p90 bands. The model samples a landing value at the target date.

2. Sample bet impacts with uncertainty Each bet → metric impact can be provided as explicit impactP10/impactP50/impactP90, or as a point estimate plus a confidence level that’s converted into percentiles.

3. Apply timing and reach Impacts can include:

   • lagDays: days before impact begins
   • rampDays: days to linearly ramp from 0% to 100% impact
   • reach: fraction of users affected (0–1)

4. (Optional) Propagate cascade effects If you provide metric driver relationships (e.g., from Driver Analysis), the model can propagate upstream impacts into downstream goal metrics with coefficients and optional lag.

   Cascade timing notes:

   • Cascades only begin after the upstream bet fully ramps (lag + ramp complete), then apply their own ramp (~10% of remaining days, clamped 1-7 days). This is hard-coded and may understate cascade effects for bets with long ramps or short horizons.
   • When multiple bets affect the same upstream metric, the cascade uses the minimum effective days across all bets (most conservative timing). A slow bet can throttle cascade timing for faster bets hitting the same metric.
   • Driver lagDays is supported; cascade ramp is not yet configurable.
   • For multi-hop cascades (3+ hops), marginal analysis approximates with a single timing value and may diverge slightly from simulation results.

5. (Optional) Model shared risk via themes If multiple goals/bets share a theme (e.g., “Activation”), the simulation can correlate their sampled outcomes so you don’t get false diversification.

6. Compute P(hit) and landing ranges After many iterations, Segflow computes:

   • P(hit) = % of simulations where the goal is hit (within tolerance)
   • Landing p10/p50/p90 at the deadline
   • Status buckets (off track / at risk / on track / safe)

Example: Planning Coverage for a Quarter (Illustrative)

Scenario: You have 3 goals by end of quarter: grow activation, reduce churn, and keep support backlog below a guardrail threshold. You have 6 bets proposed across growth and reliability.

How you’d use Portfolio Goal Analysis:

1. Create a goal per metric with a target value + target date and a baseline forecast (p10/p50/p90).
2. Attach bets with effort plus impacts (with lag/ramp/reach if needed).
3. Add themes (Activation, Retention, Reliability) and set priorities so the portfolio score reflects what matters most.
4. Add guardrails for “must not break” metrics and set thresholds.
5. Run the analysis and compare P(hit) across goals, then use marginal analysis to rebalance effort.

What you might learn:

• Activation is adequately covered but still only ~60% P(hit) because uncertainty is wide.
• Churn is under-covered: even the median assumed bet impact doesn’t close the median shortfall.
• The backlog guardrail has a high P(breach), suggesting you need to reallocate effort or add mitigation before scaling growth bets.

What You Provide

Required Inputs

• Goals – Target value + target date per metric, plus a baseline forecast (p10/p50/p90 time series).
• Positive direction – Whether “good” means the metric goes up (e.g., revenue) or down (e.g., churn).

Bets and Impacts

• Bets + effort – Use one consistent effort unit (e.g., person-weeks).
• Bet → metric impacts – Absolute impact in the metric’s units, with either:
  • explicit impactP10/impactP50/impactP90, or
  • expectedImpact + confidence (low / medium / high)
• Timing + reach – Optional lagDays, rampDays, and reach (0–1).
• One impact per metric per bet – A single bet cannot have multiple impacts on the same metric (e.g., immediate + delayed). To model phased effects, split into separate bets sharing the same themeId (so they remain correlated) and allocate effort proportionally.

Optional Inputs (Advanced)

• Themes + priority – Group goals/bets and weight portfolio scoring (priority 1–10).
• Guardrails – Mark goals as guardrails and set a guardrail threshold to track breach risk.
• Driver relationships – Metric-to-metric coefficients for cascade propagation. Cascade timing uses a 1-7 day ramp (not configurable). This works well for fast-propagating relationships (e.g., feature → engagement) but may understate lag for slow ones (e.g., marketing → pipeline with 30+ day cycles).
• Correlation strength – 0–1 for how strongly same-theme outcomes co-move.
• Iterations – Simulation iterations (default: 10,000).
• Team capacity – Constraints for rebalancing suggestions.

Validation Rules

The model enforces these constraints (errors will be thrown if violated):

• Unique IDs – All goalId, betId, themeId, and teamId values must be unique. Duplicates cause silent data corruption in theme rollups and marginal analysis.
• Strictly increasing forecast dates – Forecast points must have unique dates in chronological order. Duplicate or out-of-order dates break interpolation (division by zero, binary search failures).
• Valid metricId references – Bet impacts must reference a metricId that exists in a goal or in a driver relationship (source or target). This allows bets to impact upstream metrics that cascade to goals. Typos in metricIds are caught with helpful error messages.
• No cycles in driver relationships – Driver relationships must form a directed acyclic graph (DAG). Circular dependencies (e.g., A → B → C → A) are detected and rejected with an error listing the involved metrics.

Goal Hit Tolerance

• tolerance – How close to target counts as “hit” (default: 5%). Example: with a 5% tolerance, a goal of 100 is treated as hit at ≥95 for “up” goals (or ≤105 for “down” goals).

Lag and Ramp Configuration

• lagDays – Days before impact begins. Use when effects are delayed (e.g., sales cycle, rollout, indexing lag).
• rampDays – Days for linear ramp from 0% to 100% impact. Use for gradual rollouts.
• reach – Fraction of users affected (0–1). Use when an impact only applies to part of the population.

What You Get Back

Goal Outputs

• P(hit) – Probability of hitting the goal by the deadline (within tolerance).
• Landing range – p10 / p50 / p90 projected landing values.
• Shortfall – Gap between target and expected landing (direction-aware).
• Coverage status – Whether median bet impact plausibly covers the baseline gap (pre-bet gap to target): uncovered / under / adequate / over.
• coverageUncertain – True when bet impact variance is high relative to the baseline gap. Coverage may show “adequate” while P(hit) remains low due to uncertainty. When this flag is set, rely on P(hit) rather than coverage status for decision-making. Note: Variance calculation assumes bet impacts are independent, which understates true uncertainty due to coherent sampling and theme correlation. The flag may under-fire in highly correlated portfolios.
• Contributing bets – Which bets affect the goal metric and how much median impact they add.
• isOverdue – True when daysToTarget === 0 (same-day or past deadlines). Overdue goals have no bet impact applied (day-based timing means no time to materialize) and P(hit) reflects only the baseline forecast. This includes same-day deadlines where targetDate is later in the day. Consider filtering or flagging these.

Percentile inversion warning: When bets cascade through negative driver coefficients (e.g., A -> B with coefficient -0.5), the impactP10 and impactP90 values in contributingBets may be inverted (P10 > P90). This is mathematically correct but can confuse visualizations. Check for impactP10 > impactP90 and handle accordingly.

Guardrail Outputs (when enabled)

• P(breach) – Probability of violating the guardrail threshold.
• Risk level – safe / warning / danger.

Status Definitions

• Goal status
  • safe: ≥85% P(hit)
  • on track: 50% to < 85% P(hit)
  • at risk: 25% to < 50% P(hit)
  • off track: < 25% P(hit)
• Guardrail risk
  • safe: < 10% P(breach)
  • warning: 10–30% P(breach)
  • danger: >30% P(breach)

Portfolio Outputs

• Summary – Counts by goal status, average P(hit), priority-weighted average P(hit), total effort, guardrails at risk.
• Theme rollups – Aggregate P(hit) and effort per theme, plus balance signals (under/over invested).
• Marginal analysis – Estimated P(hit) improvement per effort unit per bet and a recommendation.

Rebalancing Suggestions (Separate API Call)

Limitations:

• Marginal analysis and rebalancing only optimize for goal P(hit), not guardrail breach risk. A recommendation to “increase” a bet may improve goal attainment while worsening a guardrail. Always cross-check rebalancing suggestions against guardrailResults before acting on them.
• Recommendation thresholds are absolute values, but portfolioValue scales with bet effort. Large bets may be biased toward “increase” and small bets toward “decrease.” Ensure consistent effort units across the portfolio for fair comparisons.

simulateChange() limitations:

• Does not support adding bets. To add bets, call analyze() with modified input.
• The coverageUncertain flag is NOT updated after removing bets. It reflects the original simulation state only. For accurate uncertainty after changes, run a full analyze().

The analyze() method returns marginalAnalysis — per-bet metrics showing portfolio value and recommendations. To get concrete rebalancing suggestions (proposed effort changes with rationales), call suggestRebalancing() as a separate step:

const model = new PortfolioGoalModel();
const result = model.analyze(input);
 
// marginalAnalysis is already in result
console.log(result.marginalAnalysis);
 
// For concrete suggestions with effort deltas, call suggestRebalancing:
const suggestions = model.suggestRebalancing(result, {
  teamCapacities: input.teamCapacities, // optional constraint
});

This two-step design lets you inspect marginal data before generating suggestions, and pass additional constraints (like team capacity) to the rebalancing logic.

How to Interpret Results

• Read P(hit) as risk, not certainty – A 60% goal isn’t “fine”; it’s a coin flip that needs attention.
• Use landing ranges to set expectations – Wide p10–p90 means you should plan for volatility and avoid overcommitting.
• Coverage is diagnostic, not a victory lap – “Over-covered” doesn’t mean guaranteed; it means your median assumptions exceed the median gap.
• Correlations reduce real diversification – Two bets can look independent but still rise/fall together if they share the same underlying risk.
• Guardrails are constraints, not goals – A high P(breach) should override “high upside” bets until mitigated.
• Rebalancing is a starting point – Use recommendations to focus discussion, then sanity-check assumptions and dependencies.

Correlation Semantics

Correlation strength applies within each goal’s simulation — it correlates baseline forecast sampling with bet impact sampling when they share a theme. This prevents overconfident P(hit) estimates for goals that depend heavily on theme-correlated bets.

Theme inheritance for unthemed bets: Bets without an explicit themeId inherit the goal’s theme during simulation. This means unthemed bets are correlated with the goal’s baseline by default. The rationale: bets affecting a goal are assumed related unless explicitly assigned to a different theme. To make a bet truly independent, assign it to a unique theme or set correlationStrength: 0.

Important limitations:

• The current implementation does not compute joint portfolio probability (P(hit all goals)).

• The avgPHit and weightedAvgPHit are simple averages, not correlated joint probabilities.

• Cross-goal correlation is not modeled — if two goals share the same theme, their P(hit) values are computed independently.

• Quantile flip limitation (important for complex portfolios): Theme correlation flips the “good luck” direction based solely on goal direction (positiveDirection), NOT per-bet impact sign or cascade coefficient sign. This causes incorrect correlation in two scenarios:

  1. Harmful bets (negative expectedImpact): For an “up” goal, high quantile = “good luck” = larger positive impact. But for a harmful bet, high quantile = larger negative = WORSE outcome. The correlation incorrectly treats this as good luck.
  2. Negative driver coefficients: If metric A drives B with coefficient -0.5, “good luck” on A produces “bad luck” on B. The cascade doesn’t flip quantile direction, so theme correlation can be inverted.

  Impact: For portfolios with few harmful bets and mostly positive driver coefficients, this is negligible. For complex driver graphs with negative coefficients, theme correlation may be unreliable.

If you need joint probability analysis (e.g., “what’s the chance we hit all three growth goals?”), you would need to run a custom simulation that samples all goals together with shared theme factors.

Best Practices

• Use realistic uncertainty bands (p10/p50/p90) instead of single point estimates.
• Keep effort estimates consistent across teams so “per effort” comparisons stay fair.
• Set positiveDirection correctly for “lower is better” metrics (churn, latency, CAC).
• Use themes to model shared risk (campaign-dependent bets, platform work, etc.).
• Re-run as assumptions change (new bets, updated forecasts, observed impact after shipping).

Summary

The Portfolio Goal Analysis turns a roadmap into a probability-weighted view of goal attainment and risk. Use it to see what’s likely to land, what’s under-covered, where guardrails might break — and how to rebalance effort to improve your odds.