For Years, My Work Ended Too Early

For almost a decade as a Product Designer, I worked on dozens of products.

I conducted research.
Facilitated workshops.
Designed user journeys, flows, and design systems.
Defended prototypes with conviction.
And my role almost always ended at the same point: the handoff.

After that, the product became someone else's responsibility. Engineering implemented it. The business team sold it. Marketing acquired users. And the market (the part I rarely got to observe up close) decided whether any of it actually made sense.

I helped define the product.
But I rarely experienced the product in the way that truly mattered.
At some point, that started to bother me.

And it turned into a question:
What happens when a Product Designer follows the entire journey?

Not just designing the solution.
But discovering the problem. Building it. Shipping it. Charging for it. And learning directly from the consequences.
That question is what led to Tennis Glicko.

The goal was never to build a tennis website

People assume I built this because I like tennis.
That wasn't the reason.

Tennis was simply the testing ground for a much bigger hypothesis:
Can a Product Designer, in 2026, use AI to build, validate, and monetize a real product almost entirely alone?

I didn't want to create a Figma case study.
I wanted to build a business. With real users. Real problems. And the most definitive signal of all: someone entering their credit card information.
I deliberately chose one of the most hostile environments I knew.

On one side, a market filled with exaggerated promises. On the other, Pinnacle (arguably the most efficient betting market in the world.)

If I could build something honest and desirable there, I could build it anywhere.

Discovery started before the first screen

Before opening Figma, I spent weeks trying to understand the market.
I analyzed competitors. Studied how odds worked. Immersed myself in communities. Spoke with users. Read forums.

And I found a pattern.
The promise was always the same: make more money.
The proof looked the same too. Profit screenshots. Carefully selected results. Wins highlighted. Losses hidden.
An entire industry built on survivorship bias.

But there was something even more interesting happening beneath the surface.Trust was broken. Nearly every user I spoke with had already been disappointed by a similar service.

When I organized the research using the Jobs To Be Done framework, three clear needs emerged:

• I want to quickly identify where the market and a competent model disagree.

• I want to simulate scenarios myself before making a decision.

• I want to understand whether my decisions are improving over time.

Notice the pattern.
Two out of the three jobs put the user in control.
The discovery process was telling me something important: people didn't want a prophet. They wanted a tool.

I wrote that insight down.
But I still didn't understand how important it would become.

Defining the MVP: Great products are an exercise in elimination

My initial hypothesis was simple.
If I could build a model that performed better than the average bettor, I could sell value signals.
The temptation to expand was enormous. Community features. Mobile app. Rankings. Notifications. Advanced dashboards.

I had new ideas every day.

The question that saved me months of wasted effort was:
What's the smallest product capable of proving or disproving the hypothesis?

The MVP was reduced to four pillars:

• Model-generated probabilities

• Model vs. market divergence (VOPO — Value Over Pinnacle Odds)

• Matchup simulator

• Premium subscription

Nothing else.

The design knew something I didn't yet know

The design decisions ended up revealing something interesting.
The freemium wall was one of the hardest decisions in the project because it sits exactly at the intersection of UX, business, and ethics.
The strongest signals appeared blurred for free users. You could tell something important was there, but you couldn't see exactly what it was.

The difference between generating curiosity and generating frustration was incredibly small.
And it depended almost entirely on how the experience was communicated.
I also built a visual identity deliberately distant from traditional betting products.

A near-black background. Every numerical value displayed in a monospace typeface, because aligned numbers subtly communicate rigor.
No exaggeration. No promises. No "win now" messaging.
The goal was to communicate analysis, not emotion. Confidence, not euphoria.

Today, I see an interesting irony.
My design was already selling a tool.
My copy was still trying to sell an oracle.

The designer understood it before the entrepreneur did.

AI didn't replace my work, it expanded my reach

There's a recurring narrative that AI is replacing professionals.
My experience was exactly the opposite.
AI didn't replace Product Design.
It dramatically expanded the reach of a Product Designer.

I used AI to explore architectures, create components, structure APIs, refine copy, interpret data, and plan features.
But there was one line it never crossed.

AI never made a product decision.

When I had clarity, it accelerated execution.

When I lacked clarity, it simply helped me build the wrong thing faster.

That was one of the biggest lessons of the project.
In the future, the differentiator won't be who can execute.
It will be who can decide.

