Free · Complete edition

The SEE Framework

Name: The SEE Framework
Author: Court Bluford

Stability, Engagement, Expansion for State Lottery Mobile Apps

By Court Bluford · Updated May 30, 2026

Take the free assessment Get the playbook & workbook

The SEE Framework

Stability, Engagement, Expansion for State Lottery Mobile Apps

Court Bluford · Lissiland LLC · Richmond, Virginia

Take the free assessment · Get the playbook

How to Use This Book

This book is free in digital form. It explains why and what. The workbook scores where you are. The playbook (paid) gives you meeting templates, vendor contract language, and jackpot readiness checklists.

Free quick assessment (12 questions): https://lissiland.com/see-framework/assessment/

Who this is for

Reader	You will learn…
Lottery operator — digital director, product, marketing, compliance, QA	How to govern vendor-delivered apps, enforce the right sequence, and stop funding growth before the foundation holds
Vendor / provider — platform, mobile agency, integrator	How to align roadmaps and contracts to outcomes operators trust, and how to push back when marketing runs ahead of Stability

Many state lotteries run their entire online presence through vendors. That does not mean operators outsource accountability. This book gives both sides shared language.

Operator vs vendor callouts

Throughout this book:

Operator: Guidance for the lottery organization — governance, gates, oversight.

Vendor: Guidance for the delivery partner — evidence, SLAs, roadmap discipline.

The one rule

Stability → Engagement → Expansion

Fix the app. Build the relationship. Then grow.

Everything in this book serves that order.

About the Author

I’m Court Bluford, founder of Lissiland — an independent mobile product consultant based in Richmond, Virginia.

I’ve been building mobile apps since 2008. I’ve been in the state lottery space since 2022, including serving as head of product for a native lottery mobile app. I’ve worked with several state lotteries and their vendors and providers — on both sides of the table.

I’ve sat in the rooms you sit in: sprint planning with a jackpot deadline looming, legal review when an App Store gambling form says your state “can’t legally gamble,” QA sign-off when geolocation works in the lab but fails at the state border, and marketing meetings where everyone wants push notifications tomorrow.

I’ve resolved App Store rejections with promotions already scheduled. I’ve gone through appeals with both Apple and Google — successfully — including work that helped pioneer streaming HTML5 lottery games when Apple allowed them outside the binary. I’ve learned from lottery directors, executives, and heads of QA who’ve been in this industry far longer than I have.

What I can’t do in this book: Name clients or cite their private metrics. I work in this space now and won’t create conflicts. Every story is real; identifying details are changed where needed.

What I can promise: The patterns repeat across states. The order of operations is the same. The politics differ. The principles don’t.

If you’ve ever looked at your lottery app and thought, We’re working hard — so why isn’t this working? — you’re who I wrote this for.

Contact: hello@lissiland.com · Strategy call: https://calendar.app.google/NzxJ6Ny1cCau7jj56?utm_source=lissiland&utm_medium=book&utm_campaign=strategy-call

Chapter 1: The Night the App Said You Weren’t Home

Let me tell you about a kind of failure that doesn’t show up as a crash.

The app opens fine. The UI loads. The user taps to purchase or verify location — and gets a message that they’re not in the state. They are in the state. They’ve been in the state for twenty years. They’re standing in their kitchen. The app just decided otherwise.

Geolocation inconsistency is a Stability problem. It doesn’t always spike your crash rate. It spikes your rage rate — one-star reviews, support calls, abandoned carts, and users who never come back. I’ve seen it break trust faster than a outright crash because the app looks fine while gaslighting the player.

Now combine that with a large jackpot week. Marketing is live. TV, radio, push, paid social. Downloads surge. The site slows. The app slows. Check numbers times out. Wallet deposit works — because money going in is optimized — but withdrawal still takes forever, and support is underwater. ASO hasn’t been touched in a year except version bumps. Push notifications go out generic — “Big jackpot tonight!” — to everyone, including people who opted into scan-only features and now feel spammed.

That’s not bad luck. That’s building in the wrong order.

Operator: You feel this in board meetings when marketing reports downloads and digital reports ticket volume — and neither number matches user sentiment in the store.

Vendor: You feel this when the operator approves a campaign Friday and asks why geo failed Saturday — as if load testing were optional.

What players actually say

These are real App Store review patterns from lottery apps — kept verbatim because they’re more accurate than any slide deck:

“not making an account just to scan tickets. Why is any information needed just to scan a ticket to see if it’s a winner or not? … The primary purpose of this app is to conveniently scan tickets and it doesnt do that without collecting unnecessary data and giving you pretty useless notifcations. literaly pointless … uninstalling” — 1 star

“After years of using this app it is currently not working. Cannot make a purchase. … The location and alarm screen keep popping up and won’t allow me to make a purchase. I can make a deposit but not able to make a purchase. … It appears to be an app issue.” — 1 star (140 people marked this helpful)

The first review is Engagement and product policy — transactional vs relational, scan without friction. The second is Stability — geo, wallet flows, broken purchase path. Both are Stability-first issues from the user’s perspective.

Many users won’t write a review. They just leave. That’s the silent leak.

The $2 million lesson (once, not twice)

A state lottery spends two million dollars on a marketing campaign. Beautiful creative. Perfect targeting. Fifty thousand downloads in week one.

Then twelve percent of those users can’t check numbers during the jackpot draw. The app errors out. One-star reviews. Social posts. Local news picks up “app doesn’t work on biggest night of the year.”

The campaign did more harm than good.

I’ve seen variations of this story in lottery, gaming, travel, and streaming. The industry vertical changes. The sequence mistake doesn’t.

Marketing is not growth if the product fails at peak moment. Marketing is accelerated churn.

In 2026, when a crisis like this hits, the smartest response I’ve seen is build in public: show users you’re listening, fixing, testing, and shipping — over months, not a single apology press release. Turn the crisis into Engagement. But only after Stability stops actively breaking.

Why I’m writing SEE

Most teams skip straight to Expansion — ASO, ads, push, features — while Stability holes bleed users they’ve already paid to acquire.

SEE is the order I wish someone had handed me before I learned it the slow way:

Stability — App works. Geo works. KYC works. Wallet works both directions. Survives jackpot night. Feels native, not a wrapped website.
Engagement — Users feel seen. Feedback loops close. Push is useful. Language matches players, not internal taxonomy.
Expansion — ASO, campaigns, CPP, deeplinks — after the first two.

It’s not clever. It’s uncomfortable — because Stability means pausing features and campaigns people already promised.

That’s the job.

Chapter 2: The Industry Is Wrong (And You Already Know It)

The industry standard says: Build features. Run campaigns. Optimize for downloads.

Your App Store reviews say otherwise.

It’s like throwing a grand opening for a restaurant that hasn’t finished the kitchen. Balloons outside. Line at the door. Then the food never arrives. Hype gets people in. Product keeps them.

The contrarian truth: Your app is your marketing — especially now, when AI makes hype cheap and trust expensive.

Users don’t stay because you had great promo. They stay because scan works, numbers load, purchase completes, and withdrawal doesn’t feel like a black hole.

Fix the leaks. Then pour the water.

Seven obstacles (you’ve met at least three)

1. Building features before Stability — Roadmap full while geo fails at the border.

2. The leaky bucket — Paid users hit broken flows and leave.

3. Transactional, not relational — “Complete task” beats “player feels valued.”

4. Ignoring feedback — “Just one review” until it’s 140 helpful votes.

5. Building for averages — Heavy users love the scanner; roadmap ignores it.

6. Marketing a broken app — Jackpot campaign into a failing check-numbers flow.

7. SEE as a project — Six-month push, then back to feature factory.

Operator: Obstacle 7 shows up when vendor changes or leadership changes — unless SEE is in the contract rhythm.

Vendor: Obstacle 1 shows up when operators fund Expansion SOWs while Stability backlog is open — push back with data, not attitude.

The central question

How do I build a lottery mobile app that works reliably, builds trust, and grows organically — in that order?

Every chapter answers part of that question.

Chapter 3: The SEE Framework and Ten Insights

Three pillars

Stability

Your app works when users need it. No crashes that matter. No geo false negatives. No KYC black holes. Deposit and withdrawal within honest SLAs. Core tasks survive jackpot load. UX feels native on iOS and Android — whether truly native or quality cross-platform.

How you know you have it:

Crash-free sessions ≥ 98%
Geolocation first-attempt success ≥ 95%
Core task completion ≥ 90%
Jackpot load test passed within 30 days of major campaign
Support tickets shift from “broken” to “feature” and “how do I”

Engagement

Users come back because they want to — within responsible gaming constraints. Feedback becomes relationship. Push is segmented and useful. Copy uses Mega Millions, not draw based games.

How you know you have it:

30-day retention ≥ 25% (stretch 40%+ where daily use cases exist)
Three core actions within three taps: scan, check numbers, purchase/jackpot
Reviews mention trust, speed, clarity
Feedback flywheel running weekly

Expansion

People find the app and trust the listing enough to download. ASO is intentional — seasonal, jackpot-aware, honest. Campaigns pass a marketing gate.

How you know you have it:

View-to-download ≥ 20% on branded search
Rating ≥ 4.0 sustained
Custom Product Pages for major draws
Organic share of downloads healthy

Gates between pillars

Gate	Rule
Stability → Engagement	Crash-free ≥ 98% OR Stability workbook score ≥ 60
Engagement → Expansion	Retention not in free fall; core tasks stable; rating not collapsing
Any → Marketing spend	Marketing Gate Checklist (Playbook Template 04) signed
Jackpot campaign	Jackpot Readiness (Playbook Template 03) signed

Operator: Gates are your leverage when vendors say “we need to ship marketing for the draw.”

Vendor: Gates protect your team from blame when campaigns amplify Stability debt.

The leaky bucket formula

Impacted users = New users × % hitting broken flow
Lost users     = Impacted users × Abandonment rate
Lost value     = Lost users × estimated LTV

Example:

10,000 campaign-driven users
12% hit a crash or geo fail early
50% abandon
$50 LTV → $30,000 lost from one broken flow

Fix cost $25,000 → positive ROI before you spend another dollar on ads.

Use this in budget meetings. Operators respect math. Vendors respect operators who bring math.

Cognitive load is Stability

An app that never crashes but exhausts users feels broken.

Cognitive load = mental effort per task. High load: too many decisions, hidden navigation, inconsistent patterns, internal jargon on every screen.

Cognitive Load Score (approximate):

(Decisions per task) × (Screens to complete) × (Information density)
Target: under 5.0 for core flows

For lottery apps, core flows are scan, check numbers, purchase. Count the taps. Count the “wait, where am I?” moments. If scan takes five screens, Stability and Engagement both fail — even with zero crashes.

Ten insights (expanded)

Each insight is a chapter of behavior change — not a bullet on a slide.

Insight 1: Stability comes first. Always.

Reliability beats perfection. Players forgive slow more often than broken — but they forgive neither on jackpot night.

Lottery example: Geo false negatives during purchase — fix before second-chance feature sprint.

This week: List top 10 Stability defects from reviews + support. Fix #1 before any Expansion meeting.

Insight 2: The leaky bucket is math, not metaphor

Every marketing dollar into a broken flow has a measurable waste line. Calculate it before the next campaign.

Operator action: Require Template 04 for spend over your threshold.

Vendor action: Bring the calculation to QBR — proactively.

Insight 3: Engagement is relational, not a feature list

One line on a thank-you screen — We’re here if something doesn’t work — shifts tone from extraction to partnership. Responsible gaming apps can add value through clarity and reliability, not hype.

Transactional scan: “Ticket scanned.”
Relational scan: “Not a winner this time. Saved to your tickets. Next draw Tuesday — want a reminder?”

Insight 4: The 11th experience (Daniel Priestley)

Many users don’t decide an app is useful until roughly the 11th interaction. Priestley’s work popularized this idea. What he doesn’t emphasize: all 11 must be smooth. One geo fail on touchpoint 4 breaks the chain.

Action: Map touchpoints 1–11 for your app. Mark Stability risks on each.

Insight 5: The 7-11-4 rule (Google)

Roughly 7 hours of engagement, 11 touchpoints, 4 locations (app, email, web, social) to build trust for a significant action. For iLottery, “significant action” includes first wallet deposit — not only first download.

Orchestrate channels. One blast email doesn’t replace a broken app.

Insight 6: Outliers beat averages

Heavy users scan daily — that’s your strength. Rare users fail KYC — that’s your blocker. Optimize for edges; the middle follows.

Insight 7: Feedback is free consulting

Weekly triage (Playbook Template 06). Priority = impact × frequency. Close the loop publicly when you fix store-reported bugs.

Insight 8: Trust is built in moments

Trust isn’t a badge. It’s geo working on the first try. Withdrawal completing when you said it would. Scroll feeling like a native app, not a browser tab.

Insight 9: ASO is trust, not keywords

Keywords get you found. Trust gets you downloaded. “Draw based games” finds nobody. “Mega Millions” and “Scan ticket” find humans.

ASO without Stability is lipstick on a broken first session.

Insight 10: SEE is a system, not a project

Monthly review. Quarterly QBR. Gates in contract. Scorecard every quarter. Stop → slide back.

Part 28: The Ten Insights — Expanded for Lottery Mobile

Each insight below includes definition, lottery context, operator guidance, vendor guidance, and a Monday-morning action. These expand the summary in the main text into field-ready depth.

Insight 1: Stability Comes First — Expanded

Definition: Stability is reliable completion of core tasks under real-world conditions—not laboratory conditions, not demo accounts, not executive Wi‑Fi.

