Can you share an example of a failed prototype that ultimately led to a better solution? What specific insight from the failure proved most valuable?

As the founder and CEO of IntelliSession, an AI-powered therapy note-taking tool, one of our first prototypes was a browser extension that failed because we misunderstood our users' workflow. The extension was designed to help therapists integrate IntelliSession into their other software tools, and we assumed they'd use it before each session to prepare. In reality, most therapists delay administrative work until the end of the day, so our extension simply wasn't part of their natural routine. After piloting the feature and seeing usage drop, we interviewed our beta users and uncovered this false assumption. In the next iteration, we redesigned the extension to let them capture information quickly and defer admin tasks for hours, or even days. That version proved far more successful. The biggest lesson we learned was simple but powerful: never build around how you think users behave. Always consult your users first to learn how they actually behave, and build around that.

Back in 2006, I started to build a touch screen device for merchants so that they could process payments on a touch screen. I sourced all the components from China. I created the prototype for around $2000 a piece, we could not sell at that price point, so we had to scrap the project. In 2007, when iPhones were launched, that gave a booster to my dreams. iPhones and iPads had everything I needed in my device, including internet and it was only costing $600. In fact most of the customers already had bought the iPhones so all I had to do is build the software for iPhone devices. I got that software built and sold it to merchants. I ended up building better POS for customers. Never loose the hope.

We built a laminated glass unit that showed strength early on. However, it failed during a controlled wind load test by cracking along the bottom edge at 130 mph rather than our target speed of 150 mph. What was most interesting about this failure was its cause. When we subjected the unit to slight floor vibrations, the stress moved up through the frame creating a very thin crack that expanded under the applied pressure. This event significantly impacted how we approached applying tension to the frame. We transitioned from using a uniform clamp with an 8-point load distribution system to a staggered pressure layout with a 12 point load distribution system. The second design successfully passed the wind load test at a speed of 165 mph. It became evident to us at that time, even small movements in structure can reveal weaknesses long before the storm hits.

I built a fast-loading reader for Publuu that prefetched everything ahead of time. Smooth page flips, that was my goal. Ufortunately, it backfired - people on slow connections got stuck waiting because the prefetch queue ate all their bandwidth. That failure forced me to rethink it. I switched to a small predictive model that watches how fast someone scrolls and where they're looking. Assets only load when their behavior actually suggests they need them. I had to realize and accept how wrong my assumptions actually were. That I built what made sense only in theory and not how real users behaved. Now I treat every prototype like a test that shows me where I'm wrong. That's the whole point.

We prototyped a heavy, multi-layer metal ornament that looked great, but bent envelopes and cost way too much to mail to clients. What we learned is that so many of our corporate clients send ornaments to their clients and staff. We redesigned an ultra-thin photo-etched stainless steel with cutouts, and the weight/thickness spec was added to the product page, that version became a top seller. An expensive lesson, but sometimes that is part of the process.

One of the most substantial failures I had was an early prototype we created that was really trying to automate too much too quickly. The intention was good, but the execution was poor: we built a system that assumed users wanted completely hands-off automation, when the users in fact needed visibility into the process, control of what it was doing, and therefore the ability to explain and to make decisions. The prototype "worked" in the sense that it was technically functional, but the users just did not trust it - and that was the failure. What shifted everything for me was the realization that trust is not something you build in later, but it has to be baked into your design from the upfront. That unusable protoype made us rethink what the interaction model was going to be altogether. Instead of a replacement it went to an augmentation, reasoning, ability to override, and users involved in the flow. And that shift resulted in a far better product. The users trusted the product more than the previous, and it not only performed exponentially better than the previous model, it had also been constructed in a way that was in line with how people actually wanted to work. I learned a great deal from this failure including that I needed to validate earlier, especially around user expectations one of the things I learned, and secondly, to elevate trust from a feature to an actual requirement. In hindsight, the bad version of the prototype was one of the most pivotal experiences across all the things I developed.

I've always considered product failures to be infrequently the result of wasted effort. I see them more as calibration instruments... admittedly a brutally effective set of calibration instruments if you know what to measure. Consider the Apple Newton. In 1993, Apple released a device marketed as a digital assistant. It featured handwriting recognition and an initial price point of $700. It failed, mostly because the technology wasn't sufficiently refined to be useful without users having to get accustomed to it. But it was the kindling that eventually became the iPhone. The value in the Newton wasn't the device, but the realization that users wanted a portable computer, just not one that they needed a learning curve to access. The Newton failure forced Apple to question assumptions and provided a level of clarity that was able to drive future success. Simplify the solution, rather than solve for complexity, and the market would come. Failure can sometimes divorce the ego from the solution process. It can show where you've been building for engineers and not for end-users. I tend to believe that's the graveyard of most good ideas, by overengineering the solution. The Newton failed, but it provided Apple with a road map. Make it simple, make it portable, make it something users don't need a user guide for.

