Introducing the SHIP Score: Straightforward prioritization for indie founders
Now that you can build anything in a fraction of the time, how do you figure out what's important?
With the emergence of Claude Code, it seems like everyone I know—developers and non-developers alike—now feel like the possibilities are endless for what they can build.
You’re no longer constrained by the time of writing code. You’re no longer constrained by code-writing abilities.
Now, there’s still time involved: lots of time writing product requirements documents for the Claude, and tons more time on QA (which is mostly manual). I included this illustration in a recent post for my company’s engineering blog:
Projects are shipping much, much faster, and that creates a new challenge:
Now that you can suddenly build anything quickly, how do you decide what to build?
This is a problem I’m hearing about more and more, especially from developer founders.
Prioritization is not a new problem. But before, projects took longer, and much, much more time was spent writing code. The number of times product builders would have to make decisions about which feature was next wasn’t all that often. Maybe twice a month as they prioritized sprints.
But now?
It might be multiple times a day. They’re spending much, much more of their time thinking at the strategic level.
(I know there are a lot of people who read this newsletter who aren’t developer founders, but they’re the original audience of Deploy Empathy, so I hope you’ll excuse me. And besides, with AI coding, there are now so many product people, designers, and researchers who suddenly feel unlocked about their product ideas that perhaps this is relevant for them, too.)
Which leads me to the SHIP Score
Last summer, I was having a conversation with a founder friend. We were talking about their product roadmap, and I asked how they were prioritizing.
They said:
“I’m prioritizing how you told me to – by listening to my customers!”
Customer complaining about a bug?
They’d drop everything and fix it.
Customer said they’d sign up if a new feature was added?
Drop everything again.
I paused, as I don’t think you should build whatever your customers want.
This conversation was a wake-up call for me.
It made me realize that I could do a much better job guiding people on how to apply what they’re learning in interviews.
You should listen, but you should also filter.
All of the possible things you [read: you personally, your team, your company] could be working on—bug fixes, feature ideas, internal tools, basically any ticket or issue—need to be filtered through the lens of what has revenue potential, competitive advantage, and what you’re capable of building and maintaining.
To make it easy to weigh those factors against each other, I created the SHIP Score: a simple scoring system to see where your highest-ROI opportunities are and go from a jumble of ideas and loose prioritization to a nice rank-ordered list.
The SHIP Score is a distillation of the prioritization framework I’ve been using in my own business for years.
If you don’t have a way to rank issues against one another, it can feel like you’ve just got a giant chaotic pile of things. And whatever is screaming at you the most will end up getting worked on… even if it isn’t the most important in the long run.
Should you work on the technically-interesting refactor that feels like it would unlock a ton of new features (but high-risk to execute)? Those little bug fixes that two customers emailed you about overnight? The huge new feature that would allow you to go after an attractive customer segment? What about the jankiness in your signup flow?
Calculating a the SHIP Score
There are three factors:
Strategic Heft: How much it differentiates you from competitors in a way that customers care about
Income: The upside/downside revenue potential
Perspiration (originally called Programming, but credit to my friend Ben Aldred for this much better name): How much sweat it will take to build, operationalize, and maintain it
Each of these factors is scored out of 5. Add strategy to income then subtract the perspiration, and that’s the SHIP score for each feature.
The idea is that you go through all of your potential projects and tasks — bug fixes, new features, refactors, infrastructure work, everything — and give it a score.
Let’s dive into each category.
Strategic Heft is competitive advantage. In other words, how much does this differentiate you from competitors in a way that customers care about? Does it make your tool stickier and reduce churn? Does it do something your competitors don’t do and you already know your customers are solving manually (and not to their satisfaction)?
Strategic Heft should be scored out of positive 5. If all of your competitors have a feature and none of your customers are asking about it, score 0. By contrast, if you’ve picked up on an unmet need in a lot of interviews, support or sales calls that your competitors aren’t solving, that would score 5.
Income should take upside (new revenue) as well as downside (lost revenue) into account. In addition to positive revenue opportunities, it should also take into account the revenue potential of not doing something. For example, that risky infrastructure overhaul might make sense if your customers are threatening to leave because of unreliable uptime.
Perspiration is negative because this is the effort it takes to scope, build, maintain, and promote something. A feature with a lot of unknowns, dependencies, interconnected parts, or new conceptual thinking requires a lot of work, even if AI is doing the coding. And even with AI is doing the coding, QA is a much bigger percentage of time (remember the chart above). And then there’s operationalizing it: design, marketing, communications. The formula makes this cost clear. This score is base-2 (exponential): a 1 is something that can be done in under a week, and a 5 would take six months.
You can see the full SHIP Score definitions on GitHub here.
Putting the SHIP Score into practice with Claude
And now you might be saying, well that’s all well and good in theory, but how do I actually use this?
When I first wrote up the SHIP Score last summer, I shared it with a bunch of founder friends privately.
One of those friends I mentioned earlier, Ben Aldred, has been using the SHIP Score for his research operations platform Participant Kit for the past six months. He’s helped me stress-test and refine it, and has generously agreed to share how he’s applied it.
Ben started using the SHIP Score before implementing an AI-driven development workflow. Initially, he had everything scored in a spreadsheet, but as his team’s engineering process has become more AI-driven, so has his SHIP scoring.
For context, let’s start with Ben’s current development process. He prefers to chunk projects into smaller, discrete tasks, and here’s what that usually looks like today:
(PS: If you’re also doing Ralph Loops, I can’t help but give a shout-out to my husband Mathias’ new open-source project, Chief, which makes it easier to harness Ralph Loops to build big projects with Claude.)
In addition to lots of helpful feedback over the past six months, Ben’s stroke of brilliance was to create a Claude Code skill he can talk to to figure out the SHIP score of a particular task.
Claude uses the SHIP Score definitions and interviews him about it:
Here’s an example from the skill instructions:
## Interview Principles
- Start at 0% confidence for every feature
- Push back on vague answers - “could help” is not validated demand
- Challenge assumptions - “I think customers want this” needs evidence
- Track confidence explicitly throughout
- Don’t settle for gut feelings - dig for specific examples
- Reference the framework definitions when explaining scores
He then had it create a database of all of his issues, ranked by SHIP Score:
Based on the skill that Ben created, I’ve created a GitHub project to help you put the SHIP Score into action. The project includes the framework itself and skill instructions.
What the SHIP Score does (and doesn’t) do for you
Help with the feeling of drowning in decisions. I created the SHIP Score before AI coding became widespread, and it’s something you can use even if you aren’t developing with AI.
But the reason why I’m telling you about it now is because with the advent of AI coding, I suddenly know a lot of people who are crushed by the amount of decision-making they’re now having to do. Using the SHIP Score system means you can clearly see which high-ROI opportunities you should put Claude to work on.
Help with feeling like you’re drowning in issues. Decisions and AI aside, it can be overwhelming to look at a list of hundreds of issues. Bugs, new features, opportunities, random ideas you had in the shower two years ago… if you’re starting your work day looking at a giant list every day, it’s no wonder you might just work on whatever customers and prospects requested overnight in your inbox.
Using the SHIP Score helps you overcome that overwhelm and recency bias and prioritize what’s important.
But it won’t do the underlying work for you. Like AI, the outputs are only as good as the inputs. In order to be able to answer questions about competitive advantage, you need to have done the work of understanding customers and the market landscape yourself. You need to have a sense of what your overall strategy is (here’s a great book if you don’t). AI isn’t going to be able to determine for you what’s important to your business, your customers, where the competitive advantages are, or what the sweat involved with QAing and maintaining a new feature will be.
(This is something I find time and time again: AI is amazing at working with frameworks and running with an existing concept, but you need to give it a lot of material, and even then, there are limits. As I wrote about in the new edition of Deploy Empathy, it’s pretty decent at summarizing a jobs-to-be-done interview with enough context and prompting. But it can’t tell me what I found interesting, insightful, or important in the interview.)
AI can take away a lot of the work, especially when it comes to writing the code, but it doesn’t eliminate all of it. You still need to do the legwork yourself.
Besides, now that you’re spending less time coding, you have more time for customer interviews :)
That’s all for now,
Michele
Every word of this newsletter was written by me the old-fashioned way.
Featuring a foreword from Jobs to Be Done Playbook author Jim Kalbach, the updated and expanded edition of Deploy Empathy includes instructions for analyzing your customer interviews with Claude — plus everything people loved about the first edition, like interview scripts for common situations and a comprehensive guide on how to get people to really open up to you in interviews.