Journal

Over the past year I started building products alone, with AI, from idea to production. First Bloom, a training app I use every day. Then km7, a voice companion for runners. Real products, real users, no team.

The thing nobody tells you about building with AI is that execution was never the hard part. It felt like the hard part, because it was the slow part. Months of development made every decision feel expensive, so we got good at planning, estimating, negotiating scope. AI removes most of that friction — and what's left, suddenly visible, is the actual hard part: knowing what to build.

When code becomes cheap, the expensive things are the ones that were always expensive. Understanding a problem well enough to describe it precisely. Deciding what to leave out. Noticing when you're building for an imagined user instead of a real one. I've thrown away more working features this year than in my whole career — not because they were broken, but because building them was so fast I could afford to learn they were wrong.

That inversion changes what product management is. The role was never really about coordinating output, but organisations treated it that way because output was the bottleneck. Now a single person can ship what used to take a team a quarter. The bottleneck has moved to judgment: which problem, which bet, which evidence would change your mind.

It also changes discovery. AI compresses build time, but it doesn't compress learning time. Users still need weeks to show you how they actually behave. If anything, cheap execution makes discovery more important, because the cost of confidently building the wrong thing has never been lower — you can now build three wrong things in the time it used to take to build one.

I keep meeting product managers worried that AI makes their role obsolete. Building with it daily has convinced me of the opposite: the parts of the job AI absorbs are the parts that were never the point. What remains — problem selection, taste, the ability to say no with evidence — has quietly become the whole job.

The teams that will struggle are not the ones without AI skills. They're the ones that never learned to decide what's worth building, because the slowness of execution always hid that gap.

Product discovery is the work a team does to understand which problem is worth solving — and for whom — before committing to building a solution. That's the whole definition. Everything else is technique.

Most teams I meet don't lack discovery methods. They have interview guides, opportunity trees, experiment templates. What they lack is the willingness to let discovery change their mind. The roadmap is already promised, the feature is already named, and discovery becomes theatre: interviews run to confirm a decision that has already been made.

You can tell real discovery from theatre with one question: what evidence would make you not build this? If nobody can answer, it isn't discovery. It's documentation for a decision that predates it.

Good discovery starts from the decision, not the method. What are we actually trying to decide — whether the problem exists, whether our solution fits it, whether people will change their behaviour for it? Each of those needs different evidence, and most need far less machinery than teams assume. Not every question deserves an A/B test. Some just need five honest conversations and the discipline to hear the answers.

The classic objection is that discovery slows delivery down. My experience is the opposite: teams skip discovery to move fast, then spend quarters shipping variations of something nobody asked for. Slowing down at the front makes everything downstream faster, because the direction holds under pressure instead of shifting with every stakeholder meeting.

AI has made this more true, not less. You can now prototype in hours what used to take weeks, which means you can put something concrete in front of users almost immediately. That's a gift for discovery — and a trap. Faster building means you can also validate faster in the wrong direction, mistaking the speed of iteration for the quality of learning.

The teams that do discovery well don't treat it as a phase that ends when development starts. They treat it as a rhythm — a continuous habit of checking that the problem is still real, the bet still makes sense, and the evidence still points where they're going.

The most interesting part of teaching future PMs was not the theory. It was watching them run into the same walls experienced teams hit: assumptions presented as facts, consensus reached too early, activity mistaken for evidence.

In May 2026, I stepped into a new kind of room. Hyper Island invited me to be an Industry Leader for their Product Management course — Collaborative Project & Stakeholder Management. Five weeks, one real client brief, a final week where every team ran a workshop with real stakeholders from a real company.

I went in thinking I would be the one with the answers. What happened was the reverse. A room full of good questions makes you put words to things you have been doing on instinct for years. I learned as much about what I believe as I taught.

The teams that did the most interesting work were the ones who slowed down in front of the client. They asked the uncomfortable question: is this actually the problem? They did not take the brief for granted. They surfaced assumptions and opened up the opportunity space before reaching for solutions. What made it work was not method — it was that they had learned to think together first, to disagree without rushing to consensus.

That is the part of product management no framework really captures. We work in a time where AI makes shipping faster every month. Which makes a few things matter more, not less: that instinct to question the problem before building the solution, and the ability to think together with other people. Neither can be generated.

I will be back at Hyper Island after summer as Industry Leader for another course. Turns out teaching is exactly the kind of thing that feels slightly too big — until you do it.

AI isn't failing. What I'm seeing instead is teams getting very good at moving fast in directions that were never clearly defined to begin with.

Everyone says they're doing AI, but when you look closer, most of the effort is concentrated around activity rather than outcomes. Tools are introduced, pilots are launched, dashboards start filling up, and for a while it looks like real progress is happening.

Then a few months pass, and the uncomfortable question comes up: what actually changed for the business? In many cases, the answer is still unclear. Not because the technology isn't capable, but because success was never defined in a way that could guide decisions.

As a result, AI ends up being used where progress is easiest to demonstrate. Teams write faster, ship faster, and produce more, which creates a sense of momentum without necessarily improving anything that matters.

What's much harder, and significantly more valuable, is using AI to understand customers more deeply, connect fragmented insights, and improve the quality of decisions before teams commit to building. Speed on its own doesn't create better outcomes. It just shortens the path, whether that path is right or wrong.

