No ratings yet.

How I ended up building this

The logistics industry has always been a pretty interesting one to me. It’s among the biggest in the world, as well as one of the most necessary to fulfill our needs, all across Maslow’s hierarchy of them. I have worked closely with a forwarding agency, based in Rotterdam, for a couple of years. Through them, I have come to learn about all the processes, challenges and problems that exist in the current world of logistics. I’ve been attacking the problem of inefficient logistics mechanisms from many angles, driven by my own interest. This course felt like the perfect moment to bring one of these angles “to life”. Naturally, I was happy that my teammates agreed to work on a so-called “empty miles solution”: one that aims to reduce the bizarre statistic of about 21.6% of EU road-freight kilometres being driven “empty”, meaning there’s no cargo on board in the container of a truck, just air. My teammates agreeing to this idea was my first indication that the idea was worth exploring, which got me thinking in ways to solve this massive problem for this massive industry.

From idea to working prototype

Since the idea originated with me, I felt like it was my duty to take most of the initial design and features into my own hands. I’ve built many (business) applications before with Claude Code, so building a prototype didn’t sound like anything new to me. What did surprise me, is the complexity caused by the number of interconnected decisions that overlap and rely on each other.

The basic concept sounds straightforward: take an empty container and use it for another shipment instead of sending it back to a depot. But then you have to consider container compatibility (which carries MANY variables), release times, carrier permissions, depot rules and whether a newly calculated route actually saves companies money in the end. I also came to realise that my domain knowledge alone didn’t bring me to a useful answer to the problem we’d identified. Knowing that empty running is inefficient, and even understanding the cause, is a long way from knowing which empty containers can realistically be reused, who needs to share information, who has permission to approve the move and who actually benefits. Finding nearby containers won’t be the hardest of challenges, but getting this entire system to work for everyone to save a couple of hundred euros per shipment is a massive ladder to climb.

With my dear friend Claude Code by my side, it was not speed that I needed. It was a clear feeling of direction, and a sharp view ahead of what this prototype had to do, and what it had to look like. To do that effectively, I had to make decisions on which features did deserve a spot in our v1, and which didn’t

Doing the math

After having randomly generated mock data to test our reasoning models against (to measure efficiency and accuracy of our solution’s inherent models), a big finding was that this business model can “make or break” depending on container suppliers’ reuse fees. Depending on how high these are in real scenarios, potential savings for forwarders can shrink from a couple of hundred euros to not much more than an average kapsalon nowadays. Some might still find that worth the try, but a company won’t switch up dispatching processes for savings like that.

A nicer surprise, however, was the fact that the model I had configured to extract information from mock data, had a 100% accuracy rate (against a baseline of 28.9% by code-run scripts) on 45 fictional booking emails. An important moment, since I wouldn’t have been proud to demo a prototype that can’t even deliver the result I was excited to pitch about.

Being aware of these challenging factors hanging over our head, it was important to add nuances to our demo. While pitching this as a potential weekly 5-figure saver for the Randstad forwarding area, it was important to note that industry adoption on a large scale is the crucial factor to pull this off, which is exactly the factor you can’t expect to work in your favour all the time in logistics.

Making the demo speak for itself

At first, I had built a very practical prototype that performed all the necessary features, but in a way that wasn’t self-explanatory even to myself. I caught myself staring at my laptop thinking; what on earth am I even looking at? I decided that for a nice-looking prototype, you need the visual appeal to speak even more to your audience than the functionalities of your platform. At the same time, you don’t want a malfunctioning application, so it’s a game of finding the ultimate balance between visual appeal and functionalities to make sure your audience actually gets your solution. A concrete example of how I did this was to use the infamous “less is more” principles, especially when we’re talking about text: no need for 6 bullet points that no one is interested in reading, I’d rather have 1-2 catchy headlines that spark people’s attention, so I can clarify what we mean by that while demonstrating the rest of our prototype.

Working as a team, not just building my part

Even though I was mainly responsible for the build of our prototype, collaborating and brainstorming with my teammates was a crucial part of the process to narrow down on what we exactly wanted to achieve and make happen with this project. It wasn’t too hard for us to find our way through the challenges and questions we faced during this project, but I’m convinced that having 3 other people with semi-different backgrounds to work with on a project is way more than the fourfold of efficiency you can reach in a group. Different insights and perspectives bring ideas, angles and feedback (both positive and negative) to the table that no AI assistant, let alone yourself, can truly offer.

What I’d do differently next time

Although I am very satisfied with the way this project went, there are a couple of things I would’ve done differently. Firstly, I’d say I’d narrow down from the beginning on the exact end goal of a certain prototype. In this case, functionality was definitely a high priority, but in the end, the only interaction people would have with it would be on a demo day. Hence, I could’ve taken into account earlier that it should be more of a “pitchy” demo, rather than a full-on logistics software solution.

Secondly, this project has reminded me of the importance of having feedback from other people, especially those with different perspectives and backgrounds. Your idea and solution might be self-explanatory to yourself (except for those confusing moments I explained above), but it requires a whole different approach to make others understand what you’re trying to achieve.

Empty kilometres are definitely a massive inefficiency that, in some ideal world, could be saved with a clever tool. After working through this project, I still believe that. However, I have become a tad skeptical about the easiness of solving it, for two intertwined reasons: first of all, why has no one else been solving it on such a scale? I believe it has to do with the second reason, which is something I touched upon lightly earlier: industry adoption is not a given in logistics. For hundreds of forwarders to share sensitive information to save money, you better save them quite some. Hence, I am not dropping this project, and will continue to research this (and other) angles to make sure we all cut a bit of CO2-emissions, driver costs and fuel costs in order to keep our overconsumption in the happy place we have it in in these days.

