Helping UX teams do their best work.

When I first started at theScore as an IC, the work was in front of me and I experienced the challenges and triumphs first hand. When I moved into a manager role, I was accountable for other people's work, but the triumphs became other people's triumphs, and it became more about celebrating their work and coaching them to be better designers. When I moved into the Director role, the responsibility changed again. I was responsible for building the teams and systems that empower the whole team to do great work, consistently, and at scale.

As the team grew over the course of 4 years through theScore, theScore Bet's expansion and then Penn's acquisition, the idea of designing a UX org wasn't a theory anymore, it was a real problem to solve. How do you maintain the high-quality standard for design? How do you know you're working on the right thing from a company perspective? How do you collaborate at scale with so many product teams? Not only this, but UX processes differed from team to team. Research wasn't being looped in at the right moments. Nobody could articulate what "great" looked like at each level. Before we could solve any of this, we needed a shared foundation to build from.

In January 2023, I brought UX leadership together for a two-day on site at the office. Seven UX leaders, two days, one question: why does a UX team exist, and what does it mean to be a great one?

We started with stickies on a FigJam board, each person writing their own answer to questions like "Why do we do the things we do here?" and "What would it look like if the UX team stopped existing tomorrow?"

The team was quick to respond with answers like: "We advocate for the user and we'd lose their voice in the room", and "The business would fail, we'd build on flaky assumptions", and also "Quality would erode quietly until the app is unusable".

By the end of day two after a lot of discussion and a lot of stickies, we had a vision:

And a purpose that grounded it in the work itself:

We also landed on six values:

• People First
• Strategic Yet Tactical
• Strive for Excellence
• Create a Safe Space
• Empower Each Other
• Always Learning

Each one was shaped by the people who would have to live it. For example, "Create a Safe Space" came out of a raw conversation about mistakes, transparency, and the fear of being penalized for speaking up. "Always Learning" was about staying curious in an environment that moved fast enough to make people feel like they were already behind.

A few months later we ran a follow-up strategy workshop with the same UX leads to translate what we'd built in January into concrete goals and objectives. We came into the session with a clear question: what blockers, risks, threats, and problems do you see us encountering that will prevent us from achieving our vision and purpose?

Since UX metrics didn't exist, we couldn't demonstrate impact. Process differed from team to team with no shared ownership across disciplines. Design systems adoption was inconsistent. Research wasn't scoped into product roadmaps early enough to matter. Designers weren't being built up to make autonomous decisions.

From there, we organized everything into two tracks: goals tied to our team vision, and goals tied to our purpose. Each one of these goals then had key outcomes tied to it.

• Foster genuine team connections and growth
• Showcase the UX team's work in the community
• Build a unified, cross-functional process

These goals produced key outcomes like improving pulse survey scores in engagement areas like job satisfaction, creative freedom, and connection with others; establishing retention metrics; completing the career journey framework for each discipline; running monthly UX Townhalls; and hiring a Design Ops manager to give the team the support it needed.

• Build processes to support the way we strategically build experiences
• Adhere to and evolve our unified experiences to improve efficiency without compromising quality
• Measure and positively impact user satisfaction and business metrics (ROI)

These goals produced outcomes like the 10-50-90 design review framework, a UXR Playbook 2.0, full adoption of design tokens across Sportsbook and Casino, and a standardized Jira workflow across feature teams.

The harder structural question was how to organize the team itself, not just internally but in relation to the rest of the org at large. Early conversations with Product and Engineering leadership were leaning towards building teams based on KPIs such as a team for retention, a team for acquisition, and so on.

Inspired by Peter Merholz's work on org design for product companies, I advocated for a model that organized teams around user experiences rather than product KPIs. We structured teams around the actual user journey through the betting product: Accounts and Onboarding, Discovery and Browse, Betslip, Post-Bet. This way, PMs, engineers, and designers could think in terms of journeys, feel the areas of friction of the experience they owned, and spot problems across that journey that would be invisible to a team working from a product backlog alone.

Within the UX org itself, we also formalized four disciplines: Product Design, UX Research, Design Systems, and Design Operations. Clarifying those disciplines made it possible to define what mastery looked like in each one, set appropriate expectations cross-functionally, and hire amazing people for the right role.

Creating the team structure was a good foundational step to building a high-performing team. But the real work was making a case for the new UX teams and working within the allocated budget to stand them up. This meant participating in leadership planning cycles and reviewing the budget allocated for our UX team.

