R1.2:Tasks1

Посты студентов
1

взял слишком большую но насущную проблему.
описал верхнеуровнево так:

Планирование по 4 направлениям-продуктам

P1. tradium - Nikita macro BRD, phases 0,1,2, need to create milestones. Wait until we finish terminal. No backlog. PO: George

P2. e8 marketing tool. PO: James. Phase 0 for Artem 4 tasks. Lots of docs by James. Artem developer. Artem will bring more people. Funding? No backlog.

P3. TraderScore (leftovers from Armando). PO: George. Alexey Geraskin + Eugene Shestakov. two developers. No backlog.

P4. terminal: added hyperliquid. Dylan payments to Delegate 3%?

1. Опишите, что (какие объекты) должно измениться в физическом мире после того, как задача будет реализована. Явно пропишите: с точки зрения какой роли вы будете смотреть на ситуацию.

У нас должно появиться 4 MVP продуктов.

На них нужно смотреть со стороны ролей:

R1. пользователей (трейдеров)

R2. команды разработки e8markets, которые разрабатывают код систем

R3. команды маркетинга e8markets, которые будут продвигать продукты

R4. команды бизнеса, которые должны зарабатывать на этих продуктах

Опишите, что вас смущает, что у вас “дребезжит”, то есть, распишите нынешнюю ситуацию/контекст с выбранной точки зрения/viewpoint.

меня смvущает

D1. несоответствие количества разработчиков амбициозности задач

D2. отсутствие необходимых артефактов: vision, OKRs, user journey mapping, бэклога features/user stories/tasks

2. Выделите в описании агентов, которые будут теперь действовать иначе. R1-R4

Назовите эти иные действия.

For R1 для продукта P3 будут иные действия:

A1: трейдер сможет посмотреть на свой TraderScore чтобы оценить прогресс в своем обучении

A2: результаты торгов трейдера изменяться в лучшую сторону

A3: трейдер сможет посмотреть на параметры drift/tilt/focus/risk чтобы оценить свой прогресс по каждому из них

A4: поведение трейдера по параметрам drift/tilt/focus/risk изменится в лучшую сторону

Назовите результаты этих действий: какие объекты изменят состояния (с точки зрения выбранной роли), назовите создаваемые артефакты.

Проверьте, назвали ли вы все объекты из пункта 1?

3. Распишите, каким образом/способом/методом вы будете проверять, что в физическом мире произошли нужные вам изменения. Какие замеры вы будете делать, чтобы увидеть, что изменения реальны, что вы будете измерять?

M1: трейдер стал реже “blow account” (количество дней до того как трейдер потерял свой аккаунт увеличилось)

M2: drift уменьшился

M3: tilt уменьшился

M4: risk уменьшился

M5: focus увеличился

4. При каких условиях результат возможно получить? А при каких невозможно?

- команда разработки каждую неделю демонстрируют видимый прогресс

- команда маркетинга каждую неделю демонстрируют видимый прогресс

5. Какие сигналы могут вам указать заранее на то, что делается что-то не то?

- отсутствие осязаемого результата (фичи, для команды разработки, новые пользователи для команды маркетинга)

понял, что дальше нужно расписывать по каждому направлению, и сделал такой шаблон:

TraderScore FPF Planning Card

Status

Draft v0.1. This card is a grounding artifact, not an approved backlog or milestone plan.

Sources

  • Product track notes in products/TraderScore/AGENTS.md.

  • FPF repair guidance in products/FPF-product-planning-analysis.md.

  • Mockup reference: https://www.e8x.ai/, fetched on 2026-05-21.

Product Boundary

TraderScore is the trader performance intelligence product inside the E8/SimFi training environment.

Inside the MVP boundary:

  • Trader-facing score dashboard for funded/simulated trading accounts.

  • A visible 1000-point TraderScore or SimFi score.

  • Pillar-level scoring for risk, execution, behavior, consistency, and adaptation.

  • State monitors for drift, focus, tilt, and risk.

  • Account-level and multi-account track record views.

  • Live activity feed for behavior/risk signals.

  • Daily focus or action plan that translates score signals into next trading behavior.

  • Population/rank comparison against a trader cohort.

Outside the MVP boundary until explicitly approved:

  • Brokerage execution, deposits, margin, or live broker custody.

  • Guaranteed trading improvement claims.

  • Full coaching curriculum.

  • Automated trade execution or forced trade blocking.

  • Commercial payout/payment logic.

  • Back-office admin tooling beyond what is required to validate the trader-facing MVP.