No ratings yet. When our project began I imagined a very different travel platform. I wanted to explore a social space where people, especially solo travelers, could connect while traveling. My idea came from the thought that travel is shaped by the people we meet and not only the places we visit. A platform could help someone find a companion for an activity, for example, exchange advice with another traveler, making you feel less alone in an unfamiliar city.
That idea was supported by my own experience. I have worked in boutique hotels in Amsterdam, where travel often seemed personal and social rather than just transactional. A friend of mine had also considered a similar travel startup idea, which made me curious about whether there was an opportunity to build something around this concept. At that point I expected our project to focus on the social side of a trip.
As our team explored Layla, an AI travel assistant, the direction changed. Layla could already help travelers discover destinations and put together itineraries through conversation. We initially discussed the difficulty of choosing the right option among so many flights, hotels and activities. But the question that stayed on my mind was simpler: once someone has an itinerary, who actually books it?
Your plan can look complete while the traveler still has to check availability, compare prices and terms, book each component, and keep track of confirmations and more. If a flight changes, it may affect your hotel arrival or planned activities. I focused my contribution on explaining this gap between having a plan and having a trip that actually works.
Finding evidence for that problem taught me to be more precise. Expedia Group research showed that travelers viewed an average of 141 travel content pages and spent just over five hours with travel content before booking. Those figures were very similar to my own experience while browsing through Booking.com, Tripadvisor and other sites. Yet, they do not measure the work of making or changing reservations. A more relevant survey found that 54% of travelers were more likely to choose a platform where they could book all trip elements. Respondents also mentioned time savings and easier trip management as reasons to book them together.
Our proposed feature became an agent that could take an approved itinerary, check current options, present prices and terms, make authorized bookings and collect confirmations in one customer journey. If one reservation changed, it would check the effect on the rest. For example, after a later flight arrival, Layla could flag a conflicting activity, propose another option and wait for approval before changing it. Thus, the opportunity was in coordinating connected bookings together, rather than adding another way to chat about travel.
We also had to revise our strategic argument. I initially thought of Layla as an independent platform that could challenge established booking sites through Expedia’s inventory. Expedia’s acquisition of Layla changed that framing. The connection to supply and booking infrastructure became more plausible, but we could no longer describe Layla as an outsider challenging Expedia. Instead, our project explored how Layla could change the booking experience within an established travel company.
The part of the project where I was most involved was creating our Canva prototype. It made me turn a broad idea into screens a traveler could actually follow. I designed a route from Layla’s trip card to the booking decision, including the messages the traveler would see before agreeing with a purchase. Instead of saying that the agent would be “transparent,” I had to decide what information and what amount belonged on the screen and when it should appear. A message about a flight being £100 over budget needed to be visible before approval instead of being buried in a general description of the itinerary, but at the same time could not be too overwhelming for the travel to not demotivate them from the booking.
The prototype used green, yellow and red risk levels. A green booking matched the traveler’s requirements and needed a straightforward review and confirmation. A yellow booking called attention to a specific difference, like a new supplier or a smaller budget overrun. A red booking involved a more serious issue, such as high extra cost or a non-refundable option, and directed the traveler to review alternatives or contact a human travel expert. Each level had a different amount of explanation and review before payment.
Designing those screens revealed a tension I had not expected. Requiring approval for every booking sounds reassuring, but people may stop reading if every screen looks the same. On the other hand, an agent that moves too quickly could leave the traveler feeling that they had agreed to something they did not understand. The risk levels were our attempt to put more attention on decisions with greater consequences. They are prototype choices that would need extensive testing in a big sample instead of just a proof that we have solved approval fatigue.
I also included a confirmation and feedback stage. Once the traveler approved a simulated booking, the prototype showed that it had been confirmed, added to the trip card, and sent by email. The feedback questions asked whether the traveler felt sufficiently informed about anything that differed from their requirements. I wanted the experience to continue past the payment button because, from my hotel experience, trust depends partly on what happens after a reservation is made. People need a clear record and a way to get help if something goes wrong.
Making the prototype in Canva was useful precisely because it had interaction limits. I could demonstrate how the interaction might feel, but the screens did not make real reservations or prove that the agent could manage every supplier’s rules. The prototype helped us test whether the concept was understandable; it did not prove that the full operation would work.
Collaboration helped me move away from my first idea while still utilizing its core concepts. My interest in the social side of travel kept me interested in the human side of the booking experience – a traveler may want efficiency but they also want to feel understood and in control. Questions from teammates pushed us to explain what booking the whole trip really meant and where the traveler would make each decision. I learned that a project often improves when the team is willing to narrow an appealing idea into a problem it can explain and test.
I began with a vision of connecting travelers to one another and ended up designing how a traveler might work with an AI agent. Both ideas are about making travel feel easier but the second made me think much more carefully about business strategy. The opportunity is not only that AI can produce an itinerary quickly, but also about if a company can connect recommendations to reliable action while gaining enough trust for people to let it be in full control.

No ratings yet.

AI is going to revolutionize most everything. AI will give you a much more efficient and reliable workforce. AI will save your time. And overall, AI will allow people to do their jobs better and produce more with less effort. I felt this before we started the project, and I feel it now. The difference the project made for me was to provide clarity around where this is true. It is true if there is a well-defined “job” for the AI, if the AI fits into a viable business model, and if the AI’s performance can be measured relative to current methods. Below is a reflection on the members of the team and the choices we made. Below are the challenges we faced. And finally, below is a discussion about how my views have evolved regarding both AI and strategy.

I was responsible for being the critical voice within the group; keeping track of the narrative throughout the process; questioning the components of the project including the user of the product, the problems we were solving for the users, and whether all aspects of the argument fit together; maintaining consistency in telling the story from problem through economics and evaluation. In addition, I created the dashboard for the prototype which was then presented by me; assisted the team in creating a Canva presentation to support our arguments; developed a name and logo for Slipstream which would represent the product. I utilized an AI Assistant (Claude) to create some of the dashboard elements and assist in developing various logo options. I determined what had to be shown on the dashboard; reviewed and iterated on Claude’s input; ultimately chose which option to pursue.

One of the toughest decisions was how to charge for the product. As a team, we came to an agreement on the pricing model. Our discussion of the pricing model linked the value provided to the customer with the cost to provide that value. Thus, it made the economic feasibility clearer than before. I was impressed at how difficult it is to develop a solution (especially one based on AI) that is both reliable and easy-to-use versus one that simply demonstrates functionality. A tool that provides risk alerts to project managers is of little help if the project manager cannot rely upon the tool’s assessments and ignores them due to poor performance.

