Step 7. Score for what you can actually build

You now have a data map and a list of use cases scored for business impact. The second scoring dimension is feasibility: how hard is it to actually build this?

Feasibility has two components, and you should score them separately.

Data feasibility — does the data exist, is it accessible, and is it good enough? Use your data map from Step 6 to assess each use case. A use case that requires attributes you know are missing or unreliable will score low here regardless of how valuable it would be.

Capability feasibility — does your team have the skills to build it? A churn prediction model requires different skills than a dashboard. A real-time alerting system requires different infrastructure than a monthly report. Be honest about what your team can deliver in the near term.

Score each dimension on a 1–5 scale:

Score	Label	Description
5	Ready now	Data exists, is accessible, clean, and has sufficient history. You could start building tomorrow.
4	Minor gaps	Mostly there but needs some cleaning, joining, or enrichment. A few weeks of work.
3	Achievable with effort	Data exists but is fragmented, poor quality, or hard to access. A meaningful engineering project.
2	Significant investment	Key data is missing or requires new capture mechanisms. A multi-month effort to get ready.
1	Not currently possible	Data does not exist and cannot be readily created. Requires new processes or systems.

The overall feasibility score for a use case is the lower of the two component scores. A use case that is a 5 on data but a 2 on capability is still a 2 overall — you cannot build what you do not have the skills for.

Keep the component scores visible in your working. A use case that is a 5 on data and a 2 on capability is a hiring or partnering problem. One that is a 2 on data and a 5 on capability is a data engineering problem. These have different solutions and different timelines.

Example — B2B SaaS

Stage	Question	Data	Capability	Overall	Notes
Marketing	Which campaigns are driving signups, and what is the cost per trial?	4	4	4	Marketing and product data need joining, but both exist and are accessible.
Marketing	Which campaigns are most likely to bring in accounts that convert and stay?	3	3	3	Requires joining marketing source data to long-run retention outcomes, which needs history.
Sales	What is our win rate by deal size and segment? Where are we losing?	4	4	4	CRM data is typically clean enough for this.
Sales	Which prospects are most likely to close, and which should the team prioritise this week?	3	2	2	Needs engineered features from CRM activity. ML model required.
Signup	Where are people dropping off in the signup flow?	5	4	4	Product analytics tools capture this natively.
Signup	Which visitors are most likely to complete signup if we intervene?	3	2	2	Propensity model requires behavioural features and ML capability.
Onboarding	What proportion of new accounts complete onboarding, and how long does it take?	4	4	4	Product events are typically well-instrumented for this.
Onboarding	Which new accounts are struggling and need intervention before they disengage?	4	3	3	Data is available; threshold-based alerting is achievable without advanced ML.
Activation	What is our time to first value, and how does it vary by segment?	4	4	4	Standard product analytics work once activation event is defined.
Activation	Which users are at risk of never activating, and what nudge is most likely to help?	3	2	2	Recommendation model for nudge type adds significant complexity.
Ongoing usage	Which features are being used and which are being ignored?	5	4	4	Product event data is typically the most mature data asset in a SaaS business.
Ongoing usage	Which product investments would most improve retention? Which disengaged users are about to churn?	3	2	2	Feature importance analysis on retention requires clean cohort history; churn model adds ML requirement.
Expansion	Which accounts have grown usage without upgrading their plan?	4	4	4	Usage and billing data join is straightforward.
Expansion	Which accounts are ready to expand, and what is the right offer and timing?	3	2	2	Propensity model on usage signals plus offer recommendation adds two layers of complexity.
Renewal	What is our renewal rate by segment and cohort?	4	4	4	Billing data is typically accessible.
Renewal	Which accounts are at risk of not renewing, and what should we do about each one?	3	2	2	Churn model with next-best-action recommendation requires ML engineering.
Churn	Why are customers leaving, and does the reason vary by segment?	3	3	3	Needs exit survey data combined with usage history — data quality varies significantly.
Churn	Which active accounts are most likely to churn in the next 90 days?	3	2	2	Binary classification model on usage and engagement features.
Win-back	What is our win-back rate, and which types of former customers return?	4	4	4	Historical billing and CRM data is sufficient.
Win-back	Which churned accounts are worth pursuing, and what offer has the best chance of working?	3	2	2	Win-back propensity plus offer optimisation — two model layers.