Lottery context: Core tasks include scan (where permitted without unnecessary friction), check numbers, geolocation verification, KYC completion, wallet deposit, wallet withdrawal, and game purchase during peak draw traffic. A failure on any one layer poisons perception of the whole app.

Why teams skip it: Stability work is invisible when it succeeds and painfully visible when it fails. Features are easy to announce in press releases. “Geo false negatives down four points on Android 14” is not press-release fodder—but it is player-retention fodder.

Operator: Fund Stability Features as a named roadmap category in board materials. Require vendor proof before Expansion campaigns.

Vendor: Tag every sprint item S/E/X in Jira or equivalent. Escalate when operator requests Expansion work while P1 Stability backlog is open.

Monday action: Pull last thirty days of reviews containing “crash,” “location,” “verify,” “withdraw,” or “slow.” Count. That number is your Stability P0 list seed.

Insight 2: The Leaky Bucket — Expanded

Definition: Acquisition spend multiplied by broken-flow exposure multiplied by abandonment equals measurable waste—not metaphorical waste.

Lottery context: Jackpot campaigns amplify leaks. A geo failure that affects eight percent of users during a fifty-thousand-download push is four thousand people—not eight percent of an abstract cohort.

Operator: Require leaky-bucket calculation on Template 04 before any campaign over your spend threshold.

Vendor: Provide broken-flow exposure rates from analytics, not estimates, in gate meetings.

Monday action: Run the worked example in the Leaky Bucket Formula figure with your last campaign’s real numbers.

Insight 3: Engagement Is Relational — Expanded

Definition: Engagement is the felt experience of being respected by the product—not notification volume, not feature count.

Lottery context: Responsible gaming constraints limit promotional hype. They do not limit clarity, gratitude, status on KYC, or helpful error copy. Relational lottery apps explain what happened and what happens next.

Operator: Audit push notification segments. If one blast list exists, Engagement is immature.

Vendor: Implement segment hooks in notification service before next marketing request.

Monday action: Rewrite one error message in plain language and ship it this week.

Insight 4: The 11th Experience — Expanded

Definition: Habitual product usefulness emerges after repeated smooth interactions—Priestley’s eleventh-experience heuristic applied to lottery mobile.

Lottery context: Touchpoint four is often geo or KYC. Touchpoint seven is often first push opt-in. Touchpoint eleven might be habitual scan-before-work or check-numbers-after-draw ritual.

Operator: Facilitate touchpoint mapping workshop with vendor UX lead.

Vendor: Deliver visual journey map artifact, not only spreadsheet.

Monday action: List touchpoints one through eleven for your app on one whiteboard photo.

Insight 5: The 7-11-4 Rule — Expanded

Definition: Trust for significant action accumulates across time (roughly seven hours), interactions (eleven touchpoints), and places (four locations: app, email, web, social).

Lottery context: First wallet deposit is a significant action. A single TV spot without email follow-up, app deeplink, and store listing trust is one touchpoint pretending to be a campaign.

Operator: Campaign briefs must list four locations and expected touchpoints—not only media buy.

Vendor: Technical deeplink and email template readiness are campaign blockers, not post-launch todos.

Monday action: Pick one upcoming campaign and count current touchpoints honestly.

Insight 6: Focus on Outliers — Expanded

Definition: Heavy users reveal strength; struggling users reveal blockers; the middle follows the edges.

Lottery context: Eighty percent of daily scans from twenty percent of users is common. Roadmap should dominate scanner excellence before adding peripheral features heavy users ignore.

Operator: Ask vendor for cohort analysis quarterly, not only aggregate MAU.

Vendor: Bring outlier charts to QBR pre-read, not only on request.

Monday action: Identify your most-used feature from analytics and one feature nobody uses. Stop funding the second until the first is flawless.

Insight 7: Feedback Is Free Consulting — Expanded

Definition: Public feedback is market research you did not pay for—if you close the loop.

Lottery context: Facebook groups and Reddit threads for state games are unfiltered Stability dashboards. Ignore them and you ignore early warning.

Operator: Assign owner for weekly feedback triage (Template 06)—not “someone in marketing.”

Vendor: Fix + release note + review reply is one workflow, not three departments.

Monday action: Respond publicly to three recent negative reviews with substance, not “contact us.”

Insight 8: Trust Is Built in Moments — Expanded

Definition: Trust accumulates in micro-interactions: scroll physics, button response, honest loading states, withdrawal status visibility.

Lottery context: Web-wrapper scroll that fights the user reads as unofficial even when branding is perfect. Native-feeling interactions read as legitimate public infrastructure.

Operator: Include native quality standard in vendor SOW (Template 08).

Vendor: Demo core flows on lowest supported device in QBR, not only flagship iPhone.

Monday action: Record screen capture of purchase flow on three-year-old Android. Watch without sound. Note every distrust moment.

Insight 9: ASO Is Trust — Expanded

Definition: Store listing is the first product experience—not marketing wallpaper.

Lottery context: Players search game names, not internal product categories. Listings must mirror player language and show trust on screenshot one.

Operator: ASO owner named before next jackpot season.

Vendor: Deliver seasonal CPP assets on same timeline as ad creative.

Monday action: Open your store listing on a phone you do not use daily. Read as a stranger.

Insight 10: SEE Is a System — Expanded

Definition: Systems have calendars, owners, and gates. Projects have end dates and consulting nostalgia.

Lottery context: Vendor transitions, leadership changes, and RFP cycles kill projects. Systems survive via SEE Steward, monthly Template 01, and contract clauses.

Operator: Name SEE Steward in writing with time allocation.

Vendor: Assign counterpart steward and shared dashboard access.

Monday action: Put monthly SEE review on calendar for next twelve months before closing this book.

Chapter 4: Stability — The Lottery Stack

Stability in lottery mobile is not abstract uptime. It is whether a player standing in their kitchen at 9:58 p.m. on a jackpot night can scan a ticket, check numbers, and complete a wallet purchase without being told they are outside the state, without waiting ninety seconds on a spinner, and without wondering if the app is a website wearing a costume.

I’ve learned to evaluate Stability as a stack of layers. When one layer fails, the layer above it cannot compensate. Engagement cannot fix geolocation. Expansion cannot fix withdrawal delays. The stack must hold from the bottom up.

Layer 1: Geolocation and jurisdiction

Geolocation is the silent killer of lottery Stability because it often does not register as a crash. Analytics show a completed session. The user experience is failure. They are in the state. The app disagrees. They retry. They toggle location services. They reboot. They leave a one-star review that a hundred and forty other people mark as helpful.

Geolocation failures cluster at borders, in apartment buildings with weak GPS, on older Android devices, and during handoffs between Wi‑Fi and cellular. They spike when third-party location SDKs update without regression testing. They destroy trust because the app is accusing the player of fraud or incompetence.

What good looks like: First-attempt geolocation success at or above ninety-five percent, measured separately for iOS and Android. False “not in state” rates tracked as a first-class metric, not buried inside “location errors.” Clear copy that explains why location is required and what to do when it fails.

What I do in reviews: Ask for geo success by OS version, by device tier, and by distance from state border. Ask whether QA tests on real devices in real border towns, not only simulators at headquarters.

Operator: Require geo dashboards in vendor QBRs. If the vendor cannot show false-negative rate, they are not measuring Stability.

Vendor: Proactively report geo regressions after SDK or OS updates. Operators should not discover geo failures from Facebook groups.

Layer 2: KYC and identity

Know-your-customer flows are legally necessary for iLottery. They are also Stability killers when manual review queues back up, document upload fails silently, or users loop through the same verification screen three times without status updates.

Automated KYC is not a luxury feature. It is Stability infrastructure. Every hour a user waits in “pending verification” is an hour they tell friends the app does not work. Support tickets labeled “can’t verify” are Stability tickets, not Engagement tickets.

Design principles that hold up:

Show status at every step: submitted, reviewing, approved, needs resubmit.
Never lose uploaded documents on app backgrounding.
Provide human-readable rejection reasons, not codes.
Allow save-and-return without restarting the entire flow.

Operator: Compliance owns policy; digital owns completion rate. Both metrics belong on the same dashboard.

Vendor: Report KYC funnel drop-off weekly during launch windows. A drop at step three is a P1 until explained.

Layer 3: Wallet — deposit fast, withdrawal honest

The fastest way to lose player trust is asymmetric wallet performance. Deposit completes in seconds. Withdrawal takes days with no visibility. Users conclude—reasonably—that the operator wants money in but not money out. Whether fair or not, that perception is a Stability and Engagement catastrophe.

Stability here means predictable SLAs published in plain language, in-app status for pending withdrawals, and error messages when payout rails fail—not infinite spinners. If withdrawal truly takes forty-eight hours for compliance reasons, say so upfront at first deposit. Surprises read as broken.

Operator: Publish withdrawal SLAs internally and externally. Measure variance from SLA as a Stability metric.

Vendor: Do not optimize deposit path at the expense of withdrawal observability. Both are core tasks.

Layer 4: Peak load and jackpot readiness

Large jackpots are your Super Bowl. Every non-lottery app wishes for this kind of intentional traffic spike. Lottery apps that treat jackpot night like any other Tuesday fail publicly.

Load testing is not “we ran JMeter once.” Load testing for lottery means simulating check-numbers volume, wallet transactions, and geolocation calls at multiples of baseline, on production-like infrastructure, with rollback plans and comms templates ready. Playbook Template 03 exists because I’ve seen too many campaigns launch without a signed 72-hour gate.

The marketing acceleration penalty is real: if twelve percent of campaign-driven users hit a broken flow and half abandon, you didn’t gain fifty thousand users. You bought six thousand angry ambassadors.

Operator: No jackpot marketing sign-off without load test evidence. Your brand is on the line, not the vendor’s.

Vendor: Bring load test results to gate meetings before the operator asks. Include p95 latency, not only success/fail.

Layer 5: Native quality versus the web wrapper

Many lottery programs ship hybrid or web-wrapper experiences for speed-to-market reasons. That choice can be valid. What is not valid is leaving players with scroll physics, back-button behavior, and offline handling that scream “mobile website.”

Users do not care about your architecture slide. They care that the app feels like an app. Wrapper debt shows up in reviews as “just use the website” and in Engagement metrics as single-session users who never return.

Remediation does not always mean rewrite everything overnight. It means a named plan with milestones: core tasks native-first, offline caching for check numbers, biometric session restore, platform-appropriate navigation. Stability includes honest UX engineering.

Operator: Ask vendors to demo session-zero on 3G and in airplane mode before renewal.

Vendor: Quantify wrapper debt in roadmap terms. Operators respect honesty more than “hybrid is fine forever.”

Layer 6: Cognitive load

An app that never crashes but requires eight decisions to scan a ticket still fails Stability in the user’s mind. Cognitive load is the mental effort required per task: decisions, screens, unfamiliar labels, inconsistent navigation.

Measure your three core flows—scan, check numbers, purchase—and count taps, decisions, and jargon instances. Target under five on the Cognitive Load Score for each. The three-tap rule is not dogma; it is a forcing function for habit formation on the path to the eleventh experience.

Stability metrics must be visible to both sides with the same definitions:

Metric	Target	Review cadence
Crash-free sessions	≥ 98%	Weekly
Geo first-attempt success	≥ 95%	Weekly
Core task completion	≥ 90%	Weekly
KYC completion (automated path)	Trending up	Weekly
Withdrawal within SLA	≥ 95%	Monthly
P1 open count	Trending down	Daily in launch windows

If operator dashboards and vendor dashboards disagree, believe user reviews first, then reconcile instrumentation.

Thirty days to Stability (summary)

Week one: measure honestly. Week two: triage P1s and schedule load test if jackpot within sixty days. Week three: fix highest impact times frequency. Week four: communicate fixes publicly and schedule monthly SEE review.

The Stability sprint diagram in the main text is your wall poster. Do not hang it unless you intend to run it.

Part 18: Extended Implementation — Stability in Thirty Days

The Big Picture

Most teams are building features while their app crashes or have unknown error messages that some special developer has to look up in his special document. They’re running marketing campaigns while users can’t verify their identity or geolocate within the state. They’re optimizing for downloads while 40% of users abandon after first use.

The industry tells you to “build features, run campaigns, optimize for downloads.” It used to work when there were less options. But in today’s app store? Features don’t matter if your app continually has error messages. Marketing doesn’t work if users can’t complete tasks. Downloads don’t matter if users don’t come back.

What many teams also miss is an app that works but requires too much thinking still feels broken. Users abandon not because it crashes, but because it’s mentally exhausting. Cognitive load, the mental effort required to use your app, is a Stability issue. When users have to think about every action, remember where things are, find too many documents to explore or make too many decisions, they experience the app as unreliable, even if it never crashes.

The Reality Check: We all have experienced products and services that make you think… of all the complaints we have… you added a new feature? Users are telling you exactly what’s broken. They’re leaving reviews. They’re complaining. And you’re building features? Fix what’s broken first. Then build new things.

The Solution: Fix Stability first. Build Engagement second. Focus on Expansion third. Keep the main thing, the main thing.

The Story

Let me paint you a picture.

A streaming app launched a major campaign during a live event. 200,000 downloads in 48 hours. But the app crashed during peak viewing. Users couldn’t watch. Support was overwhelmed. Within a week, 70% of those users were gone.

The campaign cost $500K. The reputation damage? Lasting. The users lost? Permanent.

Here’s what those reviews actually say:

“Downloaded during the big game. App crashed. Couldn’t watch. Uninstalled.” - 1 star