In addition to adding new teams, it was important to retain the great team we already had. This meant researching UX compensation benchmarks across the industry to make sure our pay scales were competitive enough to attract and retain the people we needed. Having the data made those conversations with HR and finance concrete rather than anecdotal.

Headcount allocation was another lever to work through. Rather than asking for more designers generically, I made the case for where specific roles would have the most impact. Solving questions like:

• Which feature teams were under-resourced?
• Where can a junior hire grow under a senior mentor and increase capacity without increasing cost proportionally?
• How can a Design Systems and a Design Ops person support the org and create value for the entire team?

Getting a dedicated budget for Design Systems and Design Ops was its own argument. Both functions are easy to deprioritize because their value is distributed and slow to show up in business and product KPIs. I framed them in terms the business understood: Design Systems reduced redundant work across teams and shortened the time it took to roll out changes consistently across products. Design Ops created the infrastructure that let designers focus on craft instead of coordination.

One of the most consistent sources of friction on the team was the lack of a shared language for growth. Designers didn't know what was expected of them at each level and the question of whether someone wanted to move into management, or whether they'd be better served by deepening their craft, had no good answer because neither path was well defined.

I championed building the career journey framework that covered five levels, from Associate through Design Director, with an explicit fork at the senior level: a management track and an IC track.

We mapped each level across five competencies: Visual Design, Interaction Design, Content and Writing, Information Architecture, and UX Research, each with five proficiency tiers. Each of the competencies had a clear description of what was expected at that level. However, the goal wasn't to create a rubric to check boxes — it was a shared vocabulary so that when a manager said "you're not quite at Senior yet," they could point to something specific rather than something felt.

The height of scaling the UX org was right around Covid, where WFH and hybrid culture was mandated. It was a whole new ball game because now I had to scale the team while working remotely. This meant processes and systems were that much more vital to the success of the team.

We ran monthly UX Townhalls that gave the full team a window into what everyone was working on. It was a moment to celebrate work, surface interesting problems, and remember that there was a team beyond your immediate team. We launched a Research Newsletter so UXR insights could reach the broader organization in a format people would actually read. And we ran UX Campfires: smaller, more informal gatherings where designers shared work-in-progress, talked craft, and had conversations that the larger format didn't leave room for.

We also created a Fun Squad: a small rotating group whose only job was to keep the team connected in ways that had nothing to do with work. Trivia nights, fun facts surveys, team activities. What made it work wasn't the specific events. It was the decision to distribute ownership of culture to the people living it, rather than treating it as a leadership responsibility. Leadership sets the conditions. The team decides what to do with them.

We ran quarterly pulse surveys to stay honest about how the team was actually feeling. Not just engagement scores, but open questions about what was working, what wasn't, and where people felt unsupported. The results shaped how we ran the following quarter, whether that meant adjusting how we ran Townhalls, reprioritizing leadership time, or addressing tensions that hadn't surfaced any other way.

The vision workshop produced some really meaningful outcomes that motivated the team and drove excitement around working together. However, the hardest part of that work was staying honest about whether we were actually living those values in the months that followed. Due to company wide layoffs and other unforeseen circumstances, some of the values really started to stand on shaky ground. I would've liked to revisit them and continue to adapt them but didn't get the chance to because I left the company shortly after.

Advocating for user-experience-based team organization required a sustained case made to multiple leaders over time. It also required a lot more inter-communication between teams to make sure there wasn't duplicative work and holes didn't start appearing in the UX. One way to get ahead of this would've been to make cross-functional weekly meetings depending on the features that the teams were working on. For example, if the promos team was working on a new promo that would've impacted the betslip, there would've been more touch points between those two teams to make sure there was no overlap.

The framework was only as useful as the conversations it enabled. A document that lives in Excel or Confluence didn't change anything. What really changed things was managers using it consistently, referencing it in 1:1s, and calibrating against it openly. That was what took longer to get right than the framework itself.

Kiid AI is a startup founded by the Product and Engineering leaders of theScore. The vision was to build a personalized AI that learns a user's tone, interests, and values from conversation, and uses that understanding to connect them with the people around them. Every user created their own AI, and it was trained on that person based on chats and app activity. I joined as the head of UX to design both the mobile and web apps from early concept through MVP launch.

When we first started discussing the design strategy, we quickly realized there was no product out there that existed similar to this app. We weren't necessarily designing a chatbot, and we weren't designing a social network, we were designing both at once. It had to feel like an AI companion with a real personality, sitting inside a social graph that gave others access to that personality.