Example — Non-bank lender

Stage	Question	Data	Capability	Overall	Notes
Marketing	Which campaigns are generating applications that go on to settle? What is the cost per settled loan?	3	4	3	Marketing platform and application system need to be joined — UTM tracking through to settlement is often missing or inconsistent.
Marketing	Where should we shift budget to get more of the right applications?	3	3	3	Needs settled-loan attribution working first, plus a channel optimisation model.
Referral	Which brokers are sending the most volume and the best quality applications?	4	4	4	Broker data and application outcomes are typically well-captured.
Referral	Which brokers should we invest more in, and which are costing more than they are worth?	4	3	3	Data is available; commission cost-benefit model requires some engineering.
Application	What is application volume by channel and how is the mix trending?	5	4	4	Core operational data, typically clean and accessible.
Application	Are there sources of applications we are underinvesting in?	3	3	3	Requires market-level benchmarks as well as internal data.
Pre-approval	What proportion proceed to full approval, and where do they fall over?	4	4	4	Stage-level conversion data is standard in the application system.
Pre-approval	Which applications are likely to fail at approval so we can flag them early?	3	2	2	Predictive model on application features requires ML and sufficient historical decline data.
Document collection	How long is this taking, and where are the delays?	4	4	4	Timestamps on document receipt events are usually captured.
Document collection	Which applications are going to miss settlement targets unless we intervene?	3	2	2	Time-to-completion model requires historical stage timing data and ML capability.
Approval	What is our approval rate, and how does credit performance compare to what we expected?	4	3	3	Approval data is accessible; comparing predicted vs actual default performance requires model monitoring capability.
Approval	Are there applications in the queue we should prioritise or escalate?	4	2	2	Queue prioritisation scoring model adds ML complexity on top of accessible data.
Settlement and funding	What proportion of settlements are on time, and where do delays come from?	4	4	4	Settlement timestamps are core operational data.
Settlement and funding	Which loans in the pipeline are at risk of not settling on time?	3	2	2	Predictive model on pipeline features.
Servicing	How is the book performing by cohort, product, and channel?	5	4	4	Servicing platform data is typically rich and well-structured.
Servicing	Which borrowers are showing early signs of stress before they miss a payment?	3	2	2	Early warning model on behavioural signals requires feature engineering and ML.
Hardship	What proportion of hardship arrangements result in the borrower returning to normal repayments?	4	4	4	Outcome tracking on hardship cases is standard in case management systems.
Hardship	Which borrowers are at risk of entering hardship in the next three months?	2	2	2	Limited behavioural signals available before hardship is declared; model requires data that is often not captured.
Arrears	Which contact approaches are most effective at resolving arrears?	3	3	3	Requires contact activity logged against outcomes — data quality varies by collections team.
Arrears	Which borrowers in arrears are most likely to resolve without escalation, and which need immediate action?	3	2	2	Resolution prediction model on arrears history and borrower features.
Discharge or refinance	How many customers are leaving at refinance and what is the typical timing?	4	4	4	Discharge data is typically well-captured.
Discharge or refinance	Which borrowers are most likely to refinance away in the next six months, and is there an offer that would retain them?	3	2	2	Prepayment prediction plus retention offer optimisation — two model layers.

If your capability scores are dragging down use cases you know are worth building, that is exactly the problem our platform is designed to solve. TrueState gives teams without large ML engineering headcounts the ability to build the predictive and prescriptive use cases that would otherwise sit in the strategic bet column indefinitely.

For teams that have completed this strategy process, we offer free onboarding — usually priced at $35,000. Book a walkthrough to see how it works.