We once tried and tested an AI-driven threat scoring tool. It generated overwhelming results, as it flagged too many false positives. Although, the prototype seem promising, it did not work for us. We understood that context is more important over volume. We developed a version that prioritized actionable threats (adjusting the scoring logic and incorporating richer OSINT data).

I've worked in the climate tech industry my whole career, leading global investment portfolios and challenging industrial R&D teams to deliver on the tough nuts to crack, particularly when early stage prototypes fall short of expectations. The key thing about prototypes is that they fail. A lot. What you do with that failure... now that's where the success comes in. Sometimes it's when you fail that you get it right. I'll be honest, I always took a bit of an interest in the Dyson vacuum story. James Dyson famously worked through over 5,000 prototypes to develop a working model. That's around 14 per week over 7 years, for those keeping score at home. No hyperbole here, because the moment of insight that drove it forward was actually brilliantly simple: it wasn't airflow that was the issue, but rather particle separation. And he had to think like a cyclone to truly solve it. Crazy how long it can take to find out what doesn't belong in your design. The second he stopped attempting to optimise the clogging elements and simply eliminated them from the equation, it stopped being about refinement and started becoming about disruption. The point I'm trying to make is that when a prototype fails, it doesn't always mean that the wrong solution was tried. More often than not, it means the wrong question was asked. For Dyson, it meant trying to optimise a filtration system that was destined to clog, when the right solution lay in eliminating the system. That is it, when a prototype fails, that is when you go back and really examine the assumptions embedded into the design. The most powerful data point may be the one you thought was irrelevant to the problem set from the start.

We created a fantastic prototype based on client specs, a prototype that really looked the part. With gleaming pride, we watched the users. Nothing but crickets. It turned out our optimistic assumptions about how users would actually engage with the product were completely wrong. We had to start from scratch and construct lots of minimal concepts, built around a single behavioral layer. The biggest lesson from this was the realisation that a prototype should be an experiment built to disprove our best assumptions. The moment we started doing that our costs dropped, our iteration and experimental velocity increased, and we ended up solving real-world problems with the product (rather than hypothesized ones). The moral of the story is to fail quickly, learn precisely, and build around the single 'wow' the prototype reveals.

I still vividly recall the time at my workplace when we created an incredibly realistic telehealth portal prototype with a beautiful user interface and fluid animations. After testing, users found the scheduling process very confusing and ignored the visual refinements. What they wanted was clarity and speed. Thus, the prototype failure was a harsh lesson for me; I had invested too much in high fidelity and had become emotionally attached to it. I then switched to low-fidelity sketch prototypes with defined testing objectives, focusing on validating a single assumption at a time. This was a significant shift, as it fast-tracked iteration, enabled me to eliminate false ideas without bias, and, in the end, created a more straightforward scheduling interface that reduced task time by 40% and increased successful bookings by 25%.

Here at Legacy Online School, the first "live plus self-paced" module was a significant engagement booster in our opinion. It seemed to be a very good idea: clean interface, micro lessons, community chat. But after a few months, logging in wasn't helping the students at all. The failure forced us to face an uncomfortable truth: we had designed for students, but not with them. So we decided to stop the development, and we invited 50 students to take part in a co-design session. We wanted to know when they actually study, what was stealing their attention, and what making learning feel natural for them. Their suggestions made a great impact on everything. They were asking for shorter bursts, study partners, and flexible live check-ins which they could join whenever it felt appropriate. That failed prototype gave us our biggest insight: design is only validated in reality, not in planning rooms. It inspired the Flow Learning model that centers on 10 minute sessions, peer momentum, and differentiated supports in live check-ins. Engagement and retention improved right away, but more importantly, learning started to feel joyful again. I often say afailed prototype is not a failure, it is a guidepost. At Legacy, we forward with listening, adapting, and building with our students—not for our students.

