After we suffered several major blows on our journey with AerinX, and our original plans and hopes seem to be deteriorating, I find it one of my most important and valuable duties to face and analyze the causes of how things turned out, however painful it is. I find this retrospection of utmost importance not to find people to blame or ruminate on what could have been, but for clarity, to draw and learn the lessons, and make sure I (and we) can do better next time.

1. Things We Did Well

An important disclaimer before I start digging into our mistakes: we at AerinX had an amazing, competent, dedicated, responsible, hard-working team who did their best to make AerinX a success. All the decisions we had, we made them in good faith, with the best of our actual knowledge. This applies to employees, management, board, external consultants, and founders as well.

In fact, there were quite a lot of things that we did very well, just to mention a few:

• Founder team of complementing expertise
• Intensive research and problem validation in the aviation industry upfront
• An experienced aircraft maintenance executive in the board right from the beginning
• Cheap early prototype to validate our solution concept
• Partnership with a local aircraft maintenance company to work closely with during development
• Amazing team and company culture
• Agile development processes
• Managing R&D in a time and cost-effective way
• Amazing live-demos and exhibition participations
• Quality marketing materials and well thought-out sales process
• International industry presence from the beginning (Europe, USA, Middle East, and Far East)
• Value proposition and pricing for aircraft maintenance companies
• Managing funding and costs effectively

2. Lessons Learned

Even with the best of intentions and hardest of work, our experience, knowledge, processes, decisions were sometimes incomplete or even outright wrong. The goal of my inquiry is to identify these steps that we could have done differently and better if we had the experience and knowledge at the time.

I’d like to group these takeaways and lessons into different categories:

• General approach and processes of how to build a startup
• General characteristic of a new B2B market
• Ideal business-side team and roles in a startup
• Characteristics of the aviation industry
• Collection of insights we could’ve learned earlier

2.1 General Approach and Process of How to Build a Startup

If I wanted to summarize how to build a startup according to my current experience and knowledge, I would say this:

• 1) Value Proposition: come up with a clear and concise value proposition for each of your customer segments (use Alexander Osterwalder’s value proposition canvas)
• 2) Business Model: build a business model around it with every building block in it (use Osterwalder’s business model canvas): revenue streams, pricing, sales strategy, sales and marketing channels, partnerships, key activities, resources, cost structure, everything
• 3) Decompose the Business Model into Prioritized Key Assumptions: decompose your whole vision and business model into independent and testable assumptions, then prioritize them along importance (how dealbreaker is it if the hypothesis turns out to be false)
• 4) Design Tests for the Key Assumptions: design different cost-effective tests to validate or invalidate each of the key assumptions (use the wide variety of available test methods offered by David Bland and Alex Osterwalder in their book Testing Business Ideas)
• 5) Start Testing and Keep Testing: if any of the key assumptions prove to be false, then modify elements of the business model and keep testing, until
  • You run out of ideas for modifying the model
  • You succeed by having a market-proven scalable and profitable business model

This process was more or less clear to us back at the beginning, but not crystal clear to the details and actual everyday practices. So we somewhat followed the methodology, but not nearly as deeply and consistently as we should have. I try to collect the mistakes we made:

Not Having a Clear Value Proposition for each Customer Segment

The first mistake we made was that we focused too much on technology and the problem to solve, but we didn’t have a clear value proposition for each of our customer segments. We had a value proposition for MRO (aircraft maintenance provider) companies who were performing aircraft inspections mainly in hangars. Although we knew that the bigger value is on the airline side, we didn’t pay much attention to our airline offering because our technology was not yet working well during shorter outdoor inspections which were key for airlines.

Leaving Blank Fields in the Business Model

Second, there were several gaps in our plans that we thought we could deal with later on. Along with neglecting the airline side altogether, we had no initial pricing (assumption) for our MRO customers, let alone a ROI calculation to support it.

Seeing our first two mistakes I can say that we somewhat misunderstood what lean really meant. We thought lean was about “first thing first” or “let’s worry about that (for instance our offering for airlines) when we get there”. We thought lean applied to everything, including the elements and details of the business model. Now I understand that this is not the case. We have to have a complete sensible plan where all the key elements are in place, no matter how much of it is unproven fantasy. What lean really means is that instead of building our (very expensive and risky) fantasy, start testing and validating its elements as fast and as cheaply as possible! The methods and ways of testing key assumptions are what should be lean and agile, not the value proposition and the business model itself!

