The Scaleup Strategy Audit: 3 Questions To Ensure You’re Growing In The Right Direction

A 10-minute sanity check when you can feel the complexity creeping in

Strategy is often treated like a all-you-can-build backlog.

More planning, more headcount, more process to manage the growth they already have.

• A new tool to fix the last tool

• A new layer of process to manage the last hire

• A new initiative because a competitor shipped one

Adding feels like progress. Questioning feels like slowing down. But momentum is quietly leaking out through the complexity, because strategy was never about adding more.

That’s the part most leaders skip when they’re scaling. But a new initiative bolted onto a shaky foundation just helps you grow in the wrong direction faster.

Faster, and still wrong.

Here’s the 3-question test I use, and If you can answer all three with specifics instead of slogans, your foundation will hold as you scale. If you can’t, more headcount and more tooling won’t save you.

Let’s start with the one most teams get wrong right when the growth is good.

Question #1: What problem are we actually solving?

When teams scale, they start describing their work in the language of their own org chart.

Product talks roadmap. Marketing talks pipeline. Ops talks process. Each one names the activity it owns, not the outcome the customer is actually paying for.

And the customer is never paying for the activity.

Take a product team shipping a new feature because usage dipped. The internal pitch is “we need a better platform.” Underneath, the churn traces back to something simpler. The product had gotten harder to live with, and the team felt it as a rising worry about retention. The feature is just one mechanism that might address it.

When you frame the work as the activity, every team optimizes its own slice and the customer’s actual problem goes unowned. When you frame it as the outcome underneath, the whole org can finally point at the same thing.

Most teams get this wrong in a few predictable ways as they grow.

• They ship the deliverable. A feature, a campaign, a process. Everyone can see motion, but no one can tell whether it achieved the outcome.

• They defend the function. “That’s a marketing problem.” “That’s a product problem.” The org chart becomes the map, which tells you who owns what, not why the customer should care.

• They measure their own effort. Velocity, story points, activities closed. Effort is invisible to a customer until it changes something they feel.

Each of those keeps the conversation at the level of what you do. None of them touches what the customer gets to stop worrying about once your product works.

Instead, write down the initiative or the team’s mandate in one plain sentence. Then ask “why does the customer care about that?” Take the answer. Ask “why” of that answer. Do it five times. You’ll feel the ground shift somewhere around the third or fourth pass, when the answer stops being about your roadmap and starts being about the customer’s reality.

If your final answer isn’t tied to something a customer can feel, time they get back, or money that stops leaking, you stopped digging too early.

I once worked with a group of optometrists fixated on website visibility. They were paying a premium for high-end video hosting to house dozens of patient testimonials right on their site, convinced the work was about storage and presentation. I ran with that and built them a polished player with every testimonial parked on the page.

Those testimonials were dying on a page almost no one visited.

A testimonial on your own site only moves people who already found you. Its real value is in the feed, as social proof in front of people who’ve never heard of you. So we cut the premium hosting, moved that spend to plain storage to keep every clip, and built a publishing cadence. One testimonial at a time, scheduled across their YouTube and social channels, each given its own window to breathe. The traffic moved once that trust was living in the feed, in front of people who didn’t know the practice existed yet.

Remember: your customer doesn’t lie awake thinking about your roadmap. They lie awake thinking about the problem your product makes disappear. Build for that.

Question #2: What are we saying no to?

A strategy you can’t say no inside of is just a wish list with better formatting.

The fastest way a scaleup loses its edge is by trying to serve everyone and ship everything. It feels responsible. There’s a big logo waving a contract, a board member with a pet initiative. So you say yes. Yes to the segment slightly outside your core, yes to the custom build for one loud account, yes to the project everyone quietly suspects is a distraction.

And every one of those yeses is a quiet no to something else.

Say yes to the wrong initiative and the focus that made you fast goes somewhere else. So does the roadmap slot the right work would have taken. The cost is real. It’s just invisible, because it shows up as the thing that didn’t ship.

Say you’ve built a product that wins with mid-market technical buyers. That’s your edge. Your motion, your onboarding, your support, all of it is tuned for that buyer. Then a household-name enterprise shows up wanting a heavily customized version. The deal is big. The logo is tempting.

If you take it, look at what you just did. You bent the roadmap. You split your best engineers. And worst of all, you blurred the one thing that made you obvious to the buyers you actually win, because now you’re “a platform for everyone” instead of “the product mid-market technical teams choose.” That enterprise deal didn’t cost you a quarter. It cost you the focus that was driving your growth.

The strongest scaleup leaders I know all use a version of the same tool. Call it a ‘Not-to-do’ list.

It’s three to five lines, written down, naming the customer segments, features, and deals you will not chase no matter how good the quarter looks. Not “things that distract us,” that’s too vague to protect you. Specific. “We don’t build one-off features for a single account.” “We don’t enter a new segment without a repeatable motion.” “We don’t take a logo we can’t serve well.”

The list does two things:

• It makes the next hard call easy, because you decided it once, on a calm day, instead of re-litigating it every time a tempting wrong-fit lands on the roadmap.

• And it makes your whole team sharper, because the clearer the boundary, the easier it is for everyone to point their work at the same edge.

