Skip to content
Richard SmithVirginia

Product Management Lead

Make better product decisions.

See the outcomes first. Then explore how I bring customer needs, business priorities, and delivery realities into a choice people can carry forward.

The people doing the work usually know something the plan is missing. I make room for that knowledge.

View my outcomes Meet the man behind the methods

Check current capacity

Better Decisions Create Momentum

Selected experience

Outcomes with the context left in.

Each example separates the measured result from my contribution and the limits of the claim.

Amtrak Contractor through Randstad

37.5% improvement in operational signal quality across four iterations.

Owned discovery through an approved proof of concept, turning shop-planning assumptions into a testable decision model.

Approved proof of concept; not a production deployment or an operational-savings claim.

Sol Systems

60% fewer customer-service interventions within three months for a migrated subscriber cohort.

Led discovery through launch and simplified onboarding and billing behavior so more support needs were handled within the product experience.

The result applies to the migrated cohort, not every subscriber.

Planet Payment

36% less manual intervention and rework across 6+ markets.

As Solution Consulting Manager / Product Owner, redesigned form, validation, and workflow logic while balancing shared platform behavior with regional needs.

Contribution and scope are retained with the measured outcome.

Madison Square Garden

Helped launch VIP-suite mobile ordering, increasing hospitality spend by 23%.

Worked across operations, vendors, and technical teams in a live-event environment.

“Helped” is deliberate; this is not a claim of sole causation.

These outcomes are supported by my resume and have not been independently audited. Read the full resume (PDF).

Ways to work together

Match the responsibility to the work.

A role, reserved leadership capacity, focused advice, a specific product skill, and a defined project are different commitments.

Fractional leadership

Reserved leadership capacity

For recurring decisions and a defined leadership gap, with responsibilities, capacity, exclusions, and review points agreed.

See the leadership scope

Focused advice

One consequential choice

For a client who needs a bounded decision brief rather than ongoing delivery ownership.

See the decision scope

Specific product skills

Targeted support where the team needs it

Discovery, facilitation, product operations, prototyping, or decision modelling can support existing ownership without replacing it.

Discuss a specific need

Defined projects

A bounded output with a finish condition

For evidence or delivery work with an agreed question, inputs, output, stop rule, and handoff.

See a project example

Product management engagement examples

Three ways to bring decision-first product work into a live challenge

These are starting examples, not the only ways to work together. I also welcome full-time Product Management Lead opportunities.

Focused advice · one consequential choice

Decision Brief

Fit
A client with one important decision and scattered context.
Problem
People cannot yet agree what they are deciding.
Deliverable
A decision brief with the dilemma, protected horizon, constraints, options, trade-offs, recommendation, and revisit trigger.
Primary benefit
A shared basis for choosing the next investment.
Investment
Fixed scope and fee agreed before work starts.
Additional value
A concise record the client can share internally.
Decision trigger
Before another consequential commitment.

Boundary: One decision, up to three stakeholder conversations, and one revision. It does not include a working production system. Inputs, schedule, definition of done, and remaining uncertainties are agreed during scoping.

Discuss a Decision Brief

Defined project · one material uncertainty

Evidence Sprint

Fit
A client with framed options whose commitment would rest on an untested assumption.
Problem
An uncertainty could change the choice.
Deliverable
One bounded investigation or prototype, findings, updated options, and a decision playback that preserves remaining uncertainty.
Primary benefit
Evidence that supports proceeding, changing, or stopping.
Investment
Fixed scope and fee agreed before work starts.
Additional value
Reusable learning and a documented decision trail.
Decision trigger
Before funding the option that depends on the uncertainty.

Boundary: One uncertainty, available evidence, and a defined stop rule. It is not unlimited discovery; findings may support proceeding, changing, or stopping.

Scope an Evidence Sprint

Fractional · continuity across decisions

Embedded Product Leadership