Being Unaware of Key Assumptions

We definitely identified several assumptions in our business model explicitly, just to mention a few:

• Aircraft skin inspections are a tedious, time-consuming, manual process
• Quality of structural damage documentation is heterogeneous and low quality, which causes frequent complications
• MRO companies are interested in solutions that can improve the skin inspection process
• MRO companies are interested in our solution concept
• Mixed reality technologies are mature enough to support aircraft inspections

But we didn’t systematically go through all the different aspects of our business model to explicitly define all the key hypotheses that are crucial to our success. A comprehensive list of assumptions would have been impossible anyway, since our business model itself contained a few gaps.

Not Prioritizing Key Assumptions

Besides not having a complete list of critical assumptions, we didn’t prioritize these assumptions regarding importance or testing cost. Since my background was in software engineering and our applied technology (mixed reality) was relatively new with several challenges and uncertainties, I focused my energies on the related feasibility assumptions (can we build it?) rather than on more fundamental customer-related (what exactly do customers do and need?) and business-related (how much are they willing to pay?) questions and assumptions.

Creative and Agile in Product Development, rather than in Assumption Testing

As good engineers do, we’ve put all our creativity and agility into designing and building our product. This agility also means that in many cases we came up with pretty creative ways to solve difficult problems with simple and cheap solutions because we were always aware of our limited money and runway.

This same lean approach can and should have been applied to assumption testing as well to come up with creative and cheap tests to approve or disprove key hypotheses. This of course doesn’t always have to involve software development.

Stopping Assumption Testing after a While

We did our fair share of assumption testing in the beginning, almost exclusively through customer interviews. These discussions were tremendously useful and insightful. After learning enough (at least we believed enough) about our customers, about inspection processes, and customer needs, we thought the next step was to actually build something and show it to customers. So we stopped testing and started building. To our bad luck, our product was R&D heavy, so we had to spend some serious time and money until we could deliver and show something meaningful and usable to our customers.

What we didn’t know or weren’t aware of enough were some important things:

• Customer interviews are only one way to test assumptions and get insights, and not necessarily the best one. Especially because it is one thing what people say and another what people later do. We had to learn this the hard way.
• There are a whole lot of assumption testing methods available out there to be used to test business ideas and hypotheses. We can rank these methods regarding evidence strength and implementation cost, just like we rank user stories in our backlog regarding business value and development effort.
• Once a key assumption is validated to some degree, our job is not over. We should move forward to even stronger (and more expensive) validations, up until the ultimate proof: paying customers and satisfied users. We applied this approach very well in building our product (designing and implementing cheap and simple features or prototypes, then later replacing them with more robust and convenient solutions), but not in testing all the key elements of our value proposition and business model.

Agile Software Development VS Lean Startup Building

To summarize the lean startup building process, the philosophy is in many ways similar to agile software development, but with different goals and elements:

	Agile software development	Lean startup building
What is the end product	A working software product	A market-proven scalable and profitable business model
What is the blueprint of what you build	Software requirements and feature concepts fulfilling the requirements	A value proposition canvas embedded in a business model canvas
What are the elements in your backlog	User stories	Tests related to key assumptions in the business model
Templates to implement backlog elements	Software design patterns (MVC, singleton, factory, builder, etc.)	Business idea test methods and templates (customer interview, concierge MVP, landing page, wizard of Oz, etc.)
How do you prioritize backlog elements	– Business value for customers- Development effort (cost)	– How essential is the assumption to the business- Evidence strength of the test- Cost of implementing the test
How do you measure progress	Working software with additional features	More stable business model with decreasing uncertainty and risk level, through additional key assumptions validated with increasing evidence strength

2.2 General Characteristic of a New B2B Market

After examining the general process and method, let me zoom in more to the characteristics of the market where we are operating with AerinX: a new B2B market. By new I mean that aircraft structural inspections were and still are in most cases manual and paper-based processes. Only recently, in the last 5-10 years were solutions appearing that support and digitalize this process, and the market is only tiptoeing to get familiar with these products. The early stage of this market implicated several things that we had to learn the hard way.

We saw early on that the problem and the customer pain was real. Our solution seemed to give a well-suited answer to several of the customers’ pains. On top of that it was a cool innovative cutting-edge technology, at a time where most of our customers had dedicated departments for innovation and digitization. What can go wrong? Well, a whole lot of things actually…