When the designer becomes CEO/CTO/CFO…

For the first time in my career, I was responsible for everything.

Research. Strategy. UX. UI. Code. Databases. Metrics. Acquisition. Conversion. Retention. Monetization.

The product launched in four languages from day one.

And that completely changes how you perceive product development.

In Figma, decisions feel free.

In production, every decision has a cost.

Every feature increases maintenance.

Every screen increases complexity.

Every choice must justify its existence.

That's when I realized that building products is far more an exercise in elimination than creation.

And that's also when I understood something important:

The Product Designer I used to be started at the wireframe and ended at the handoff.

The Product Designer this project turned me into starts with a business hypothesis and doesn't rest until users are paying for the right thing.

The Night the Data Destroyed My Thesis

It was almost midnight when the backtest finished.

The result appeared on the screen:

ROI: -1.1%

Exactly the bookmaker's margin.

450,000 matches used to calibrate the model. Two years of data. More than 3,000 real bets.

And my supposed profit detector wasn't beating the market.

It was matching it, and paying commission (juice).

I stared at the screen for a while.

Long enough that I couldn't tell you how long.

The easy way out appeared immediately.

Ignore it.

Hide it.

Publish only the winning results.

Pretend the outcome was better.

Nobody would know.

I would.

So I asked the only question that actually mattered:

What is this test measuring? And what is it not measuring?

That's when I realized I was looking at the wrong number.

ROI wasn't the only information available.

There was another metric I had ignored because I was too busy being disappointed:

ECE: 0.69%

The model was extremely well calibrated.

When it predicted 70%, the outcome happened close to 70% of the time.

Consistently.

Auditable.

Reliable.

And it was exactly what that burned-out bettor from my discovery research had asked for: data they could trust to make their own decisions.

That's when the realization hit me.

The sentence that summarizes the entire project:

I spent months trying to sell gold (profit predictions) while sitting on a gold mine of high-quality shovels.

I wasn't building a profit machine.

I was building an analysis tool.

The pivot: From prediction to capability

That's when I stopped selling predictions.

And started selling capability.

The capability to analyze.

The capability to decide.

The capability to find meaningful information in seconds.

The product itself barely changed.

The positioning changed completely.

The simulator. The VOPO metric. Match analysis. Performance tracking.

They had always been tools.

I was simply insisting on calling them an oracle.

The backtest didn't kill the product.

It killed the wrong narrative about the product.

And the audience changed, for the better.

Selling gold attracts people who want to get rich quickly: a volatile audience that churns after the first bad week because variance always wins in the short term.

Selling shovels attracts people who value consistency.

And those people stay.

Promising an outcome you don't control bakes churn into inevitable disappointment.

Delivering a capability that remains consistently true builds retention on solid ground.

In every gold rush, the people who became truly wealthy were the ones selling pickaxes.

Results

In four months:

• Product launched and operating continuously in 4 languages

• More than 200 registered users across 15 countries

• Proprietary model using 42 variables per prediction

• More than 11,170 real bets audited live

• Backtest validation using 465,000 tennis matches

• Model ECE of 0.69% — calibration better than Pinnacle's opening line

• A lean but recurring international subscriber base

It's not a unicorn.

It's not a billion-dollar startup.

But it's a real product.

Built. Validated. Monetized.

And repositioned based on evidence.

What I learned about product design in 2026

Tennis Glicko changed how I see the profession.

Not because of what it taught me about AI.

But because of what it taught me about judgment.

AI dramatically reduced the cost of execution.

Building has never been more accessible.

But discovery is still hard.

Interpretation is still hard.

Positioning is still hard.

Decision-making is still hard.

Technology made building cheaper.

And increased the value of judgment.

And judgment has always been at the heart of Product Design.

I didn't become an engineer.

I became a designer whose material is no longer the screen.

It's the entire product.

Conclusion

When I started this project, I wanted to answer a question:

Can a Product Designer build a real product alone?

Today, the answer is clearly yes.

But that is no longer the most interesting question.

The question that remains is:

What does a Product Designer do when they can build anything?

My answer is simple.

They spend less time designing screens.

And much more time discovering what deserves to exist—and having the courage to sell the shovel when everyone around them is trying to sell gold.

Because in 2026, execution stopped being the bottleneck.

Judgment became the product.