MVP Promise

After the MVP exists, an E8 trader can open a TraderScore experience and see a current, evidence-backed view of their trading performance, behavioral state, and next improvement focus across one or more E8 accounts.

The MVP does not promise to make the trader profitable. It promises to make the trader’s score, risk/behavior signals, cohort position, and next improvement action visible enough that the trader and E8 team can inspect progress and decide what to improve next.

Viewpoints

Trader View

The trader sees a current score, pillar breakdown, risk/behavior monitors, account track record, cohort rank, and a focused action plan.

The trader can answer:

  • What is my current TraderScore?

  • Which pillar is limiting my score now?

  • Am I drifting, tilting, losing focus, or loosening risk?

  • How do I compare with the relevant trader population?

  • What concrete action should I take in the next session?

Engineering View

The engineering team has a bounded product surface to implement and validate: scoring inputs, score calculation, dashboard surfaces, activity signals, account aggregation, and evidence links.

The team can answer:

  • Which data inputs produce each score and monitor?

  • Which code modules own score calculation, signal generation, and UI publication?

  • Which score values are computed versus mocked?

  • Which user/account states are supported in MVP?

Marketing View

The marketing team gets a product story grounded in inspectable trader improvement signals instead of generic analytics language.

The team can answer:

  • Which visible TraderScore surfaces can be shown in campaigns?

  • Which claims are allowed: score visibility, behavioral feedback, training-ground insights.

  • Which claims are not allowed without evidence: profitability improvement, account survival improvement, causal guarantees.

Business View

The business team gets an MVP that can support retention, differentiation, and trader development, while keeping evidence and revenue assumptions explicit.

The team can answer:

  • Does TraderScore increase trader engagement with E8?

  • Does it support better trader retention or repeat participation?

  • Does it create a defensible product difference versus generic prop-firm dashboards?

  • What evidence is required before claiming business impact?

Roles

Role

Holder

Responsibility

Product Owner

George

Own product scope, acceptance decisions, and prioritization.

Legacy Source Owner

Armando

Source of leftover context, prior work, or unresolved decisions. Holder status must be confirmed.

Developer

Alexey Geraskin

Implement or validate assigned TraderScore product/code work.

Developer

Eugene Shestakov

Implement or validate assigned TraderScore product/code work.

Trader/User

E8 trader

Uses TraderScore to inspect performance and adjust trading behavior.

Engineering Team

E8 Markets development team

Builds scoring, dashboard, signal, and data integration surfaces.

Marketing Team

E8 Markets marketing team

Turns approved product surfaces into accurate external/internal messaging.

Business Team

E8 Markets business stakeholders

Evaluate retention, revenue, differentiation, and product viability impact.

Changed Actions

Trader Actions

  • The trader checks a current TraderScore before or after trading sessions.

  • The trader inspects pillar scores such as risk integrity, execution quality, behavioral stability, consistency/durability, and adaptation/context fit.

  • The trader monitors drift, focus, tilt, and risk state instead of only P&L.

  • The trader reviews live activity signals such as loss-cap risk, elevated drift, pace above baseline, or early exits.

  • The trader follows a daily focus/action plan such as holding winners longer or skipping borderline setups.

  • The trader compares their rank and score trajectory against a relevant population or cohort.

Engineering Actions

  • Developers implement a score model with named inputs, outputs, and calculation ownership.

  • Developers connect account/trade data to score, pillar, and monitor outputs.

  • Developers distinguish computed values from mock/demo values.

  • Developers expose evidence or traceability for score-affecting signals.

  • Developers ship weekly demonstrable product increments that show real state changes, not only documentation.

Marketing Actions

  • Marketing uses approved TraderScore surfaces and screenshots to explain the product.

  • Marketing avoids causal or profitability claims until the evidence plan supports them.

  • Marketing tests messaging around trader self-awareness, behavioral feedback, training-ground improvement, and cohort ranking.

Business Actions

  • Business stakeholders evaluate TraderScore using engagement, retention, conversion, and cohort metrics.

  • Business stakeholders decide whether TraderScore becomes a core E8 differentiation claim, a retention feature, or an internal development tool.

  • Business stakeholders approve which claims can be made commercially.

Changed Objects

Object

Current State

MVP Changed State

Trader account