While the theoretical aspects discussed in class exceeded my expectations, the create, deliver and capture framework proved very practical. It allowed the team to organize the development of the solution and make it more cohesive and credible. Without it, I believe we would have developed a series of features rather than a complete business model. It provided a common framework for addressing questions related to how value was added; how that value reached customers; and how we intended to profit from the delivery of that value.

The feedback we received was a turning-point. The feedback indicated that while our primary testing effort focused on whether stakeholders would adopt an AI system that automatically read emails, Teams, Slack and other project-related communication; privacy and trust were significant issues but did not demonstrate whether the system was effective at identifying project risks. The feedback further recommended developing a controlled environment using a sample of project-related email communications, meeting minutes and task lists and then compare the output of the AI against the existing project management processes regarding missed commitments identified; false alarms generated; time saved; and usability.

We transitioned from “Will people adopt this?” to “Does it really work compared to what they currently do?” While we continued to address privacy and trust as part of the overall governance consideration for the project, these issues were no longer the sole measures of success. I learned that evidence must evaluate your claims and that a topic can appear important without being the correct issue to measure.

Due to differing schedules, lectures and work competed for everyone’s attention. However, we were able to schedule regular meetings and keep them brief and productive. Each meeting allowed us to discuss what we were working on, why, and how, allowing us to work independently prior to our next scheduled meeting yet maintain an integrated outcome.

This project demonstrated that even though AI technology continues to evolve, ultimately it relies on human judgment and decision-making. For example, in our application, the project manager remains in control, while the AI functions as a supporting agent. With this role, there exists the potential for AI to significantly augment a project manager’s workflow. Specifically, it will save time and resources previously spent performing redundant tasks, enhance visibility into project status and identify potential risks, misunderstandings and missed elements thereby allowing the project manager to focus on key items and deliver higher quality projects.

Additionally, it has influenced my way of thinking about strategic planning. Asking “Can AI perform this function?” is only the first step. Ultimately, the more difficult questions include; Who gets credit for providing value? How does one defend their solution over competitors? What happens when both customers and competitors also have competent AI systems? Creating a worthwhile use of AI requires more than just demonstrating capabilities. It requires a viable business model, empirical evidence and clearly defined roles for humans. When I began the course I thought primarily about what AI could accomplish. I now conclude that I should think more about what makes an AI-based idea worthy of development.

No ratings yet. Throughout the last few years, I have become slowly more health-conscious. I became aware of the importance of having good nutrition, and the many things that it entailed, including the different macronutrients required for staying in good health. As I mostly cooked at home throughout my time in my bachelor’s degree, I simply excluded unhealthy foods from my eating, including limiting the amount of oil I used, as well as cutting back on sugar drastically. However, a part of the student experience was to try out the local restaurants (at least it was for me), and there my diet went. I could’ve just logged what I ate into a calorie tracker app, but in the context of a restaurant, that caused lots of guessing (and second-guessing) and never being sure if I was on the right path to health.
I accepted that as a fact, and lived my life accordingly, and as such I wasn’t able to completely hit my health goals.
As we started the academic year and this assignment was discussed, many ideas were floated around, such as tools to make international compliance on goods easier, but eventually another group member suggested something I had not thought about in a long time: a way to keep track of your macros regardless of who the cook is. With the development of AI, this was a much more attainable goal, and one I was on board with almost immediately, since it resonated with me directly.

As we decided the parts that each member was going to take on, I ended up with governance, failure analysis, and the final recommendations. In the meantime, I gave some assistance on other parts so we could finish the project as a whole before I started on mine, as my part needed a more complete picture of the app to finish. Through this collaboration during development, I saw something interesting happen that I had only ever heard described: scope creep. As we all gave input on how to develop the app, too many features eventually got proposed, and the scope drifted far from our original plan. We eventually decided what stayed and what went. Because all of us were genuinely interested and invested in the project, it became a real joy to iterate on it, and what came out of that process was shaped in interesting ways by the different backgrounds we each brought.
Finally, when it came to my part, it was greatly supported by the hard work and number-crunching done by those working on the parts before mine, which left me to interpret those numbers and build an analysis on top of them. That was easier said than done, since I had to make sure every claim stayed consistent with the final figures, and those figures often changed with the other group members iterating. Fortunately, I was able to work with the team directly on deciding the right numbers, and they readily told me when a figure or an idea changed, which mattered a lot, since the recommendation and the economics shifted alongside those changes. Deciding the failure conditions and risks the app might face also required a high level of understanding of how the app actually worked, step by step, and what could go wrong at each stage, which meant looking closely into the mechanics as well as the relevant laws and concepts attached to it, like data privacy and allergen regulation. I also found it genuinely interesting to work through the conditions the app would face in an agentic future, since it took a lot of second-order thinking to reason through how everything would behave once other players had agents of their own too.

My first real failure in this part was how I approached governance to begin with. I started by giving risks a label, High or Medium, which looked serious and studious but didn’t say who actually fixes and owns each problem, and was quite subjective. I then rebuilt it around five specific failures, each with an owner and a fix.
The future-market part of my slides went through almost as many versions as the risk table, labelling every player a threat or an opportunity before I rewrote it into three plain questions instead, what changes for that player, why it matters, and what we do about it, which was much more explainable and easy to follow.
Evidence forced a change elsewhere too. When I checked the €0.40 per order figure against where it actually came from, it turned out to be mostly payment fees rather than anything to do with running the software, so I split the two apart instead of leaving it as one number.