“Waste of time. App doesn’t work.” - 1 star

That campaign? Cost a lot of money, PR nightmare.

But there’s another story. A gambling app never crashed. It worked perfectly. But users had to navigate through five screens to scan a ticket. They had to remember where settings were. They had to make decisions at every step. Users abandoned not because of bugs, but because of cognitive exhaustion. When they redesigned to reduce cognitive load… consistent placement, predictable patterns, muscle-memory navigation… retention increased 40% without fixing a single bug.

The Proof

Apps with crash‑free session rates above ~99.85% tend to earn 4.5★+ ratings, while those slipping toward ~99.7% often sit under 3★. Stability correlates tightly with user satisfaction and app store success.

Crashes and instability drive fast churn, even modest increases in crash rates are associated with sharp drops in retention, higher uninstall rates, and negative reviews that damage visibility and trust.

Fixing stability doesn’t just improve metrics in isolation… it stops you from bleeding users you already paid to acquire. On average retention rates are already low (e.g., ~25–30% Day 1 and under ~6–7% Day 30), so fixing performance holes compounds the benefit of every other improvement you make.

And it’s not just tech, cognitive load matters too. Clean, predictable design helps users complete tasks without friction, which increases meaningful engagement and reduces abandonment. (This aligns with core UX research on usability and task completion.)

The Leaky Bucket Formula:

Impacted Users = Downloads × (% of users exposed to crashes + % of users exposed to error)
Lost Users = Impacted Users × Abandonment Rate
Lost Revenue = Lost Users × Average LTV
ROI = (Lost Revenue - Fix Cost) / Fix Cost

Example:
10,000 downloads
12% of users hit a crash early on → 1,200 impacted
50% abandon the app → 600 lost users
$50 LTV per user → $30,000 in lost revenue
Fixing top 10 bugs = $25,000
→ ROI: 20% gain — just from stability alone.

After introducing the formula, evolve the concept:

Leak size: Your crash rate × abandonment rate × LTV = cost per leak
Cost per hole: Which bugs cost you the most users? Fix those first.
Marketing acceleration penalty: How much faster do you lose users when marketing drives traffic to broken features? Calculate this to justify fixing bugs before marketing.
Penalty Multiplier = New Users from Campaign × % hitting broken flow × Abandonment Rate × LTV

The Stability Score:

Stability Score = (Crash Rate × 0.4) + (Error Rate × 0.3) + (Load Time × 0.3)

Target: Under 2.0

If your score is above 2.0, stop reading. Go fix bugs.

Cognitive Load Score:

Cognitive Load Score = (Number of decisions per task) × (Number of screens to navigate) × (Amount of information to process)

Target: Under 5.0
If above 5.0, you're asking users to think too much.

The Action

You can do this today:

Measure Your Stability Score
- Calculate: (Crash Rate × 0.4) + (Error Rate × 0.3) + (Load Time × 0.3)
- Target: Under 2.0
- If above 2.0, stop reading. Go fix bugs.
Calculate Your Cognitive Load Score
- For your three most frequent tasks, calculate: (Decisions × Screens × Information)
- Target: Under 5.0
- If above 5.0, redesign to reduce thinking required
List Your Top 10 Bugs
- Review crash reports
- Review support tickets
- Review user feedback
- Prioritize by impact and frequency
List Your Top 10 Cognitive Friction Points
- Where do users have to think too much?
- Where do they have to remember where things are?
- Where do they have to make too many decisions?
- Prioritize by impact and frequency
Fix Them
- Start with the highest impact bugs
- Then fix the highest impact cognitive friction points
- Fix them one by one
- Test after each fix
- Measure the results
Calculate Your Leak Size and Marketing Acceleration Penalty
- Leak size: Crash rate × Abandonment rate × LTV = cost per leak
- Cost per hole: Which bugs cost you the most users? Fix those first.
- Marketing acceleration penalty: How much faster do you lose users when marketing drives traffic to broken features?
- Use this to justify fixing bugs before marketing
Don’t Move to Engagement Until Stability Is Fixed
- Crash rate should be under 2%
- Users should be able to complete core tasks
- Cognitive load should be low (users can navigate using muscle memory)
- Support tickets should be mostly feature requests, not “it’s broken”

The Stability Checklist:

Crash rate is under 2%
Users can complete core tasks without errors
App loads in under 3 seconds
App works during peak times (less than 5% performance dip)
Error messages are helpful, not cryptic
App behaves consistently (same experience every time)
Cognitive load is low (users can navigate using muscle memory)
Support tickets are mostly feature requests, not “it’s broken”

The Political Reality: Marketing is measured on downloads, not retention. Your CMO wants to show growth. Your board wants to see numbers. Downloads are visible. Retention is invisible.

The Career Risk: If you say “no” to marketing, you look like you’re blocking growth. If you say “yes” to marketing a broken app, you waste money and damage reputation.

The Organizational Solution: Show the math. Calculate your marketing acceleration penalty… how much faster do you lose users when marketing drives traffic to broken features? Present it as “We can spend $X on marketing now and lose 60% of users, or spend $Y fixing bugs first, then spend $X on marketing and keep 85% of users. Option 2 costs less and delivers more.”

The Action: Calculate your marketing acceleration penalty. Present it as a choice: fast growth with high churn, or slower growth with retention. Show the 12-month revenue difference.

Objection #3: “Our Users Don’t Give Feedback.”

The Reality: Users give feedback all the time. In reviews. In support tickets. In Reddit groups. In Facebook groups. You’re just not listening.

The Truth: Feedback isn’t just data. It’s a relationship. The apps that improve fastest aren’t the ones with the smartest teams. They’re the ones that listen best.

The Solution: Set up feedback collection. Reddit. Facebook groups. Reviews. Support. Categorize it. Prioritize it. Act on it. Close the loop.

The Action: Set up feedback collection from all sources. Categorize feedback (bugs, features, UX issues). Prioritize (Impact × Frequency = Priority). Act on feedback. Close the loop (tell users what you did).

Objection #4: “We Need to Be Good at Everything.”

The Reality: Teams optimize for the average user. They build features that appeal to the middle. Nothing stands out. No one becomes a loyalist. No one becomes an advocate.

The Truth: Outliers reveal what matters. Heavy users show you what they love. Rare users show you what’s blocking them. The middle will follow.

The Solution: Find your core strength. Dominate it. Be mediocre at the rest. That’s how you stand out. That’s how you build virality.

The Action: Analyze your heavy users (what do they love?). Analyze your rare users (what’s blocking them?). Find your core strength. Dominate it. Be mediocre at the rest.

Objection #5: “Our App Store Rating Is Fine. We Don’t Need ASO.”

The Reality: Your app might have a decent rating, but if people can’t find it, it doesn’t matter. And if they find it but don’t trust it enough to download, it doesn’t matter.

The Truth: ASO isn’t just about keywords. It’s about trust. Keywords get you found. Trust gets you downloaded.

The Solution: Audit your ASO. Add trust signals to screenshots. Optimize for conversion, not just search. One screenshot change can be worth $47,000 in the first month.

The Action: Audit your ASO (title, subtitle, description, screenshots). Add trust signals to screenshots. Optimize for conversion. Test different variations.

Objection #6: “We Don’t Have Budget for This.”

The Reality: You’re already spending money. On marketing that doesn’t work. On features users don’t use. On campaigns that drive users to a broken experience.

The Truth: Fixing Stability first actually saves money. You stop losing users you’ve already paid to acquire. The ROI is clear: Fixing top 10 bugs = $25,000. Lost revenue from crashes = $30,000. ROI: 20% return (conservative).

The Solution: Start with Stability. It’s the cheapest fix. Then build Engagement. Then focus on Expansion.

The Action: Calculate your leaky bucket formula. Identify your top bugs. Fix them. Measure the ROI.

Objection #7: “This Won’t Work in Our Industry.”

The Reality: The same problems show up across every industry. Gaming apps. Travel apps. Streaming apps. Ferry reservation apps. Lottery apps. Same problems. Every time.

The Truth: Users are users. And broken apps are broken apps. The industry doesn’t matter. The principles do.

The Solution: Test SEE against your app. If it works, use it. If it doesn’t, ignore it. But the principles are universal.

The Action: Test SEE against your app. Start with Stability. Measure the results. Then move to Engagement. Then Expansion.

Objection #8: “Compliance Says We Can’t Do That.”

The Political Reality: Compliance teams are risk-averse. They say “no” to protect the organization. Your RFP requires specific features. Your regulations limit what you can do. You can’t change the constraints.

The Career Risk: If you fight compliance, you lose. If you accept “no” for everything, nothing improves. You’re stuck.

The Organizational Solution: Reframe SEE within compliance language. “Stability” becomes “reliability requirements.” “Engagement” becomes “user satisfaction metrics.” “Expansion” becomes “responsible growth.” Show how SEE delivers compliance outcomes (user protection, responsible gaming, data security) through user success, not feature checkboxes.

The Action: Translate SEE into compliance language. Show how Stability delivers reliability requirements. Show how Engagement delivers user satisfaction metrics. Show how Expansion delivers responsible growth. Get compliance as an ally, not a blocker.

Objection #9: “Who Owns This? It’s Not in Anyone’s Job Description.”

The Organizational Reality: Product owns features. Engineering owns code. Marketing owns downloads. But who owns the order? Who owns the user journey? Who owns retention? Nobody. It falls between silos.

The Career Risk: If you take ownership, you’re responsible for outcomes you can’t control. If you don’t take ownership, nothing changes. You’re stuck.

The Organizational Solution: Appoint a SEE Steward. Not a project manager. Not a coordinator. A steward. Their job is to ensure the order is followed. They don’t do the work, they ensure the work follows the order. They’re measured on outcomes (retention, trust, growth), not activity (features shipped, campaigns run).

The Action: Create the SEE Steward role. Define it as “Ensures Stability → Engagement → Expansion order is followed. Measured on user outcomes, not activity.” Put it in someone’s job description. Make it permanent.

Objection #10: “This Is Too Simple. We Need Something More Complex.”

The Reality: Most app problems aren’t complicated. They’re just uncomfortable. It’s uncomfortable to pause features and fix bugs. It’s uncomfortable to admit users don’t trust your app. It’s uncomfortable to realize marketing won’t save a broken experience.

The Truth: SEE isn’t magic. It’s not clever. It’s just the right order of operations, learned the slow way, written down so you don’t repeat the same mistakes.

The Solution: Test SEE against your app. If it works, use it. If it doesn’t, ignore it. But simplicity is a feature, not a bug.

The Action: Test SEE against your app. Start with Stability. Measure the results. Then move to Engagement. Then Expansion.

Chapter 5: Engagement — Relational Lottery Apps

Engagement is where lottery apps often confuse compliance constraints with permission to be cold. Responsible gaming limits promotional hype. It does not require you to be transactional. You can be clear, respectful, and relational at the same time.

Relational apps make users feel seen, heard, and helped. Transactional apps extract a task and leave. In lottery mobile, the difference shows up in retention, review adjectives, and whether users disable notifications.

Transactional versus relational — lottery examples

Transactional scan: “Ticket scanned.”

Relational scan: “Not a winner this time. Your ticket is saved. Next draw is Tuesday at eleven—want a reminder?”

Transactional error: “Error 503.”

Relational error: “We couldn’t reach the server. Your ticket is saved locally. Tap retry or check again after the draw.”

Transactional push: “BIG JACKPOT TONIGHT!!!”

Relational push: “Mega Millions drawing in two hours. Your saved numbers are ready to view.”

The relational versions respect time, reduce anxiety, and stay inside responsible messaging. They also increase return visits without dark patterns.

The three-tap rule for lottery

Identify your three highest-frequency player actions. For most lottery apps they are scan ticket, check numbers, and purchase or view jackpot information. Each must be reachable within three taps or gestures from a cold start after onboarding.

Map the taps honestly, including permission dialogs that appear every time. A geo prompt on every purchase is a tap tax that destroys Engagement over months.

Operator: Validate tap maps with real players, not internal staff who know where settings hide.

Vendor: Propose tap reductions in sprint planning with before/after diagrams. Easier to approve than abstract “UX improvements.”

Language is Engagement

Internal product language is built for RFPs and compliance docs: draw-based games, instants, einstants, geolocation verification, second-chance promotions. Player language is Mega Millions, Powerball, Scratch Tickets, Online Games, Confirm you’re in [State], enter to win again.

Every screen, push, email, and store listing line is Engagement. Jargon reads as talking down. Plain language reads as respect—especially for public-sector lottery brands.

Run a jargon audit on your top ten screens. Count how many labels require insider knowledge. Replace or explain every instance.

Mapping the eleventh experience

Daniel Priestley’s eleventh-experience concept is useful for lottery: habit forms after repeated smooth interactions. Map touchpoints one through eleven from download through habitual use. Mark Stability risks on each. One geolocation failure at touchpoint four breaks the chain before habit can form.

Typical lottery touchpoints: download, first open, first scan, email confirmation, second scan, check numbers, push opt-in, jackpot check, first wallet deposit, second purchase, referral or review. Not every app has all eleven; your map will differ. The exercise is the point.

Google’s 7-11-4 heuristic complements this: roughly seven hours of engagement across eleven touchpoints in four locations—app, email, web, social—to build trust for a significant action. In iLottery, first wallet deposit is that significant action. Orchestrate channels; do not blast one channel and call it Engagement.

Push notifications — useful versus spam