We were a team of 2 designers, working very closely with the product and engineering teams. We were scrappy and moved quickly, but at the same time had a ton of work in front of us that was difficult to validate without building a full product. For example, we were designing onboarding for a product whose entire value proposition only becomes obvious once a user already has friends on the platform. Cold-start was the hardest design problem in the entire product, and it touched everything from onboarding to early retention to how we explained the product in its first ten seconds.

Our first concept was to make onboarding feel like talking to your AI for the first time. It was conversational, asking about things like email, interests, values, etc. and the responses would be saved and prompted back to the LLM. This way it felt seamless between completing onboarding and the behaviour of the product itself. Although it was a compelling idea on paper, it wasn't the most efficient or most effective way of getting users through the door fast. Routing every onboarding field through an LLM call made the flow extremely slow and inconsistent, and being rigid about which questions every user had to answer meant we collected a lot of generic data and very little that actually made someone's AI feel like them.

After testing out the initial onboarding UX, we decided to go with a "form + convo" hybrid. First users would fill out fast, validated forms for the basics (name, school, date of birth), and then this was paired with a conversational layer that adapted to whatever the user actually cared about. That hybrid went through a few more revisions in order to fine tune where the line sat between forms and conversation.

A key moment in the initial alpha tests was the research feedback we got from friends and family. Some had sharp and very specific critiques such as: the UI was polished, but the value proposition wasn't explicit early enough, and mechanics like the AI's "Score" felt unclear. Users kept asking "why do I care?" about elements we'd assumed were self-explanatory. This early feedback reframed a lot of how we approached onboarding afterward. We needed to explain the "why" before asking for the "what,".

Most social apps default to a content feed as the home tab. When we were thinking about what "home" meant in this app, we made a deliberate product decision to make the user's own AI chat the home tab. Friends and DMs were the two other pages on either side by swiping left or right. This reinforced the core idea of the AI being a representation of you and everything else (friends, messaging, discovery) radiates out from that center rather than competing with it for attention.

We landed on swiping interactions because the idea was in the short term, we were going to create a persistent chat experience with the chat input being at the bottom of the screen, reachable at all times. As a result, the conventional tab bar you see on most apps would not have the space to exist.

Shortly after beta testing and soft launching the app, we decided to cut the web product and focus entirely on mobile. Web was slowing us down quite a bit and we still hadn't validated product market fit.

Over the course of the project, we shipped a working mobile and web app to approximately 5,000 users in the Appstore and Playstore. The product included AI chat, friending, DMs, onboarding, settings, message reporting, and a growing library of social games. It reached the point where users could engage with the core idea directly and react to it by writing reviews and giving feedback. Early feedback consistently confirmed that the concept landed once a user had even a small social graph in place.

Routing everything through an LLM felt true to the product's identity, but it wasn't automatically the right interface for every task. Forms are faster and more reliable for structured data and this should have been kept separate from conversations where the product's personality shines. Learning to split the two deliberately, rather than treating "more AI" as inherently better design, was one of the most useful shifts in how the team worked.

In UX, gamification works best as an enhancement to a product that already has legs to stand on. Score and points in the app were meant to signal how well a user's AI knew them, but we didn't explain that clearly on screen and when they increased, users didn't know what was in it for them. As a result, the numbers just sat there ignored by users.

Ultimately, the product did not find product market fit in the end. Users did not see the value in chatting with their own AI and chatting with friends AI's either. We saw early signs of this sentiment in alpha and beta research sessions, but we still moved forward in spite of that. Something I've personally learned at Kiid is how critical it is to collect real outside feedback early and often. Especially for a product whose value wasn't self-evident on first open.

Section content placeholder.

Section content placeholder.

Section content placeholder.

Section content placeholder.

After theScore was acquired by Penn in Oct 2021, our UX team merged with an entirely new UX team, new designers, new managers, and new leadership across the org. As the design team grew, it became harder to maintain a high-quality standard for design that was consistent yet scalable.

This wasn't just a design process problem, it was a cross-functional one as well. Product managers and engineers had their own expectations for when they'd see work, as well as Senior Leadership. Principals and senior managers needed a clear escalation path for approvals without becoming bottlenecks on every project.

Designers were getting feedback too late, often times when major directional changes were no longer practical. At the same time, design review meetings lacked clarity as to who needed to be in the room, what kind of input was appropriate at each stage, and what it meant to be "done".

The goal was to create a design review framework that ensured high quality designs while being conscious of the ebbs and flows of the design process. From concepts to final polished designs with high visibility across the organization.