Fit
A team with recurring product decisions and a leadership capacity gap.
Problem
Decisions lose continuity between discovery and delivery.
Deliverable
Clear decision ownership, prioritized learning and delivery work, and a review rhythm tied to changing trade-offs.
Primary benefit
Accountable product leadership across the moving parts.
Investment
Reserved capacity agreed to your needs.
Additional value
Better handovers and clearer decision ownership.
Decision trigger
When a repeated decision gap is blocking product work.

Boundary: Responsibilities, exclusions, capacity, and review points are explicit. This does not replace product, design, engineering, or delivery specialists and is distinct from employment.

Discuss product leadership capacity

These are examples of how I can support a product as a consultant, fractional leader, or full-time Product Management Lead. I bring customer conversations, cross-functional communication, prioritization, and delivery context together so the decision is clear before automation or implementation is scoped. Any paid engagement begins with an agreed scope and fee.

A small interactive experiment

Pick a knot. Follow a thread.

Try a familiar dilemma and watch a short decision brief take shape. Your selections stay in this page. Nothing is submitted or stored.

A hand in a green plaid sleeve follows an orange thread back to a knot.

Four familiar product situations

Choose what would be most useful to learn first.

Each scenario and response is authored. It is a signal, not a diagnosis, forecast, or recommendation about your organization.

Choose a situation

Illustrative dilemma · Onboarding support

Keep asking staff to repair onboarding problems, or automate a process we do not fully trust?

Bounded aim: Help customers complete one onboarding handoff with fewer avoidable corrections.

Affected people: Customers completing onboarding; frontline/support colleagues repairing exceptions; and the product, operations, and technical people responsible for the service.

Credible alternativesClarify guidance and ownership; add reviewed staff assistance; automate only verified repeatable cases; or keep the current process temporarily while learning.
ConstraintAccount changes need authorized approval. This is an operational fact, not an uncertainty to eliminate.
Which uncertainty would be most useful to investigate first?

The three choices are authored starting points. A real team may identify a different uncertainty before acting.

Authored response

Choose an uncertainty to see its evidence path.

No answer is inferred. All twelve complete paths remain available below.

Read every option

Compare every evidence path

Each scenario keeps its dilemma, affected people, alternatives, and constraint in view. None declares a winning product option.

Onboarding support · Repair onboarding or automate it?

Dilemma: Keep asking staff to repair onboarding problems, or automate a process we do not fully trust?

Bounded aim: Help customers complete one onboarding handoff with fewer avoidable corrections.

Affected people: Customers completing onboarding; frontline/support colleagues repairing exceptions; and the product, operations, and technical people responsible for the service.

Credible alternatives: Clarify guidance and ownership; add reviewed staff assistance; automate only verified repeatable cases; or keep the current process temporarily while learning.

Constraint: Account changes need authorized approval. This is an operational fact, not an uncertainty to eliminate.

Are customers being stopped by unclear guidance?

Test whether instructions or ownership are driving repeat support.

Signal, not diagnosis
Whether repeat support requests arise mainly from instructions or ownership that customers cannot follow.
Bounded evidence
The product journey owner and support lead review a small, agreed sample of recent cases and test revised guidance with representative users. Record the sample limit; do not generalize beyond it.
Trade-off
Clearer guidance is quick and preserves human authorization, but it will not resolve genuine exceptions or prove automation is safe.
Owner and next action
Product journey owner names the sample and guidance change; support lead verifies how cases were classified. No automation commitment is made.
Review
Revisit after the bounded review/test, or sooner if a consequential exception appears.

Are genuine exceptions driving the repair work?

Separate repeatable work from cases needing judgment or approval.

Signal, not diagnosis
How often consequential exceptions occur and which ones need human judgment or authorized approval.
Bounded evidence
An operations owner and product partner classify a bounded sample of cases with frontline colleagues, separating repeatable work from consequential exceptions.
Trade-off
Classification protects judgment and exposes automation limits, but takes staff time and may delay a simpler guidance improvement.
Owner and next action
Operations owner approves the categories; product owner records which cases, if any, are candidates for a later bounded test.
Review
Revisit when the sample is classified or when a new exception changes the risk.

