← All issues

23 August 2026 · Helen Beckford

If Everything Is a Priority, Nothing Is.

The Issue: You're trying to build everything at once and finishing nothing.

Here's a pattern I see in almost every start-up and scale-up I work with. The founder has a vision. It's ambitious, it's exciting, and it involves about forty things that all need to happen simultaneously. Platform features. Sales outreach. Marketing materials. Curriculum development. Employer engagement. Operational processes. Vendor management. The list grows every week.

Everything feels urgent. Everything feels critical. And because there's usually very little in the way of resources (money, time, and people), the temptation is to start everything and hope for the best.

What actually happens? Priorities change weekly. The team starts working on something, gets pulled onto something else, then something else again. Nothing gets finished. Nothing gets delivered. The team becomes demotivated because they never get to see a piece of work through to the end. Meanwhile, the founder is frustrated because nothing seems to be moving forward despite everyone being busy all the time.

If that sounds familiar, the problem isn't your team. The problem is that nobody has decided what matters most.

What I See Every Day: Busy teams delivering nothing.

I once walked into a scale-up where priorities were shifting weekly. Different stakeholders were pulling the team in different directions. The commercial side wanted sales and marketing. The product side wanted platform features. The operations side wanted processes documented. Everyone had valid needs. Nobody had agreed which came first.

I raised it with the leadership team: you need to prioritise. But here's the thing about prioritisation in a start-up, and I’ve seen this is scale-ups. It doesn't feel like a priority. When money is tight, time is short, and there's pressure from every angle, the idea of pausing to decide what to work on feels like a luxury. Getting someone in the room to help you prioritise feels like a cost, not an investment. Founders are seldom aware of the value until someone helps them articulate it.

So I implemented a repeatable prioritisation process. And here's the uncomfortable truth: for the first couple of months, it might have felt like less was being done because not everything was started. But in reality, it was the first time in a while that a substantial amount of work actually got delivered. The team stopped starting and started finishing. They had to accept that some things would wait. But the work that did get picked up was the right work. It was completed properly. And the team's morale shifted because they could finally see something through to the end. That's the paradox of prioritisation: doing fewer things at once means getting more things done.

I've also seen the flipside of this with founders working with vendors. Poor prioritisation leads directly to scope creep. The founder hasn't decided what's in and what's out, so they keep adding requirements mid-build. The vendor keeps building. The timeline extends. The cost increases. And at the end, the founder has spent twice as much and still doesn't have a finished product because they tried to get everything in one go.

What Needs to Happen: Decide what matters most, accept what can wait, and protect your team from constant context-switching.

I use a few methods with clients depending on their size and situation, but one of the simplest to explain is MoSCoW:

  • Must have: Without this, we cannot launch / operate / survive. Non-negotiable.

  • Should have: Important, but we can work around it in the short term if we have to.

  • Could have: Nice to have. Would improve things. But won't break us if it waits.

  • Won't have (for now): We've consciously decided this is not happening in this phase. (And if you've read newsletter #4, you'll know to log that decision and the rationale behind it.)

The power of MoSCoW isn't in the categories. It's in the conversation it forces. When you sit your team down and make them place each initiative into one of these four buckets, the debates that surface are exactly the debates you should be having. And the "Won't have" column is the most important one, because that's where you create focus by explicitly deciding what you're not doing.

Here's the hard truth about prioritisation: saying yes to everything is the same as having no priorities at all. Every time you add something to the "Must have" list, ask yourself: if everything is a must have, what are my team actually going to deliver this month?

I also use a custom-built scoring tool with clients to help them score initiatives and get to their priorities within an hour or so. If that's something you'd find valuable, I'm planning to make it available soon, so keep an eye out.

Beyond the framework, there are a few principles that make prioritisation stick:

  • Review priorities regularly. Not weekly (that's how you end up in the constant-shifting trap). Fortnightly or monthly, depending on your pace.

  • Make priorities visible. If your team doesn't know what the top three priorities are, they'll make their own assumptions. Write them down. Share them. Refer back to them when someone suggests adding something new.

  • Protect your team from context-switching. Every time you pull someone off one piece of work onto another, you lose momentum on both. Let people finish things.

Tip of the Week: Run a prioritisation session in under an hour.

If you've never formally prioritised your initiatives, use this prompt to get started:

Context: I am a non-technical founder running a start-up/scale-up. I have a long list of initiatives, features, and tasks that my team and/or vendors are working on (or want to work on). I need to prioritise ruthlessly because I have limited time, money, and people. Here is my current list of initiatives: [paste your list here, even if it's messy. Include everything: product features, operational tasks, vendor work, sales activities, whatever is competing for attention.]

Role: Act as an experienced IT delivery consultant and prioritisation coach who specialises in helping start-ups and scale-ups focus on what matters most without overcomplicating the process.

Action:

  1. Take my list of initiatives and categorise each one using the MoSCoW framework: Must Have, Should Have, Could Have, and Won't Have (for now).

  2. For each initiative, provide a one-sentence rationale for why you've placed it in that category.

  3. Challenge me: identify 3 initiatives that I've probably been treating as "Must Have" that could realistically wait, and explain why deferring them won't cause the damage I think it will.

  4. Identify any dependencies between initiatives (e.g. "you can't do B until A is complete") and flag where I might be trying to run things in parallel that should be sequential.

  5. Provide a suggested focus plan for the next 4 weeks: what should the team work on first, second, and third, and what should explicitly be parked.

Format: Present the MoSCoW categorisation as a table with columns for: Initiative, Category (M/S/C/W), Rationale, and Dependencies. Present the challenge and focus plan as separate numbered lists.

Target Audience: The output should be written in plain English that a non-technical founder can use to run a prioritisation conversation with their team immediately.

Wrapping Up the Series

Over the past five newsletters, I've tried to give you the governance basics that every start-up and scale-up needs when working with technology vendors, or building anything themselves:

  1. Your contract should protect you, not your vendor. Know what's in it. Know what's missing. (Read #1)

  2. Document what you asked for. If you didn't write it down, you can't complain about what you got. (Read #2)

  3. Know what was built and prove it works. A design document and test evidence are not optional extras. (Read #3)

  4. Record your decisions, risks, and actions. One spreadsheet. Three categories. Five minutes to set up. (Read #4)

  5. Prioritise ruthlessly. If everything is a priority, nothing is. Say no to things so your team can finish the things that matter.

None of this is complex. None of it requires enterprise-grade tools or a PMO team. It's the basics. And getting the basics right is the difference between a start-up / scale-up that scales with confidence and one that's constantly firefighting.

This is the fifth and final edition of my series, What Your IT Vendor Isn't Telling You, written for founders and non-IT leaders navigating software delivery without a safety net.

If any of this series has resonated, I'm happy to give you 20 minutes of my time to talk through whatever you're dealing with. No pitch. This stuff genuinely matters to me, and I'd rather you had an experienced pair of eyes on it before it becomes a bigger problem.

Get the next one in your inbox

Helen Beckford

The Priority Call

One idea per week on the decisions behind technology investment. No noise, no filler.

No spam. Unsubscribe anytime. See our Privacy Policy.