I led the design of the framework while working closely with the Product Design team leads including managers and principal designers. Through a series of about 3 workshops with feedback loops from the design team, we came up with 3 stages in the framework:

• 10%: Rough concepts, sketches & early designs
• 50%: Wireframes
• 90%: Final designs & approvals

At each one of these points there was a check in with design managers and teammates. At 90%, the designs would be reviewed by leadership and ready to ship if there's no further feedback. This gave every discipline a shared vocabulary for where a project was and what was expected of them.

In order for these 3 phases to be successful, at the beginning of the project, designers along with their managers defined the project size using a short checklist of requirements.

• Small: Small fixes could move faster with lighter-touch check-ins
• Medium: Optimizations to existing screens, flow or function, new functionality on an existing experience
• Large: Brand new feature, flow or redesign aimed to solve one or more user problem

The framework became the standard operating model for design reviews across all product design feature teams. Designers had clear expectations for what to bring to each checkpoint, and cross-functional partners knew when to show up and what kind of input was useful.

The biggest shift was at the extremes. At 10%, sharing rough concepts with leadership early meant fewer surprises at the end. Directors and principals could flag strategic misalignments before teams had invested weeks of polish. At 90%, directional feedback dropped significantly. Work arrived at the right fidelity, and reviews became about refinement rather than redirection.

More broadly, it created a shared language between design, product, and engineering. Escalation paths became clearer, and the ad-hoc, high-stakes feedback that had previously derailed late-stage work became the exception rather than the rule.

The framework went through two major versions based on a survey sent to the Product Design team.

V1 established the core structure and was used as a working draft with a small group of senior designers and PMs.

V2 refined the reviewer roles (clarifying manager vs. principal vs. director involvement), addressed open questions raised in V1 (Design Systems representation, small project check-in requirements, what belongs in the Discovery phase), and added rollout guidance including a comms plan, Loom training, and PM alignment sessions.

Early on the process started to feel like a formal checklist of deliverables instead of focusing on outcomes. We gave in to some of that pressure in V1, which made the process feel rigid. In hindsight, we would have pushed back harder from the start and kept it principles-based rather than output-based.

V1 was rolled out broadly during a townhall which created confusion and uneven adoption. For V2, we soft-launched with a smaller group of designers and PMs who were already using parts of the framework, incorporated their feedback, and built training materials before broader rollout. The people most affected helped advocate for it and that made all the difference.

We initially scoped this as a Design-only process. It wasn't until the terminology started spreading that we realized it needed cross-functional buy-in from the start. If we'd looped in Product and Engineering earlier, the framework would have landed with more shared ownership and less retrofitting.

The word "approval" created friction. It made the process feel like a gate rather than a conversation. We reframed this language in V2, positioning managers and principals as active coaches throughout, with formal approvals reserved only for specific milestones.

After building the 10-50-90 design review framework, we had a shared vocabulary for design fidelity stages, but design was still only one piece of the picture. Product managers were running their own planning processes. Engineers were being pulled in at the wrong moments. Research insights weren't landing in time to shape direction. We needed something that would unify the process, that's where Uniform came in.

As teams grew across Sportsbook, Casino, PAM, and theScore Media, the cost of misalignment compounded. Features arrived at the 10% review without a clear problem statement. Scope decisions were made mid-design. Eng feasibility conversations happened too late. The 10-50-90 reviews were doing real work, but they couldn't compensate for everything that happened, or didn't happen, before them.

In Q4 2023, we ran a structured retro across ICs from UX, PM, and Engineering to understand where our existing framework was adding value and where it was creating friction. The feedback we received was that the framework was too design-centric, too linear, and too disconnected from how teams actually worked. Feedback arrived too late to act on. Review checkpoints felt like gates. Eng and research weren't represented where they needed to be. And for smaller projects, the overhead wasn't worth it.

The goal was to build Uniform as a truly cross-functional framework that could guide a team from problem definition all the way through to shipping and learning.

Uniform needed to be a framework, not a rulebook. It needed to be something teams could adapt to the size and complexity of what they were building, rather than a checklist that added process for its own sake.

For V2, the Design Ops team took the lead with building the new and improved version of Uniform. We formed a working group of 13 ICs spanning UX Design, UX Research, Product Management, Engineering, and Technical Program Management. People that were boots on the ground and had visibility into how this would be successful.

The group had three objectives:

• Test the framework on real feature teams and gather feedback
• Fill in the gaps from functions that weren't yet represented
• Simplify wherever possible

We also walked all of the engineering directors through Uniform to gather direct feedback on where the framework wasn't serving the eng org and what it needed to do better. Their input shaped several structural decisions: earlier eng inclusion at the 10% review for feasibility input, async review options for directors who couldn't attend every session, and clearer ownership at the Build phase.

V1 was an initial attempt at a unified lifecycle, framed as Explore → Define → Execute. It established the RACI model (Owner, Partner, Consulted, Informed, Approver), embedded the 10/50/90 review checkpoints into the lifecycle, and introduced a dashboard for tracking initiative status across business units. But it was still too linear, too heavy for smaller projects, and didn't represent the Build and Learn & Iterate phases in any meaningful way.

V2 restructured the phases around how teams actually work: Define → Explore → Refine → Build.

• Define: Captured the upfront problem clarity work.
• Explore: Where design solutions branched and tested.
• Refine: Narrowed to a single high-fidelity solution ready for build.
• Build: Design and engineering worked side by side through implementation, resolving edge cases as they surfaced.

Each phase had clear checkpoints, owners, deliverables, and the flexibility to be skipped for work that didn't need it.

Some other improvements that were made in V2 based on feedback from the team:

• Removed the 95% Final Exec Approval checkpoint that had been creating bottlenecks, and introduced optional observers at each review to reduce scheduling friction.
• Clarified which steps were optional vs. required.
• Revisited the core structure for different zoom levels.
• Built a dashboard for async leadership visibility.
• Determined the overlap in adjacent processes like grooming, release planning, and continuous discovery.

Uniform became the standard for how product teams at theScore organized their work, from early problem definition through to ship. The phases (Define, Explore, Refine, Build) gave every discipline a clear picture into where a project was and what was expected of them. Review checkpoints were no longer design reviews; they were cross-functional alignment moments with clear audiences, delivery formats, and decision criteria.

In addition, the cross-functional reviews allowed Engineering leads to flag feasibility early. Research insights were positioned at the Define stage where they could actually shape direction. Product managers owned the product brief and spec, but collaborated with design throughout the process.

The retro data made it clear that V1 had been used inconsistently across teams, not because it was wrong, but because it hadn't landed with shared ownership. When processes come from one function, the other functions comply at best. We learned to treat the working group not just as a feedback mechanism but as the core team responsible for advocating for Uniform within their disciplines.

One of the most repeated pieces of feedback was that the framework felt like a checklist. Teams resisted it when they felt forced to follow steps that didn't serve the work. The reframe in V2 (every step is optional until you decide it isn't) shifted it from compliance to ownership of decisions. Teams felt trusted to make the call, and they used more of the framework as a result.

Engineering's feedback was that it felt like they were involved in the wrong ways. Directors couldn't attend every review. ICs were consulted too late for their input to change anything meaningful. What eng actually needed was async discoverability for leaders and earlier, lower-stakes involvement for ICs at the 10% stage. We addressed both in V2, but it required genuinely listening to what they asked for rather than designing a solution on their behalf.

Broad announcements didn't change how teams worked. What worked was starting with people who are already partially using it, incorporating their feedback, and letting them carry it into their teams. Real adoption happened in the working group, one feature team at a time.

The goal was to show the team's ability to move faster by removing unnecessary process, but some of what we added to make that possible (new templates, new checkpoints, new documentation) ended up feeling like more red tape rather than less. Cutting process is its own kind of process, and it has to be designed with the same care as what it's replacing.

Despite trying to make Uniform non-linear, it kept feeling linear because of how approvals were structured. Once a team had signed off on a mid-fi direction, going back to concept exploration meant unwinding decisions and stakeholders who'd already moved on. The framework allowed for going backward in theory, but the approval structure made it costly enough in practice that teams rarely did.

theScore had spent a decade building one of the most-used sports media apps in North America. With roughly 4 million monthly active users at the time, once there were rumblings of sports betting being legalized in the US, it was a natural extension to the media product. There was no playbook for what a media-native betting product should feel like, and no existing design system built for regulated, real-money flows.

The first version of theScore Bet was designed by myself and one other designer. It took four months of designing and a year to build covering everything from onboarding and identity verification to deposits, withdrawals, the sportsbook, and the bet slip. I led focus group research sessions, built quick concepts and wireframes through to hi-fi designs in order to launch a successful product.