A surprise that occurred was that I assumed that the AI itself would be the part that caused the most problems. That was not the case, the model only interprets what the diner asks for and talks to them, while the application handles the nutrition maths and builds the order, so lots of the issues are to do with the restaurant, not with the app, such as wrong recipe data, or a kitchen that skips ingredients.
Another surprise was how much of governance had nothing to do with the AI, but more so with the app design. I hadn’t considered calorie floors to matter as much as they did, as the app could be encouraging someone to eat too little by rewarding restriction. I was also surprised in terms of privacy. I knew orders involved personal data in some loose sense, but I hadn’t really registered that a meal choice can reveal a health condition, which puts it under GDPR Article 9 rather than ordinary data. Once that was understood, consent and keeping only what’s needed in terms of data became an important part of the app’s design and was put into the slide.
Working through the agentic future question changed how I think about this product more than anything else in the project. I started by asking what our AI could do, and our assignment pushed towards what stays scarce once AI is enabled in everyone’s lives Reading a menu and estimating macros becomes free for everyone. What stays rare is a contract with a kitchen and a confirmed order, instead of always upgrading new technologies. If I did it again, I would check claims earlier rather than later, which would save a lot more time, and give more time for thinking and developing new ideas

5/5 (1)

My Starting Point

Before beginning my Master’s in Business and Information Management, I studied hospitality management and worked for a year as a Management Trainee at a luxury hotel in Vienna. Developing a strategy for an AI travel agent therefore felt particularly relevant to me. It felt like a meeting point between the world I had come from and the one I am now learning to understand.

In hospitality, I learned to notice the small things that make an experience feel personal. Remembering someone’s name, their favorite drink, or how they like to spend their time can make them feel understood. I initially approached our Layla project with a similar mindset. I thought agentic AI could help solve the headaches people face when planning travel. For example, I personally don’t enjoy following an hour-by-hour itinerary, but I care about choosing hotels and restaurants intentionally. A friend of mine loves having every hour planned. I imagined the opportunity lay in helping every kind of traveler find their own version of a meaningful trip.

As the project unfolded, however, the idea became more complicated. Understanding what someone wants is one thing, but being trusted to act on that understanding is another. Over the course of the project, this difference changed both my team’s strategy and my own expectations of what we were building.

My Contribution

My main responsibilities included bringing together market and financial research to justify our prototype, developing the prototype evaluation and market test, and contributing to our final evaluation and ethical considerations. Although these were separate sections of the deck, working on them rarely felt separate. Each time I tried to strengthen one argument, I returned to a finding we had made elsewhere, and I began to see how closely the different parts of a strategy depend on each other. I also found that consistent dialogue with my lovely teammates was essential to building a cohesive, defensible storyline.

Evaluating Our Proposal

The hardest part of my contribution was evaluating our proposal critically. We could not actually test the prototype because of feasibility constraints, so I had to imagine how it could be tested and what evidence would make the results meaningful. Developing the proposal and prototype had given us something to believe in. Evaluating it meant stepping back and asking where and how that belief might be challenged within the context of a real-world business strategy.

I developed a proposed experiment comparing manual booking with our agentic booking flow, along with KPIs to assess success or failure. I considered booking completion, efficiency, risk classification, and safety separately. This helped me see that success could not be reduced to one encouraging result. We had to consider that an AI agent might complete more bookings while possibly making decisions outside the traveler’s approved conditions. A smoother experience would lose its value if the user had to bear the costs of an unsafe or unapproved decision.

I also had to accept the limits of what I could conclude. Designing a test did not mean we had tested the idea, and finding supporting research did not mean our particular solution would work. Our recommendation therefore had to leave room for uncertainty. This was difficult, but valuable, and I learned that taking a proposal seriously also means defining the conditions under which it should change or stop.

Rethinking Trust

Trust became the most interesting thread running through this process. I brought an understanding of trust from hospitality, but the project made me see it differently. At the hotel, guests often arrived with confidence in the institution we represented. I could then build on that foundation through personal attention and consistent service. With our AI agent, I realized that the foundation itself needed more consideration.

Our market research suggested that feeling understood did not necessarily mean feeling ready to hand over control. As our research and discussions developed, trust became more central to our strategy than preference matching alone. I found this particularly interesting because it challenged the instinct I had brought from hospitality: that better personalization would be the clearest way to create value.

Our Risk-Weighted Approval System helped turn this learning into a design choice. The agent’s freedom to act depended on whether a transaction remained within approved conditions or required further human judgment. I began to see that human involvement could make delegation possible. The key was to give people enough confidence to let the agent take some of the work from their hands.

Learning from My Teammates

My teammates also helped me recognize where my own thinking needed adjustment. One moment that stayed with me was when a teammate questioned my approach to the prototype justification. I had misinterpreted the lecture slides explaining what the section needed to achieve. I was surprised at first, but once they explained their concern, it became an “aha” moment. I appreciated that they noticed something I had missed. That exchange reminded me how easy it is to become absorbed in developing an argument before checking whether it answers the right question. It also showed me the value of letting others see unfinished work, and how my contribution became stronger because someone was willing to question it.

Looking Ahead

By the end of the project, I understood AI strategy as something more interconnected than I had initially imagined. Personalization depends on understanding the customer, adoption depends on confidence, and automation depends on reliable execution. Each promise brings another responsibility, further showing the importance of trust in this delicate system. In the future, I look forward to deepening this understanding and potentially contributing to AI strategies that are rooted in a user’s best interest and trust.

5/5 (2)

Intro

I entered the AI strategy lab with a very technological lens. I believed that in digital markets, the most sophisticated algorithm would win. Strategy was just a matter of plugging a Large Language Model into a workflow and watching it do magic. However, the past eight weeks completely dismantled my assumptions. It replaced it with a nuanced understanding of how digital technologies reshape entire industry structures, economics and most importantly: what a sustainable advantage means in this era.

I want to define our project with an analogy that I am calling the “Gold Rush”. During the 19th-century gold rush, conventional wisdom dictated that those selling the pickaxes made the real money. Today, foundational AI models are the pickaxes. My greatest realization in this course was that when pickaxes become cheap, commoditized, and universal, the only defensible strategy is owning the gold mine itself.

The great catastrophe and Pivot

That realization was born out of a catastrophe near the end of our project. We originally set out on Track B to build a third-party startup that would scrape Reddit data, process it with an LLM, and sell consumer insights to brands. We thought our “smart” AI application was our moat. Then, we made a devastating discovery: Reddit was already developing “Reddit Community Intelligence.” The whole team somehow missed this and basically we were creating something that already existed. Our entire business model was redundant after 90% of the work was finished.