Everyone wants push for marketing. Few teams invest in segmentation. Scan-only users receive jackpot blasts. iLottery users receive irrelevant retail messages. Users disable notifications entirely, and you lose draw results and win alerts with the spam.

Segment at minimum: scan-only, retail-info, iLottery active, lapsed iLottery. Match copy to segment. Measure opt-out rate per campaign, not only open rate.

Operator: Push strategy is policy. Marketing and digital co-own segmentation rules.

Vendor: Implement technical segmentation; do not wait for marketing to define audiences in code comments.

Feedback flywheel — weekly discipline

Collect from stores, support, Reddit, Facebook groups, and in-app. Categorize: Stability, Engagement, Expansion. Prioritize by impact times frequency. Act. Close the loop in public review responses when fixes ship.

The worst pattern I see: PR teams responding “message us privately” to public failures. Public problems deserve public fixes. When you resolve geo failures, say so in release notes and review replies. Future users read those threads before downloading.

Responsible gaming as Engagement ally

Responsible gaming features—limits, reality checks, self-exclusion links—are not Engagement enemies when implemented clearly. Hidden limits feel sneaky. Visible, plain-language controls build trust with regulators and players.

Engagement within RG constraints means clarity, reliability, and helpfulness—not slot-machine psychology copied from Vegas apps your players never asked for.

Engagement metrics that matter

Metric	Lottery baseline	Stretch
30-day retention	≥ 25%	≥ 40% daily-use features
Core task completion	≥ 90%	≥ 95%
Session quality	Depth, not vanity opens	Tasks completed per session
Review adjectives	trust, fast, easy	love, reliable
Push opt-out rate	Declining	Stable per segment

Do not fund Expansion to fix declining retention without Stability audit first.

Part 19: Extended Implementation — Engagement Playbook

The Big Picture

This is your operational playbook for building Engagement. Not philosophy. Not theory. Tactics you can implement this week.

The Operational Framework:

Map your user journey (all 11 touchpoints)
Identify relationship moments (where can you add value?)
Build feedback loops (how do you know it’s working?)
Measure outcomes (not activity)
Reduce friction through the three-tap rule (key actions must be accessible within three taps or gestures)

The three-tap rule isn’t about counting taps. It’s about optimizing for the most frequent actions. For lottery apps… scanning a ticket (1 tap), checking numbers (2 taps), making a purchase/checking a jackpot (3 taps). Everything else can take longer, but these three must be instant. Every tap beyond three is friction that breaks the relationship-building chain. If users can’t reach key actions quickly, they won’t make it to the 11th experience where they recognize your app’s value.

The Story

A gambling app mapped their user journey through the early lifecycle: download → first scan → email → second scan → check numbers → social post → third scan → in-app notification → website visit → jackpot check → first purchase. They identified relationship moments: after first scan (thank-you message), after check numbers (status update), after feedback (response). They added simple elements at each moment. Retention improved significantly. Not because of features. Because of operationalizing relationships.

The principle? Every touchpoint is an opportunity to build trust. Map your journey. Find the moments where you can add value. Then operationalize them.

But then what does “add value” mean?

Instead of just completing a transaction (scan ticket, check numbers, purchase), you make users feel:

Seen: Acknowledge their action with a simple thank-you or confirmation
Heard: Respond to feedback, even if you can’t fix it immediately
Helped: Provide useful information (jackpot updates, draw times, responsible gaming resources) without being asked
Valued: Show you care about their success, not just their transaction

Lets talk through some actual examples. Because when I first heard “add value” it meant absolutely nothing to me.

Transactional (no value added):

User scans ticket → App shows “Ticket scanned” → Done
User scans ticket → App shows “Not a winner” → Done
User checks numbers → App shows results → Done
User makes purchase → App shows confirmation → Done or worse is offers them an add-on

Relational (value added):

User scans ticket → App shows “Ticket scanned. We’ll notify you if you win.” → Value: Sets expectation, reduces anxiety
User scans ticket → App shows “Not a winner this time. Your ticket is saved. Want to turn this into a digital playslip for the next draw on [date/time]?” → Value: Acknowledges the result, removes friction from re-entering numbers, and smoothly carries intent forward into the next draw without forcing the user to decide now.
User scans ticket → App shows “Congratulations! You won $X. Your ticket is saved. Next steps: [claim instructions based on prize amount]. Questions? We’re here to help.” → Value: Celebrates the win, provides clear next steps, reduces claim anxiety, offers support
User checks numbers → App shows results + “Next draw in 2 days. Set a reminder?” → Value: Proactive help, not just data
User makes purchase → App shows confirmation + “Your ticket is saved. Check anytime.” → Value: Reassurance, reduces support burden
After error → App shows “Something went wrong. Here’s how to fix it.” → Value: Helpful guidance, not just an error code
After feedback → App responds “We heard you. Here’s what we’re doing.” → Value: Shows you’re listening

The key difference is transactional apps extract value (complete task, leave). Relational apps add value (complete task, feel better about the experience, want to come back). For state lotteries specifically, this works within responsible gaming constraints… you’re adding value through clarity, reliability, and helpfulness, not through promotional tactics.

The Language Problem in Engagement:

But here’s what breaks engagement: You’re using language your users don’t recognize.

When you say “draw based games,” users think “What’s that?” When you say “Mega Millions,” they know exactly what you mean.

When you say “instants” or “einstants,” users are confused. When you say “Online Games” and “Scratch Tickets,” they understand.

Every touchpoint—every email, every notification, every screen—is an opportunity to speak their language. When you do, they feel understood. When you don’t, they feel talked down to.

The Operational Example:

The Martha’s Vineyard Ferries app sees strong summer engagement. Not because it’s flashy. Because it’s reliable. We mapped every touchpoint. Email confirmations. Push notifications. Real-time updates. Status changes. Each one is a relationship moment. Each one is operationalized. That’s the playbook.

The principle:

Reliability creates relationships. When users know they can count on you, they come back. Map your touchpoints. Operationalize each one. That’s how you build trust that compounds.

The Facts

The Proof: Apps that incorporate relationship or social elements tend to see higher engagement. When users feel connected… to other people, creators, or a community… they return more often, spend longer in sessions, and are more likely to leave positive reviews.

Apps that deliver a smooth, reliable early experience retain users far better than those with bugs or performance issues. Early failures strongly increase abandonment, while stable experiences help turn new users into regulars. The first handful of interactions are especially important in shaping long-term behavior.

Apps that make key actions quick and easy to reach achieve higher task completion and lower drop-off. Reducing friction… such as minimizing taps or steps—helps users feel confident, move faster, and stay engaged.

The 7-11-4 Rule:

Google’s consumer research found that a potential customer needs about 7 hours of engagement, across 11 distinct touchpoints, within 4 different locations, to build enough trust to make a significant purchase.

The Engagement Metrics:

30-day retention: Target 25%+ (for lottery apps)
Session length: Target 3+ minutes
Task completion: Target 80%+
Key actions accessible within 3 taps: Should be yes
Users come back voluntarily: Should be yes
Reviews mention trust, reliability, or value: Should be yes

The Action

The Operational Playbook (This Month):

Map Your User Journey (Week 1-2)
- List all 11 touchpoints (download through 11th experience)
- Identify relationship moments (where can you add value?)
- Document current state (what happens at each moment?)
- Create a journey map (visual or spreadsheet)
- Apply the three-tap rule: Identify your three most frequent actions. Count the taps/gestures to reach each. If any exceed three, redesign the path.
Identify Relationship Opportunities (Week 3-4)
- After first use: Thank-you message?
- After feedback: Response?
- After error: Helpful guidance?
- After success: Celebration?
- List 5 relationship moments you can add this week
- Optimize key action paths: Ensure scanning, checking numbers, and purchasing are all within three taps
Build Feedback Loops (Month 2)
- How do you know relationships are working?
- Track: Support ticket tone (complaints → feedback?)
- Track: Review sentiment (negative → neutral/positive?)
- Track: Return rate (users coming back voluntarily?)
- Track: Task completion time (are key actions getting faster?)
Implement One Relationship Element (This Month)
- Pick the easiest relationship moment
- Add it (thank-you message, status update, proactive help)
- Measure: Does support ticket tone change? Do reviews improve?
- Iterate: What works? What doesn’t?
Operationalize the 11 Touchpoints
- Mobile app: What relationship moments exist?
- Email: How do you add value, not just ask for something?
- Social media: How do you engage, not just broadcast?
- Website: How do you help, not just sell?
- Create a touchpoint matrix: What happens at each moment?
- Reduce cognitive load: Ensure each touchpoint requires minimal thinking. Users should navigate using muscle memory, not active decision-making.
Implement Gradual Training for Major Changes
- Don’t remove friction all at once
- Introduce changes in steps
- Let users adapt to each change before introducing the next
- Make transitions feel inevitable, not disruptive

The Engagement Checklist:

30-day retention is 25%+ (lottery apps)
Users come back voluntarily
Session length is 3+ minutes
Task completion is 80%+
Key actions are accessible within 3 taps
Users recommend the app
Positive review sentiment
Support tickets decrease over time

Chapter 6: Expansion — ASO That Converts

Expansion is where lottery programs leave the most money on the table because ASO is treated as a version-number update chore instead of a trust-building product surface.

Keywords get you found. Trust gets you downloaded. A player who finds your listing during a jackpot week and sees jargon-filled screenshots of a broken-looking UI will not install—even if you rank first.

The ASO trust stack

Icon: Recognizable at small size. Official without looking like a seal thrown in a blender.

Title and subtitle: Player actions and game names, not internal product taxonomy.

Screenshot one: Problem, solution, trust signal—official branding, scan action, player count if truthful, security cues appropriate to your jurisdiction.

Subsequent screenshots: Story flow, not feature vomit. Show check numbers, scan, responsible play resources where required.

Description: Keyword-rich but human. Say Mega Millions and Powerball. Say Scratch Tickets and Online Games.

Custom Product Pages: Jackpot-specific destinations for paid and owned media. If you run a Powerball campaign without a Powerball CPP, you are sending traffic to a generic landing experience inside the store.

Seasonal and jackpot ASO

Jackpot seasons change search behavior. Update screenshots, CPP, and promotional text before the draw, not after peak. Assign an owner. Put it on the marketing calendar next to TV buys.

Operator: ASO updates are campaign deliverables, not “when IT gets to it.”

Vendor: Propose seasonal ASO packs as a productized line item in SOW renewals.

Deeplinks and campaign alignment

Campaign without deeplink sends users to home screen. Campaign with deeplink sends users to check numbers, specific game, or scan. Test deferred deeplinks on iOS and Android before Marketing Gate sign-off.

Competitor audit — quarterly

Pick three peer lottery apps in other states. Compare screenshot one, subtitle, rating trend, and review themes. You are not copying features. You are benchmarking trust signals and player language.

Conversion metrics

Metric	Target
View-to-download (branded search)	≥ 20%
Impression-to-view	Trending up with seasonal updates
Rating	≥ 4.0 sustained
CPP conversion vs default	CPP should win or tie

ASO without Stability is lipstick. If reviews say “doesn’t work,” fix the app before buying search ads.

Hidden keywords and visual polish

Teams debate hidden keyword tactics in screenshot backgrounds. Reasonable people disagree. What is not debatable is visual polish: consistent spacing, legible type, screenshots that look designed—not exported from a staging build at midnight.

Mathematical harmony sounds abstract until you watch a user choose between your listing and a competitor’s based on which “feels official.” Brains read polish as care.

Expansion completes the SEE sequence. It does not replace it.

Part 20: Extended Implementation — Expansion and ASO

The Big Picture

Most teams think ASO is about keywords. They optimize for search. They pack descriptions with jargon. They focus on downloads. Keywords DO get you found. But TRUST gets you downloaded.

ASO isn’t just about showing up in search. It’s about showing up in a way that builds trust.

But here’s what most teams miss: Language is the most important piece of Expansion and Engagement. Your copywriter doesn’t need to write good copy. They need to speak the same language as your users.

The Language Problem:

You can have the best copy according to internal folks. But your users are reading and scratching their head at all the jargon that means nothing to them.

“Draw based games” is NOT the same as “Large jackpots” or “Mega Millions” or “Powerball.” To us internally, it is. To users, they just know game names and scratch tickets. Some don’t even know scratchers used to be called instants. So I can assure you there is no confusion between “einstants” and “instants.” Just call them “Online Games” and “Scratch Tickets.”

We all hate people that turn casual conversation into big word jargon or using multi-syllable words… basically talking down to us, but using big words.

The Solution:

Speak like your users speak. Use the words they use. Not the words your internal team uses.

“Draw based games” → “Mega Millions” or “Powerball” or “Large jackpots”
“Instants” or “einstants” → “Online Games” and “Scratch Tickets”
“Second chance promotions” → “Enter to win again”
“Geolocation verification” → “Confirm you’re in [State]”

When users see language they recognize, they trust you. When they see jargon, they leave.

But trust isn’t just about security badges and user counts. It’s also built through visual harmony. Mathematical relationships… consistent spacing, harmonious proportions, smooth curves… create a subconscious sense of quality. When interfaces feel “polished” rather than “cheap,” users equate that with reliability. The brain recognizes mathematical precision as a signal of care and attention to detail.

The Reality Check: The website is hard to navigate but you want me to trust your app experience? And imagine when they do take your word that the app is a better experience, to only find it being a web wrapper of your mobile website. Trust is built across all touchpoints. If your website is broken, why should users trust your app? If your app is just a web wrapper, why should users download it? Consistency builds trust. Broken experiences break trust.

The Story

