Skip to content
Erik Tagirov
Menu

Product ownership

From an unclear request to work the team can start.

I clarify the problem, work through options with stakeholders and turn agreed decisions into priorities, scope and acceptance criteria.

My role continues during delivery: resolving questions, checking the result and deciding what to change next.

Explore the KYC example

Design for how the work actually happens

In the TrustChange onboarding project, company preparation and personal verification could happen at different times and involve different people. That changed how we designed the flow, its stages and saved progress.

I led the design in close collaboration with Compliance and Engineering.

One onboarding process. More than one person.

Company preparation and personal verification do not always happen in the same session.

01 / 03

Company assistant

Prepare the company documents

An assistant can begin the business onboarding and prepare the required information before the director is available.

The document requirements were defined with Compliance.

The product decision: support the hand-off without losing progress.

Simplified process illustration — not the original product interface.

The questions behind the process

This is the operating model I use to connect incoming requests with product decisions, delivery and learning. It is a working approach, not a claim to a new methodology.

Choose a stage to see the questions and documents behind it.

Choose a stage to see the questions and documents behind it.

  1. SignalUnderstand where the request came from and what needs attention.

    What I check

    • Source of the request is identified and logged
    • Request type is classified (bug, feature, debt, strategic)
    • Urgency is assessed against defined criteria
    • Actionable signals are separated from background noise

    Working artifacts

    Intake log · Classification guide · Triage criteria

    Ready to move forward

    Incoming requests are logged, classified, and routed to the right next step.

  2. DiscoverySeparate the problem, the evidence and the assumptions.

    What I check

    • The core problem is framed without an assumed solution
    • Key assumptions are explicitly documented
    • Relevant stakeholders and users have been consulted

    Working artifacts

    Problem brief · Assumption log

    Ready to move forward

    The problem is understood well enough to make a real decision about whether and how to solve it.

    Where higher risk calls for more depth

    Deep discovery focusing on evidence, user research, and cross-functional boundary alignment to de-risk high-stakes decisions.

    • Problem framed via verified user pain-points and data
    • Critical assumptions have been tested, or the remaining uncertainty is recorded.
    • Edge cases and boundary conditions are explicitly mapped
    • Alternative problem definitions have been considered
  3. DecisionAgree whether to proceed, defer or stop, and record why.

    What I check

    • The decision is recorded as proceed, defer, or reject
    • The decision has a clear owner
    • Constraints and dependencies are noted

    Working artifacts

    Decision log · Options brief

    Ready to move forward

    Every item progressing further has a documented decision and a named owner behind it.

    Where higher risk calls for more depth

    Rigorous decision gating including options analysis, trade-off documentation, and formal sign-offs from key stakeholders.

    • Documented comparison of at least two alternatives
    • The proposed direction is checked against the agreed goals.
    • Operational and technical risks are explicitly accepted
    • Named accountability for the outcome is recorded
  4. PrioritisationOrder the work against value, timing and dependencies.

    What I check

    • Strategic importance is assessed against goals
    • Timing urgency is validated
    • Dependency impacts are understood

    Working artifacts

    Ranked backlog · Dependency view

    Ready to move forward

    The backlog reflects a defensible ordering that the team can explain and stakeholders can follow.

    Where higher risk calls for more depth

    Strategic sequencing using weighted criteria, cross-backlog dependency mapping, and long-term roadmap impact analysis.

    • Value/Effort ratio is calculated and challenged
    • Dependency conflicts with other work-streams are resolved
    • Opportunity cost of deferring other items is accepted
    • Resource availability for full-depth execution is confirmed
  5. ShapingDefine the scope, acceptance criteria and important edge cases.

    What I check

    • The intent of the work is clearly stated
    • Acceptance criteria are binary and testable
    • Logical constraints are defined

    Working artifacts

    Shaped brief · Acceptance criteria

    Ready to move forward

    The team has enough context to start, and unresolved questions are visible.

    Where higher risk calls for more depth

    Full-spectrum shaping: inclusive of technical architecture notes, detailed edge cases, and cross-functional quality standards.

    • Technical implementation notes included for context
    • Edge cases and error states are explicitly handled
    • Security / Accessibility / Performance requirements defined
    • Downstream impacts on documentation or support are noted
  6. Delivery supportResolve questions and keep implementation connected to the agreed intent.

    What I check

    • Clarification requests are resolved quickly
    • Edge cases that emerge are decided, not avoided
    • Scope remains connected to the original intent
    • Acceptance criteria are used as the active reference

    Working artifacts

    Clarification log · Scope interpretation notes

    Ready to move forward

    The PO is a reliable point of contact during delivery — reducing interruption while protecting product intent.

  7. ValidationCheck the delivered work against the agreed criteria and release conditions.

    What I check

    • Acceptance criteria are checked systematically
    • Defects are separated from scope change requests
    • Deployment readiness is confirmed
    • Feedback is recorded and assessed for its effect on the release or follow-up work.

    Working artifacts

    Acceptance checklist · Release validation notes · Feedback queue

    Ready to move forward

    What was delivered matches what was shaped, and release happens because readiness is confirmed.

  8. Review and learningCompare the outcome with the original intent and decide what changes next.

    What I check

    • Actual impact is compared to the original decision rationale
    • Signal quality and accuracy are assessed in hindsight
    • Process friction points are noted
    • Backlog implications are identified and acted on

    Working artifacts

    Outcome review · Retrospective notes · Process updates

    Ready to move forward

    Learning from each cycle improves the accuracy and speed of future iterations.