How Severe Is That Pain?

I recently read it in Steve Blank’s book, The Startup Owner’s Manual, that you can and should categorize customers and their problems on the following scale:

• #1 They have a problem, but are unaware of it
• #2 They are aware of having a problem
• #3 They are actively searching for a solution and have a timetable for finding it
• #4 The problem is so painful that they assembled a solution out of existing parts
• #5 They already have or can quickly acquire a budget

The first early adopter companies who will be eager to work with us even in the early stages of development, and are happy to use and pay for a half-done, untested, buggy solution have very severe pains, on level #4 or #5, but at least level #3. Most companies are not like this, they don’t take such risks.

We learned that:

• Most of our customers were on level #2 (having a problem and being aware of it)
• Very few were on level #3 (actively searching for a solution and having a timetable)
• And we met maybe one company on level #4 or #5 (who developed an application in-house to solve their problem)

The problem with level #2 customers is that:

• They are cautious and slow, nothing is urgent to them
• They want the product to be perfect before using it in production
• They evaluate the product endlessly
• They want to include as many people in the decision making as possible (to share decision responsibility and risk)
• They usually don’t have the budget and sometimes don’t even know whose budget it should be

Sales and marketing efforts

When you operate in a new market, your sales and especially marketing efforts need to be multiplied, to familiarize and educate your customers about the problem and your solutions, to communicate benefits, return on investment or comfort them about real or imaginary risks. This takes serious time and money. In an established market – where the problem and the available solutions are well-known for customers – when facing a purchase decision, customers usually don’t question the relevance, value or risks of using the product, they rather compare your solution with alternative solutions regarding functionality, price, etc. In our case, in a new market, every single aspect of our solution is scrutinized with cautiousness and doubt, where we have to prove ourselves over and over again.

Return of investment (ROI)

If we do our job well, sooner or later we bump into some financial decision maker, who wants to see solid numbers that back up the financial value of our solution. And no, probabilities and indirect savings don’t play, only the direct, solid, easy-to-calculate numbers. Unfortunately our ROI calculation was based on a solid direct cost saving that is not too big, plus a very big saving that is more indirect and probabilistic…

My favorite example is ERP systems. Nobody can actually calculate the savings or the value of an ERP system. Solution providers don’t even calculate value in their marketing materials. And everybody seems to be fine with this. Why? Because ERP systems fought their battle with educating the market about their importance and necessity about 30-40 years ago, which was no less of an uphill struggle than what we face today. Today, ERP systems and their value are taken for granted. To decide whether their price is high or low, customers compare prices with other ERP systems and their own budget, not with the (incalculable) business value.

Another key lesson we learned in pricing is that as a rule of thumb, companies expect at least 5-10x ROI over price to purchase a new product because they have several additional costs and risks to plan and calculate with, like changing processes, training people, integration into IT infrastructure, risk of technology adaptation, etc. At least 10x ROI comfortably covers these additional costs and risk, less than 10x ROI does not always move the needle.

Integration

In B2B software, integration is absolutely essential in most solutions (depending on the data the system manages). So much so, that often even for product evaluation or trial periods they want to see operating interfaces between the new system and existing ones. This generates challenges for several reasons:

• In an evaluation period, the customer is reluctant to pay us for the interface development, since they don’t yet know whether they wanna buy the product
• Providers of already used software are usually slow and expensive when it comes to interface development, mostly because they can be. Customers usually don’t put that much pressure on them when it is about interfacing with a product to evaluate
• Customers are also reluctant to pay for this other side of the interface development
• On top of all this, interface development can have its project management (synchronizing three parties: the customer, the developer of the new product and the existing product) and technological challenges as well

Would They Buy it for Free?

I also read a key question in Steve Blank’s book, that no entrepreneur ever wants to ask their customers: “Would you introduce and use it for free?” It sounds too risky to ask such a question, but unfortunately it is a perfectly valid one. And the answer is far from obvious, for the same reasons companies expect a 10x return on investment (see above): the price they pay for the product is often only a fraction of their total cost of ownership, and then we didn’t even consider the risk.

We faced several times in the past few years that a customer had the real pain, they were very much aware of it, they were actively looking for solutions to solve it, they loved our solution concept, they tried and were amazed of our actual product, they accepted our price and ROI calculation, but still they didn’t want to buy and use our product.