A gambling app was struggling with discoverability. Good keywords. Showing up in search. But conversion was low. Users would view the app listing, then leave without downloading.

The screenshots were clean. Professional. But they didn’t answer the question users were asking: “Can I trust this?”

So they changed 4 screenshots, the first one users see, to show trust signals. Security badges, user count (“Used by 500,000+ players”), recent wins.

That’s it. 4 screenshots. Three trust signals.

The result: Conversion from view to download increased. At their average revenue per download, that one screenshot change was worth $220,000 in the first month.

That’s the power of trust signals.

What mattered more is the users who downloaded were better quality. They completed more purchases. They came back more often. They left better reviews.

But they also redesigned their app icon and screenshots to use mathematical harmony—consistent spacing, harmonious proportions, smooth rounded corners (squircles rather than basic rounded rectangles). The visual polish increased perceived quality, which increased trust, which increased downloads.

The Facts

Maintaining at least a 4.0★ rating is generally a minimum goal for expansion and user acquisition. Below about 4 stars, an app may deter many potential downloaders. Across all iOS apps, the average rating is about 4.6★ (on Google Play it’s a bit lower at ~4.2★). Apps consistently rated 4.5★+ tend to be extremely stable and user-approved.

Apps that use mathematical harmony in their visual design (consistent spacing, harmonious proportions, mathematical precision) see 15% higher perceived quality scores, which correlates with higher download conversion rates.

The ASO Score:

ASO Score = (Search Visibility × 0.3) + (Trust Signals × 0.4) + (Conversion Rate × 0.3)

Search Visibility = Do you show up in search?
Trust Signals = Do users trust you?
Conversion Rate = Do users download when they see you?

Target: Above 3.5

The Expansion Metrics:

Search visibility: Target top 10 for primary keywords
Conversion rate: Target above 20%
Organic growth: Target 60%+ organic downloads
App Store rating: Target above 4.0
Review quality: Should mention trust, reliability, or value

The Action

You can do this today:

Audit Your Current ASO
- Review: Title, subtitle, description, screenshots, icon, keywords
- Compare to top competitors
- Identify your biggest opportunities
- Check: Is your subtitle the largest piece? Is it packed with features and actions?
Optimize Your Title and Subtitle
- Title: App name + actions/features (e.g., “State Lottery App: Rewards and Scan”)
- Subtitle: Focus strictly on features and actions (largest piece of the puzzle)
- Make sure subtitle fits character limits
- Pack subtitle with keywords you want to capitalize on
Optimize Your Screenshots
- Tell a story: Problem → Solution → Outcome
- Include trust signals (security, official, user count)
- Apply mathematical harmony: Use consistent spacing, harmonious proportions, smooth curves
- Add hidden keywords in the same color as background (AI recognizes them, users don’t)
- Use keywords/tags for harder-to-reach keywords
- Test different variations
Optimize Your Description
- Use the language your users use, not internal jargon
- Say “Mega Millions” and “Powerball,” not “draw based games”
- Say “Online Games” and “Scratch Tickets,” not “instants” or “einstants”
- Pack it with features and actions users actually search for
- This is where you can be more keyword-heavy than title or subtitle, but use user language, not industry jargon
Improve Your Reviews
- Respond to negative reviews
- Fix issues users complain about
- Make it easy for satisfied users to leave reviews
Set Up Deeplinking
- Choose a deeplinking solution (AppsFlyer, Branch.io, or custom)
- Set up regular deeplinks for installed users
- Set up deferred deeplinks for new users
- Create Custom Product Pages for campaigns (jackpot-specific pages)
- Test: Do links take users directly to games/actions?
Apply Mathematical Harmony to Visual Design
- Use consistent spacing (8px or 16px grid)
- Apply harmonious proportions (golden ratio where appropriate)
- Use smooth curves (squircles for rounded corners rather than basic rounded rectangles)
- Ensure visual polish creates subconscious sense of quality

The Expansion Checklist:

Chapter 7: Feedback Systems

The Big Picture

Feedback isn’t just data. It’s a relationship. The apps that improve fastest aren’t the ones with the smartest teams. They’re the ones that listen best.

Users give feedback → You act on it → Users see you’re listening → They give more feedback → You improve faster → Users trust you more → They use the app more → They give more feedback.

That’s the feedback flywheel.

A lottery app has hundreds of valuable pieces of feedback at any week, doing nothing. Don’t think one review doesn’t matter. Feedback is intelligence. It’s free consulting. It’s your roadmap.

Systematize it. Set up feedback collection from all sources. Reddit. Facebook groups. Reviews. Support. Categorized it. Prioritized it. Acted on it. Closed the loop. Your app ratings will improved from 2s and 3’s to 4 stars within 18 months. Make sure you also respond back to the lower rated reviews that speak to the issue that you now have fixed. It can be tedius but truly valuable. Not just for the user that left the comment but for future users that come across it.

It is truly important that users see you are listening. They will provide more feedback. Then they became advocates.

The One-Star Review Formula:

Every one-star review is a gift. It tells you exactly what’s broken. It tells you what users care about. It tells you what to fix.

Here’s the formula:

Read the review
Identify the core problem
Fix it
Respond to the review
Close the loop

That’s how you turn complaints into connection.

The Reality Check: The worst thing I continue to see PR folks acting as if they aren’t real people is telling people to message them with their issue. NO. Respond with the fix if it can be public. So others can fix it as well. When users complain publicly, respond publicly. When you fix something, announce it publicly. Don’t hide behind “message us privately.” Be transparent. Show you’re listening. Show you’re fixing things. That’s how you build trust.

The Facts

The Proof: Apps that build feedback flywheels see:

Ratings improve from 2.8 to 4.5 stars within 18 months
Retention increases 40%
Support tickets decrease 60%
Users give better feedback
They become advocates

The Feedback Flywheel Formula:

Feedback → Action → Trust → More Feedback → Faster Improvement

This compounds. Each cycle makes the next cycle stronger.

Where Feedback Lives:

App Store reviews
Google Play reviews
Support tickets
Reddit groups
Facebook groups
Twitter/X
Email feedback
In-app feedback

The Action

You can do this today:

Set Up Feedback Collection
- App Store reviews
- Google Play reviews
- Support tickets
- Reddit groups
- Facebook groups
- Twitter/X
- Email feedback
- In-app feedback
Build the Feedback Flywheel
- Set up: Collect → Categorize → Prioritize → Act → Close the Loop
- Assign owners for each step
- Measure: Time from feedback to action
- Include Reddit and Facebook groups in your collection system
Run a Feedback Deep Dive
- Gather all feedback from the last 30 days (including Reddit/Facebook groups)
- Identify patterns and opportunities
- Create an action plan
- Prioritize: What are users complaining about most in groups? Fix that first.
Analyze Feedback by Outliers, Not Averages
- Segment feedback by rare users (low engagement): What’s blocking them? What’s confusing?
- Segment feedback by heavy users (high engagement): What do they love? What can’t they live without?
- Fix what blocks rare users. Amplify what heavy users love.
- Remember: The middle will follow. Focus on the edges, not the middle.
Use the One-Star Review Formula
- Read the review
- Identify the core problem
- Fix it
- Respond to the review
- Close the loop
Align Vendor Incentives
- Review your vendor contract: What are you paying for? Hours or outcomes?
- Add stability metrics to vendor performance reviews (crash rate, error rate, task completion)
- Create a separate budget line for stability work
- Make feedback response time a KPI (time from feedback to fix)
- Share user feedback (positive and negative) directly with the development team
- Include stability wins in vendor showcases and case studies
- Reframe bug fixes as portfolio wins, not technical debt

The Feedback Checklist:

Feedback collection set up from all sources
Feedback categorized (bugs, features, UX issues)
Feedback prioritized (Impact × Frequency = Priority)
Feedback acted on
Loop closed (users told what you did)
Reddit and Facebook groups monitored
One-star reviews responded to
Vendor incentives aligned with user outcomes
Stability metrics included in vendor performance reviews

Chapter 8: Operating SEE — Operators, Vendors, and Rhythm

SEE Steward

One named person ensures sequence — operator side, vendor side, or co-owned with documented RACI.

Measured on: crash rate, retention, rating, conversion — not features shipped.

Runs: Template 01 monthly, Template 02 quarterly.

When the vendor runs everything

Use Template 09 — Operator Oversight Checklist.

You still own:

Marketing gate sign-off
Jackpot readiness sign-off
Contract SLAs (Template 08)
Honest monthly score comparison

Red flag: Vendor dashboards green, reviews red — believe reviews first, then reconcile data.

Vendor contract essentials (Template 08 summary)

Numeric Stability SLAs (crash-free, geo, P1 time)
Roadmap tagged S / E / X
Stability sprint capacity when P1 open
Marketing gate for spend over threshold
Jackpot load test mandatory
Weekly feedback triage
Native quality standard
App Store rejection notification SLA

Operator: If it’s not in the SOW, you can’t govern it.

Vendor: If SLAs are impossible, renegotiate before signing — not after jackpot failure.

Compliance as ally

Reframe SEE in compliance language:

SEE pillar	Compliance frame
Stability	Reliability, player protection, geo integrity
Engagement	Responsible communication, transparent UX
Expansion	Responsible growth, honest advertising

Compliance teams say no to risk. SHOW them Stability reduces regulatory and reputational risk — faster than feature checklists.

Budget filter

Every major spend through Template 10 — Stability, Engagement, or Expansion classified honestly. Defer Expansion when Stability < 60. Show leaky-bucket math for marketing.

Part 13: The Vendor Partnership Playbook

When a state lottery runs digital entirely through a vendor, two failure modes appear repeatedly. Operators abdicate accountability because “that’s the vendor’s job.” Vendors optimize for contract deliverables—features shipped, hours billed—instead of player outcomes. SEE exists to give both sides shared language and gates that align incentives.

I have sat on both sides. The best partnerships feel like one team with two org charts. The worst feel like email volleyball during a jackpot outage.

When the vendor runs everything

Operators still own:

Brand and public trust
Marketing gate sign-off before major spend
Compliance language and responsible gaming posture
Contract SLAs with numeric Stability targets
Jackpot readiness approval
Quarterly outcome QBR attendance by an executive sponsor

Vendors still own:

Delivery evidence: dashboards, load tests, release notes
Weekly feedback triage summaries
Roadmap tagging: Stability, Engagement, Expansion
Honest escalation when operator requests bypass gates

Neither side owns “hope.”

QBR structure that works

Quarterly business reviews fail when they are feature demos. They succeed when they start from an outcome scorecard:

Crash-free sessions versus target
Geo first-attempt success
Core task completion
30-day retention trend
Store rating and review themes
Marketing campaigns run and whether gates were signed

Then discuss roadmap through SEE filters. Defer Expansion spend if Stability SLAs missed two consecutive months.

Playbook Template 02 is the agenda. Use it verbatim until you outgrow it.

SOW clauses that change behavior

Summary of Template 08—full language in the Playbook:

Numeric Stability SLAs with remedies
SEE Steward participation monthly
Roadmap items tagged S/E/X; operator deferral rights when Stability breached
Minimum sprint capacity for Stability when P1 open
Marketing gate for campaigns over threshold
Jackpot load test mandatory
Weekly feedback triage
App Store rejection notification within two hours
Native quality standard for core tasks

Operator: If it is not in the SOW, you cannot govern it—only negotiate about it after failure.

Vendor: If SLAs are unachievable with current architecture, renegotiate before signing, not after jackpot night.

Escalation without politics

Escalate with data: crash rate chart, geo false-negative examples, review quotes, leaky-bucket dollar estimate. Avoid adjectives without numbers. “Users are angry” is true; “geo false negatives up four points since release 4.2 on Android 14” is actionable.

Renewal preparation — ninety days out

Build a term scorecard: which SLAs met, which failed, review theme trends, Stability sprint history, operator satisfaction with gates. Bring proposed SEE clauses for next term. Vendors who bring this first win renewals.

Operator oversight without micromanaging code

Template 09 is the monthly operator-only honest review: Are we funding features while geo is broken? Do our reviews match vendor dashboards? Did marketing launch without our gate sign-off?

You do not need to read pull requests. You need to read player reality.

Part 16: Monthly Operating Rhythm

SEE dies when treated as a six-month initiative. It lives when it becomes calendar infrastructure.

SEE Steward role

One named person ensures sequence—operator side, vendor side, or co-owned with written RACI. Measured on outcomes: crash rate, retention, rating, conversion—not features shipped.

Steward runs Template 01 monthly and ensures Template 02 quarterly happens with pre-read data.

Monthly SEE review — sixty minutes

Agenda: score snapshot, Stability metrics, Engagement themes, Expansion only if gates open, gate decisions for next month, three assigned actions with owners.

No slide decks longer than the metrics dashboard. If a meeting needs forty slides, metrics are not trusted.

Quarterly workbook scoring

Full workbook (paid print/digital from lissiland.com/see-framework/shop/) or internal copy. Operator and vendor score separately, then align gaps. Trends matter more than absolute numbers quarter one.

Free twelve-question assessment online is the teaser; quarterly full scorecard is the operating system.

Budget filter on every major spend

Template 10 for any feature, marketing, or redesign request over your threshold. Forces honest S/E/X classification and leaky-bucket math for campaigns.

Building culture

Leadership models sequence publicly: “We are pausing ASO spend until geo holds above target.” Celebrate Stability wins in all-hands: “Withdrawal SLA met three months running.” Reframe bug fixes as player-facing reliability features in board decks.