This felt like a project-ending disaster. In reality, this has become the cause for our deepest learning moment. We realized that as a third-party wrapper, we were entirely at Reddit’s mercy. There was no defensibility at all. This basically became the starting point of our pivot to Track A. Instead of imitating Reddit’s Community Intelligence, we reimagined ourselves to be Reddit’s internal innovation team. We were tasked with transforming the company’s enterprise data offering from reactive, raw data access into proactive, semantic early-signal intelligence. So in only one day, Reddit transformed from our greatest platform threat into our biggest ally. We stopped trying to build the pickaxe and realized we already owned the mine.

Designing of the Ecosystem and the Future-Market Test

Following the pivot, I took ownership of our Competitive and Ecosystem Analysis, as well as the Future-Market Test. My objective was to evaluate how AI alters platform power and ecosystem dependencies.

Super straightforward to start with, but I immediately realized that our suppliers (frontier LLM and cloud providers) offered not a little bit of competitive advantage. They are literally available to everyone for free. To build a defensible ecosystem, I applied the concept of multi-sided platform pricing. Following core course concepts, I designed a dual-subsidy model: we heavily subsidize the everyday Reddit users to generate the vital data (the foundational subsidy), and we offer a constrained “Free” tier to enterprise analysts to break the adoption barrier (the targeted subsidy).

What did challenge me the most intellectually was my contribution to the future-market test. Evaluating our strategy against a scenario where enterprise clients have their own autonomous AI agents really humbled my confidence in our work. If an enterprise agent can summarize Reddit on its own, why pay us? So once again, by applying the course frameworks, I argued that digital markets do not become frictionless. The friction shifts from finding information to actually verifying it which is something only we can do. Following that, I pivoted our long-term strategy from a visual dashboard to an infrastructure API that external agents are forced to use if they want reliable information. Our moat became the historical baseline and first-party access to Reddit’s longitudinal data, which is not imitable by any other client.

Evidence, Iteration, and Feedback

Our project’s foundation was built on continuous experimentation and feedback. Early in our prototype development, we made a mistake. We assumed the LLM would naturally connect the dots between scattered Reddit posts and automatically generate clear, strategic value. However, when we reviewed our first iteration, the data dashboard actually did not show us much useful information. The raw outputs were messy and lacked actionable insights. 

This failure gave me a core lesson: powerful technology cannot rescue a weak problem definition or poor implementation context. Having an advanced LLM was nowhere near enough.  We had to actively design the information environment. We need to ask ourselves how a manager could improve which type of decision-making through which mechanism.

While I was not actively hard coding the prototype, I discovered that being able to critically evaluate the output and give strategic feedback was just as valuable as building the dashboard itself. What matters is whether the prototype meaningfully tests the solution and key assumptions. I was able to act as a critical “user” during the test. This collaborative form perfectly balanced technical execution with strategic feedback. That is what enabled us to make the dashboard function exactly the way we intended.

Learning from Collaboration

Collaborating through a high-stakes pivot fundamentally changed how I view teamwork. When we discovered our initial idea was unoriginal, there was a moment of intense frustration. The friction within the team was noticeable. Literally: “Guys are we this stupid?” However, we learned to separate our egos from our ideas. We used the course’s experimentation mindset not just for the prototype, but for our team decisions. We looked at the evidence, agreed our current path was a failure, and collectively committed to the Track A pivot. It sounds so straightforward, but having done most of your work and suddenly having to rewrite everything because we were all too “stupid” to see that Reddit already had our idea, is very humbling. However, dividing the workload strategically allowed us to rebuild our business model, governance framework, and ecosystem map in time. Collaboration in a team is not about avoiding failure, but how fast you can adapt and pivot when things go wrong. Something I had never experienced before in a school project. The stakes felt a lot higher during the AI strategy lab.

A New Strategic Paradigm 

The AI Strategy Lab has irrevocably changed my understanding of future business strategy. I came into this course believing that technological superiority was the ultimate goal. I am leaving with the conviction that strategy means to design a market, not merely participating in it.

As GenAI and Agentic AI accelerate transformation of modern business, the underlying principles of economic goods do not disappear, they are just rapidly redefined. Technology is highly replicable, but what cannot be easily replicated is a well-designed market mechanism. Our technology is not the most sophisticated, but by deeply integrating it into enterprise workflows, we amplify the one scarce complementary asset that no algorithm can fake. Reddit’s longitudinal data is transformed into an indispensable truth layer that future autonomous agents will be forced to rely on.  Moving forward in my career, I will no longer look at new technologies and just ask, “What can this tool do?” Instead, I will ask, “What unique advantage does this tool make stronger, and how does it make our customers’ lives easier?” True lasting success comes from owning the gold mine, not just selling the pickaxes used to dig 

5/5 (1)

My role and contribution

Over the last few weeks, my team and I had been developing an AI-based prototype for online returns inspection. The goal of our model was to partially automate the returns process for Inditex. In order to select a project idea, each member brainstormed a few concepts of their own and picked one that seemed most promising. My idea made the cut since the prototype seemed the most feasible. The problem scope was well-defined and supported by the professor. My main part in this project consisted of drafting the “Problem”, “Opportunity”, and “Business model” components, and then turning them into slides. This required extensive research on the current scale and costs of online returns, benefits of AI automation, and value potential for Inditex’s main stakeholders. My other roles also included supporting others’ research by suggesting potential sources and datasets, helping design the automated inspection process, and exploring solutions to online returns fraud.

Important decisions and iterations

