Upgrading Your
Operating System

“If it had an acronym, I had a template for it.”

Have you ever experienced this?

• Perfectly executed, following the process.

• Hitting the velocity target every sprint.

• Shipping the features on the roadmap, on time.

• Feeling secure, because the artifacts are all there: OKRs, JTBD, UAC, …

I followed the recipe, measured the ingredients perfectly, but the dish came out bland.

“Why does this happen, over and over, even in teams filled with smart, dedicated people?”

The answer is not in our processes, but in our psychology.

Cognitive ease

System 2 requires significant mental effort, and our brains are inherently lazy. We default to System 1 whenever possible.

“We, and the industry at large, have fallen into the Framework Trap.”

Is silent

You cannot feel it happening. Nothing breaks, nothing is late.

Seductive belief

That the right process will automatically yield a high-quality outcome.

We become so focused on the ceremony of our chosen methodology that we forget to engage in the deep thinking it was meant to support.

Why it keeps happening

1. Reach for the framework
2. Fill it in
3. It feels productive
4. The thinking it was meant to hold never happens

and the artifact looks finished, so nothing calls you back

What David had

• Daily standups at 9:15 AM sharp, never more than 15 minutes.

• Sprint planning with perfectly groomed stories and clear acceptance criteria.

• Retrospectives that actually led to action items.

• A Jira board that was a work of art: every ticket estimated, every epic linked to an initiative, every initiative mapped to an objective.

Most impressively, their velocity was rock solid. Eighteen consecutive sprints averaging 87 story points, standard deviation under 5.

“The team had become obsessed with maintaining that velocity. It became the ultimate measure of success.”

Sprint 1Sprint 18

High velocity ≠ high value.

“They were on a feature factory treadmill, running faster and faster but going nowhere meaningful for the user.”

The turning point

1. What job are our users hiring our product to do?

   Not: what features do they request?

2. What’s the single biggest barrier preventing them from succeeding at that job?

   Not: what’s next on the backlog?

3. If we could only ship one thing this quarter, what would create disproportionate value?

   Not: what can we ship fastest?

Users weren’t hiring CloudMetrics for “more dashboards.” They were hiring it to answer one question faster than they could by hand: “Which of my marketing campaigns is actually driving profitable customers?”

Framework Trap × Velocity Trap
= Feature Factory

Are we in a feature factory?

Six questions, drawn from the ones this talk already asks. The tickable version is on the page below.

1. Can you connect every roadmap item to a customer problem or business outcome?
2. Can you name the job your users are hiring your product to do, rather than the features they request?
3. Do you know the single biggest barrier stopping them at that job?
4. Do you know what would create disproportionate value this quarter, rather than what ships fastest?
5. Is there a number your team is prouder of than velocity?
6. Your velocity held steady for six months. Did revenue, engagement and satisfaction hold with it?

If these questions make you uncomfortable, you are likely caught in the trap. Lol… But frameworks are not the enemy. That would be just as dangerous as blind framework worship.

My earlier stage at Mekari

• I led a team that was framework-averse. “We don’t need process. We’re agile with a lowercase ‘a’.”

• Sprints had no rhythm. Developers got blocked waiting for design specs that didn’t exist.

• Designers built beautiful interfaces for features engineering had already ruled infeasible.

• I would have an “aha” moment mid-sprint and try to pivot the entire direction.

They worked incredibly hard, but the work wasn’t accumulating into coherent value. They were drowning in their own flexibility.

Introducing frameworks didn’t make them less creative, it freed them to be more creative, because they stopped spending cognitive energy on coordination.

This is when frameworks work beautifully

Learning a new domain

For a junior PM, frameworks are training wheels. Jobs-to-be-Done gives you a structure for thinking about user needs before you have the intuition.

Team coordination

Shared language and predictable rhythms. Across product, design and engineering, Scrum or Shape Up is the skeleton that lets everyone know what to expect.

Scaling decisions

Five people can decide in conversation. Two hundred people across eight teams need frameworks to stay consistent and still decide autonomously.

A clear, complicated domain

Where cause and effect are predictable, follow the pattern. Don’t reinvent a standard checkout flow. That pattern is decades of accumulated wisdom.

Follow, or transcend?

• Is the problem well understood?

  Yes → follow

• Are you still learning the domain?

  Yes → follow

• Do several people need to move in step?

  Yes → follow

• Is the uncertainty genuine?

  Yes → transcend

• Are the stakes high?

  Yes → transcend

• Is the framework optimising the wrong thing?

  Yes → transcend

The masters aren’t the ones who know the most frameworks, or the ones who reject all frameworks. They know which to apply in which context.

This is what I mean by upgrading your operating system.

The meta-skill of knowing which tool to use when, and the judgment to recognise when no existing tool fits and you need to think it through from scratch.

Your brain’s energy budget

System 2

The slow, analytical mode is especially energy-intensive. It burns more glucose, and your brain really doesn’t want to do this.

System 1

So it constantly looks for ways to conserve energy, handing work to the more efficient System 1.

Which is why, after a day of back-to-back meetings, you cannot muster the energy to think deeply about strategy. Decision fatigue.

Your brain loves patterns. This is why filling out a framework feels productive.

The problem is that cognitive ease and cognitive quality are not the same thing.

To be continued…