Reflections on AI, product thinking, and software development from Puzzel’s CPO, John Håkansson.
“100% predictability = 0% innovation"
That’s a quote from Henrik Kniberg, Chief Scientist and Co-founder at Abundly.ai, and it’s been rattling around in my head for years as a motto for how to build and run products. It’s also a pretty good lens for everything that’s changing right now.
I’ve recently joined Puzzel as Chief Product Officer. We build a leading cloud-native CX platform used by organisations across Europe, and like many companies right now, we’re actively exploring what AI means in practice. Not only for our product, but for how we work, collaborate, and make decisions internally.
That’s why we invited Henrik Kniberg and the team from Abundly to spend a full day with our product and engineering organisation.
If you've spent time in the agile or product world, you've probably come across Henrik's work, even if you didn’t know his name. The skateboard-to-car illustration? That's him. The Spotify Engineering Culture videos? Him. The bridge vs tunnel alignment sketch? Also him.
He’s helped shape how teams think about product development for decades, often through deceptively simple sketches and frameworks. Today, much of his focus is on how AI is changing the craft of software development.
The goal for the day was simple: everyone should leave with new inspiration, practical experience, and at least one thing they would do differently the next day.
From "no way" to "no going back"
Henrik shared a story from 2022 that set the tone for the day. A friend told him AI would soon be writing code. After 30 years in software development, his reaction was essentially: no chance.
Then GPT-4 arrived.
He locked himself in a cabin in the Stockholm archipelago for a week, turned off his phone, and used AI for everything.
Two realisations. First: AI is genuinely good at coding if you know how to talk to it. Second: knowing how to talk to it is a skill.
The punchline? He now considers GPT-4 "really bad." The speed of this field is a bit absurd.
The spectrum
One concept that stayed with me was a spectrum ranging from 0% AI to 100% AI involvement.
At one end, you write everything yourself. At the other, AI generates the work and you barely review it. In between are several different modes:
- AI suggests while you write
- AI generates and you refine
- AI generates and you review selectively
- AI handles larger parts of the workflow autonomously
The point wasn't "go full autopilot." It was: master all five, and develop the judgment to pick the right one.
“Your attention is a limited resource. Choose wisely where to spend it.”
That landed hard.
At Puzzel, we’re not just using AI to build software. We’re building AI into the product itself. Our customers deal with the same question every day: where should humans focus, and where should AI take over?
Unlike many AI use cases, they already have highly trained humans in the loop, agents handling real conversations with real consequences. The challenge isn’t automation for its own sake, but knowing when AI should act, when it should assist, and when it should step aside.
Resolving real customer pain points matters more than automating admin. AI should improve the experience by offloading repetitive work, allowing people to focus more of their energy on the conversations where human judgment and empathy make the biggest difference.
The questions that mattered most
The best part of the day wasn’t the slides or the demos themselves. It was the conversations in the team and the difficult questions that followed.
A few themes stood out.
Faster isn't always better. A faster feature factory isn't the goal. Without healthy discovery habits, AI just helps you build the wrong things faster. UX is more than UI and shiny new things. Talking to real humans won't disappear.
The Beyoncé Rule. Someone asked how you trust AI-generated code if nobody checks it. A colleague's answer: "If you liked it, then you should put a test on it." Hard to argue.
Brain rot vs. infinite teacher. If AI does the hard stuff, how do you learn? The counter: use AI as a teacher. It's infinitely patient. But it won't volunteer to teach you. You have to ask.
The productivity trap. Someone pointed out that massive productivity leaps aren't automatically good. Anxiety, shrinking attention spans, isolation. When Henrik mentioned coding while making pasta, Someone argued that sounded horrible. I appreciated the honesty. I also like pasta. :)
Moats in the age of "anyone can build anything." We discussed what happens to competitive advantage in SaaS when the cost of building drops to near zero.
My own reflection: the moat shifts from "can we build it" to "do we understand the problem deeply enough." Building a chatbot is easy. Building one that a compliance officer in an European bank will actually sign off on requires domain depth, governed knowledge, and trust earned over years, not sprints. The real moat isn't any single feature. It's having enough layers: orchestration, regulatory understanding, a partner ecosystem, a system that learns from real conversations. Copying one piece doesn't get you the whole thing.
Output ≠ Outcome
AI makes teams faster. That is not automatically a good thing. The temptation is to produce more features simply because we can. But more features do not necessarily create more value.
Use the newfound speed wisely. Refactor the messy bits. Improve architecture. Remove what doesn't work. Run experiments. Tighten security. Simplify the UI. Henrik even had a slide for this called "Don't just spray out new features!" with a bunch of devs hosing the user café with random buttons and gears. It's funnier than it sounds. And uncomfortably accurate.
This is not just an engineering challenge. It is a product challenge, and one of the most important ones we face. Speed without direction creates noise, not value. What we build, why it matters, and what success looks like .. that clarity has to come before the engineering starts. Otherwise we are just making a bigger mess, faster.
This deserves its own conversation, and I will come back to it together with our CTO Signe since this is a top priority for us to get right. As we accelerate delivery, the discipline of product thinking matters more, not less. Sharp prioritisation. Clear outcome ownership. Honest validation. The job is making sure we are building the right things, not just building things right and fast.
What stays, what shifts
Henrik made another point I keep coming back to.
We’re entering the age of generalists. Small teams can now ship products with decent security, UX, and architecture without needing specialists in every area.
But when something is truly critical, you still need human expertise. Not necessarily because AI can’t generate a solution, but because experience is needed to judge whether the solution is actually good, secure, scalable, or appropriate in the real world.
Specialists should broaden. Generalists should deepen.
The threshold for learning has dropped dramatically. That’s exciting and disorienting in equal measure.
So, what now?
I don’t think there’s a neat conclusion yet, and that’s probably fine.
This shift is happening in real time. The move towards more agentic, AI-assisted ways of building software is already changing how teams work, collaborate, learn, and define quality.
At Puzzel, we’re leaning into that change with curiosity, optimism, and a healthy amount of critical thinking.
Most importantly, we’re trying to stay focused on outcomes over hype.
The original goal for the session was simple: leave with one thing you’ll do differently this week.
I think most of us left with several.
Thanks to Henrik Kniberg and the Abundly team for a day that was equal parts inspiring and unsettling. In the best way. More to come!
//John Håkansson, CPO at Puzzel
