Blank Canvas Thinking. Don’t ignore experts. Ignore inherited conclusions.

Experts are great at explaining how something works.

They get a lot less useful when the answer to “why do we do it this way?” is…

“Because that’s how it’s done.” 😂

Most of us inherit our view of the world. Job titles. Business models. Software categories. Methodologies. Even the words we use to describe the problem.

Then we spend years trying to get a little better than everyone else playing the same game.

That’s a hard way to stand out.

Better invites comparison. Different changes it.

“Our CRM is easier.” “Our consultants are faster.” “Our AI is smarter.”

Better is useful. But when everyone is better, the buyer just compares features and prices.

First-principles thinking asks a different question:

What if the existing category is part of the problem?

Where I learned this

I’ve spent a lot of my career around big transformation programs. There’s no shortage of methodology. Project management. Change management. Enterprise architecture. Agile. Design thinking.

And transformation is still really hard.

So I kept asking: if we already have all these disciplines, why do transformations still struggle to turn strategy into results?

I could have written another methodology. Instead, I questioned the category. Maybe transformation didn’t need another methodology. Maybe it needed execution management.

That became Transformation Execution Management. And later, the TXM Body of Knowledge.

I didn’t start with “I want to write a book.” I started with “I think we’re describing the problem wrong.” The book came later.

And it’s still evolving. The book isn’t proof that I’m right. It’s me making the thinking explicit enough for other people to challenge.

Then: where’s the system?

A framework is one thing. Running it is another.

If TXM says transformation needs an execution system… where is it? PowerPoint? Excel? Jira? Each one solves part of the problem. None of them is the thing.

So I started ClarisTXM, an experiment in turning the ideas into a working system.

Because it’s easy to invent a framework. It’s much harder when your own software has to survive it.

My favorite test: eat your own dog food

If I say businesses should work from first principles, I should.

If I say AI changes how software gets built, I should be building software differently.

That doesn’t prove I’m right. But it gives the idea somewhere to fail. I like that.

AI made me do it all again

When generative AI exploded, everything became an “AI something.” Copilots. Agents. AI platforms. AI architects. I did it too.

Then I asked: if we started today, knowing what AI can do, would we design the process the same way? The application? The work itself?

Probably not. That question is what Business AI Architecture is about.

And if AI changes how software gets built, the lifecycle should change too. That’s the AI-DLC: from canvas to customer, with AI doing more of the building and people approving what ships.

And sometimes the honest answer is: don’t use AI. When you need the same right answer every single time, a rule or a calculator beats a model. 🤔

How I work

1. 1Engineer. Design the right solution, from the problem up.
2. 2Execute. Make it real. A plan nobody runs is just a nice document.
3. 3Excel. Keep improving the results. Which feeds the next round of engineering.

Try it yourself

You don’t need my framework. You don’t need my terminology. You definitely don’t need my conclusions.

Grab a blank page and ask:

• What do I know?
• What am I assuming?
• What changed?
• What doesn’t make sense anymore?
• What problem do I see differently from everyone around me?

Then draw it. Build it. Test it. Name it if you need to. Teach it to someone else.

And see where it goes. That’s what I’m doing here. 🙌

— JP