How to prioritize in the AI era

One of the first projects I worked on at GitHub back in 2013 was improving and evolving our API. Even then, we were seeing more traffic to the API than to the website itself with millions of developers were already automating their workflows. Prioritization wasn’t just important: it was critical to scaling adoption and focusing on what was going to help the biggest number of developers.

But how did we decide what to build, and when?

Keeping It Human-Readable

Inspired a bit by the RFC keywords, I boiled down prioritization into three categories: MUST, SHOULD, and COULD.

These were easier to understand than technical-sounding rankings like P0, P1, or P2. Let’s be honest — I’m never going to tell my wife a plumbing repair is a “P0.” But I will say we must get it fixed today.

This kind of plain-language framework doesn’t just work well for people: it works surprisingly well for LLMs too.

Here’s a tiny spec I recently gave to Copilot CLI’s upcoming “plan” mode:

You're building a web app overlay for Todoist, enabling enhanced tracking, prioritization, and LLM integration.You MUST sync changes bidirectionally with Todoist.You SHOULD offer a clean, compact UI.You COULD build it with Ruby on Rails using Turbo.

From this small seed, Copilot expanded the plan with helpful detail — all while staying aligned with the guardrails I’d defined. It gave structure without boxing in the implementation.

Other Triple Constraints

You might be more familiar with another triad: Time, Scope, and Cost.

The Triple Constraint in Project Management: Time, Scope & Cost

Triple Constraint is the time, scope and cost for a project: three interdependent levels that you can adjust when managing projects. Read on and learn how.

ProjectManagerJason Westland

This is the classic project management triangle (aka the “pick two” meme). Each of these constraints impacts the others, just like our MUST / SHOULD / COULD framework.

You can’t implement a SHOULD or COULD that undermines a MUST.

That balancing act is key — and it’s not just theoretical. Jason Fried from Basecamp talks about delegating projects, not tasks.

Delegating projects, not tasks

We recently received this email from a REWORK Podcast listener who had a question... “...I think it was in Shape Up that the idea of delegating projects rather than tasks came up. And I’m trying to move this way, of working with my own team. I just wonder if you guys have any tips or help for making…

He focuses on defining constraints like team size and timeline — while still giving teams the creative freedom to figure out how to deliver.

Clarity That Enables Agency

Whether you’re working with a teammate or a tool like Copilot, clear guidance is essential. You want to define the guardrails, not every turn in the road.

MUST / SHOULD / COULD provides just enough structure to enable creative problem-solving without over-specifying the implementation.

In practice, I almost always introduce a final constraint: time or resources. Many triad-based frameworks do this for good reason: constraints breed creativity. Knowing both what success looks like and what tools or time you have sets the stage for thoughtful, innovative work.

What prioritization frameworks have you found to work, particularly when working between teammates and AI? Let me know.