Is the available evidence reliable enough to choose?

Check whether records support a responsible comparison.

Signal, not diagnosis
Whether support records consistently describe the source, correction, authorization, and outcome needed to compare options.
Bounded evidence
A named product/data owner traces a small sample to source records with frontline review and documents missing or contradictory fields. Stop at the agreed sample.
Trade-off
Improving evidence delays a solution decision, but avoids automating a false pattern.
Owner and next action
Product/data owner records the evidence limits and recommends improving evidence, running one bounded test, or deferring; the authorized decision owner decides.
Review
Revisit when the audit finishes or reliable new evidence materially changes the option comparison.
AI and human judgment · Where should AI assist?

Dilemma: Use AI to accelerate a consequential workflow, or keep asking people to absorb every repetitive step?

Bounded aim: Reduce repetitive effort without giving a probabilistic output unreviewed authority over a customer or operational consequence.

Affected people: Customers affected by errors; frontline colleagues reviewing or acting on output; and product, operations, risk, and technical owners.

Credible alternatives: Improve deterministic rules and source data; add human-reviewed AI assistance; automate only verified low-consequence cases; or retain the current manual workflow while learning.

Constraint: Consequential customer or operational actions require an authorized accountable owner, regardless of how a recommendation is produced.

Is the repeated work stable enough to assist?

Test whether similar inputs actually call for similar treatment.

Signal, not diagnosis
Whether the apparent pattern survives differences in source, context, timing, and consequence.
Bounded evidence
A product and operations pair classify a bounded sample of recent cases, recording where the same-looking input required a different response.
Trade-off
Classification delays a prototype, but prevents a polished assistant from encoding a pattern that is not stable.
Owner and next action
Product owner defines the sample; operations owner validates exceptions and decides whether a reviewed-assistance test is responsible.
Review
Revisit after classification or when a new case breaks the proposed pattern.

Which errors still require human judgment?

Separate reversible suggestions from consequential actions.

Signal, not diagnosis
Which false positives, omissions, or edge cases could materially affect a customer, obligation, or live operation.
Bounded evidence
Risk and frontline owners walk a bounded set of failure examples through consequence, reversibility, detection, and escalation.
Trade-off
Keeping review protects accountability but limits speed and may reduce the apparent automation benefit.
Owner and next action
Risk owner sets the non-automatable boundary; product owner scopes only reversible assistance inside it.
Review
Revisit after a bounded assisted-use trial or immediately after a new consequential failure mode.

Where must recommendation end and authority begin?

Trace who may review, approve, act, and explain.

Signal, not diagnosis
Whether the proposed workflow makes the transition from generated output to accountable action explicit.
Bounded evidence
Trace one representative recommendation from source through review, approval, action, correction, and audit, naming each owner and system.
Trade-off
Explicit handoffs add friction, but preserve the ability to stop, correct, and explain a consequential action.
Owner and next action
The authorized operational owner approves the handoff; the technical owner implements no broader permission than that decision allows.
Review
Revisit when authority, model behavior, source data, or consequence changes.
Competing priorities · Which priority should move first?

Dilemma: Keep every roadmap commitment moving, or make an explicit choice about what the team can responsibly carry?

Bounded aim: Choose the next product investment without hiding customer consequence, delivery dependency, or the work that must pause.

Affected people: Customers waiting for improvement; colleagues operating the current service; delivery teams; and business owners accountable for the outcome.

Credible alternatives: Protect current reliability; reduce the scope of a commitment; run a bounded test of a new opportunity; or defer one option with a named review trigger.

Constraint: Near-term delivery capacity and existing operational obligations cannot support every proposed commitment at once.

Which unmet need creates the most material consequence?

Compare customer effect, not request volume alone.