Every sportsbook screen had to satisfy a regulator before it satisfied a user. Bet slips, odds formats, responsible gambling messaging, KYC and geolocation checkpoints, and self-exclusion tools were all subject to review by gaming commissions, and requirements varied by jurisdiction. Design decisions that would normally be a quick iteration (copy on a confirmation screen, the order of onboarding steps) went through legal and compliance review before they could ship. We built our onboarding and identity-verification flows to be modular so each new state or province could be configured to its specific regulatory requirements without a redesign.

The design strategy we established for theScore Bet was to build a new app that still felt instantly familiar to millions of existing users of theScore. From my perspective, that familiarity was critical because the gaming industry runs on trust and sensitivity around user data. As a result, we needed theScore Bet to inherit the credibility users already had in the media app, not build it from scratch.

When designing the betslip, we decided to keep it persistent across the app so users could build it from anywhere without losing their place. Also all of the apps at the time had geolocation verification after users placed a bet, which in my mind was a broken experience. Users needed to see that they were in the correct location before placing that bet so it had a higher chance of successfully going through.

Live betting required odds and lines that updated in real time without the screen feeling like it was shifting under the user's thumb mid-tap, which meant careful work on animation timing and layout stability around fast-changing numbers.

Registration, KYC, and geolocation aren't typically thought of as "design" work, but for a regulated betting product they were the highest-stakes screens in the app. If we got these wrong, a user wouldn't be able to legally place a bet, regardless of how good the rest of the product is. We treated pre-registration and identity verification as core onboarding design by building clear progress states and plain-language explanations for why each step (ID verification, location check, deposit limits) was required.

The first version of theScore Bet lived apart from theScore's media app out of necessity, but that separation was costing engagement: users had to leave the content that was driving their interest in a bet to go place it. In November 2019 we shipped FUSE, an integration layer that let users build a bet slip directly inside theScore's media app and hand off into theScore Bet to confirm and place it. This was the first time a North American sports media app let users construct a wager without leaving their content feed, and it became the connective tissue between the two products for the rest of my time there.

When Ontario opened its regulated online sports betting and iGaming market to private operators on April 4, 2022, we combined the sportsbook and a new casino product into a single app, theScore Bet & Casino, rather than launching them separately. That meant designing a navigation model and visual language that could hold sportsbook, live betting, and slots/table games as peers, under an AGCO license and an operating agreement with iGaming Ontario, without the casino product feeling bolted onto the sportsbook.

theScore Bet launched in New Jersey on September 3, 2019, becoming the first mobile sportsbook built by a media company in North America. theScore Bet's handle reached $81.6 million in fiscal Q2 2021 (ended February 28, 2021), up 491% year-over-year and 46% quarter-over-quarter, as the betting product scaled across four live US states: New Jersey, Colorado, Indiana, and Iowa.

The single best month on record at that point was March 2021, with $30.8 million in handle. In Ontario's first ten days as a regulated market, theScore Bet was one of just four operators (alongside Bet365, FanDuel, and BetMGM) accounting for 79% of all sports betting app downloads in the province, a strong signal for a media-company entrant going up against established global sportsbooks.

theScore's media app, which fed the betting product through FUSE, was averaging 3.9 million monthly active users and 488 million sessions per quarter by Q2 fiscal 2021, with users opening the app an average of 125 times a month. Across its lifetime, theScore's media app has been downloaded more than 16 million times on Android alone and built a user base north of 10 million. That always-on media audience, and the FUSE integration's ability to convert media attention into betting activity, was central to theScore Bet's growth story relative to sportsbooks without a media property behind them.

Growth in handle didn't translate to profitability on its own: Q3 fiscal 2021 gaming revenue was still negative ($2.5 million net), even as media revenue hit a record $8.9 million the same quarter. That gap between user and handle growth versus gaming profitability shaped a lot of the product and design roadmap during this period, particularly around increasing same-game parlay adoption and in-app casino cross-sell once Ontario launched.

Early on, the team treated regulatory review as a gate at the end of the process. It worked far better once we brought compliance and legal into design conversations from the start, the same way we'd involve engineering. Knowing what a regulator would and wouldn't accept before we designed a flow saved repeated rework, and it meant the most heavily reviewed screens (onboarding, KYC, responsible gambling) got design attention proportional to how much they mattered.

Sportsbook and casino didn't need to look identical to feel like one product. What mattered was that account, wallet, identity, and responsible-gambling controls were singular and consistent. Once those were unified, the sportsbook and casino surfaces could diverge visually to fit their content without users feeling like they'd left the app.