I learned this hosting a big tailgate for my alma mater’s rivalry game. I tried to cater to two crowds at once: the people who wanted to post up and stay all day, and the people who just wanted a quick stop before heading into the stadium. The result was a logistics knot. Conflicting food, conflicting entertainment, conflicting ideas about screens and tech for the people staying outside.

You cannot serve two masters.

I said no to the stadium-goers and built the whole thing for the all-day crowd, because that was the real use case. Most people coming weren’t going into the game anyway. They were there for the festivities, the food, the reunion with old friends and folks in town from rival and neighboring schools. Once I picked that one person and built only for them, every call got easier. The food made sense. The setup made sense. And the people who did head to the game still had a great time, because nothing was watered down trying to please everyone.

Try to build a product that delights everyone and you build one that’s remarkable to no one.

Question #3. What would have to be true for this to work?

A goal without a list of preconditions is just a number you’re hoping at.

Most goals set while scaling sound something like, “We want to hit $50M ARR next year.” Then everyone goes right back to doing what they were already doing, as if naming the number does some of the work. No one sat down and mapped the system that would have to exist for that output to be the natural result.

For any goal you care about, ask: what would have to be true for this to be basically inevitable?

It’s a strange little phrase, “would have to be true,” and it does something specific. It moves you out of wishing and into reverse-engineering. You stop staring at the goal and start describing the world in which the goal already happened. Then you go build that world.

Say you want to become the default platform in your category inside a year. Don’t list what you’d do. List what would have to be true.

• It would have to be true that a new customer reaches first value in days, not weeks, so growth never stalls on a slow onboarding.

• It would have to be true that your pricing and packaging screen out the accounts you can’t serve well, before they ever sign and clog up the system.

• It would have to be true that one repeatable motion drives most of your new revenue, so scaling means doing more of one thing instead of inventing five.

Every line is a condition you can actually go make true, or admit you won’t. It converts a vague ambition into a short list of buildable facts, and it tells you immediately where you’re lying to yourself.

Because here’s what happens when you do this honestly. You write the things that would have to be true, and you get to one and feel your stomach drop, because you know the org isn’t willing to do it. Maybe it’s sunsetting a beloved product line. Maybe it’s holding the pricing line. That flinch is the most useful information in the whole exercise. It means your goal and your behavior are pointing in different directions, and right now, behavior is winning.

But the flinch is also the fix, because it shows you exactly where the lie is.

So pick your biggest goal for the next quarter. Write the things that would have to be true for it to be inevitable. Then be honest about which ones the org will actually build. If you can’t make them true, your strategy is broken, and now you can see it.

I ran into this with a workers’ comp healthcare firm. We took the Florida playbook that was working and forced it onto a new California contract, assuming the process was universal. Boy were we were wrong. Throughput was abysmal, because the Florida script ignored California’s regulations and the way influence actually flowed there.

Instead of pushing harder on a broken script, I asked: what would have to be true for California to match Florida’s throughput?

In Florida, we opened by calling the patient, because we’d built enough influence to help direct care. California was an insured-director state, and we hadn’t earned that influence yet, so care was steered by the physician’s office that wrote the prescription. For the same results, it would have to be true that we built real relationships with those physician offices first, before a patient ever got a call. That one truth reshaped everything. It became its own California scheduling department, built backward from what the market actually required.

A goal tells you where you want to go. The preconditions tell you whether you’ve actually decided to go there.

Strategy is addition by subtraction.

Strip away the the goals no one mapped and the initiatives that exist because someone once said yes.

What’s left is a small set of true things you can scale on.

Pick one decision that’s live for you right now, a hire, a feature, a new segment, a number you’ve already committed to, and run all three questions against it before you spend another month on it.

To make that part simple, I turned the whole audit into a prompt. You drop in the decision you’re weighing, and it walks you through what problem you’re really solving, what you’d be saying no to, and what would have to be true for it to work. A few minutes, not a planning offsite.

Here’s the prompt:

I'm going to describe a major initiative or goal my company is pursuing as we scale, and why we're pursuing it. Pressure-test it against three questions and tell me the single one we're answering with a slogan instead of specifics.

Here's the situation:
[Describe the initiative or goal, who it's for, and why you're doing it.]

Test it three ways:

1. What problem are we actually solving? Trace my stated reason down to the customer. Keep asking "why does the customer care about that?" If the answer bottoms out at our roadmap, our team's effort, or our org chart instead of something the customer can feel (time they get back, money that stops leaking, a worry that disappears), this question fails.

2. What are we saying no to? Pursuing this should require a specific no: a segment we won't serve, a feature we won't build, a deal we won't chase. If I can't name what this initiative costs us, what focus or roadmap slot it takes, then it's an additive yes that protects nothing, and this question fails.

3. What would have to be true for this to work? For the goal I described, name the preconditions that would make it basically inevitable. If I haven't mapped them, or if there's a precondition my org clearly won't build, this question fails.

Then give me one finding, not three. Name the earliest question that fails, because the early ones poison the later ones: if I don't actually know the problem (1), my no (2) and my preconditions (3) are aimed at the wrong target. Explain why it fails using my own words, not strategy jargon. Don't tell me what the answer should be. End with the sharp question I should sit with to fix it myself.

If all three hold with real specifics, say so plainly and tell me why each one holds. Don't manufacture a problem to seem useful. A foundation that holds is exactly what I need to hear.

Use it on something real this week.