Shipping with Judgement

I used to think prioritization was simple and straightforward, but that’s far from the truth. For a part of my career, i’ve struggled with this a bit. I’m pro build first, show, not tell. Lol.

The question usually was, “How hard is it to build this?”. So you’d gather a set of ideas, debate them a bit, plug them into a framework like RICE, and squint at the spreadsheet until something resembling a roadmap emerged. Reach. Impact. Confidence. Effort. All tidy. All reasonable. Awesome … not exactly.

And for a long time, that actually worked.
Because like i said earlier, the hardest part of shipping software… was actually shipping or building it.

But something subtle, and then not so subtle, changed. TADAAAA!

AI didn’t just make products smarter. It made building shockingly and insanely fast.

Prototypes that once took weeks now take hours. I mean, we used to have or call them weekend projects for a reason, but these are minute projects now.

You can stitch together tools, glue APIs, scaffold backends, and deploy globally, often in a single sitting. One shot from infinity and beyond. Things that once required a team and a sprint now require an idea and a keyboard. Scratch that, you only need an idea and your voice. The End!

And that’s… intoxicating.

But also quietly dangerous, because building got cheap, while owning didn’t.

The hard part moved. It just moved somewhere less visible.

Now the real cost is:

• maintaining what you ship
• supporting edge cases
• keeping compatibility
• handling security & compliance
• absorbing cognitive load
• explaining behavior to new teammates
• and carrying the weight of every “quick win” you ever said yes to

It took me a while to admit this, but we didn’t update our decision-making when the world changed.

We just kept shipping faster.

Eventually, centuries later, I realized the real constraint isn’t velocity anymore.

It’s judgment.

The Build vs Buy Reality (That I’m Learning the Hard Way)

I personally build tools with AI a lot more now. And honestly, it’s hella fun. It feels like superpowers and, I..am..Ironman. Snap!!!

But at some point, I usually hit the same question:

Should I have built this?

Emphasis on “should i have,” because by then, it already exists, and sometimes it has 0 users, and I’m sitting there rethinking my life choices. lol.

Build vs Buy is now more real than ever.

If the question is “Can I build it?”
The answer is more than likely:

Yes.
Yes.
Yes.
Yes to infinity…and beyond.

It’s ridiculously easy now.

But if the question is:

Should I build it?

…arriving at a simple no is often complicated, political, emotional, and often slow.

And that’s when I realized:

Our frameworks were still optimized for a world where effort was scarce. That’s no longer true.

Which brings me back to RICE.

Why RICE Started Feeling Wrong

I still like RICE. It’s thoughtful. It’s clean. It asks:

How big is the impact, and how much effort will it take?

But that model assumes effort is the bottleneck.

Today… it isn’t. Effort shrank. Ownership didn’t.

And RICE doesn’t ask:

• What will this cost us every day after launch?
• How risky is this if it breaks?
• Does this actually move our strategy forward?
• Will this slow down everything else later?

So I found myself wanting a way to have those conversations without turning product decisions into a PhD dissertation.

Something simple enough for a whiteboard. Something honest enough to stop us lying to ourselves.

That’s how I ended up with something I now call SCORE.

Yes, you heard it right, and no, it’s not meant to be clever. It’s meant to be usable.

SCORE — A Simple Lens for Post-AI Product Judgment

At some point I wrote down the five questions I actually wanted to ask about any feature or product. And they turned into this:

S — Strategy
C — Cost (long-term)
O — Opportunity
R — Risk
E — Effort

Each gets a 1–5 score.
Nothing fancy. No multipliers. No hidden math.

Here’s what they mean in plain language:

• Strategy — Does this move us closer to what we must be great at?
  1 = totally off mission
  5 = core to our differentiated value

• Cost (long-term) — How expensive is this to own?
  Not build, own. Maintenance, support, cognitive load, compliance.
  1 = almost no drag
  5 = heavy, ongoing burden

• Opportunity — How big is the upside if this works?
  1 = niche benefit
  5 = meaningful growth / retention / leverage

• Risk — How bad is it if this goes wrong, and how uncertain is it?
  1 = reversible, contained
  5 = public, legal, data, operational, or reputational blast radius

• Effort — How hard is it to get to first value?
  1 = small change
  5 = multi-team project

Then I sum the two sides of the story:

Value  = Strategy + Opportunity
Burden = Cost + Risk + Effort

And that’s it. Two numbers. Not precision, but perspective.

From there, the pattern gets very clear:

This is the only math I want in a meeting, because this isn’t about being right. It’s about being honest.

The Moment This Actually Clicked

There was a point at Onboardbase, like many Founders or PMs, where a big customer asked for a feature. Not a bad feature. Just… not something that objectively made the product better right now. Eventually, yes… but other things were better bets right now.

We said yes. Of course we did.

It was easy to build. It made them happy. There was revenue attached. Awesome!!! Right?

Six months later, it was showing up everywhere:

• in bug queues
• in onboarding confusion
• in technical debt
• in roadmap constraints

We thought we had been pragmatic. Really, we had just been short-sighted.

If we’d run that feature through SCORE back then, the conversation would’ve looked different:

• Low Strategy
• Medium Opportunity (for exactly one or two customers)
• High Risk (edge cases + dependency)
• High Long-Term Cost
• Low Effort