We created a complete online quote comparison system which simply failed on our target customers. The principle appeared to be brilliant in the paper: upload your current policy, have side-by-side comparisons across carriers instantly in 90 seconds. Months of development, in-house testing, and confidence made us launch it. Nobody used it. It happens that individuals making purchases in the area of health insurance do not desire to be mechanized as long as they become genuinely confused or terrified to make the wrong choice. The clients would jump lines entirely by our fancy tool and make calls directly, yet using the platform would have taken shorter time. That stung, honestly. It all broke through when a follow-up call to a potential client who did not complete the online process took place. She explained to me that she did not require another calculator. I require someone who could give me the details of why this plan is more expensive by 200 dollars and why it could be saving me thousands in case of something happening. The very conversation made a difference. We polished the standalone tool and remodeled our complete intake process of clients. Today we refer to technology to obtain a pre-liminary information, but any quote has a planned consultation. There is no haste in making decisions. Our close rate increased to 23 to 68 percent in six months since we have indeed learned that insurance buying is not transactional, but emotive. Human connection is supported by the best technology; it does not take its place.

An unsuccessful prototype that continues to affect me in my current role was a first attempt at automation in a complicated workflow with one over-generalized AI model. It seemed simple on paper, but the system kept producing contradictory results because it was trying to do too many things at once as a model populated with too many edge cases. The big breakthrough was when we abandoned the "one-model-does-everything" plan and broke the workflow into small, specialized components. The insight was that it was not a weak algorithm that was causing the failures, it was unclear boundaries. When we established the components with clear purpose, accuracy and reliability shot up immediately. This type of case has also solidified a lesson I've seen again and again: you don't solve complexity with more power, but with a cleaner structure.

I once introduced a pre-made plant bundle to my customers, thinking it would make shopping easier for novice gardeners. The bundle was a bust and customers told me they wanted more flexibility when choosing plants, rather than a pre-selected set. I was initially defensive but I asked for more feedback. The feedback was, that while the bundle was convenient for the customer, the personalized experience of selecting each plant was more important to them. That failure led me to offer curated bundles where customers could select plants based on criteria such as color, bloom time, or pollinator friendliness. The backend work was more complex, but the bundles sold better and customers were happier. The lesson was to prototype small and listen to feedback even when the idea seems intuitively helpful but customers want something different.

Our initial soak room testing involved placing real beer into the tubs, although we used only small quantities. The concept seemed appealing at first, but it proved extremely difficult to manage. The strong aroma made cleaning much more challenging, and one guest even asked if he was supposed to drink the bath water. This experience revealed that guests wanted the benefits and ambiance of a beer spa without actually bathing in beer. We ended up replacing the beer with large herbal barley-hop tea bag blends, which provided the same sensory experience without creating any mess.

When building a web app, probably the initial version you create actually sucks and you cannot scale it. The way I learned this was through a painful failure with my timer app. Initially, it was a sophisticated one page program with social components, shared features, user accounts, and many other features probably nobody was going to use. Because I was attempting to synchronize timer states across devices in real-time, it took months to build and crashed frequently. For what should have been a basic tool, the infrastructure costs were absurd. Due to the app's complexity, I only had about 100 users after three months of bug fixes. I learned from the failure that people do not want Swiss Army knives. Rather, they are looking for a hammer that functions flawlessly. I completely rebuilt everything as a static page with no database, accounts, or fancy features. Just an instantaneous timer. Now it gets a lot of visitors because it does "a few" things perfectly instead of twenty things poorly.

We got it wrong on our first rental calculator. We obsessed over property conditions, like roofs and furnaces, but completely ignored tenant screening. Turns out, landlords told us a bad tenant was way worse than a leaky roof. So we rebuilt it with tenant risk front and center, which is what they actually cared about. If you're building a tool, find the user's biggest headache. It's probably not what you think.

We tested a resume-builder functionality that auto-suggested the bullet points depending on the job titles. The initial idea was well-received by users, but in real-life testing, they found the suggestions to be too generic and uneditable, which led to frustration and high drop-offs. The failure taught us that rushing without personalisation is a false victory. We remodelled the tool to allow users to have editable templates and phrasing that AI recommended, tailored to their specific industry. This switch doubled interaction twice, and it was demonstrated that empowerment is more important than automation in career tools.

The first scheduling system we built for Tutorbase was too rigid. Our instructors were flooding us with support tickets just trying to book their classes. The feedback made it clear we needed a dynamic calendar that could handle how busy language centers actually work. We changed it fast, and the support tickets stopped. That's when we learned to get things in front of users early and listen to what they tell you.