How I work
Most of the work happens on walls like this, long before anything ships.
The most expensive mistake in product isn't building something badly. It's building the wrong thing well. A whole team can spend a year shipping a beautiful answer to a question nobody asked.My job is to make sure that doesn't happen. I lead product from the exciting messy start, when there's an opportunity and no real problem yet, through to the thing running in production. Here’s how I’ve worked each stage for 18 years.
01. Scoping & betting
Be wrong on paper, not in production.
Good work starts in a problem space, not a brief. So I name the bets out loud: write down what we're assuming, then figure out the cheapest way to find out which of those assumptions are wrong, before a build finds out for us.
When I joined Bemakers (read the Bemakers case study here) there was no product, just a deck, a vision and two founders with deep industry knowledge. The space was a wonderful mess of customs, excise and market-by-market rules, the kind of complexity that stays invisible until it goes wrong. The bet we settled on was specific: that beverage brands stuck behind importers would come direct if we gave them a webshop and quietly absorbed all the legal and operational machinery underneath. Simple on paper, hiding an enormous amount of work. Naming that bet plainly is what told us what to build, and what to leave alone.
02. Interviewing
The idea has to survive contact with real customers.
Before anything gets built, the idea has to survive contact with real customers. Not a survey. I sit with the people who would actually use the thing and listen for the problem they describe without being prompted. I’ve done it well past a hundred times now, and it’s the discipline I trust most.
It’s really about sparking conversations and getting reactions. If I could design the thing without asking anyone first I would, but I can’t, and the reactions are where the design actually comes from. The job is to get something crude in front of people to react to, as fast as possible.
The first is an example from an internal workshop, getting all our assumptions on a board and categorised. The second is putting those assumptions - translated into product features - in front of a user. It’s crude, and that’s the point.
03. Affinity mapping
Sorting the noise into patterns.
Raw interviews are noise until you group them. When the same thing surfaces across customers who have never met, that's a real pattern, and patterns are what you act on. The outliers don't get ignored, they become the next thing to go and check.
When working with Danske Bank, I took each feature idea to users and sorted their reactions into three piles: what they expected as table stakes, what they merely liked, and the few things that genuinely surprised them. The piles set the build order, not our opinions about what was clever. The seasoned reader here will understand how this is really just the Kano Model, used loosely as an artifact in a co-creation session.
Their reactions, sorted into must-haves and the rare delighters. The Kano Model is a forever favorite of mine.
04. Sketching
Thinking with a marker.
An idea described in a meeting gets polite nods. The same idea drawn on a wall gets argued with, and the argument is where it gets better. I sketch fast and rough, against three questions at once: what the business wants, what the technology can do, and what the user is trying to get done. The work that matters is where those three disagree.
At Nordea, I sketched the corporate dashboard dozens of ways before a pixel existed: how to show a treasurer their liquidity across DKK, USD and EUR, the week's payments, and whether anything needed acting on today. One rough screen carried the whole intent in a margin note, "a daily visit to ease my mind, alert me if there's anything to worry about." (Read the Nordea case study here)
The same screen drawn a dozen ways, then taken to the people who'd live in it.
05. Testing and validating
When the right answer is don't launch.
A prototype that demos well can still fail in a customer's hands. Testing is how I tell a signal from proof. A few people nodding is permission to keep going, not permission to build. I would rather ship a little earlier than is comfortable, while it's still cheap to change, but not before the thing has survived a real customer.
At Nordea, we had written the bets down: that customers wanted self-service, and that they had the information a form asks for. Then we put the prototype in front of nine corporate treasury teams, Orkla, Vestas and Carlsberg among them, and watched them try to open an account. They couldn't. The form tested fine; they just didn't have the answers it asked for, because their account manager had always handled that. "I can't answer these questions when I open an account."
Proven wrong on almost every assumption, which is exactly what a good test is for. So the recommendation was not to launch. We aimed the project at the simpler requests customers could actually finish and left account opening for another round.
06. Shipping, then adoption
Adoption is the hard part. And probably the part we don’t talk enough about.
Launching is easy. The real test comes later. The product is rarely just the product. It's the advisors who recommend it, the marketing that explains it, the teams who have to change how they work.
At Nordea, I led the UX for the platform meant to pull a large company's scattered banking, FX trading, payments, KYC done by hand over email, into one coherent place. The part I'm proudest of is the architecture underneath it, built so the bank could move one heavy process onto it at a time. The proof is that processes kept moving onto it after I was gone.
07. AI in the mix
Now I can run the loop alone.
The loop hasn't changed. Find the real problem, make it visible, validate it, ship it, watch what happens. What has changed is speed and scope. AI lets me synthesise a stack of interviews in an hour, spin up a working prototype where I used to have a sketch, and build and ship things that used to need a team. It hasn't replaced the judgment about what's worth building. It has removed most of the reasons that judgment used to wait on other people.
The work I like runs that whole arc, from a problem nobody has named yet to a product people quietly depend on, built so the thing that ships is the right one, not a beautifully made guess. That span used to take a team. Increasingly, it doesn't.
I get to decide exactly just how much confetti is needed when a task is complete. I need a lot of confetti. Read more about the task manager project if curious (about confetti-levels especially).
How I work
From the mess to the thing that ships. The methods I work by that get me from one to the other.
Most of the work happens on walls like this, long before anything ships.
The most expensive mistake in product isn't building something badly. It's building the wrong thing well. A whole team can spend a year shipping a beautiful answer to a question nobody asked.My job is to make sure that doesn't happen. I lead product from the exciting messy start, when there's an opportunity and no real problem yet, through to the thing running in production. Here’s how I’ve worked each stage for 18 years.
01. Scoping & betting
Be wrong on paper, not in production.
Good work starts in a problem space, not a brief. So I name the bets out loud: write down what we're assuming, then figure out the cheapest way to find out which of those assumptions are wrong, before a build finds out for us.
When I joined Bemakers (read the Bemakers case study here) there was no product, just a deck, a vision and two founders with deep industry knowledge. The space was a wonderful mess of customs, excise and market-by-market rules, the kind of complexity that stays invisible until it goes wrong. The bet we settled on was specific: that beverage brands stuck behind importers would come direct if we gave them a webshop and quietly absorbed all the legal and operational machinery underneath. Simple on paper, hiding an enormous amount of work. Naming that bet plainly is what told us what to build, and what to leave alone.
02. Interviewing
The idea has to survive contact with real customers.
Before anything gets built, the idea has to survive contact with real customers. Not a survey. I sit with the people who would actually use the thing and listen for the problem they describe without being prompted. I’ve done it well past a hundred times now, and it’s the discipline I trust most.
It’s really about sparking conversations and getting reactions. If I could design the thing without asking anyone first I would, but I can’t, and the reactions are where the design actually comes from. The job is to get something crude in front of people to react to, as fast as possible.
The first is an example from an internal workshop, getting all our assumptions on a board and categorised. The second is putting those assumptions - translated into product features - in front of a user. It’s crude, and that’s the point.
03. Affinity mapping
Sorting the noise into patterns.
Raw interviews are noise until you group them. When the same thing surfaces across customers who have never met, that's a real pattern, and patterns are what you act on. The outliers don't get ignored, they become the next thing to go and check.
When working with Danske Bank, I took each feature idea to users and sorted their reactions into three piles: what they expected as table stakes, what they merely liked, and the few things that genuinely surprised them. The piles set the build order, not our opinions about what was clever. The seasoned reader here will understand how this is really just the Kano Model, used loosely as an artifact in a co-creation session.
Their reactions, sorted into must-haves and the rare delighters. The Kano Model is a forever favorite of mine.
04. Sketching
Thinking with a marker.
An idea described in a meeting gets polite nods. The same idea drawn on a wall gets argued with, and the argument is where it gets better. I sketch fast and rough, against three questions at once: what the business wants, what the technology can do, and what the user is trying to get done. The work that matters is where those three disagree.
At Nordea, I sketched the corporate dashboard dozens of ways before a pixel existed: how to show a treasurer their liquidity across DKK, USD and EUR, the week's payments, and whether anything needed acting on today. One rough screen carried the whole intent in a margin note, "a daily visit to ease my mind, alert me if there's anything to worry about." (Read the Nordea case study here)
The same screen drawn a dozen ways, then taken to the people who'd live in it.
05. Testing and validating
When the right answer is don't launch.
A prototype that demos well can still fail in a customer's hands. Testing is how I tell a signal from proof. A few people nodding is permission to keep going, not permission to build. I would rather ship a little earlier than is comfortable, while it's still cheap to change, but not before the thing has survived a real customer.
At Nordea, we had written the bets down: that customers wanted self-service, and that they had the information a form asks for. Then we put the prototype in front of nine corporate treasury teams, Orkla, Vestas and Carlsberg among them, and watched them try to open an account. They couldn't. The form tested fine; they just didn't have the answers it asked for, because their account manager had always handled that. "I can't answer these questions when I open an account."
Proven wrong on almost every assumption, which is exactly what a good test is for. So the recommendation was not to launch. We aimed the project at the simpler requests customers could actually finish and left account opening for another round.
06. Shipping, then adoption
Adoption is the hard part. And probably the part we don’t talk enough about.
Launching is easy. The real test comes later. The product is rarely just the product. It's the advisors who recommend it, the marketing that explains it, the teams who have to change how they work.
At Nordea, I led the UX for the platform meant to pull a large company's scattered banking, FX trading, payments, KYC done by hand over email, into one coherent place. The part I'm proudest of is the architecture underneath it, built so the bank could move one heavy process onto it at a time. The proof is that processes kept moving onto it after I was gone.
07. AI in the mix
Now I can run the loop alone.
The loop hasn't changed. Find the real problem, make it visible, validate it, ship it, watch what happens. What has changed is speed and scope. AI lets me synthesise a stack of interviews in an hour, spin up a working prototype where I used to have a sketch, and build and ship things that used to need a team. It hasn't replaced the judgment about what's worth building. It has removed most of the reasons that judgment used to wait on other people.
The work I like runs that whole arc, from a problem nobody has named yet to a product people quietly depend on, built so the thing that ships is the right one, not a beautifully made guess. That span used to take a team. Increasingly, it doesn't.
I get to decide exactly just how much confetti is needed when a task is complete. I need a lot of confetti. Read more about the task manager project if curious (about confetti-levels especially).
How I work
From the mess to the thing that ships. The methods I work by that get me from one to the other.
Most of the work happens on walls like this, long before anything ships.
The most expensive mistake in product isn't building something badly. It's building the wrong thing well. A whole team can spend a year shipping a beautiful answer to a question nobody asked.My job is to make sure that doesn't happen. I lead product from the exciting messy start, when there's an opportunity and no real problem yet, through to the thing running in production. Here’s how I’ve worked each stage for 18 years.
01. Scoping & betting
Be wrong on paper, not in production.
Good work starts in a problem space, not a brief. So I name the bets out loud: write down what we're assuming, then figure out the cheapest way to find out which of those assumptions are wrong, before a build finds out for us.
When I joined Bemakers (read the Bemakers case study here) there was no product, just a deck, a vision and two founders with deep industry knowledge. The space was a wonderful mess of customs, excise and market-by-market rules, the kind of complexity that stays invisible until it goes wrong. The bet we settled on was specific: that beverage brands stuck behind importers would come direct if we gave them a webshop and quietly absorbed all the legal and operational machinery underneath. Simple on paper, hiding an enormous amount of work. Naming that bet plainly is what told us what to build, and what to leave alone.
02. Interviewing
The idea has to survive contact with real customers.
Before anything gets built, the idea has to survive contact with real customers. Not a survey. I sit with the people who would actually use the thing and listen for the problem they describe without being prompted. I’ve done it well past a hundred times now, and it’s the discipline I trust most.
It’s really about sparking conversations and getting reactions. If I could design the thing without asking anyone first I would, but I can’t, and the reactions are where the design actually comes from. The job is to get something crude in front of people to react to, as fast as possible.
The first is an example from an internal workshop, getting all our assumptions on a board and categorised. The second is putting those assumptions - translated into product features - in front of a user. It’s crude, and that’s the point.
03. Affinity mapping
Sorting the noise into patterns.
Raw interviews are noise until you group them. When the same thing surfaces across customers who have never met, that's a real pattern, and patterns are what you act on. The outliers don't get ignored, they become the next thing to go and check.
When working with Danske Bank, I took each feature idea to users and sorted their reactions into three piles: what they expected as table stakes, what they merely liked, and the few things that genuinely surprised them. The piles set the build order, not our opinions about what was clever. The seasoned reader here will understand how this is really just the Kano Model, used loosely as an artifact in a co-creation session.
Their reactions, sorted into must-haves and the rare delighters. The Kano Model is a forever favorite of mine.
04. Sketching
Thinking with a marker.
An idea described in a meeting gets polite nods. The same idea drawn on a wall gets argued with, and the argument is where it gets better. I sketch fast and rough, against three questions at once: what the business wants, what the technology can do, and what the user is trying to get done. The work that matters is where those three disagree.
At Nordea, I sketched the corporate dashboard dozens of ways before a pixel existed: how to show a treasurer their liquidity across DKK, USD and EUR, the week's payments, and whether anything needed acting on today. One rough screen carried the whole intent in a margin note, "a daily visit to ease my mind, alert me if there's anything to worry about." (Read the Nordea case study here)
The same screen drawn a dozen ways, then taken to the people who'd live in it.
05. Testing and validating
When the right answer is don't launch.
A prototype that demos well can still fail in a customer's hands. Testing is how I tell a signal from proof. A few people nodding is permission to keep going, not permission to build. I would rather ship a little earlier than is comfortable, while it's still cheap to change, but not before the thing has survived a real customer.
At Nordea, we had written the bets down: that customers wanted self-service, and that they had the information a form asks for. Then we put the prototype in front of nine corporate treasury teams, Orkla, Vestas and Carlsberg among them, and watched them try to open an account. They couldn't. The form tested fine; they just didn't have the answers it asked for, because their account manager had always handled that. "I can't answer these questions when I open an account."
Proven wrong on almost every assumption, which is exactly what a good test is for. So the recommendation was not to launch. We aimed the project at the simpler requests customers could actually finish and left account opening for another round.
06. Shipping, then adoption
Adoption is the hard part. And probably the part we don’t talk enough about.
Launching is easy. The real test comes later. The product is rarely just the product. It's the advisors who recommend it, the marketing that explains it, the teams who have to change how they work.
At Nordea, I led the UX for the platform meant to pull a large company's scattered banking, FX trading, payments, KYC done by hand over email, into one coherent place. The part I'm proudest of is the architecture underneath it, built so the bank could move one heavy process onto it at a time. The proof is that processes kept moving onto it after I was gone.
07. AI in the mix
Now I can run the loop alone.
The loop hasn't changed. Find the real problem, make it visible, validate it, ship it, watch what happens. What has changed is speed and scope. AI lets me synthesise a stack of interviews in an hour, spin up a working prototype where I used to have a sketch, and build and ship things that used to need a team. It hasn't replaced the judgment about what's worth building. It has removed most of the reasons that judgment used to wait on other people.
The work I like runs that whole arc, from a problem nobody has named yet to a product people quietly depend on, built so the thing that ships is the right one, not a beautifully made guess. That span used to take a team. Increasingly, it doesn't.
I get to decide exactly just how much confetti is needed when a task is complete. I need a lot of confetti. Read more about the task manager project if curious (about confetti-levels especially).