Use the depth the work needs

Higher risk or uncertainty

Use deeper discovery, options analysis and cross-team review when the cost of getting it wrong is high.

Full path: show details

Used when uncertainty is high, scope crosses multiple boundaries, or the risk of failure is significant. The full path can draw on all eight stages: thorough discovery, structured decision-making, careful prioritisation, complete shaping, active delivery support, and rigorous validation. Used for new features, major changes, and high-stakes releases.

Known, bounded changes

Use a shorter brief and fewer formal steps when the work is understood. Keep ownership, acceptance checks and follow-up explicit.

Lightweight path: show details

Used when uncertainty is low, scope is limited, and the risk of getting it wrong is manageable. The shorter path focuses on Signal → Decision → Shaping → Delivery, with acceptance checks and follow-up kept explicit. Discovery and documentation are kept proportional to the uncertainty; verification remains part of the work. Appropriate for known bugs, minor improvements, and operational debt with clear parameters.

Less documentation does not mean skipping verification.

Where I take responsibility

Problem and scope
Make the request and its boundaries understandable.
Decisions and priorities
Record the reasoning and keep the backlog ordered.
Team alignment
Connect business, engineering and compliance where their needs meet.
Delivery and feedback
Resolve ambiguity during implementation and review what changed.

Documents that support the decisions

These four portfolio samples show how I structure problem framing, decisions, delivery preparation and outcome review.

Problem Brief

Define the problem before choosing a solution.

Useful when

A request needs evidence, context or a clearer problem statement.

View exampleHide details: Problem Brief

Merchant payout status visibility

Portfolio sample — not a reported client result.

Source section 2
Problem statement

The current workflow confirms payout submission but does not explain progress, waiting states, or likely next steps in a way that reduces uncertainty for merchants. This creates avoidable support load, lower trust in the payout flow, and weak operational transparency.

Source section 5
Desired outcome

The product should communicate payout progress more clearly so that merchants can understand:

  • whether the payout is still processing
  • whether it is waiting for an internal check
  • whether any action is required from them
  • when they should expect another update
Download PDFDownload Markdown

Decision Brief

Record the options, trade-offs and reason for a product decision.

Useful when

The team needs to commit, defer or reject a direction.

View exampleHide details: Decision Brief

Merchant payout status visibility

Portfolio sample — not a reported client result.

Source section 1
Decision to make

Choose the most appropriate first release for improving merchant visibility during payout processing and manual review.

Source section 6
Recommendation

Recommend Option A: merchant-facing status model in product for release one.

This option gives the highest ratio of clarity improvement to delivery complexity.
It also preserves a clean path for later expansion into notifications if the first release proves that clarity improves and support demand decreases.

Source section 7
Trade-offs accepted
  • The first release improves clarity, not channel coverage.
  • We accept that some merchants will still prefer asynchronous updates later.
  • We prioritize understandable states over perfect granularity.
Download PDFDownload Markdown

Shaped Brief

Give the team a clear scope, acceptance criteria and important edge cases.

Useful when

An agreed direction needs to become work the team can start.

View exampleHide details: Shaped Brief

Merchant payout status visibility

Portfolio sample — not a reported client result.

Source section 2
Scope for release one
In scope
  • new external payout status labels
  • short explanatory helper text for each visible state
  • display update in merchant payout detail view
  • fallback behavior for unsupported internal states
  • event logging for status visibility checks
Not in scope
  • email notifications
  • redesign of full payouts history
  • new payout engine logic
  • changes to manual review policy
Source section 5
Acceptance criteria
  1. Merchant sees one clear payout state in the payout detail view.
  2. Each state has short supporting copy written in plain language.
  3. Internal statuses are mapped to one merchant-facing state through an explicit rule set.
  4. Unsupported internal statuses do not break the payout detail screen.
  5. Events are logged when the payout detail view is opened for measured states.
  6. Support and operations review the visible copy before release.
Download PDFDownload Markdown

Outcome Review

Compare what happened after release with the original intent.

Useful when

There is enough feedback or operating evidence to decide what comes next.

View exampleHide details: Outcome Review

Merchant payout status visibility

Portfolio sample — not a reported client result.

Source section 2
Original intent

The release aimed to reduce uncertainty after payout submission by making payout progress more understandable without changing the underlying payout engine or introducing new notification channels.

Source section 8
Follow-up decisions
  1. Keep the current external status model as the base layer.
  2. Explore targeted asynchronous notifications for longer-running review states.
  3. Refine copy for the “Action required” path before broader rollout.
  4. Improve support tagging so post-release measurement stays reliable.
Download PDFDownload Markdown

See how I coordinate the delivery side.

Project delivery