Operationalizing a Program When Inputs Are Thin

Most of my favorite work starts with a shrug or a sliver of an idea: “We need… something.” “What about a new approach to onboarding?” “I feel like there’s opportunity here.” No briefing document. Maybe an instinct or an inclination. Definitely a looming deadline. Bring it on, this is my superpower. 

I’ve had people tell me this is a strength for years, so I did some self-reflection on why this seems to come so naturally for me, while it doesn’t for others. Here’s my approach to operationalizing a project, program, or process when the inputs are thin, but the stakes are real.

Start with the outcome (and the stakes)

What are we actually trying to do? What’s the impact we’re trying to make, by when, and what happens if we miss? I also stack-rank it against everything else so we’re honest about priority and tradeoffs. And I make sure it ties back to company goals so the “why now” is clear.

Find the gaps → pick 1-2 moves

What’s missing or unclear? Is this the right thing to be doing or is there something “like this” that would work better? I’ve also learned over the years to stop focusing on “what’s realistic and doable” to first focus on “what’s possible”. From there, I cut to the 1–2 activities or actions that are most likely to move the result.  Then I’ll build out the pros/cons to see if it makes sense to just whittle it down to one clear path forward.

Size the lift (and match resources)

I use the same approach regardless of size, but speed changes. Whether it’s a small pilot or a bigger program, I’m still asking who’s involved, what we want people to feel and do, and why this path over another.

This is when I start to do a quick reality check on budget and resource requirements (people and tools, etc.) do we have what we need, or do we deprioritize something else? And if we don’t have what we need, but we think it could make a pretty big impact - could we cost-effectively outsource part or all of it.

Take the temperature (buy-in early)

This is a big piece that I’ve learned over the years. The bigger the project, the more people we need bought in. Particularly when it starts to span multiple functions. Do people see the value or understand what happens if it’s not delivered? If not, do we build buy-in, or is this DOA and needs a rethink? The goal is to reduce risk, but still aim high. 

Make it real (at pace)

After we set direction, it can drift into project management realms:

• A one-page decision brief: what we’re delivering, options/tradeoffs, owner, steps, and how we’ll measure success. If we need to build buy-in, we meet vs. relying on email response or shared documents for input. 

• Demonstrate visible proof at key checkpoints (a trimmed path, a demo script, a customer call) so people react to something real and see progress and momentum.

• A simple rhythm: short check-ins, clear handoffs, and a running list we actually strike through. (Love crossing off that list)

Decide what not to do

I keep cutting work that doesn’t move the result. No new microsite if a page will do. Rethink the process if it isn’t making sense. Reuse what already works (if it ain’t broke, don’t fix it). When we cut we make sure everyone is aware of it, so there’s no question or confusion later on handoffs or delivery.

Keep the pulse

Regular updates are important to remind people why we’re doing this, especially when concepts become actuals and second-guessing creeps in. I run a 15-minute weekly check-in (goal, status, blockers, decisions needed) and keep a simple decision log so choices stick. Plus I send regular updates to key stakeholders to keep them apprised of progress.

Operating at the leader layer

• Decision velocity. I build out choices with options, tradeoffs, and opt-outs so leaders can say “yes/no” fast.

• Narrative → numbers. I translate the idea into a plain story tied to company goals with leading/lagging measures (which aren’t always data points).

• Influence without drama. One of the more challenging pieces, but the focus is on aligning the right leaders, handling pushback, and cutting scope that doesn’t move the result. But if you’re not getting enthusiastic or interested buy-in up front, then the project likely won’t be successful, so it could be back to the drawing board.

Operationalizing vague requests is a lot like defensive driving. Eyes up, watch the possibilities—are they pulling out, turning, stopping?—and be ready to act. That’s how I bring a project to life and get it done and dusted.

Operationalize a program - in practice

If the ask is “Improve an Onboarding Program”:

• Goal: Reduce time-to-value for customers from 21 to 10 days by X date.

• Moves: Shorten the initial setup path; add a live check-in on day two; add next-level onboarding two weeks later and follow with a check-in.

• Week-one proof: Run five new customers through the trimmed path; watch where they stall; iterate. Repeat in week-two.

• Skip: Fancy email sequences; a new portal build.

If the ask is “A Sales Enablement Initiative”:

• Goal: Lift win rate in X product group from 18% to 25% by end of Q2.

• Moves: Get clear on the problem story; equip reps with three pieces of proof buyers believe (customer clip, live demo path focused on the primary pain point, ROI snapshot).

• Week-one proof: Try the new materials in ten active deals; track meeting-to-proposal rate.

• Skip: A big “training” session; a full deck overhaul.

The sun comes out and the fog dissipates on vague ideas when we define the outcome, set guardrails, make ownership clear, line up buy-in and decisions early, and keep a steady rhythm until it’s done and dusted. From “we need… something” to “we did the thing.”