Fixing the operating model to find the social-trading product.

Context

ADSS operated four trading products across institutional, private, and retail markets.

The business served experienced traders who understood leverage, execution, spreads, and risk.

It also wanted to grow among customers who did not.

That created two connected product problems.

The first was external.

New-to-market retail users were entering a product category designed around expertise. The platforms gave them access to instruments, charts, and execution tools, but not necessarily the confidence to act.

The second was internal.

The product organization was fragmented across platforms, functions, and vendors. Research was repeated. Design decisions were difficult to compare. Product teams commissioned overlapping work because previous evidence was hard to find, harder to trust, and rarely connected to the decision it was supposed to inform.

The company was trying to find its next retail-growth proposition through an operating model that made every new proposition slower and more expensive to evaluate.

The obvious temptation was to treat these as separate issues:

• Build the new product
• Fix product operations later

They were not separate.

A weak operating model does not only waste money.

It changes which product opportunities the organization is capable of seeing.

The Real Problem

At first glance, retail churn looked like a familiar usability problem.

The platform was dense.

Onboarding carried regulatory friction.

Trading terminology was difficult for inexperienced customers.

The interface exposed similar complexity to a twenty-year forex trader and someone placing a first position.

The default response would have been:

• Simplify onboarding
• Add more education
• Improve tooltips
• Reduce interface friction
• Explain risk more clearly

All reasonable.

None addressed the deeper issue.

Our analysis tracked where new-trader cohorts dropped inside the activation funnel.

The pattern suggested that many new traders did not primarily lack information.

They lacked confidence in their own judgment.

They were more comfortable learning from, observing, or following other traders than making isolated decisions inside a professional trading interface.

That changed the product question.

It was no longer:

How do we make the existing platform easier for beginners?

It became:

What product would allow a beginner to participate before they have developed expert-level confidence?

That was the opening for social trading.

[ + ]

My Role

I joined ADSS as Head of Product, reporting directly to the Chief Product Officer.

My remit crossed product discovery, product definition, research, design, platform transformation, and operating-model improvement across four regulated products.

I directly led the social-trading initiative from customer discovery and proposition definition through MVP delivery and go-to-market planning.

I also:

• Supported the redesign of ADSS’s proprietary trading platform
• Contributed to the transition away from dependence on MT4 and MT5
• Managed evaluative work around an AI-powered market-insights proposition led by the Product Director and external vendors
• Restructured product research and design operations
• Consolidated overlapping vendor and internal workflows
• Worked with KPMG, Adaptive Financial Consulting, and Turing across transformation and technology programs
• Participated in executive product and market-expansion discussions with the CPO

I was not the sole owner of every trading platform or transformation stream.

My role was to connect product opportunity, customer evidence, proposition design, and the operating system required to deliver them.

[ + ]

Decision 01 — Stop treating novice churn as an interface defect

The trading platforms were largely structured around experienced-market behavior.

The underlying model assumed that the user:

• Understood the instruments
• Could interpret market information
• Knew how much risk to take
• Was confident enough to act independently
• Needed speed and control more than reassurance

That model worked for experienced traders.

For new retail customers, it created a confidence cliff.

The product gave users execution capability before it gave them a credible path toward decision confidence.

We could have responded by simplifying the interface.

But a simpler expert product is still an expert product.

The evidence pointed toward a different opportunity: let users learn and act through the visible behavior of other traders.

This reframed social trading from a feature idea into a product thesis.

The discovery work also surfaced a ceiling.

We measured the total potential user base (TPUB): active and churned traders in the UAE who matched our ideal customer profile (ICP). It came to around 70,000 users.

That number reframed the growth question. Competing harder on the existing platform could win a larger share of a fixed pool. It could not enlarge the pool.

To grow past that ceiling, we had to expand the category itself, not just the funnel. Social trading was the category-creation bet: a proposition capable of reaching customers the expert-trading TAM had never included.

The growth opportunity was not only making trading easier. It was making participation possible before expertise had fully formed.

That distinction shaped the proposition that followed.

[ + ]

Decision 02 — Turn the trust gap into a social-trading MVP

Once the trust problem was explicit, the next challenge was avoiding a superficial answer.

Adding a social feed to a trading platform would not create a social-trading product.

The proposition needed to answer:

• Why should a user trust another trader?
• What performance information should be visible?
• How should risk be represented?
• What should a user copy: a trader, a strategy, or an individual position?
• How much control should remain with the user?
• Where should regulatory warnings appear?
• What happens when copied performance declines?
• How does the product avoid turning social proof into reckless imitation?

The work moved from customer discovery into proposition definition, product architecture, MVP planning, and go-to-market preparation.

The MVP was designed to test the core behavioral thesis:

Would visible, attributable trader behavior reduce the confidence barrier for new retail customers?

That was more valuable than testing whether users liked a collection of social features.

The MVP’s north-star metric was activation of new retail cohorts: could social participation move first-time users from access to a first confident action.

We instrumented the thesis around activation rate and early-cohort retention, not feature engagement, and required that any lift arrive without unacceptable regulatory or risk exposure.

The MVP was delivered with a go-to-market plan, but it had not reached enough commercial maturity during my tenure to claim a scaled outcome.

That distinction matters.

The product thesis became defensible.

The long-term market result remained unfinished.

[ + ]

Decision 03 — Stop producing new evidence long enough to retain the old evidence

While the social-trading proposition was developing, the operating-model problem became impossible to ignore.

The same questions were being studied repeatedly across four products:

• Onboarding funnel drop-off
• KYC completion rate and where applicants dropped off
• Pricing comprehension
• Platform switching
• Trust
• Beginner behavior
• Product complexity

Each project was scoped, recruited, delivered, and synthesized independently.

The same insight could be purchased several times without becoming organizational knowledge once.

