HOW TO: Scope a Project When No One Actually Knows What They Want

Written By Azsha Preble

From a TAM who doubles as a project manager, strategic partner, internal merchant advocate, and occasional therapist for my book of business.

If you’ve worked in fintech, subscriptions, or really any complex technical environment, you’ve probably experienced this moment:

A stakeholder says, “We need to improve our billing experience.”
Or, “We want to support more flexible pricing.”
Or my personal favorite, “We just need this to work better.”

No requirements. No clear definition of success. Just urgency.

As a Technical Account Manager (and a PMP certified project manager), this is where a surprising amount of my work actually begins: not with execution, but with interpretation.

Because in reality, most projects don’t start with clarity. They start with ambiguity. And your job is to turn that ambiguity into something buildable.

Here’s what that actually looks like on the ground.

Step 1: Translate vague asks into real problems

Most stakeholders don’t bring you requirements, they bring you symptoms.

“Billing is broken” might actually mean:

  • Customers are churning due to failed payments

  • Finance can’t reconcile reports

  • Pricing changes take too long to implement

If you jump straight to solutions, you’ll miss the mark.

Instead, I start with structured questions:

  • What’s happening today that shouldn’t be happening?

  • Where is this breaking down (customer, ops, finance, engineering)?

  • What’s the impact if we don’t fix this?

If you don’t understand the ask, ask questions! You’re not gathering requirements yet, you’re identifying the actual problem space.

Step 2: Identify stakeholders (and their competing definitions of success)

Here’s where things get real.

“Success” means something different depending on who you ask:

  • Product wants flexibility

  • Engineering wants simplicity

  • Finance wants accuracy

  • CX wants fewer tickets

If you don’t surface this early, it will absolutely show up later as friction.

As a TAM, part of being a strategic partner is making these tensions visible before they derail the project.

I’ll often summarize it back explicitly:

“It sounds like we’re optimizing for flexibility on the product side, but we need to balance that with finance reporting accuracy. Let’s define what trade offs we’re willing to make.” Or something way less polished, but that gets the sentiment across ;) That one sentence can save weeks of rework.

Step 3: Define the “shape” of the solution before the details

Before diving into tickets, configs, or timelines, I focus on outlining the system at a high level.

In payments and subscriptions, that usually means mapping:

  • Systems involved (billing platform, payment gateway, ERP, etc.)

  • Data flow (what triggers what)

  • Key decision points (pricing logic, retries, edge cases)

You don’t need perfect detail, you need alignment on structure.

This is where a lot of TAMs differentiate themselves from pure support roles.
You’re not just answering questions, you’re helping design how things should work.

Step 4: Break ambiguity into decisions, not tasks

This is a big shift.

When a project is unclear, the instinct is to start listing tasks:

  • Configure plans

  • Update pricing

  • Build integration

But tasks assume decisions have already been made.

Instead, I focus on defining the decisions that need to happen:

  • What pricing models are we supporting?

  • How should failed payments be handled?

  • What systems are the source of truth?

Once those are answered, the tasks become obvious.

Step 5: Document assumptions (because there are always many)

In ambiguous projects, assumptions are everywhere, and can be dangerous if left unspoken.

Examples:

  • “We’re assuming all customers will be migrated at once”

  • “We’re assuming tax handling won’t change”

  • “We’re assuming existing payment methods are reusable”

I make these explicit early.

Not because they’re all correct, but because it’s easier to adjust a known assumption than uncover a hidden one halfway through implementation.

Step 6: Create a version 1 scope (and expect it to evolve)

At this point, you’re ready to define scope- but it probably won’t be perfect on the first try! And that’s okay.

A strong v1 scope should include:

  • Problem statement

  • Goals / success criteria

  • High level solution design

  • Key decisions made

  • Known unknowns

The goal isn’t perfection, it’s alignment.

From there, you refine.

What this actually looks like as a TAM

On paper, this process overlaps heavily with traditional project management. That’s where my PMP training comes in handy.

But in practice, as a TAM working with strategic merchants, it’s more fluid:

  • You’re translating between business and technical teams in real time

  • You’re identifying risks before they’re formally documented

  • You’re shaping solutions without owning all the implementation

You’re not just managing a project, you’re helping define what the project even is.

Final thought

The most valuable work often happens before a single task is created.

Anyone can execute a well defined project.
Far fewer people can create clarity where none exists.

That’s the difference between being reactive and being a true strategic partner.

Anything you would add?

Azsha Preble
Next

HOW TO: Understand ACP (Agentic Commerce Protocol)