2.3 Ideal Business-Side Team and Roles in a Startup

Although we had a very good and competent team, in hindsight I would readjust the competences, experiences, and roles a bit:

• Until the product is proven in the market and sales becomes repeatable, the founders need to be involved in customer discovery and sales as deep as possible. We made the mistake to delegate certain parts of sales and user consultancy too early.
• Marketing in a new B2B market is essential. At least one full-time marketing person is needed from the very beginning to research the market, generate and publish marketing materials non-stop.
• We need less of a sales-executor or sales-closer in the beginning, but more of a sales-person who can work in uncertainty and is able to change and adjust messages according to feedback.

2.4 Characteristics of the Aviation Industry

Only a few people in our team had experience in the aviation industry before. It turned out that aviation has its own characteristics that we weren’t fully aware of in the beginning.

Long Sales Cycles

Sales cycles are painfully, painfully long in the aviation industry. To me it was unimaginable that the average time from a first contact to a closed deal is measured in several (3-4) years as a rule of thumb in this industry. Yes, years, not months! For a startup with a limited runway – usually 6-24 months at any given time – this is not good news.

Limited Number of Customers

The number of bigger airlines with big-enough fleet and MROs with big-enough operation is a few hundred worldwide, not more. And the majority of the market is concentrated in about a dozen mammoth companies. This implies a specific approach to sales and marketing.

Misaligned Interests

We developed an aircraft maintenance (MRO) solution whose main beneficiaries were airlines with more flight hours and less delays. Even in the case of an airline with an in-house MRO, the two organizations are so far from each other with so different processes, needs, performance indicators, and interests, that it turned out to be extremely challenging to tie the two organizations together and align their interests. Airlines usually say “this is a maintenance tool, go talk to maintenance”. MROs usually say “this is a nice tool but for us it is not worth this much because we don’t care that much about how long an inspection takes”. Very often they can’t even decide whether our solution belongs to the MRO’s budget or the airline’s.

Conservatism

Although serious innovation initiatives and investments can be seen everywhere to streamline, modernize, and digitize aviation and aircraft maintenance, the industry in general is very conservative, probably because of the high stakes involved in aviation safety. So much so, that the current big thing (in 2023) is major aircraft maintenance ERP system providers coming out with tablet and mobile applications, so that mechanics and technicians don’t have to use papers to document their work and later walk back to their offices at the other end of the building to enter data on their workstations. One of the current buzzwords in aircraft maintenance is “paperless”. In 2023! So with a mixed-reality solution we might be a bit too early.

Covid

And of course as an aviation startup, covid didn’t help our case either (no explanation needed)…

2.5 Collection of Insights We Could’ve Learned Earlier

In this final chapter, I collected a list of crucial insights that we learned along our journey about our market and our customers. This is quite natural that there are loads of information and facts to uncover when we try to enter a market. The key question is how much time and money it costs to discover these key facts, and how much does it cost to re-calibrate (pivot) our product, our marketing, our strategy and our team to adjust to the realities of the market. Of course it is easy to be clever in hindsight, but with a thoroughly followed customer discovery process time and money could definitely have been saved, along with much of our runway.

So let’s see a (non-comprehensive) collection of key insights about our customers, our market, and our product, grouped into different categories.

ROI Calculation and Sales

• Customers only accept the very obvious, straightforward, direct cost reductions and values in a business case (like work-hours saved). They are reluctant to accept more complicated, indirect, and probabilistic calculations like freed up hangar space, avoided or reduced delays, or less complications during pre-flight checks.
• Building a strong business case with a case study is only possible if we give away our solution to a customer for free, in exchange for PR, marketing, and business case building cooperation.
• We have to start sales in the customer organization where the biggest benefit or ROI lies (airline side).
• The better quality digital data sounds good in marketing and sales, but nobody buys our solution only because of the data, unless we explain to them how exactly (with use-cases and ROI assigned) can they exploit that data.

Aviation Business

• Airlines and MROs have very different – often conflicting – interests and motivations.
• Maintenance companies are not interested too much in reducing work hours if those work hours are charged by the hour anyway.
• For MROs our ROI calculation can only be based on work hours saved – which is not that big of a number. Therefore we should not focus only on MROs – not even in the early days – because we can’t build a profitable business on MROs only.
• We can build a profitable business only on airlines by increasing aircraft operation time and reducing flight delays.

Technology

