Casino streamers had built large audiences on Twitch by broadcasting themselves playing casino games. The existing model was largely passive — audiences watched, and streamers monetised that attention by pointing followers to casino operators through affiliate links.

The value chain worked like this:

Streamer plays casino games on stream.

Audience watches the stream.

Streamer directs followers to casino operators via affiliate links.

We saw an opportunity to make that relationship participatory. The question that framed the project was: what if the audience could participate in the streamer's play rather than simply watch it?

Streamer creates a shared pool on the platform.

Followers join and contribute funds.

Streamer plays casino games using the pooled bankroll while broadcasting live.

Audience watches the session live.

Winnings are distributed to participants in proportion to their contribution.

Session states, ownership, payouts and visibility all had to be defined from scratch.

Responsibilities

The original idea came from a colleague through an internal innovation programme I was running. My role was to help transform that idea into a viable product — spanning management buy-in, strategy, definition, delivery and launch.

Across the project I was responsible for:

Developing the initial concept into a defined product proposition.

Shaping the core interaction model and defining streamer + participant journeys.

Presenting the concept internally and securing management support and development resources.

Feature ideation, writing user stories and defining product rules and behaviours.

Working with the engineering team through implementation and launch.

Emphasis

Throughout, my job was to keep user value, business value and feasibility aligned as the product took shape.

Unlike a conventional individual casino journey, actions taken by one user affected an entire group. The streamer and participant experiences had to be designed as a connected system.

Streamer journey

Create pool → invite audience → receive contributions → start session → play → finish session → distribute outcome. The streamer needed to manage the pooled session without disrupting the live entertainment experience.

Participant journey

Follow streamer → discover pool → join → contribute → watch → track outcome → receive proportional winnings.

The participant needed to understand what they were joining, what their individual stake represented and how the pooled outcome affected them.

Both journeys were designed together so that every streamer action had a predictable, visible participant consequence — and vice versa.

A major part of my work was translating the evolving concept into user stories that the engineering team could build. The user stories were not simply documentation produced after the product had been defined — they became the tool for defining it.

Writing them surfaced unanswered questions around timing, account balances, ownership, proportional shares and session states.

They forced explicit decisions on error conditions, visibility and how streamers and participants communicated during a session.

Emphasis

Definition through delivery

The concept required dedicated engineering resources. I developed and communicated the proposition to management, connecting the emerging user behaviour with a potential commercial opportunity. Once support was secured, a developer team was assigned to build it.

Translating the same idea for different audiences

Strategic value framed for management.

Product behaviour framed for cross-functional stakeholders.

Actionable requirements framed for the engineering team.

The flow, at a glance: concept → product proposition → management buy-in → dedicated development team → launch.

Our original hypothesis

If we made casino streaming participatory, users would value the resulting shared gaming experience as a standalone product. We believed the combination of community, live entertainment, shared financial participation, a trusted streamer and collective wins and losses could create a new form of social casino play.

What happened after launch

WeSpin launched successfully, but the strongest value of the product turned out to be different from our original assumption. It did not become a mainstream alternative to conventional casino games but t worked particularly well within the existing streamer ecosystem — creating a new way for streamers to engage their audiences, adding participation and shared stakes for viewers. From the operator perspective, the product was not popular among traditional casino players and we shifted the commercial strategy to function as an acquisition mechanism.

The strategic shift

Original proposition: a standalone social casino product based on shared play. What market behaviour showed us: a streamer engagement and customer acquisition product built around shared play. Instead of a streamer simply directing followers to a casino through an affiliate link, WeSpin gave those followers an immediate reason to participate — "join my pool and play with me." The streamer became host, community leader, distribution channel and acquisition mechanism.

Outcome

WeSpin progressed from an internally proposed innovation idea to a launched product with a newly defined interaction model. Its strongest commercial use differed from the original hypothesis, but that learning was itself an important product outcome.

In one line

The purpose of product development is not to prove the original idea right. It is to discover where the value actually is.

Test the competing value propositions much earlier — a consumer hypothesis (people want pooled casino play as an entertainment product in its own right) against a streamer / acquisition hypothesis (streamers want pooled play because it helps them engage audiences and convert followers).

Introduce streamer and viewer interviews, assumption mapping, riskiest-hypothesis testing and early concept and prototype testing before committing engineering resource.

The underlying approach stays the same: reduce ambiguity, understand the opportunity, align stakeholders, define the experience and progressively turn strategy into something a team can deliver.

WeSpin demonstrates my ability to work in the space between strategy and delivery, particularly when the product itself is still ambiguous. The project traces the arc I return to often: idea → product model → user journeys → business case → buy-in → user stories → engineering → launch → learning.

The capabilities exercised across this project: product strategy, product discovery, concept development, innovation management, stakeholder management, user journey definition, user stories, requirements definition and cross-functional delivery.