A big decision for me, regarded representing the scale and uncaptured value of the online returns issue. I wanted to show the reader how many online-bought items end up being returned and how much those returns cost Inditex (something the brand does not officially disclose). It was a challenge to find adequate research regarding fashion retail. Therefore, I used statistics from an industry benchmarking article to come up with a proxy, since I wanted to give a concrete number. I came to the conclusion, that my final estimation was too uncertain, as the observable data ranged significantly (e.g. processing a returned apparel item indicated to cost 20%-65% of item value). My decision and subsequent solution was to let go of calculating a proxy. Instead I used different pieces of data, that when interpreted together signalled the scale of the online returns problem. At first, I wanted to calculate a grounded number to make the problem sound convincing. Then, I realized too many assumptions needed to hold to justify such number and had to abandon my initial idea. This taught me to approach my reasoning with honest scepticism and make use of available resources. Another pivotal decision was to narrow down the scope of economic calculations. My team determined that Inditex’s operational capacity is far too broad and therefore financial feasibility estimates of our project would bring ambiguous results. Therefore, we decided to focus on Inditex’s largest brand – Zara instead. The learning outcome of this roadblock was how important it is to define a manageable scope. A well-defined scope facilitates choosing relevant criteria that affect it.

What surprised or failed

What I think surprised me the most throughout the conception of the project was how impressive the prototype turned out to be. I was very happy to see our idea come to life and I think my teammate did an incredible job coding the model. I have programmed a machine learning model once before, and seeing the working prototype in action gave me a similar feeling of excitement to when I first deployed my own model. One limitation which kind of let me down was that our model moved 12 out of 24 cases for human inspection. This means an escalation rate of 50%, which significantly surpassed my team’s optimistic target of under 30%. This observation was detrimental for our project, since a large part of Inditex returns would still have to be manually checked under this prototype. This in turn would substantially reduce the labour savings proposed by automation. However, I also should acknowledge that the evaluated sample was relatively small (24 cases), and some cases were difficult on purpose. In retrospect, I feel like the results could have been more representative with a more realistic sample, for example a larger, randomly sampled number of cases. All in all, I was pleasantly surprised with the prototype my teammate built, but it should be tested further. I also think that having more accurate results would allow for better estimation of the value created and captured by this change of workflow.

How feedback and evidence changed the workflow

My teammates’ feedback changed my understanding of the online returns automation design. What I had in mind while coming up with the proposed idea was that the inspections would take place within Inditex’s facilities. To prevent return fraud, I visualized a process, where the returns move on a conveyor belt, with a camera taking pictures of each clothing item, and a mechanical arm rotates the clothes for better visibility. My perspective quickly shifted when two of my teammates pointed out that such physical requirements would imply very high operational and fixed costs. They made me realize, that continuing with my suggested process framework would make economic feasibility estimates much more uncertain, and the overall project financially inefficient. This piece of feedback made my team consider a completely different perspective and come up with an idea that the customer takes and uploads the picture of the returning article. Accounting for potential return fraud attempts, my teammate recommended introducing a direct capture feature to the prototype. This would require the user to submit the clothing photos at the same time of them being taken to prevent AI-enhanced or generated uploads. My teammates’ feedback helped me realize logic gaps within my thinking that I previously overlooked. I also understood that solving one problem (reliance on physical assets) could result in others (potential returns fraud).

What I learned from collaboration

My team’s collaboration consisted of weekly online meetings, where we would assign responsibilities and share our ideas, struggles, and solutions. Something that worked very well for us was clear task division. Since everyone had a good understanding of what their role is, all jobs were completed on time. Clear communication and feedback between the teammates helped us quickly discover problems and find reliable solutions together. What unfortunately did not work, was that every team member had multiple other assignments and exams to finish during that period. Because of that, it may seem that certain elements of the slide deck still require more polishing. Looking back, I also wish we reviewed each other’s parts more frequently and with better care. In retrospect, if I had another chance at the project, I would put more emphasis on good coordination. I would try to schedule earlier, more regular deadlines to make sure the team stays on track. I would also encourage my group to be more sceptical on their project reviews.

How the project changed my understanding of AI

I remember, I had one major doubt while undertaking this project. Creating business value with AI can oftentimes surface various ethical questions. I feel like many people nowadays feel threatened and vulnerable about AI taking over their jobs. Unfortunately, the returns automation idea would not reassure this insecurity. To create value for Inditex, this concept would have to involve certain layoffs. If this project were to succeed, I think a very small circle of people would highly benefit, while a much greater group would suffer. Here, I am referring to Inditex’s shareholders as the main beneficiary, and the warehouse inspection staff as the main victim. So, the ethical question I would like to give is whether the overall value for this small group (which I could argue may be already very wealthy) is higher than the existing value for the more vulnerable group touched by this optimizing endeavour.

No ratings yet.

First Chapter
When I first started BIM and especially this AI Strategy Lab Project, I thought about very huge, superb and complex systems; for example, a rocket, robots people use for space exploration, or AI that performs surgeries on human. I did not have many expectations about an information strategy course. I wouldn’t like it that much, though – that was my first thought. As a business student from RSM and a not very technical person, I have just a few experiences with using AI, mostly in support of assignments and exam prep. Systems and AI seemed boring to me, coding was threatening to my life, and ChatGPT, Perplexity, and Copilot were no more than helping me pass exams.

Second Chapter
It was hard in the beginning to choose a problem. We went with the basics, from one of my teammates’ experiences with flight delays. My teammate encountered a long delay on her flight to the US, which caused a lot of frustration for passengers. I also shared a similar experience as a frequent air passenger – an international student from Vietnam. On my flight to AMS this summer right before the Master, my plane took off late, causing it to land later in Dubai – which made the transit for the people who would fly to AMS tight, and the airline experienced some disruptions in handling passengers as well. I found it great that we had a problem that sat near our heart and soul.

Working on AI
We found a pain point in the airline’s existing system: the processes are delivered mostly manually and inefficiently. When many passengers require assistance simultaneously, employees must gather information, search alternatives and coordinate hotel, compensation services person by person. We found that Agentic AI can greatly help automate these tasks. With great help from the technical teammates, we successfully made the prototype, with dashboard for airline staff and app for passengers. Despite having an innovative solution, the challenges were also phenomenal. Our system does not have network effects, as it is not a platform with multiple users, but an AI system for one organization – the airline. I personally enjoy session 5: Digital Platforms the most. To me, platform effects and optimizing this to make profit for a company, or bring good to people, is a promising idea that interests me a lot. Hence, I thought it would be nice if our solution had network effects. Perhaps, like a learning platform for students or an online trading platform for clothes or music. I had this interest way before starting the project, even from my bachelor’s. But the idea about Agentic AI to solve flight disruptions was pitched during the development of AI Strategy Lab, and somehow it came to us as it was. I also have a deep connection with the idea as a frequent air traveler. So the learning experience was very fun as well. I can imagine one day this product is present at airports, on a flight to Vietnam – if ever a delay happens, my alternative flight is already displayed in the app on my phone within minutes, with coupons for food and hotels, 50% off on my next booking as a recovery gift, and 100% refund of the delayed flight…all powered by AI.