Signal, not diagnosis
Which delayed outcome changes customer ability, trust, cost, or access rather than merely preference.
Bounded evidence
Product and research owners review a bounded mix of customer evidence and frontline cases, retaining cohort and source limits.
Trade-off
Prioritizing material consequence may defer a louder or more visible request.
Owner and next action
Product owner documents the affected cohort and comparison; the accountable business owner chooses what moves.
Review
Revisit when new customer evidence changes consequence or reach.

Which dependency changes what is viable now?

Surface permissions, sequencing, and operational load.

Signal, not diagnosis
Whether a hidden dependency makes one option infeasible or makes a smaller sequence more responsible.
Bounded evidence
Delivery, technical, and operations owners map a bounded critical path and verify the few dependencies that could change the order.
Trade-off
Respecting dependencies may slow a desired feature, but avoids committing to work the system cannot yet carry.
Owner and next action
Delivery owner verifies the path; product owner proposes a viable sequence for decision.
Review
Revisit when a material dependency clears, moves, or proves false.

What evidence could distinguish the leading options?

Buy only the information likely to change priority.

Signal, not diagnosis
Which assumption about customer value, operational relief, or strategic fit is both uncertain and decision-relevant.
Bounded evidence
Run one bounded prototype, workflow observation, or data review with an explicit stop rule and no forecast beyond the observed sample.
Trade-off
A test consumes capacity now, but may prevent a larger commitment based on an untested assumption.
Owner and next action
Evidence lead protects the question and stop rule; the decision owner compares options after findings.
Review
Revisit when the bounded test completes or the priority horizon changes.
Institutional knowledge · Which knowledge is too fragile?

Dilemma: Keep relying on a few experienced people to repair recurring decisions, or structure the minimum context others need to act responsibly?

Bounded aim: Reduce avoidable dependence on individual memory without pretending that every exception can be reduced to a rule.

Affected people: Experts holding context; colleagues retrieving it; decision owners; source maintainers; and people affected when context is missing.

Credible alternatives: Clarify the authoritative source; capture rationale and known exceptions; create a small retrieval/decision aid; or deliberately retain expert judgment for rare consequential cases.

Constraint: Confidentiality, source authority, expert time, and some judgment that cannot be safely codified limit what should be captured.

Where does a capable colleague fail to find the basis?

Observe retrieval before creating another repository.

Signal, not diagnosis
Whether failure comes from source location, authority, missing rationale, or inaccessible exception context.
Bounded evidence
Ask representative colleagues to retrieve the basis for a bounded recurring decision without coaching and record where confidence breaks.
Trade-off
Observation exposes real gaps but uses expert and colleague time before any artifact is produced.
Owner and next action
Source owner identifies the authoritative location; product or operations owner chooses the smallest repair.
Review
Revisit after another uncoached retrieval attempt or when the source changes.

Which exceptions actually change the decision?

Separate useful context from an attempt to capture everything.

Signal, not diagnosis
Which recurring exceptions alter the option, authority, or consequence enough to require explicit context.
Bounded evidence
Experts and frontline colleagues classify a bounded sample of exceptions by consequence and the judgment needed.
Trade-off
Capturing exceptions improves reuse but can create false confidence if rare cases are presented as complete rules.
Owner and next action
Domain owner approves the exception boundary and names which cases still require escalation.
Review
Revisit when a new exception falls outside the captured boundary.

Who keeps the decision context current?

Test whether authority and review are visible.

Signal, not diagnosis
Whether a colleague can identify the source owner, last review, known limitation, and escalation path.
Bounded evidence
Audit a bounded set of decision aids for owner, authority, review date, limitation, and escalation fields; do not infer that presence proves accuracy.
Trade-off
Governance adds maintenance work, but an ownerless artifact can spread stale confidence faster than direct expert judgment.
Owner and next action
The accountable domain owner accepts maintenance and review cadence before the artifact is promoted.
Review
Revisit at the named cadence or whenever authority or policy changes.

Carry the structure into your own decision