Culture is what happens when the consultant leaves. SEE Steward plus calendar beats consultant forever.

Part 22: Extended Implementation — Operationalizing SEE

The Big Picture

Teams implement SEE for 6-12 months. They see improvements. Then they stop. Improvements slide back. They’re back where they started.

Projects have end dates. Systems don’t. But SEE is a system, not a project.

Implementation is a project. Operationalization is a culture. That’s the difference between short-term results and long-term success. It’s your advantage. When SEE is second nature, you don’t just follow best practices… you create them.

The Action

You can do this today:

Assess Your Current SEE Maturity
- Decide: are you treating SEE as project or process?
- Identify gaps between implementation and operationalization
- Map current decision-making to SEE opportunities
Build Your SEE Operating System
- Appoint a SEE Steward
- Launch monthly reviews and quarterly assessments
- Train teams on the SEE decision filter
Embed SEE in Organizational DNA
- Roll out SEE training at every level
- Bake SEE into all vendor and partner agreements
- Build culture with leadership modeling and shared success stories
Use SEE as a Decision Filter
- Every decision should pass the SEE test
- Does it strengthen Stability?
- Does it build Engagement?
- Does it grow Expansion?
- If it doesn’t, question it
Make It Permanent
- SEE is a system, not a project
- Build it into your rhythm
- Train teams
- Make it culture

The Operationalization Checklist:

Chapter 9: App Store and Compliance Battles

App Store rejection with a promotion deadline is a Stability event that blocks Expansion. In lottery mobile, rejections cluster in predictable categories. Process beats panic.

Rejection categories I see repeatedly

Gambling and lottery classification: Forms that misstate what a state permits. Metadata that triggers manual review. Fix: legal review of form answers against actual permitted activities—draw games, iLottery, scan-only, second-chance— with plain-language appendix for reviewers.

Geolocation and location permission: Copy that sounds surveillance-y. Missing demo instructions for reviewers. Fix: permission strings in player language; test account and location steps in review notes.

Wallet and in-app purchase: Confusion about what is sold where. Fix: architecture diagram for reviewers showing payment rails.

HTML5 and streaming games: Questions about games delivered outside the binary when Apple policy allows streaming models. Fix: technical summary, precedent references, video walkthrough of compliant implementation. I was involved in early industry work when HTML5 streaming became viable for lottery content—documentation and patience won approvals that “just resubmit” would not.

Metadata-only: Screenshots or descriptions. Fastest path if binary is fine.

Playbook Template 05 is the hour-by-hour playbook.

Appeals that succeed

Successful appeals combine legal clarity, technical evidence, and reviewer empathy. “We disagree” loses. “Here is what our state permits under statute X; here is how the app implements it; here are test steps; here is our contact for a call” wins more often.

Maintain a rejection library by guideline section. Lottery apps hit the same walls; reuse winning language without client-confidential appendices.

Legal coordination

Loop legal early—not after the third rejection. Compliance is ally when framed as risk reduction: accurate forms, accurate screenshots, accurate descriptions reduce regulatory and store risk simultaneously.

Operator: Give legal a seat at store submission calendar, not only at policy drafting.

Vendor: Never surprise the operator with a rejection hours before a campaign. Two-hour notification SLA is reasonable.

Promotion deadline triage

Time left	Action
> 48h	Standard resubmit + appeal package
24–48h	Exec alignment; explore metadata-only path
< 24h	War room; delay campaign contingency; public comms draft
< 6h	Go/no-go on paid media; protect brand over arbitrary launch date

Sometimes the bravest call is delaying a campaign one week to fix Stability. Sometimes the bravest call is shipping a metadata fix in six hours. Judgment beats heroics.

Chapter 10: Case Patterns (Anonymized)

These four patterns appear across states with different vendors and different tech stacks. Names are changed; dynamics are real.

Pattern A: The geo crisis

Situation: Mid-sized state lottery relaunched iLottery module after vendor platform upgrade. Geo false negatives jumped from three percent to eleven percent on Android within a week.

Symptoms: Reviews mentioning “I’m in [state]!” Support flooded. Conversion on purchase funnel collapsed on Samsung devices.

Root cause: SDK update plus stricter timeout on cellular handoff—not malicious, not incompetent, untested on real border corridors.

SEE response: Stability sprint. Paused Expansion ads. Weekly geo dashboard shared operator-side. Fix shipped in twelve days. Public review responses on fixed versions.

Outcome: Geo rate restored. Marketing gate reinstated with mandatory Android device matrix in load checklist.

Lesson: Geo is Stability layer one. Upgrade regression tests belong in Definition of Done.

Pattern B: Jackpot campaign into a slow app

Situation: Large jackpot. Multi-million-dollar marketing push. Downloads spiked. Check-numbers API p95 latency tripled. Crash-free rate dipped to ninety-four percent for forty-eight hours.

Symptoms: Local media picked up “app can’t handle jackpot.” Operator execs asked why vendor “didn’t scale.”

Root cause: Load test existed but used outdated traffic assumptions from pre-iLottery era. Marketing acceleration penalty in millions of impressions of failure.

SEE response: Template 03 adopted retroactively. Next jackpot required signed 72-hour gate. Stability Features roadmap presented to board as user-facing reliability investments.

Outcome: Following jackpot held ninety-nine percent crash-free. Reviews recovered over two months.

Lesson: Jackpot readiness is not optional Expansion prep. It is Stability.

Pattern C: ASO turnaround without a rewrite

Situation: App functionally stable after year-long Stability program. Downloads flat. Branded search conversion below twelve percent.

Symptoms: Beautiful TV creative driving users to a store listing with outdated screenshots, internal jargon, and no trust signals on screenshot one.

Root cause: Expansion neglected—everyone assumed marketing would carry discovery.

SEE response: Template 07 audit. New screenshot one with scan action and official trust cues. Subtitle rewritten in player language. CPP for Mega Millions season.

Outcome: View-to-download on branded search moved from twelve to twenty-four percent in six weeks without binary change.

Lesson: Expansion is trust packaging as much as keywords.

Pattern D: Vendor alignment at renewal

Situation: Operator frustrated with “feature factory” vendor. Vendor frustrated with changing operator priorities. Renewal at risk.

Symptoms: QBRs were demo theater. No shared Stability metrics. Marketing launched without vendor warning.

SEE response: Joint workbook scoring session—operator and vendor separately, then combined alignment worksheet. SOW updated with Template 08 clauses. SEE Steward named on each side.

Outcome: Renewal signed with outcome-based quarterly scorecard. Next two quarters Stability SLAs met for first time in contract term.

Lesson: Shared vocabulary prevents shared blame.

Chapter 11: Handling Objections and FAQ

“We don’t have time to fix bugs — marketing is scheduled.”
Show marketing acceleration penalty. Delay or reduce campaign — cheaper than reputation damage.

“Our vendor owns the roadmap.”
You own the gates and the contract. Template 08 at renewal.

“Compliance won’t let us change push / copy / flow.”
Engagement within RG constraints is clarity and reliability — not gambling hype.

“We’re hybrid web — rewrite is too expensive.”
Document phased native remediation. Measure wrapper UX debt in reviews monthly.

“ASO is marketing’s problem.”
Listing is the first product experience. Expansion is third — after Stability.

“Who owns SEE?”
SEE Steward. Name them. Template 01 on calendar.

“This is too simple.”
Simple is hard because it’s uncomfortable. Test 30 days on Stability. Measure.

Part 37: Objections and FAQ — Extended

But What If…? Handling the Objections

Objection #1: “My Boss Wants Features, Not Bug Fixes.”

The Political Reality: Your boss is measured on features shipped, not bugs fixed. Your RFP requires features, not stability metrics. Your vendor contract pays for features, not reliability.

The Career Risk: If you pause features to fix bugs, you look like you’re not delivering. If you ship broken features, users leave. Either way, you lose.

The Organizational Solution: Reframe Stability as a feature. “Reliability during jackpot draws” is a feature. “Zero crashes during peak traffic” is a feature. “Users can complete purchases without errors” is a feature. Frame bug fixes as user-facing features, not technical debt.

The Action: Create a “Stability Features” roadmap. List each bug fix as a user-facing feature. Present it alongside new features. Show how Stability Features drive retention (which drives revenue).

Objection #2: “Marketing Says We Need More Downloads Now.”

The Political Reality: Marketing is measured on downloads, not retention. Your CMO wants to show growth. Your board wants to see numbers. Downloads are visible. Retention is invisible.

The Career Risk: If you say “no” to marketing, you look like you’re blocking growth. If you say “yes” to marketing a broken app, you waste money and damage reputation.

The Organizational Solution: Show the math. Calculate your marketing acceleration penalty: how much faster do you lose users when marketing drives traffic to broken features? Present it as: “We can spend $X on marketing now and lose 60% of users, or spend $Y fixing bugs first, then spend $X on marketing and keep 85% of users. Option 2 costs less and delivers more.”

The Action: Calculate your marketing acceleration penalty. Present it as a choice: fast growth with high churn, or slower growth with retention. Show the 12-month revenue difference.

Objection #3: “Our Users Don’t Give Feedback.”

The Reality: Users give feedback all the time. In reviews. In support tickets. In Reddit groups. In Facebook groups. You’re just not listening.

The Truth: Feedback isn’t just data. It’s a relationship. The apps that improve fastest aren’t the ones with the smartest teams. They’re the ones that listen best.

The Solution: Set up feedback collection. Reddit. Facebook groups. Reviews. Support. Categorize it. Prioritize it. Act on it. Close the loop.

Objection #4: “We Need to Be Good at Everything.”

The Reality: Teams optimize for the average user. They build features that appeal to the middle. Nothing stands out. No one becomes a loyalist. No one becomes an advocate.

The Truth: Outliers reveal what matters. Heavy users show you what they love. Rare users show you what’s blocking them. The middle will follow.

The Solution: Find your core strength. Dominate it. Be mediocre at the rest. That’s how you stand out. That’s how you build virality.

The Action: Analyze your heavy users (what do they love?). Analyze your rare users (what’s blocking them?). Find your core strength. Dominate it. Be mediocre at the rest.

Objection #5: “Our App Store Rating Is Fine. We Don’t Need ASO.”

The Reality: Your app might have a decent rating, but if people can’t find it, it doesn’t matter. And if they find it but don’t trust it enough to download, it doesn’t matter.

The Truth: ASO isn’t just about keywords. It’s about trust. Keywords get you found. Trust gets you downloaded.

The Solution: Audit your ASO. Add trust signals to screenshots. Optimize for conversion, not just search. One screenshot change can be worth $47,000 in the first month.

The Action: Audit your ASO (title, subtitle, description, screenshots). Add trust signals to screenshots. Optimize for conversion. Test different variations.

Objection #6: “We Don’t Have Budget for This.”

The Reality: You’re already spending money. On marketing that doesn’t work. On features users don’t use. On campaigns that drive users to a broken experience.

The Solution: Start with Stability. It’s the cheapest fix. Then build Engagement. Then focus on Expansion.

The Action: Calculate your leaky bucket formula. Identify your top bugs. Fix them. Measure the ROI.

Objection #7: “This Won’t Work in Our Industry.”

The Reality: The same problems show up across every industry. Gaming apps. Travel apps. Streaming apps. Ferry reservation apps. Lottery apps. Same problems. Every time.

The Truth: Users are users. And broken apps are broken apps. The industry doesn’t matter. The principles do.

The Solution: Test SEE against your app. If it works, use it. If it doesn’t, ignore it. But the principles are universal.

The Action: Test SEE against your app. Start with Stability. Measure the results. Then move to Engagement. Then Expansion.

Objection #8: “Compliance Says We Can’t Do That.”

The Career Risk: If you fight compliance, you lose. If you accept “no” for everything, nothing improves. You’re stuck.

Objection #9: “Who Owns This? It’s Not in Anyone’s Job Description.”

The Career Risk: If you take ownership, you’re responsible for outcomes you can’t control. If you don’t take ownership, nothing changes. You’re stuck.

The Organizational Solution: Appoint a SEE Steward. Not a project manager. Not a coordinator. A steward. Their job: ensure the order is followed. They don’t do the work—they ensure the work follows the order. They’re measured on outcomes (retention, trust, growth), not activity (features shipped, campaigns run).

The Action: Create the SEE Steward role. Define it as: “Ensures Stability → Engagement → Expansion order is followed. Measured on user outcomes, not activity.” Put it in someone’s job description. Make it permanent.

Objection #10: “This Is Too Simple. We Need Something More Complex.”

The Truth: SEE isn’t magic. It’s not clever. It’s just the right order of operations, learned the slow way, written down so you don’t repeat the same mistakes.

The Solution: Test SEE against your app. If it works, use it. If it doesn’t, ignore it. But simplicity is a feature, not a bug.

The Action: Test SEE against your app. Start with Stability. Measure the results. Then move to Engagement. Then Expansion.

Additional lottery-specific objections

”Our vendor says geo is a carrier problem.”

The Reality: Carriers matter. So does your timeout logic, SDK version, fallback when GPS is weak, and copy when verification fails.

The Action: Require vendor root-cause taxonomy for geo failures. Fix what you control first.

”We cannot change the web platform this year.”

The Reality: SEE still applies inside constraints: native shell improvements, offline caching, honest loading states, dated wrapper exit plan.

The Action: Negotiate Stability SLAs on core tasks regardless of stack.

”Players expect Vegas-style apps.”

The Reality: Players expect apps that work. Civic trust branding outperforms casino cosplay in regulated markets.

FAQ for operators and vendors