Collaboration and Demo Day
I worked on the Economics of AI and recommendations for future scaling. While working together, we all had different perspectives on how to write these parts, how to design this solution, etc., as our backgrounds and studies were different, and each of us had unique way to approach problems. Pricing the AI, and reasoning the costs was the hardest part for me. I myself found it hard to convince my team that: It was not viable to find a source or academic article to reason exactly the initial development cost of 700k EUR, as this is a new AI that will be launched, not one that sustains in an existing system. From a business perspective, we should be as open and creative as academically critical. I think having solid accredited article to back up each argument is not relevant for a part like cost of AI – where we are the entrepreneurs/ creators who price our product to test and scale. I would base it on business knowledge. So in the end, I reasoned it in my own words with a small source: based on enterprise AI implementation benchmarks ranging from $600k to $1M for large integrated AI systems, we estimate an initial development investment of €700,000. A €700k development cost for an agentic AI system sits near the lower-middle range of enterprise AI costs and is realistic for a first deployment within a medium sized airline.

Given the fact that this is an AI information strategy course and the project is experimental AI Strategy Lab, I would recommend viewing the learning opportunity as trial and error. No one can give exact answers to every problem. As entrepreneurs, we should not be afraid to make wrong estimates and assumptions. Over the course, my team tended to agree with each other’s ideas, so sometimes, we neglected reflecting on our own points. I would expect my team to be more courageous in challenging each other’s viewpoints and to give compliments as well as difficult feedback more. Overall, we all worked hard on the deck – I had fun working with my team on our solution, and it was a great chance to learn about each other. I honestly feel that through this project, AI brings us humans closer to each other rather than separating us (as said by many). I had never talked this much with this many people one year back in my gap year…

Last but not least, my understanding of AI and business strategy has shifted tremendously. You don’t even need to love AI or technology. Maybe you hate it, as I do. But if you have a problem, you are able to develop a product.
I could verify the above on the Demo day.
It was a wonderful day to learn from each other. Other teams gave us feedback on how we could scale the product effectively and justify the costs. No one cared which websites I took the number from, but they were more curious about what we would do in scenarios A or B… So might as well just say the number is from my brain, and how about you get a cool suggestion from other people the next day. When listening to other groups, I noticed they also made a lot of assumptions rather than relying on a fixed piece of information.
Apart from my group, I love the learning platform for students and teachers to study Physics and Biology – I forgot the group number, but bravo, their prototype made with Loveable was so cool. The logistics platform to predict stock demands for fashion brands is fire, but I also forgot their group number…

No ratings yet.

My role
HomeMatch AI is a seeker-paid AI agent that ranks Dutch home listings on a seeker’s hard and soft wishes and explains each recommendation. My part was the business model, pricing, economics and alternatives considered. That meant answering the question the team could postpone: even if the agent works, who pays for it, how much, and what is left after costs? I started with a business view of the idea and expected the technology to be the hard part. The harder part turned out to be capturing the value.

Deciding who pays
We had three options: a seeker subscription, a success fee or agencies paying for better-matched applicants. I chose a seeker-paid subscription of €24.99 for 30 days, and this was my own decision. Home search is intensive but temporary, so an annual plan did not fit the customer journey. A 30-day pass also lets people search heavily without paying per query.
Before this project I saw pricing as deciding how much customers will pay. Rejecting the alternatives taught me that the payer also shapes the product. If agencies paid, a recommendation could favour the paying agency over the seeker. That would undermine our claim that HomeMatch works for the seeker, which is the trust problem from Session 7. A success fee aligned incentives better, but the lease happens outside HomeMatch, so we could neither observe or attribute it (Session 4). Pricing, I learned, decides whose interests the product serves.

Where my first estimate went wrong
My economics slide began with a cheap-model assumption. I put the AI cost at about €0.50 per user per month, so contribution was roughly €15.70 per user after VAT and other costs. My headline said the LLM was cheap to scale.
Then I checked which model our prototype actually runs on: Claude Opus 5.5, a top-tier model with far higher token prices. I recalculated with its published prices and my own usage assumptions of 25 listings screened per day, including thinking tokens. The AI cost rose to about €14 per user, roughly thirty times my first number, and contribution fell to €1.84 before listing-access costs. I rewrote the slide. The new headline says the LLM can erase the margin, and cost controls make the model viable.
What surprised me was that I had treated model choice like a performance question. It is also a cost-structure decision and it changed my section more than any strategic argument did. Session 4 says AI adds variable inference costs to the classic information-goods logic, but I only took that seriously once I saw it in my own numbers.

I then modelled three levers: filtering listings before the model sees them, using a cheaper model for a first pass, and batching non-urgent screening. Together they lift contribution to about €14, a 70% margin. These are assumptions we have not tested, and I have not checked whether a cheaper model ranks soft wishes well enough. The other cost lines (hosting, maps, payments, support) are also illustrative.

Pricing: what my evidence did not prove
For the price, I used existing alert services as a benchmark. Customers already pay around €29.95 per month for these services, so I saw this as evidence that people are willing to pay for help with housing search. Because I believed HomeMatch offered additional value through ranking and soft preferences, €24.99 seemed like a reasonable starting price. However, I later realised that this only provided a market benchmark. It did not prove that customers valued HomeMatch itself at €24.99. Looking back, this was one of the main weaknesses in my analysis. If I could do the project again, I would test willingness to pay directly instead of only using market benchmarks.