Which lands that squarely in:

Low-Value • High-Burden

AKA the quadrant known as:
“Don’t do this, at least not like this.”

Today, when something is good for the customer but not obviously good for the product, I don’t default to no... well, not all the time. Lol

I default to:

How do we build this without letting it infect the core?

Flags. Extensions. Add-ons. Enterprise modules. Services, not features.

Same money. Less damage.

SCORE didn’t make me smarter. It just made the trade-offs undeniable.

SCORE Isn’t a Formula, It’s a Language

I don’t want more frameworks pretending to be science.

This isn’t that.

It’s simply a way to ask, out loud:

• Is this truly strategic?
• Does the upside justify the drag?
• Are we underestimating risk because we want this?
• Are we saying yes because it’s easy?
• Are we building faster than we can own responsibly?

And to do it without spreadsheets bullying the conversation.

Most teams don’t need more speed. They need better brakes.

My Rule of Thumb Now

It’s ridiculously simple:

• High Value + Low Burden = Ship.
• High Value + High Burden = Stage & harden.
• Low Value + Low Burden = Keep tiny or buy.
• Low Value + High Burden = Kill.

And I sleep better. Because I know we’re not mistaking movement for progress.

Judgment Is the Real Bottleneck Now

AI raised the ceiling on what we can build, dramatically.

What it didn’t raise is:

• the human capacity to maintain complexity
• the patience of customers living with broken things
• the reliability expectations for production systems
• the mental bandwidth of teams

So the constraint shifted from execution to judgment. And if we don’t update how we decide, we end up sprinting straight into a wall. Pretty fast too.

SCORE isn’t perfect. But it’s simple and open to modification.
And simplicity is what makes it usable, which makes it real.

Because at the end of the day:

Shipping fast is easy now.
Shipping wisely is the real work.

And that’s why I use SCORE.

A Quick Note on Zero-to-One Ideas (and the “72-Hour Phenomenon”)

I decided to try out SCORE on some completely new ideas to see how well it worked.

And the truth is, it was only half-accurate and it needed some tweaking.

SCORE really shines once something already exists, when the question is “what should we do next?” rather than “should this exist at all?” or “is this even worth doing?”

Zero-to-one ideas live in a different world. Strategy is still forming. Risks are mostly unknown. The work is really about discovery, not optimization.

So when I use SCORE at that stage, I don’t treat it as a prediction, I treat it as a hypothesis. A snapshot of what I currently believe about Value vs Burden, fully expecting those beliefs to evolve as reality shows up.

And that’s fine, because the goal isn’t precision. The goal is honesty.

There’s also a pattern I keep seeing early on, what I call the 72-hour phenomenon:

Day 1: This is amazing!
Day 3: Wait… when would I actually use this?
Day 7: Forgotten.

That’s what happens when we optimize for the “aha moment” instead of the “Tuesday at 3 pm moment.”

You see real products don’t just dazzle you once, they quietly solve a real problem in the middle of a normal, slightly stressful weekday. So If a product doesn’t matter on Tuesday, 3 pm, it probably doesn’t matter going forward.

So I tested SCORE on some of my own personal tools, experiments and products. Out of 20, only 5 made it through. And even those 5 still deserve scrutiny. The scores weren’t some oracle truth, they were directional framing tools, useful for understanding shape and intent:

• Private Connect — High Value • High Burden
  A strategic “moat” product. Big upside, but complex, trust-sensitive, and heavier to own long-term.
  Decision: Do, but stage carefully

• AI RateLimit — High Value • Medium–High Burden
  Governance and safety for AI usage. Very real need, but it carries meaningful operational, reliability, and security weight.
  Decision: Do Soon, real market pull, but design for robustness

• InstantAPI — High Value • Medium–Low Burden
  A wedge product. Strong upside with lighter ownership cost, easier to ship, easier to adopt.
  Decision: Do Now, fast traction, easier to maintain

• PortKill — High Value • Low–Medium Burden (Golden Quadrant)
  A true Tuesday at 3pm tool. Relieves recurring developer pain with relatively low complexity and risk.
  Decision: Definitely Do Now

• GPUKill — High Value • Medium–High Burden
  Solves expensive, painful GPU problems, but it’s a strategic product with real ownership gravity and trust requirements.
  Decision: Do, but treat as a strategic product, not a quick utility

Those shapes will probably stay the same, even if the numbers shift as the products mature.

So I’ve come to think about it like this:

In the idea stage, my job isn’t to run SCORE yet, it’s to answer a simpler question:

Does this reliably solve a Tuesday at 3 pm problem for someone who actually cares?

Once the answer is yes, then SCORE becomes useful, because the conversation shifts from “could we build this?” to “should we own this?”, And that’s where Value vs Burden really starts to show up.

So this is how I see it now:

Idea stage > SCORE = hypothesis
Growth stage > SCORE = reality-check
Mature stage > SCORE = priority engine

Different certainty levels. Same lens. Just increasing judgment, and confidence over time.

Food for Thought

I know this is opinionated, and i’m open to the idea that some things might be wrong, but the truth we all agree on is that there needs to be a way to make better, honest judgment. There’s no prompt that will get you out of it.

— Dante