I think what surprised me the most in this project was realising how easy it is to become attached to an idea, even when you know very well the importance of questioning it and constantly iterating on it. From my previous experience working on AI strategy, I already knew how important it was to start with the problem rather than the solution. Yet somehow, my team and I still ended up doing the opposite.
Our initial proposal was an in-store assistant for Albert Heijn (AH) that would use the app and hand scanners to guide shoppers based on their shopping list. My first responsibility was defining the problem, so I started by looking more in depth into AH’s existing services and previous experiments. Quite soon, I found out that the app already sorts shopping lists by the walking order of the selected store, and AH had tested more advanced navigation. I was scared we might have to discard the whole idea, since our proposal had already been accepted. My first thought was, how did we not check this earlier?
I think this was particularly uncomfortable because I came into the course feeling like I already understood the importance of starting with the problem rather than the technology. During my internship at Procter & Gamble, I had worked on AI strategy within an existing business organisation, where the processes and many of the challenges were already known. In this project, however, we had the freedom to identify the opportunity ourselves. Looking back, I think that made it easier to become attached to an interesting solution before properly questioning the problem it was supposed to solve. The main functionality of our original proposal was not even particularly dependent on AI. Finding an efficient route is largely an optimisation problem, while store locations and shopping lists are data. We had mentioned AI without clearly asking what we needed it for.
Another concern I kept coming back to was who would actually use the assistant. How I saw it: frequent shoppers were probably the most likely to use an AH feature, but they already knew their store well. Meanwhile, those who would benefit most from navigation might not shop there often enough to use it regularly. At first, I saw this as an adoption issue. Later, I started questioning whether we had identified the right problem in the first place.
However, rather than starting over, we looked at what AH’s existing services were still missing. We eventually focused on situations where a shopper’s original plan no longer works, such as when a product is sold out. Instead of just helping shoppers find products, our assistant would suggest suitable alternatives based on their recipe, dietary needs and budget. The shopper would then decide whether to accept the suggestion himself. I could see a more meaningful role for AI here, as it would need to consider several factors at once. However, I was still sceptical about whether people would actually use it. We also recognised that certain decisions, particularly allergen safety, should rely on strict rules rather than AI judgment.
The part I enjoyed most was collecting evidence, from designing the survey and checking the questions for bias to analysing the results. I was genuinely interested in checking whether my doubts were valid. We considered simulating how much shorter an optimised route made a trip, but that would mostly test something AH already partly offered. Given the time, we chose an online survey with scenarios instead of in-person interviews. I was honestly sceptical we would get enough responses, but one teammate collected over 30 in a couple of hours. I do wish we had involved potential users in developing the prototype. Our teammate working on it was a frequent AH scanner user, but someone who knows the store that well might need navigation the least. I also became less satisfied with just asking people whether they had the problem and liked our solution, because that does not tell us if an AI feature adds enough value to be worth building. So we compared a recipe-aware suggestion with a simple rule. Our first rule suggested lasagne sheets instead of penne, which was unfairly weak, so we changed it to spaghetti. It was a small decision, but one of my biggest learning moments: if the alternative is weak on purpose, we are not really testing anything.
The findings surprised me. 17 of 57 respondents had a problem with a planned product on their last AH trip, including regular shoppers at the same store, and 80% would take the recipe-aware substitute compared with 51% for the category-based one. This challenged my belief that nobody would need the assistant, although stated preferences do not prove actual use. Other results changed the concept. Nobody wanted automatic swaps, and most found the checkout suggestion pushy, so substitutions stayed subject to the shopper’s approval, and we removed the checkout add-on.
Unfortunately, not everything went as planned. A form error showed some participants both versions, so we could only compare the first one each person saw, and the groups ended up uneven. I wish we had been clearer about that in our executive summary. I also realised our comparison did not prove AI was necessary, since a more detailed rule could have suggested the same pasta. That is why we recommended testing AI against a stricter rule before scaling.
Regarding my contribution to the project, I worked mostly on the evaluation, helped shape the strategic direction and ended up coordinating quite a lot around scope, deadlines and making the slides consistent. I enjoyed being able to steer the project, but I also recognised something about myself. I often coordinate because I am uncomfortable with uncertainty about how everything will come together. I like structuring the work and creating internal deadlines so that we are not rushing at the last minute. I also sometimes take on too much because doing it myself feels faster. The prototype was an opportunity to approach this differently. I would have enjoyed building something technical myself, but I had already had that experience in previous studies and internships, while a teammate with no technical background was genuinely curious about prototyping, and I really wanted him to have that opportunity. I suggested using Lovable because I felt that, given our timeframe, attempting a more complex solution without coding experience would be unnecessarily risky. I focused instead on what the prototype needed to demonstrate and pushed for the out-of-stock substitution flow once our concept changed. I learned that contributing to an important part does not always mean you have to build it yourself.
Looking back, one of the biggest lessons I learned was to be more willing to question an idea, even after investing time and effort into developing it. At first, discovering that AH already offered part of our proposed solution felt like a setback. But without that discovery, we probably would have continued developing something without properly questioning its value. I also realised that even when the evidence seems to support an idea, it is important to remain critical of what it actually proves. It reminded me again to fall in love with the problem and not the idea.