Use the Decision Brief Starter.

Preview the complete one-page structure, print or edit it immediately, or request a confirmed delivery link. Requesting the resource does not add you to ongoing updates unless you choose that separately.

An open paper folio forms a small freestanding workspace, holding varied pieces in a clear structure.
Preview the Decision Brief Starter Request a confirmed copy

Choose where to go deeper

Four journeys through the work.

Start with a current product question, follow a method, connect earlier practice to the work today, or read the longer career story.

If I had Ai capabilities then

Where should AI assist, and where should people remain accountable?

Five product situations, plus the questions that connect them.

Explore AI in real product work

Sifting

Which quiet decision is already taking shape?

Follow weak signals and institutional knowledge before committing to an answer.

Try Sifting for Better Decisions

Product practice

How did the current decision-first practice develop?

Connect earlier work in analysis, collaboration, delivery, and trust to the value it supports today.

Explore product practice in context

Career story · legacy

What is the longer journey behind the practice?

Read the preserved historical profile—including earlier Agile, business analysis, solution consulting, and learning paths—in its original format and context.

Visit the historical profile — opens in a new tab

The man behind the methods

Product leadership where people, operations, and technology meet.

I have built my career translating between people who see different parts of the same problem—and helping teams turn shared context into decisions they can carry through delivery.

I listen for what customers and frontline colleagues are already showing us, make trade-offs visible, and build enough evidence to choose—and revisit—a responsible next step.

Outside work, I enjoy walking through Northern Virginia’s towns and parks and the small conversations that make a place feel connected.

Start a conversation with Richard

Looking backRead the preserved career story — opens in a new tab

One next step

What would be useful to discuss?

Tell me what you are hiring for, what your team needs to decide, or who you think I should meet. An email starts a conversation; it does not reserve capacity or purchase work.

Illustrated portrait of Richard Smith looking back over his shoulder.
Email Richard View LinkedIn profile

How I contribute

One practice from dilemma to accountable product work.

The six moves connect a difficult choice to recognizable work, a useful output, clear ownership, and a reason to review the decision.

  1. 01

    Define the dilemma.

    Use discovery conversations and customer or frontline evidence to name the product choice and the people affected, not just the solution already proposed.

    Output
    A bounded decision statement.
    Owner
    The product sponsor confirms the choice and affected people.
    Review
    Return if the scope or accountable people change.
  2. 02

    Set the horizon.

    Align customer outcomes, business priorities, delivery needs, and the boundaries the next commitment must protect.

    Output
    Outcome, ambition, and guardrails.
    Owner
    The sponsor owns the outcome; the team tests whether it is usable.
    Review
    Return when priorities or protected outcomes change.
  3. 03

    Face the ground truth.

    Map permissions, dependencies, operational realities, technical constraints, and prior investment before narrowing the options.

    Output
    A viable option set with constraints visible.
    Owner
    Domain, delivery, and technical owners verify what is true now.
    Review
    Return when a material constraint moves.
  4. 04

    Weigh the evidence.

    Use interviews, product data, service evidence, or a bounded prototype only where uncertainty could change the choice.

    Output
    A learning plan and findings with limits intact.
    Owner
    A named evidence lead protects the question and stop rule.
    Review
    Stop or reframe when more evidence will not change the options.
  5. 05

    Choose the next step.

    Compare credible options, trade-offs, sequencing, and delivery consequences before making a commitment people can execute.

    Overlapping footprints with one route highlighted in green.
    Output
    A decision record and accountable next action.
    Owner
    The authorized decision owner commits; the team carries it forward.
    Review
    Name the evidence, date, or condition that reopens the choice.
  6. 06

    Revisit the bet.

    Review customer and operational consequences alongside delivery learning; keep, adapt, pause, or stop without rewriting the original reasoning.

    Output
    A keep, change, pause, or stop decision.
    Owner
    The decision owner reconvenes affected people.
    Review
    Use the trigger agreed in the decision record.