The evaluation results sharpened this, even though I was not the person who carried out the testing. Our main assumption was that HomeMatch would find more relevant homes and do so faster than manual search. The results showed that HomeMatch was much faster for renters, but the average relevance score was exactly the same as manual search (both 4.36). For buyers, HomeMatch was even slower in the test. This mattered for my business-model section because the case for paying €24.99 becomes weaker if the product does not yet produce better matches. It made me realise that the business model depends directly on the evidence behind the value proposition. We therefore became more careful in the final recommendation and stopped claiming that HomeMatch already produces better matches. Before charging a premium based on better fit, we would first need evidence that the improved version actually produces better matches.

I also underestimated customer acquisition. A successful user finds a home and stops paying, so success creates churn. About two paid months give roughly €25 of contribution, which caps what we can spend to win a user. Access to listings is another dependency, because platforms and agencies control the supply.

What I learned from collaboration
We divided the project into different parts, but the sections were more connected than I expected. My pricing depended on the target group. My economics depended on technical choices made in the prototype. The choice of who should pay depended on the trust argument from the ecosystem analysis. The evaluation then affected whether the value proposition behind my business model was strong enough. We also had no major external feedback on the proposal, so we had to challenge many assumptions ourselves. Internal deadlines helped, but fitting everything into 15 slides forced us to decide together what was really important. I learned that dividing tasks is useful, but everyone still needs to understand how the different parts connect.

How my view of AI and strategy changed
The project changed how I think about AI and business strategy, I initially thought the AI functionality itself would be the main source of differentiation. By the end, I understood that the technology itself is only one part of the strategy. The future-market analysis made me realise that competitors can gain similar AI capabilities, so a lasting advantage has to come from what surrounds the technology like access to listings, relationships, outcome data and trust.

My main learning point from the project is therefore that AI strategy is not mainly about finding more things for AI to do. It is also about deciding where AI creates real value, whether that value can be proven, who should pay for it and whether the business can keep enough of that value over time. If I did the project again, I would measure real token usage from the prototype from the start. I would also test willingness to pay and acquisition cost earlier and check my cost assumptions against the actual system. That would have made the strategy less dependent on what we think users value and more dependent on what the evidence actually shows.

No ratings yet.

How it started

In the beginning of the project, when we were brainstorming about the domain, one teammate who works in healthcare pointed out the problems with administrative workflow in the industry, which later became the field we landed on. However, identifying and specifying the problem was not easy, as the healthcare industry is broad with multiple complex workflows in each submarket. Due to my little personal knowledge in the healthcare industry in the Netherlands specifically, it was difficult and even a bit confusing what to tackle in the beginning. Yet luckily, one teammate who has technical background and domain knowledge of the industry, guided the rest of us through the process and came up with the solution in a collective effort. Considering that it is not feasible to create a whole paradigm shift, we decided to narrow it down to the ‘DBC optimization’ process within the medical rehabilitation market.

CareFlow

Careflow is an AI agent that analyses Diagnose Behandel Combinatie products (DBCs) for medical professionals in rehabilitation centers. It automates the time-consuming manual check of patient treatment hours against revenue and thus enables the workforce to have more time on higher-value and patient-related tasks. By increasing accuracy and efficiency, the value was created.

My role and contribution

We divided the tasks according to our individual strengths, and I took responsibility for the economics, pricing model, and the value part of the business model. I approached the analysis with the following questions: what value do we create and where to capture value from? What is the cost structure and which pricing model can we adopt?

I started with confidence based on the nature of information goods, where the initial development costs are significantly high and the recurring marginal costs later are close to zero. This has shown to be not completely correct in the model. In the system, the marginal cost per DBC analyzed is near zero, but the recurring human costs on acquiring a new rehab center/department remain substantial until onboarding is standardized. This limits the following scalability too. Regarding the pricing model, we started from charging a usage fee, after each DBC case is analyzed. However, the more I reflected on the structure the more doubts I had in mind. The main concern was the potential discouraged usage especially from small and more cost conscious organizations, which put them in a cost versus process improvement dilemma. Thus, later on, I came up with a three-tier versioning model, where the annual subscription fee is charged and plans differ mainly in DBC allowance credits. This encourages usage as organizations self-select the plans and the fixed annual fee is also easier billed. 

The results

The results surprised me positively: the AI Agent is able to reduce the time spent by more than 80%. This gives us a strong foundation to build on. The positive response from the medical professional with excitement about the official launching of the system, also shows qualitative evidence to validate initial demand. However, due to time and knowledge constraints, we were not able to test the accuracy target of the system. Considering the complexity nature of medical measurement, which requires closer look into a patient’s treatment plan and schedule to assess, we are only able to track the schedule for assessment. This leads to the prediction uncertainty, which should be tested further with medical professionals.

Collaboration

Collaborating with the team taught me how valuable the diversity within a team is. We came up with ideas from different perspectives, requiring us to constantly align our outputs but at the same time allowing us to approach the problem differently. The exchange of ideas broadened my understanding of the project domain and . The diversity in experience also built a foundation to help out each other, especially the technical expertise from one teammate. Learning from each other’s strength not only facilitates collaboration but also amplifies the effectiveness and efficiency of solutions.

Take away

Before this project, I viewed AI simply as a tool that assisted me in learning and answering my daily questions. I also underestimated the possibility of how much value an AI can create by saving time, increasing the efficiency and task accuracy. The project not only broadened my knowledge in Agentic AI but also more importantly, how we can utilize the agent to solve the relevant problems. I also learned how AI can optimize workflow to reduce human burden. I also found out that it should be used as a tool to ease more time for humans, rather than simply a replacement. This resonates with the importance of keeping the human in the loop to reinforce the guardrail. 

Seeing and learning about the projects of other groups broadened my perspectives on problem identification. I realized that finding a problem to solve does not have to be too complicated or tackling a large-scale issue straightaway. Conversely, it could be found everywhere, even just something small that emerges from our daily errands. With the critical lens developed through the project, I will approach future projects by looking closely at daily challenges, reaching out to actual customers to fully test and validate the use, ensuring that they address the real needs and thus offer opportunities for meaningful improvement.