The teams I've seen get real impact are not the ones with the most advanced tools. They're the ones who took the time to define the outcome, clarify who owns the decision, and connect insights to action before scaling anything. Without that, AI doesn't become a multiplier. It becomes noise.

There is something that happens when people are in the same room that does not happen anywhere else.

I have spent the last year helping build the Data & AI Stockholm community alongside people who care about making space for real conversations about AI in organisations. Not the hype. The actual work: what it takes to implement well, what fails and why, what problems are harder than they looked in the pilot.

What strikes me at every event is how much people need to think out loud together. We have more information available than at any point in history. Every question has an answer somewhere. But information does not tell you what to pay attention to, and it does not help you work out what you actually believe.

Rooms do that. The question someone asks from the audience. The conversation that starts during the break and does not end. The moment when two people who work in completely different contexts realise they are working on the same problem.

I think rooms are becoming more valuable, not less, precisely because so much else has moved online and become faster and more abundant. The scarcity now is presence. Time that is not optimised. Conversation that does not have a defined output.

That is what I keep trying to create. Space that slows people down just enough to think together.

When AI makes building faster, the question that used to live at the end of a sprint moves to the beginning: should we be building this at all?

I have been thinking about this since a conversation with the SeventyOne team. We were working through what is actually changing for organisations as AI accelerates delivery capacity. The answer surprised me in its simplicity: the constraint is shifting.

For years, the bottleneck in product was execution. You had an idea, you knew roughly what to build, and the challenge was getting it built well and shipped fast enough. Teams optimised for throughput. Roadmaps were full. Velocity was the thing people measured.

When building becomes genuinely fast, that changes. You can still fill the roadmap. You can still ship. But the gap between shipping something and shipping the right thing widens, and it becomes harder to hide.

The teams I see struggling are not struggling because they cannot use the tools. They are struggling because the tools exposed a gap that was always there: no reliable way to find the right problem before building the solution.

This is good news for product management. It means the work that always mattered — problem definition, discovery, deciding what not to build — is becoming harder to skip. Speed makes it visible.

The question is whether organisations will slow down enough at the front end to take advantage of that.

There is a particular kind of discomfort that comes from stepping out of a defined role into something open-ended. Not the discomfort of failure. The discomfort of not knowing exactly what the shape of success looks like yet.

I started consulting in February. It was not a dramatic decision. It was more of a quiet one: I had been thinking about it for a while, the timing felt right, and something in me knew it was time to stop waiting for conditions to be perfect before deciding.

What I did not expect was how much the transition would teach me about my own assumptions. In a permanent role, there is always a structure around you: a team, a roadmap, a set of problems that belong to you. That structure is useful. It is also, I realised, something you can hide behind.

Not knowing what comes next forces a different kind of honesty.

The first few weeks felt like learning to read a room again. Each engagement is a new context, a new set of people, a new problem to understand before trying to help with it. You cannot show up with answers. You have to show up with questions, and be comfortable staying with uncertainty longer than feels natural.

I think that is what I was looking for, without quite knowing it. Not the uncertainty itself, but what it requires of you.

Trust is often talked about as a value. In practice, it's an operating system.

When trust is present, people speak sooner. They share doubts before they harden into problems. They take responsibility because they feel safe doing so. Work moves forward with less friction, fewer defensive loops, and more honesty.

When trust is missing, everything slows down. Meetings get heavier. Decisions are deferred. People spend energy protecting themselves instead of solving problems.

I've learned that trust isn't built through grand gestures. It's built in small, consistent moments: how feedback is given, how uncertainty is handled, how mistakes are met. It shows up in whether people feel listened to when things are unclear.

In my work, I try to treat trust as infrastructure. Something you design for, maintain, and protect. Not because it feels nice, but because without it, even the best strategy struggles to take root.

Speed is easy to celebrate. Velocity looks good on slides. But speed without direction quickly turns into noise.

What I've learned over time is that effective teams don't move fast all the time. They move together. They know when to push and when to pause. They create space to think, to question, to adjust. That rhythm is what allows momentum to last.

In product work, we often confuse motion with progress. We fill roadmaps, ship features, and close tickets, yet still feel stuck. Usually that's a signal that the rhythm is off. The work is moving, but alignment is missing.

Healthy teams pay attention to this. They revisit assumptions. They name uncertainty. They allow learning to shape direction rather than forcing outcomes to match a plan created too early.

For me, good product leadership isn't about constant acceleration. It's about creating the conditions where people can do their best thinking, together, over time.

That's when progress becomes sustainable.

There are moments when work becomes quieter, not because there is less to do, but because something inside you slows down enough to notice what really matters.

For me, that often happens in spaces that have nothing to do with work on the surface. Singing in a choir. Walking without headphones. Sitting in a room where nobody is trying to impress anyone else. In those moments, patterns emerge. You start to notice how people respond, where energy flows easily, and where it gets stuck.

That attentiveness is not separate from how I work. It's foundational to it.

In product, we talk a lot about clarity, alignment, and focus. But those things rarely appear because someone forced them into existence. They emerge when we make space to listen. To what users are actually doing. To what teams are not saying out loud. To where friction keeps repeating itself.

I've learned that good decisions don't come from certainty. They come from presence. From staying with a problem long enough to understand its shape before trying to fix it.

That's the rhythm I try to work in. Not rushed. Not static. Attentive.