The instinct was to improve research velocity.

I made the opposite decision.

Before optimizing how quickly the team produced new studies, I paused long enough to build a centralized product-evidence repository.

The repository was not organized around study names.

It was indexed by:

• User intent
• Product surface
• Funnel stage
• Customer segment (ICP)
• Behavioral problem
• Product decision
• Confidence
• Applicable markets
• Previous action
• Remaining uncertainty

The distinction was important.

A library tells the team what research exists.

A decision system tells the team what the organization already knows, and whether that knowledge is strong enough to act on.

This took approximately six weeks and temporarily made new delivery slower.

There was pressure to return to the existing study pipeline.

I held the line because increasing output without retaining insight would have made the original problem worse.

By months four through six, product teams could answer some roadmap questions from existing evidence instead of commissioning another project.

The repository started to compound.

Decision 04 — Trade local optimization for portfolio comparability

Each of the four product teams had legitimate reasons to want its own methodology.

Institutional traders were not retail traders.

MetaTrader power users were not first-time customers.

The proprietary platform did not have the same interaction model as MT4 or MT5.

A bespoke framework for every product would have produced more local precision.

It would also have preserved the organization’s inability to compare anything across the portfolio.

I chose comparability over maximum tailoring.

We introduced a shared product-evaluation framework across all four platforms:

• Common recruitment principles
• Shared task categories
• Consistent scoring
• Reusable behavioral measures
• Comparable journey definitions
• Standard evidence and severity formats
• Consolidated vendor processes

The trade-off was real.

Some individual studies became less customized to one product team’s preferred method.

The gain was strategic.

For the first time, leadership could compare:

• Where platforms created the same friction
• Which user problems were portfolio-wide
• Which insights could be reused
• Which platform served which customer segment best
• Where multiple teams were paying to solve the same problem

The framework also reduced vendor fragmentation and project cost.

More importantly, it changed the unit of analysis from a single interface to the product portfolio.

For the first time, comparable activation and funnel-drop-off measures existed across segments, so leadership could see where the same friction recurred rather than reading four incompatible study formats.

[ + ]

From Evidence to Product Strategy

The repository and shared framework were not the final outcome.

They were the infrastructure required to change how product decisions were made.

The product function began entering strategy conversations with a stronger evidence base.

Instead of presenting study summaries, we could frame:

• Which customer segment was underserved
• Where the platform architecture limited growth
• Which propositions deserved MVP investment
• Which product questions had already been answered
• Where evidence was too weak to justify a roadmap commitment
• Which improvements applied across the portfolio
• Where regulated-market expansion created new product requirements

This moved the function upstream.

The goal was not to earn influence by producing more polished reports.

It was to make product evidence usable before the decision had already been made.

[ + ]

Outcome

The operating-model changes produced measurable results:

• Approximately $5 million in annual savings
• Around 20% lower project costs
• Approximately 35% faster time-to-market
• More than 30 design sprints across four products
• Reduced duplication across teams and vendors
• A reusable evidence base for product and market-expansion decisions

The social-trading initiative moved from customer evidence into a defined proposition, MVP delivery, and go-to-market planning.

The proprietary-platform transformation gained a stronger cross-product discovery and evaluation base.

The product function also became more visible in executive strategy discussions with the CPO, partners, and external transformation teams.

The most important change was structural.

Before the restructure, the organization repeatedly produced insight.

After it, the organization had a better chance of remembering, comparing, and applying it.

The savings were the visible result.

The deeper outcome was an operating model capable of supporting more consequential product bets.

What I Would Do Differently

I would have forced a clearer path from social-trading MVP to regulated market pilot.

We proved enough of the product thesis to justify the MVP.

But the next stage needed sharper commercialization criteria:

• Which customer segment should enter first?
• What behavior would prove increased confidence?
• What risk metrics would stop the pilot?
• What would qualify a trader to be followed?
• What activation or retention improvement would justify scale?
• Which market offered the best regulatory and commercial entry point?

A stronger pilot plan would have made the path from proposition to product more difficult to postpone.

I would also have pushed harder for an explicit beginner-to-expert product architecture.

The platform still exposed too much of the same density and complexity to very different users.

We discussed progressive experiences and simplified modes, but the engineering cost, platform dependencies, and regulatory implications made the decision difficult.

Those constraints were real.

The product opportunity was still worth solving.

A first-time retail trader and an institutional user should not be forced through the same cognitive and interaction model simply because they use the same execution infrastructure.

Finally, I would have connected the operating-model metrics more directly to product outcomes.

We could measure lower cost and faster time-to-market.

The more mature system would also track:

• Which reused insights changed roadmap decisions
• Which product bets were stopped earlier
• How often teams avoided duplicate discovery
• Whether faster delivery improved activation, cohort retention, and a product north-star, not only cost and revenue
• Which evidence remained valid over time

Efficiency matters.

Its value becomes stronger when it can be traced to better products, not only cheaper delivery.

Product Lessons

01  Retail churn is not always an onboarding problem. Sometimes the product assumes a level of confidence the user has not developed.

02  Social trading is not a feed. It is a trust, risk, and decision architecture.

03  An MVP should test the behavioral thesis, not the popularity of a feature list.

04  A product organization that cannot retain insight will keep paying to rediscover the same customer.

05  Repository design is product design when the user is the organization making decisions.

06  Cross-product comparability can be more strategically valuable than methodological purity.

07  Faster delivery is useful only when the organization is delivering the right thing.

08  Product transformation requires changing both the proposition and the system capable of producing it.

Closing Note

/* the two products */

> One product helped new traders borrow confidence.
> The other helped the organization retain judgment.

> Both were responses to the same failure:
> too much complexity,
> carried by the person least equipped to absorb it.

// product strategy is also the design of the organization making the product