Has trade/account history but no confirmed TraderScore surface.

Has visible score, pillar breakdown, behavior/risk monitors, and account context.

TraderScore / SimFi score

Concept exists in mockup; calculation status unknown.

Current score is displayed with calculation method, timestamp, and supported account scope.

Score pillars

Mockup shows risk, execution, behavior, consistency, and adaptation.

Pillars are defined, populated, and linked to score contribution.

Drift signal

Mentioned as meter/activity signal.

Drift has a definition, input data, severity state, and display surface.

Tilt signal

Mentioned as tracker.

Tilt has a definition, input data, severity state, and display surface.

Focus signal

Mentioned as meter.

Focus has a definition, input data, severity state, and display surface.

Risk signal

Mentioned as risk check/radar/loss-cap breach risk.

Risk has a definition, input data, severity state, and display surface.

Activity feed

Mockup shows real-time signals.

Feed displays generated trader events with timestamps, severity, and source logic.

Action plan

Mockup shows daily focus and action plan.

Trader receives one or more concrete next-session actions tied to score evidence.

Population rank

Mockup shows percentile, better-than count, and cohort average.

Rank is computed against a defined cohort with population size and window.

Multi-account record

Mockup shows seven accounts and cross view.

Trader can select all accounts or a supported account and see score context.

Product artifact set

No backlog exists yet.

Product card, measurement definitions, acceptance criteria, milestones, and proposed backlog exist.

MVP Acceptance Checks

  • A trader can open the TraderScore MVP and see a current score for at least one supported account.

  • The score display includes score value, score window, and timestamp or freshness indicator.

  • The dashboard shows at least four behavior/risk dimensions: drift, tilt, focus, and risk.

  • Each displayed dimension has a documented definition and data source.

  • The dashboard shows a pillar breakdown that explains the score at a useful level.

  • The trader can see at least one concrete action recommendation tied to a detected bottleneck.

  • The product can distinguish demo/mock data from real computed account data.

  • Engineering can trace a displayed score or signal back to its input data and calculation version.

  • Marketing has a claim-safe description that does not overstate profitability or causality.

Missing Artifacts

Product Definition

  • TraderScore product vision.

  • MVP scope statement approved by George.

  • User journey map for trader pre-session, live-session, post-session, and review flows.

  • Clear decision on whether the product name is TraderScore, SimFi Score, or both.

Scoring and Measurement

  • TraderScore formula or scoring method description.

  • Definitions for drift, tilt, focus, and risk.

  • Pillar definitions for risk integrity, execution quality, behavioral stability, consistency/durability, and adaptation/context fit.

  • Baseline and target values for each MVP metric.

  • Measurement window definitions: session, day, 7 days, 30 days, 90 days, YTD.

  • Evidence source map: trade data, account data, order changes, loss-cap events, session timing, user actions.

  • Causal-use guardrails for claims about improved trading outcomes.

Engineering

  • Inventory of Armando leftovers.

  • Current code/data location for TraderScore-related work.

  • Data availability audit.

  • Technical architecture sketch.

  • Calculation versioning plan.

  • Dashboard implementation scope.

  • QA plan for score correctness and data freshness.

Product Management

  • Milestone map.

  • Acceptance criteria.

  • Proposed backlog with feature/user story/task levels clearly separated.

  • Owner decisions for unresolved scope.

  • Release/handoff target.

Marketing and Business

  • Approved product messaging.

  • Claim register for allowed and blocked claims.

  • Cohort/ranking methodology that can support external messaging.

  • Business success metrics: activation, engagement, retention, conversion, repeat purchase, or funded-account survival.

Open Questions

  • Which existing system contains the TraderScore code or prototype?

  • Is the mockup intended as the MVP target, an aspirational dashboard, or a concept direction?

  • Which user segment is first: funded traders, challenge traders, all E8 traders, or internal reviewers?

  • Which data is available today for score calculation?

  • What was left over from Armando and what is still valid?

  • Which parts should Alexey own and which parts should Eugene own?

  • What is the minimum score model acceptable for MVP?

  • What evidence is needed before claiming that TraderScore improves account survival or trading behavior?

FPF Notes

  • Treat mockup labels as source observations, not product commitments.

  • Separate score publication from evidence: a dashboard value is not enough unless calculation method, scope, and freshness are known.

  • Avoid causal claims until a causal-use/evidence plan exists.

  • Create milestones before backlog tasks.