Impact per minute: the only prioritization framework a solo founder needs

Open your backlog right now and count the tasks. Twenty? Sixty? Every one of them felt necessary when you wrote it down, and you can only do one at a time. This is the actual job of a solo founder: not coding, not marketing, but choosing. And most of us choose badly, because the frameworks we borrowed were designed for a different species of organization. The fix is a single ratio: impact per minute. Score how much a task moves you toward your next milestone, divide by how long it honestly takes, and do the highest number first.

Why urgency matrices fail one-person teams

The Eisenhower matrix is the default answer to 'how do I prioritize?', and it's a genuinely good tool for the person it was built for: someone with a staff. Its four quadrants come with four instructions, and two of them are 'delegate it' and 'schedule it'. When you are the entire company, 'delegate' is a joke and 'schedule for later' is a euphemism for never. What survives contact with a solo founder's reality is a two-quadrant matrix: do it now, or watch it rot.

There's a subtler failure too. Urgency is a measure of loudness, not value. The tasks that scream (a flaky CI pipeline, a half-broken integration you're the only user of, an email thread that feels pressing) are rarely the tasks that get you a customer. A solo founder who sorts by urgency spends their scarce evenings firefighting a company that has no fire worth fighting yet. Meanwhile the important-but-quiet work, the landing page rewrite, the pricing experiment, the ten cold emails, sits politely in the 'important, not urgent' quadrant forever. Teams have someone whose job is to protect that quadrant. You don't.

Urgency measures how loud a task is. Impact per minute measures what it's worth. Alone, you can only afford to pay for worth.

The scoring system: impact over minutes

The framework has exactly two inputs per task. First, impact: a number from 1 to 100 answering 'how much does finishing this move me toward my next milestone?' Not toward some abstract vision, toward the next concrete gate: a working MVP, a public launch, the first paying customer, ramen profitable. A task that would be brilliant for a company at 10k MRR but does nothing for your launch next month scores low today. The anchor is what keeps the number honest; without it, everything interesting scores 80.

Second, estimated minutes: how long the task really takes, including the setup, the testing, the deploy, the part where you argue with a config file. Then divide. A task with impact 60 that takes 30 minutes scores 2.0. A task with impact 90 that takes 600 minutes scores 0.15. The 60-impact task wins, and it should: you can finish thirteen of them in the time the big one takes, and finished work starts compounding immediately while unfinished work compounds nothing.

• Impact 1 to 100, anchored to the next milestone only. Ask 'does this move the next gate?' not 'is this good engineering?'
• Minutes are honest, door-to-door time. If your estimates are always half of reality, double them before dividing; the ranking only works if the denominator is real.
• Score fast and roughly. The point is comparing tasks against each other, not producing precise numbers. A score you spent ten seconds on and act on beats a score you spent ten minutes on and second-guess.
• Don't score the whole backlog. Score the five to ten tasks you're actually torn between; the rest were never real candidates.

Quick wins are not cheating, they're the math working

Productivity culture treats quick wins with suspicion, as if easy progress were somehow counterfeit. Impact per minute says the opposite: a 15-minute fix to a signup flow that's silently losing users might be the highest-scoring item you'll see all month. Take it. The framework's whole purpose is to stop you from equating difficulty with value, a confusion engineers are especially prone to. Some of the most valuable tasks in an early product are embarrassingly small: changing a headline, adding a screenshot, replying to the one user who emailed you.

The mirror image matters just as much. Big rewrites, framework migrations, and architecture cleanups almost always score terribly, not because they're worthless but because their impact on the next milestone is modest and their denominator is enormous. Scoring them honestly is uncomfortable the first time, because it exposes how much of your backlog is sophisticated procrastination. That discomfort is the framework doing its job.

Re-score, don't re-plan

Plans decay. A competitor launches, a user reports something ugly, a marketing channel unexpectedly works. The team-sized response is a planning meeting; the solo-sized response is two minutes of re-scoring. Because every task carries the same one-dimensional score, absorbing new information means adjusting a few impact numbers and letting the list re-sort. You never rebuild a roadmap, because you never had one in the ceremonial sense, just an ordered list that's cheap to reorder.

This is also where tooling starts to earn its keep. Scoring by hand works, and you should do it by hand for a week just to internalize the reflex. But the arithmetic is mechanical, and mechanical things belong to software. shipsolo (https://shipsolo.icu) is built around exactly this ratio: every task carries an impact score from 1 to 100 and a minute estimate, and the board ranks by the quotient automatically. Its AI will even draft and score the tasks for you from a project brief or from your actual codebase (you upload a folder or ZIP and it proposes ranked tasks), which kills the blank-backlog problem. And because the ranking exists, the daily email it sends you contains the current top task, not a link to a board you'll have to re-litigate at 9pm. The free tier covers two projects, so trying the ratio on a real backlog costs nothing.

How to run it this week

1. Write down your next milestone in one sentence. Not the dream, the next gate: 'launch on Product Hunt', 'first paying customer', 'ramen profitable'.
2. List the tasks competing for this week. Aim for ten, not fifty.
3. Give each an impact score from 1 to 100 against that milestone, and an honest minute estimate. Ten seconds per task.
4. Divide, rank, and do the top task tonight. Nothing else until it's finished.
5. When something changes mid-week, adjust the two or three scores it affects and keep going. No meetings with yourself.

One warning, because every framework has a failure mode: the score is a servant, not a conscience. If the math says 'write cold emails' and you genuinely cannot face cold emails tonight, doing the second-ranked task is a fine outcome; doing nothing is the only real loss. Impact per minute doesn't demand that you become a machine. It demands that you stop pretending all tasks are equal, and that when you spend an evening, you know roughly what you bought with it. For a company whose entire payroll is your evenings, that's not a productivity trick. That's the business model.