Who should be SEE Steward? Operator: digital director or PM with campaign pause authority. Vendor: delivery lead with dashboard access.

Workbook or playbook first? Playbook for governance and contracts. Workbook for scoring workshops. Complete Kit ($99) for both.

How long until results? Stability metrics: weeks. Ratings: months. Retention: quarters.

Board metrics? Crash-free, geo success, task completion, retention trend, rating trend—not downloads alone.

Jackpot TV safe when? Template 03 signed with evidence.

Chapter 12: What Success Looks Like

Success isn’t only metrics. It’s identity:

You become the organization that fixes before it promotes. The vendor that brings bad news early with data. The operator that governs without micromanaging code.

Metrics that confirm it:

Crash-free sessions hold through jackpot night
Geo complaints drop in reviews
Withdrawal SLA met — or honestly communicated when not
Retention curve inflects
Rating climbs with reviews mentioning reliability
ASO conversion improves on same product because trust matches reality

Your next steps

Step	Resource
1. Quick score	https://lissiland.com/see-framework/assessment/
2. Full diagnostic	Workbook — `workbook/SEE_Scorecard_Workbook.md` (paid print)
3. Run it monthly	Playbook Template 01
4. Vendor renewal	Playbook Template 08 + 02
5. Jackpot season	Playbook Template 03 + 04
6. Talk it through	https://calendar.app.google/NzxJ6Ny1cCau7jj56

One action today: List your top 10 Stability defects from reviews and support. Fix the one affecting the most users.

That’s the win we’re rooting for.

Glossary

SEE Framework — Stability, Engagement, Expansion in strict order.

Stability — Reliable core product: geo, KYC, wallet, load, native UX, crash-free.

Engagement — Relational product: feedback loops, language, push, retention, trust moments.

Expansion — Discoverability and growth: ASO, campaigns, CPP, deeplinks — gated.

SEE Steward — Role accountable for sequence and outcomes.

Core Tasks — Scan, check numbers, purchase, wallet, geo/KYC as required.

Marketing Gate — Playbook Template 04 — required before major spend.

Crash-free session rate — Sessions without user-perceived crash; target ≥ 98%.

7-11-4 — Google trust-building heuristic: ~7 hours, 11 touchpoints, 4 locations.

11th experience — Priestley: habitual usefulness emerges around 11th smooth interaction.

Web wrapper — Web content in app shell without native UX quality.

Custom Product Page (CPP) — Apple seasonal/jackpot-specific store destination.

Resources

Resource	Location
Free assessment	https://lissiland.com/see-framework/assessment/
SEE overview	https://lissiland.com/see-framework/
Workbook	`workbook/SEE_Scorecard_Workbook.md`
Playbook	`playbook/SEE_Playbook.md`
Strategy call	https://calendar.app.google/NzxJ6Ny1cCau7jj56
Email	hello@lissiland.com

Court Bluford
Lissiland LLC · Richmond, Virginia
https://lissiland.com

SEE is a system, not a project. Revisit quarterly.

Chapter 13: Workshop Guide

Half-day operator workshop (four hours)

Audience: Digital director, marketing lead, compliance rep, vendor account lead invited as listener.

Agenda:

Opening (30 min): Free assessment live—each leader completes on phone. Compare focus layers. Discuss surprises.
SEE sequence (45 min): Leaky bucket exercise with your last campaign numbers. Calculate waste if twelve percent hit broken flow.
Stability stack (60 min): Rate geo, KYC, wallet, load, native UX 1–5 on whiteboard. Pick top two P1s for thirty-day sprint.
Gates (45 min): Walk Template 04 marketing gate with last campaign—would it pass today?
Steward and calendar (30 min): Name SEE Steward. Schedule monthly Template 01. Schedule quarterly workbook.
Close (30 min): Three actions, owners, dates. Book strategy call if external facilitation needed.

Materials: Workbook printouts, Playbook Template 01/04 copies, projector for dashboards.

Half-day vendor workshop (four hours)

Audience: Delivery lead, PM, engineering lead, QA, operator product owner as partner.

Agenda:

Outcome scorecard intro (30 min): Features shipped vs reviews received last quarter—alignment check.
Roadmap tagging (60 min): Label next quarter items S/E/X. Identify Expansion items to defer if Stability red.
QBR rehearsal (45 min): Mock Template 02 with real data—no demo slides.
SOW language (45 min): Walk Template 08 clauses; mark ready for renewal.
Jackpot gate (30 min): Template 03 table-top exercise with fictional $500M draw.
Close (30 min): Vendor commits to weekly feedback triage summary and shared dashboard access.

Exercises using the workbook

Gap triangulation: Operator scores question 21 (geo) and vendor scores same; discuss delta greater than two points.
90-day roadmap: Each pillar top gap becomes one thirty-day action block.
Joint alignment worksheet: Complete last page of workbook in room, sign PDF, attach to QBR pre-read.

Workshops fail without executives in the room for the first thirty minutes. Schedule accordingly.

Chapter 14: Native, Cross-Platform, and Web Wrappers

Lottery programs choose hybrid approaches for valid reasons: legacy web platforms, speed to market, shared codebase with iLottery web. The SEE Framework does not mandate native Swift or Kotlin for every screen. It mandates honest UX quality on core tasks and a remediation plan when wrapper debt hurts Stability and Engagement scores.

Native delivers best session feel, offline control, and platform API access. Cost is dual codebase or disciplined cross-platform team.

Cross-platform (Flutter, React Native done well) can deliver native-quality when teams invest in platform-specific polish—not only shared components.

Web wrapper is acceptable for transitional phases if roadmap names milestones to native-first core flows with dates.

Operator: Ask “what is our wrapper exit plan date?” in renewal. “TBD” is an answer you can negotiate.

Vendor: Quantify wrapper limitations in proposal appendices. Credibility beats overselling.

Session-zero test protocol: cold install on 3G, complete scan or check numbers, note every spinner over three seconds and every non-native scroll jank. That video clip is worth fifty slide decks in executive reviews.

Chapter 15: Responsible Gaming and Engagement

Responsible gaming is not the enemy of Engagement. Dark patterns are the enemy of Engagement in regulated lottery markets.

Clear limits, visible self-exclusion paths, plain-language odds presentation, and non-predatory push cadence build long-term trust with regulators and players. Copy that mimics slot-machine hype may lift clicks briefly and destroy brand over years.

Engagement tactics that survive scrutiny: helpful draw reminders, win notifications with claim instructions, saved numbers, transparent wallet status, celebratory but restrained win states, easy access to help resources.

Operator: Compliance review of Engagement copy should be fast-path, not six-week bottleneck, when copy reduces harm and increases clarity.

Vendor: Propose RG-visible patterns as default templates, not custom change orders.

Chapter 16: Building in Public After a Crisis

When jackpot-night failure becomes public, the recovery strategy I recommend is sustained build-in-public: show listening, testing, fixing, and shipping over months. One apology post is insufficient when a hundred and forty people marked a review helpful.

Document geo fixes, load test videos, beta programs, and release notes in plain language. Turn operators and vendors into collaborators in recovery, not defendants in comment threads.

This is Engagement and Expansion together—only credible after Stability work is visibly underway. Do not market recovery before fixes ship.

Chapter 17: AI, MCP, and the SEE Sequence

Teams ask whether AI replaces product discipline. It does not. AI accelerates output—screens, copy variants, MCP tools—but cannot guarantee geo accuracy, store approval, or player trust.

Use AI to draft ASO variants, summarize feedback themes, and generate test scripts. Do not use AI to skip Stability gates because “we can patch later faster now.”

The SEE sequence is more important when output is cheap. When everyone can generate fifty features, the teams that win measure which three actually work for players in your state.

Lissiland consults on AI frameworks and MCP for agent-ready products—always subordinate to SEE ordering: stabilize player reality before automating around it.

Chapter 18: Conference and RFP Use of SEE

For RFP authors (operators): Embed Template 08 clauses. Require SEE-tagged roadmaps in vendor responses. Ask for jackpot load test examples from prior clients without requiring confidential names.

For RFP responders (vendors): Lead with outcome scorecards from anonymized programs. Show QBR template as operating maturity signal.

For conference talks: Use free assessment live poll. Hand workbook discount codes. Book follow-up workshops.

The book is free so the framework spreads. The playbook is paid because implementation detail has sustainable value for both sides of the table.

Chapter 19: Final Word from the Field

I’ve broken things since 2009. I’ve been in lottery mobile since 2022. I’ve seen what directors and QA heads see—plus what vendors say in rooms operators never enter.

The pattern is always the same: smart people, real budgets, good intentions, wrong order.

You can fix that without a reorg, without a rip-and-replace, without pretending one vendor magic-wands everything. You need sequence, shared metrics, gates, and the humility to pause marketing when the app is lying to players about what state they are in.

Take the assessment. Score the workbook. Run the playbook templates. Book a call if you want a second pair of eyes.

Fix Stability first. Build Engagement second. Expand third.

That’s SEE. That’s the job.

— Court Bluford

Chapter 20: Foundation Revisited — Lottery Apps and the Wrong Order

Most Lottery Apps Are Broken. Why?

As a state lottery, when you build in the wrong order, you spend $2 million on a marketing campaign. Beautiful ads. Perfect targeting. Drives 50,000 downloads in the first week.

Then 12% of those users can’t check their numbers during the jackpot draw. The app crashes. Error messages. 1-star reviews.

The 1-star review user is 100% right. And this is a gem because many users don’t even tell you it’s a problem. They just drift away. And don’t think of this as 1 user. Think about your behavior when you like or dislike something… you tell others. The only time you don’t is if you are indifferent.

That $2 million campaign? It did more harm than good.

In 2026, when critical issues like this emerge, your response strategy should be creating an entire series about how you’re fixing and solving the app. Your content strategy becomes a 6-month or year-long journey from photos and videos of ideation, talking to users, planning, scheduling, all the way to launch. Build in Public becomes the campaign. Show users you’re listening. Show them you’re fixing it. Turn the crisis into connection.

Your lottery app isn’t losing users because of marketing. It’s not losing users because of features.

It’s losing users because you’re building in the wrong order.

Many State Lottery apps polish the exterior while the foundation crumbles.

The industry leaders tells you: Build features. Run campaigns. Optimize for downloads.

The industry is wrong.

What actually works, you ask? Fix Stability first. Build Engagement second. Focus on Expansion third.

What’s most interesting is the same problems show up across every industry. Gaming apps. Travel apps. Streaming apps. Ferry reservation apps. Lottery apps.

Same problems. Every time.

The strategy that works for lottery apps? It works for gaming apps. It works for travel apps. It works for streaming apps.

Why? Because users are users. And broken apps are broken apps. The industry doesn’t matter. The principles do.

This framework came from breaking things. A lot of things. Breaking things since 2009.

Failed launches. Angry users. 1-star reviews. Long nights staring at crash reports wondering why something that should work… didn’t.

What did I learn?

Most app problems aren’t complicated. They’re just uncomfortable.

It’s uncomfortable to pause features and fix bugs. It’s uncomfortable to admit users don’t trust your app. It’s uncomfortable to realize marketing won’t save a broken experience.

So teams avoid those conversations. They add polish. They run campaigns. They hope.

This book cuts through that.

SEE isn’t magic. It’s not clever. It’s just the right order of operations, learned the slow way, written down so you don’t repeat the same mistakes.

Test this against your lottery app.

If it works, use it. If it doesn’t, ignore it.

But if you’ve ever looked at your lottery app and thought… “We’re working hard… so why isn’t this working?”

You’re exactly who this is for.

Who else is this book is for?

Product leaders inside state lottery organizations
UX designers working on lottery mobile apps
Compliance teams who want progress without being blockers
Govtech consultants working with state lotteries
Public-sector CMOs who want real wins without breaking rules
State Lottery Conference members seeking digital transformation frameworks
Teams navigating responsible gaming requirements while improving UX

This book is specifically written for state lotteries and their vendor partners. The examples, the challenges, the solutions… all focused on lottery apps. But the strategy works across industries. It works in gaming, travel, streaming, and ferry apps. The principles are universal. The application is lottery-specific.

Let’s go.

Stage 2: Disruption

The Industry Is Wrong.

The Industry Standard Says “Build features. Run campaigns. Optimize for downloads.”

But looking at many of our app reviews… you see the Industry Standard is wrong.

Lottery apps are built in the wrong order.

It’s like throwing a grand opening party for a restaurant that hasn’t figured out the kitchen. You’ve got balloons outside, music playing, and a long line at the door. But once people sit down, the menu’s a mess, the food takes forever, and nobody’s coming back. That’s what it’s like when teams prioritize new features and marketing push before fixing load times, login bugs, or broken onboarding.

The hype gets people in the door. The product keeps them there.

Stability → Engagement → Expansion

You can’t build Engagement on a broken foundation. Users won’t come back to apps that crash.

You can’t build Expansion on weak Engagement. Even if people find your app, they won’t stay if they don’t trust it or see value.

But when you build in order:

Stability creates a foundation users can trust
Engagement builds relationships that make users want to come back
Expansion brings new users to an experience that actually works

The Contrarian Truth:

The industry says “marketing drives growth.” That’s wrong. Marketing is currently driving users to broken apps. Big difference.

Think of your app like a bucket. Would you spend money to fill a bucket with holes? No. So why spend marketing dollars on a broken app? If it’s full of leaks… crashes, bugs, confusing flows… no amount of water (or users) will fill it. But teams keep pouring anyway.

Your app is your marketing. Especially now, when AI makes it easier than ever to generate hype, but harder than ever to earn trust.

