Churn, a Sales Promise, and a Re-Architecture Request
Tidepool is a B2B SaaS company with three product teams and one platform team. Annual churn has risen from 5% to 8%, and the CEO's annual OKR is to reduce it to 4%. Sales has publicly promised a 'workflow automation' feature to the top 20 accounts. Engineering wants to spend two quarters re-architecting the monolith. Product has completed two months of discovery with 18 customer interviews and has a journey map with 23 pain points. The platform team is funded as a cost centre and has no direct customer contact. Each product team maintains its own backlog, and there is no shared definition of value. Releases happen every two weeks, but the platform team's work is estimated in months. Nobody owns the cross-team roadmap.
1. How should the organization define and analyse value across the Strategy, Initiative and Delivery horizons to address churn?
Read the worked answer
Strategy: define churn as the outcome and disaggregate it by segment, cohort, and lifecycle stage. Use the 18 interviews and journey map to identify which pain points correlate with actual churn, not just stated dissatisfaction. Agree leading indicators such as activation, feature adoption, support contacts per account, and renewal likelihood, plus guardrails on margin and reliability.
Initiative: convert the 23 pain points into a small portfolio of hypotheses. Each states the segment, the pain, the proposed change, expected churn impact, evidence, cost, and dependencies, including platform work. Apply bang for the buck and cost of delay. Do not fund a two-quarter re-architecture as an unvalidated initiative; frame it as an enabler with measurable exit criteria.
Delivery: slice changes so each release can be measured against a leading indicator. Instrument before building.
Reasoning: churn is lagging. Without a value model that connects platform work, product changes, and sales commitments to leading indicators, the organization will optimize local outputs and still lose customers.
2. Sales has promised workflow automation to the top 20 accounts. How should product and platform teams respond using agile analysis?
Read the worked answer
Be transparent and options-oriented. First, analyse the commitment: revenue at risk, renewal dates, the specific workflow each account expects, and whether a thin slice would satisfy them. Separate the common workflow pattern from account-specific variations.
Then present options with trade-offs:
- A minimum marketable feature for the common workflow, released to the top accounts by a stated date.
- A concierge or integration workaround for accounts with urgent renewals.
- A phased commitment with assumptions and a decision point. Involve the platform team early, because workflow automation may require shared services and could become a dependency. Put the commitment on the visible roadmap and in the same prioritization model as churn hypotheses.
Reasoning: sales commitments are real stakeholder needs, but they are not a substitute for discovery. Agile analysis makes the cost of delay and the scope options explicit, so the organization can protect revenue without silently creating a fixed-scope project.
3. Engineering wants a two-quarter re-architecture. How should the analysis decide whether and how much to fund?
Read the worked answer
Ask what outcome the re-architecture enables and how it will be measured. Link it to churn drivers, release cycle time, reliability, or the cost of delivering workflow automation. If the link is speculative, fund a time-boxed discovery or a thin enabler slice rather than two quarters.
Analysis steps:
- Quantify current pain: incident cost, lead time, defect rates, scaling limits.
- Identify the architectural runway needed for the next two or three initiatives, not a complete rewrite.
- Define exit criteria and leading indicators such as deploy time and change failure rate.
- Compare options: incremental modernization, strangler pattern, targeted refactor, or full re-architecture.
- Fund in increments with review points and keep customer-facing work flowing.
Reasoning: enablers are legitimate backlog items, but they compete for the same capacity as customer-facing work. The decision should be based on expected value and risk reduction, not on technical preference. Incremental funding preserves the ability to stop or adapt as evidence emerges.