• Most people ultimately don’t care about technology. What they care about is how technology helps them to perform a job (they already have) better or cheaper.
• The mixed reality glasses currently cannot be used for shorter inspections because of the long setup and calibration time. The consequence is that outdoor use limitation of smart glasses is not an issue at all because nobody wants to use them anyway during shorter outdoor inspections.
• At first we put our airline customers aside since mixed reality technology was not ready for outdoor use. It turned out only much later that shorter outdoor inspections can be supported with simpler solutions like a tablet application or a web-application.
• For shorter inspections, even AR functionality (on a tablet) is optional, not a must. A relatively simple web-application is already a great leap forward and of serious value.
• Most companies – especially aviation companies – are very cautious and conservative about new technologies like mixed reality.
• People want to see and try cool innovative solutions, but when it comes to buying in B2B, coolness doesn’t matter much.
• When introducing new technology to a market, examining and defining the necessary maturity level of the technology to achieve widespread adaptation is crucial. In our maintenance use-case, Microsoft HoloLens 2 was the first good-enough hardware available on the market, released in early 2020. We started our development in 2019 with MagicLeap, which turned out to be not good-enough for user adoption.

Integration

• For airlines, integration with their ERP system is an absolute must, even for the evaluation of our product.
• Real-time integration and damage data exchange between our system and an airline’s ERP is very complicated and challenging to build.
• Airlines don’t want to invest any money (implementing an interface) in a product trial.

Competition

• Major aviation ERP providers are moving into mobile direction for faster communication and paperless processes, which can support shorter aircraft inspections, eating up some of our functionality and benefits.
• Airbus SRM for Mechanics is actually a great help in the structural damage assessment process. It makes our SRM navigation feature less attractive and less needed for our customers.

Product Development

Since the real measure of progress in the discovery-phase of a startup is actually information (de-risking the business model) the product development can be considered as an unavoidable step in testing of key hypotheses in the business model. This also means that most of the software can be considered as a proof-of-concept or a throw-away prototype. This implies that software development processes can be simplified and software quality standards can be lowered compared to traditional software development:

• Less specification and less documentation is okay
• Sometimes a little more chaos is okay
• Documentations like the user manual can wait
• It is enough to document, organize and solidify things only after having a proven business model

3. Update a Year Later (April 2024)

In the last year, even with a cut-back team, we managed to progress significantly with a few of our major partners:

• We completed a successful trial and created a detailed business case document with ROI calculation and everything, with a big airline partner of ours
• We accomplished another successful trial with KPIs and ROI calculations at a major MRO partner of ours
• We acquired a general ISO 9001:2015 certificate
• We acquired an ISO 17025:2017 certificate of our SmartGlass’ measurement precision
• We implemented a few additional interfaces with our partners
• A major partner of ours presented our solution to their board of directors (in a live demo) and released a report and article about our technology in the no.1 aviation news site (to advertise their own innovative attitude by using our technology)

But despite all these efforts and accomplishments, we still couldn’t sign a long-term contract with any of these customers. This means that we are running out of funds again, and need to reconsider our plans and goals.

In my opinion, looking back at these past 5-6 years, and especially looking at the last year, there are three main reasons why we still couldn’t succeed:

• The aviation industry itself: as I wrote above, it is painfully slow, conservative, risk-averse, lagging behind with technology adoption at least by 5-10 years. Major players seek innovations, but usually lack the internal competence and processes to do so. So they rely on external companies to innovate for them, but when it comes to buying and using these innovations, they rather use these startups for endless trials and evaluations, and considerations, let them compete against each other and bleed out over the years. Of course, the industry is as it is, we could and should have known how it worked upfront.
• The priority of the problem: I find it a critical issue that the problem we are solving (structural inspection of an aircraft) is not critical and high-value enough for our prospective customers. If the problem we are trying to solve is not in the top 3-5 concerns of the ultimate decision maker, then we are in trouble. Even if we provide a valuable solution and check all the checkboxes, they will be reluctant to buy it because their focus, energy, capacity, and budget is always limited, and they have to save these for the really high-priority problems.
• Timing: I read it in several articles, analyses, and sources how crucial timing is in the success of a new venture. I still have the feeling that our technology and our solution is valuable and could be a success in the market, but maybe only in another 2-3-5? years. This is a big problem because a startup’s runway is always finite, and we don’t have the means to wait another several years until we really get going.