Users don’t stick around because you had great promo. They stay because the experience works. Because it delivers. They tell friends. They come back. That’s growth.

Fix the leaks. Then pour the water.

The Right Order:

Fix Stability (plug the holes)
Build Engagement (make the bucket valuable)
Focus on Expansion (pour the water)

That’s Stability working. Fix Stability first, then market. Not the other way around.

What do you delay by choosing Stability? Features. Marketing campaigns. New launches. But what you gain multiplies those efforts, once done. Users who actually stay. Trust that compounds. A foundation that supports everything else.

What Expansion metrics lie to you when Engagement is weak? Downloads look great. Search rankings improve. But if users don’t come back, those metrics are expensive vanity. You’re paying to acquire users who leave… that’s not growth, that’s a leak.

Chapter 21: The SEE Method — Complete Reference

The SEE Framework: The Method

The Three Steps

Step 1: Stability

Fix crashes and errors first. Nothing else matters until your app works.

What it means: Your app works when users need it. No crashes. No errors. No confusion. Users can complete what they came to do.

How to know you have it:

Crash rate is under 2%
Users can complete core tasks without errors
App performs well during peak times
Support tickets are mostly feature requests or “I want to win more”, not “it’s broken” complaints
Cognitive load is low (users can navigate using muscle memory)

What to do:

Measure your crash rate
Calculate your Cognitive Load Score for key tasks
List your top 10 bugs
List your top 10 cognitive friction points
Fix them (bugs first, then cognitive load)
Measure the results
Don’t move to Engagement until Stability is fixed

Step 2: Engagement

Build relationships. Make users want to come back.

What it means: Users come back because they want to, not because they have to. They trust you. They feel valued. They see value in using your app regularly.

How to know you have it:

30-day retention is above 40% (for lottery apps)
Users come back multiple times per week
App Store reviews mention trust, reliability, or “I love this app”
Users give feedback and you act on it
Support tickets decrease over time
Key actions are accessible within three taps or gestures

What to do:

Shift from transactional to relational mindset
Add simple relationship elements (thank-you messages, status updates, proactive help)
Apply the three-tap rule: Ensure your three most frequent actions (scanning, checking numbers, purchasing) are accessible within three taps
Focus on outliers, not averages
Find your core strength from heavy users
Dominate it. Be mediocre at the rest.

Step 3: Expansion

Focus on getting found. But only after Stability and Engagement are solid.

What it means: People can find your app when they search. They understand what it does. They trust it enough to download. Your app shows up in the right places at the right times.

How to know you have it:

App shows up in search results for relevant terms
Conversion from view to download is above 20%
Organic downloads are growing month-over-month
App Store rating is above 4.0
Users understand what your app does from the description

What to do:

Audit your ASO (title, subtitle, description, screenshots)
Add trust signals to screenshots
Apply mathematical harmony to visual design (consistent spacing, harmonious proportions)
Optimize for conversion, not just search
Use deeplinking in campaigns
Create Custom Product Pages for different campaigns

The Order Matters

Stability → Engagement → Expansion

You can’t build Engagement on a broken foundation. Users won’t come back to apps that crash.

You can’t build Expansion on weak Engagement. Even if people find your app, they won’t stay if they don’t trust it or see value.

But when you build in order:

Stability creates a foundation users can trust
Engagement builds relationships that make users want to come back
Expansion brings new users to an experience that actually works

The tradeoff: Choosing Stability means delaying features and marketing. But the alternative is worse: spending marketing dollars to drive users to a broken experience. The cost of fixing bugs is fixed. The cost of losing users compounds.

Now that you understand the framework, let’s dive deep into each pillar. These chapters will show you exactly how to implement each part of SEE, with real examples, actionable steps, and the tools you need to succeed.

Appendix A: Benchmark Reference Tables

Stability benchmarks (lottery mobile)

Metric	Minimum	Strong
Crash-free sessions	98%	99%+
Geo first-attempt success	95%	98%+
Core task completion	90%	95%+
P1 resolution	48h	24h
Jackpot load test before campaign	Required	Required + documented rollback

Engagement benchmarks

Metric	Minimum	Strong
30-day retention	25%	40%+
Three-tap core actions	Yes	Yes, verified by UX test
Push segmentation	Basic segments	Behavior-based
Review response (≤3★)	5 business days	48 hours

Expansion benchmarks

Metric	Minimum	Strong
View-to-download (branded)	20%	30%+
Store rating	4.0	4.5+
ASO update cadence	90 days	Seasonal + jackpot
Organic download share	40%	60%+

Gates: Engagement investments require Stability ≥ 60 or crash-free ≥ 98%. Expansion scale spend requires Engagement fundamentals stable.

Appendix B: Glossary

Build in public: Crisis comms strategy showing players the fix journey over months—not a single apology post.

CPP (Custom Product Page): Apple store destination tailored to campaign or game.

Core Tasks: Scan, check numbers, purchase, wallet operations, geo/KYC as required by jurisdiction.

Crash-free session rate: Percentage of sessions without user-perceived crash; target ≥ 98%.

Cognitive Load Score: Decisions × screens × information density per task; target under 5.0 for core flows.

Deferred deeplink: Link that survives app install and opens intended destination on first launch.

Feedback flywheel: Collect → act → notify → repeat; compounds trust.

Jackpot readiness gate: Template 03 sign-off before major draw campaigns.

Leaky bucket: Marketing users lost to Stability holes before Engagement can form.

Marketing gate: Template 04 approval before paid acquisition over threshold.

Native quality standard: Core tasks meet platform UX expectations—not wrapper jank.

SEE Steward: Accountable owner of sequence and monthly rhythm.

Session zero: First open experience measured like a stranger, not a stakeholder.

Stability Features roadmap: Bug fixes framed as user-facing reliability deliverables for executives.

Three-tap rule: Core actions within three taps or gestures.

Web wrapper: Web content in app shell without native interaction quality.

Appendix C: Product Ladder and Resources

Resource	Access
Free book (website)	https://lissiland.com/see-framework/book/
Free 12-question assessment	https://lissiland.com/see-framework/assessment/
SEE Scorecard Workbook ($34.99)	https://lissiland.com/see-framework/shop/#workbook
SEE Playbook ($79)	https://lissiland.com/see-framework/shop/#playbook
Complete Kit ($99)	https://lissiland.com/see-framework/shop/#bundle
Strategy call	https://calendar.app.google/NzxJ6Ny1cCau7jj56
Email	hello@lissiland.com

Recommended path:

Read the book (free).
Take the assessment (three minutes).
Run a workshop with the workbook.
Operate monthly with the playbook templates.
Book a call when you want external validation on roadmap or renewal.

SEE is a system, not a project. Revisit quarterly. Fix Stability first. Then Engagement. Then Expansion.

— Court Bluford, Lissiland LLC

Appendix D: Troubleshooting Quick Reference

Troubleshooting Quick Reference

“My app crashes during jackpots” → See Chapter 1 (Stability). Fix performance issues under load first. Test at peak traffic. Monitor crash rates.

“Users don’t come back” → See Chapter 2 (Engagement). Build relationships. Focus on outliers. Find your core strength. Make users feel valued.

“We can’t get found in the App Store” → See Chapter 3 (ASO). Optimize title, subtitle, description. Add hidden keywords to screenshots. Use Custom Product Pages. Focus on your core strength.

“Reviews are tanking” → See Chapter 1 (Stability), Chapter 4 (Feedback). Fix what users complain about. Respond to reviews. Close the loop.

“Marketing isn’t working” → See Chapter 1 (Stability) first. Marketing won’t save a broken app. Then see Chapter 3 (ASO). Use the 7-11-4 rule. Build trust, not hype.

“Users abandon during registration” → See Chapter 2 (Engagement). Remove friction. Use soft logins. Reduce steps. Make defaults work.

“Vendors aren’t delivering” → See Chapter 5 (Operationalization). Include SEE requirements in contracts. Measure vendors on outcomes. Align on technical standards.

“We don’t know what to measure” → See Chapter 1 (Stability), Chapter 2 (Engagement), Chapter 3 (ASO). Shift from vanity metrics to valuable metrics. Set up AI-powered automated reporting. Analyze by outliers.

“Teams don’t see the value” → See Chapter 5 (Operationalization). Build SEE into your rhythm. Use SEE as a decision filter. Show the math.

“Nothing seems to work” → Start with Chapter 1 (Stability). Fix crashes and errors first. Nothing else matters until your app works. Then move to Engagement, then Expansion.

Glossary

SEE Framework: A system for app growth focusing on Stability, Engagement, and Expansion in that order. Stability means your app works. Engagement means users come back. Expansion means users find you.

Stability: The foundation of your app. Your app works reliably, without crashes, errors, or confusion. Users can complete basic tasks without frustration.

Engagement: Building relationships with users, fostering trust, and encouraging repeat usage. Users come back because they want to, not because they have to.

Expansion: Improving discoverability, App Store Optimization (ASO), and marketing to attract quality users who will actually use and trust your app.

7-11-4 Rule: A marketing framework suggesting users need about 7 hours of engagement, across 11 distinct touchpoints, within 4 different locations, to build enough trust to make a significant purchase.

The 11th Experience: Daniel Priestly’s concept that many people don’t recognize an app’s usefulness until the 11th experience. All 11 interactions need to be smooth for users to make it part of their “go-to” experience.

Feedback Flywheel: A system where users give feedback → you act on it → users see you’re listening → they give more feedback → you improve faster → users trust you more.

SEE Steward: A person (or team) responsible for leading SEE implementation, training, coordination, and tracking performance across an organization.

Operationalization: Making SEE part of how you work, not just what you do. Building SEE into processes, culture, and systems so it becomes second nature.

Cognitive Load: The mental effort required to use your app. High cognitive load means users have to think about every action. Low cognitive load means users can navigate using muscle memory.

Three-Tap Rule: A principle ensuring that key actions are accessible within three taps or gestures. This reduces friction and helps users reach the 11th experience where they recognize your app’s value.

Physics-Based Interactions: Design principles that make digital interactions feel like physical objects, using concepts like weight, momentum, and friction. This creates subconscious trust because the interface feels predictable and reliable.

Mathematical Harmony: Visual design principles using consistent spacing, harmonious proportions, and smooth curves to create a subconscious sense of quality and reliability.

Turn the book into a scorecard

Take the free 12-question assessment, then use the workbook and playbook to run workshops with your vendor.

Take the assessment Get the playbook

The SEE Framework

Stability, Engagement, Expansion for State Lottery Mobile Apps

How to Use This Book

Who this is for

Operator vs vendor callouts

The one rule

About the Author

Chapter 1: The Night the App Said You Weren’t Home

What players actually say

The $2 million lesson (once, not twice)

Why I’m writing SEE

Chapter 2: The Industry Is Wrong (And You Already Know It)

Seven obstacles (you’ve met at least three)

The central question

Chapter 3: The SEE Framework and Ten Insights

Three pillars

Stability

Engagement

Expansion

Gates between pillars

The leaky bucket formula

Cognitive load is Stability

Ten insights (expanded)

Insight 1: Stability comes first. Always.

Insight 2: The leaky bucket is math, not metaphor

Insight 3: Engagement is relational, not a feature list

Insight 4: The 11th experience (Daniel Priestley)

Insight 5: The 7-11-4 rule (Google)

Insight 6: Outliers beat averages

Insight 7: Feedback is free consulting

Insight 8: Trust is built in moments

Insight 9: ASO is trust, not keywords

Insight 10: SEE is a system, not a project

Part 28: The Ten Insights — Expanded for Lottery Mobile

Insight 1: Stability Comes First — Expanded

Insight 2: The Leaky Bucket — Expanded

Insight 3: Engagement Is Relational — Expanded

Insight 4: The 11th Experience — Expanded

Insight 5: The 7-11-4 Rule — Expanded

Insight 6: Focus on Outliers — Expanded

Insight 7: Feedback Is Free Consulting — Expanded

Insight 8: Trust Is Built in Moments — Expanded

Insight 9: ASO Is Trust — Expanded

Insight 10: SEE Is a System — Expanded

Chapter 4: Stability — The Lottery Stack

Layer 1: Geolocation and jurisdiction

Layer 2: KYC and identity

Layer 3: Wallet — deposit fast, withdrawal honest

Layer 4: Peak load and jackpot readiness

Layer 5: Native quality versus the web wrapper

Layer 6: Cognitive load

Monitoring that operators and vendors can share

Thirty days to Stability (summary)

Part 18: Extended Implementation — Stability in Thirty Days

The Big Picture

The Story

The Proof

The Action

Objection #3: “Our Users Don’t Give Feedback.”

Objection #4: “We Need to Be Good at Everything.”

Objection #5: “Our App Store Rating Is Fine. We Don’t Need ASO.”

Objection #6: “We Don’t Have Budget for This.”

Objection #7: “This Won’t Work in Our Industry.”

Objection #8: “Compliance Says We Can’t Do That.”

Objection #9: “Who Owns This? It’s Not in Anyone’s Job Description.”

Objection #10: “This Is Too Simple. We Need Something More Complex.”

Chapter 5: Engagement — Relational Lottery Apps

Transactional versus relational — lottery examples

The three-tap rule for lottery

Language is Engagement

Mapping the eleventh experience

Push notifications — useful versus spam

Feedback flywheel — weekly discipline

Responsible gaming as Engagement ally

Engagement metrics that matter

Part 19: Extended Implementation — Engagement Playbook

The Big Picture

The Story

The Facts

The Action