How to design an MVP with an AI solution?
Lexunit is a group of engineers and physicists who are in IT because we want to work with AI.
Back when Lexunit has been founded, we wanted to utilize our background in mechanical engineering and we started out by focusing on the hardcore, heavy-duty world of industrial automation.
We collaborated with companies to build virtual twins of complex machinery for simulation purposes. We set up predictive maintenance practices, so the machine parts can be replaced right before they lose performance, not based on some arbitrary window set by the manufacturer. We optimized an elaborate parts storage system, so it adapts to the daily demands of a manufacturing plant.
All of these projects rise from long talks and careful analysis of the operation, until we, together with the client, identify a singular area where we can achieve a relatively 'quick win' with a Machine Learning solution.
Meanwhile, something else happened.
You know, the thing is, these big, often global, industrial companies are really hard to get into contact with for outsider experts like us. Even if your solutions could literally save millions in operational costs after completing a project in 12 weeks, the methods to put your foot in the door of the decision-makers are far from clear. So, while we relentlessly sharpened our engineering mindset with these industrial projects, we started to collaborate with the global startup world as well.
Startups are completely different from industrial companies with big technical facilities full of valuable hardware, in three key ways:
1. They are dynamic and lean in their operations. (Manufacturers operate more incrementally.)
2. They are almost always under some kind of specific time constraints (Industrial companies build and maintain process flows).
3. They usually have a very clear challenge ahead of them. (Even when they decide to pivot. That's a clear challenge as well.)
All we can say is that the engineering mindset flourishes in an environment like that. It feels like the obstacles are removed and the operational window is wide open.
These collaborations are complex technological partnerships. They dream it, we build it.
Or rather, they dream it, and we give feedback about feasibility, technical challenges, likely time frames, resource requirements, and together, we iterate. We build the first features, and we go again. The discussions never stop. The process goes on until we have a product, and sometimes the collaboration becomes indefinite, as we are integrated into the inner workings of the startup. Sometimes for years.
When we join a startup, the discussions that take place depend a lot on which phase the startup is at currently. In most cases, we are there pretty early. We are trying to build our network in the scene (we started in the Boston area a few years ago, but now we are branching out), and our first projects lead to recommendations.
More often than not, after getting into contact with us, the startup decides to restart the technical side from scratch.
This often happens because, at the beginning, startups are cooking with what they have, and when they build staff, they have to decide if they want to hire their own developers or outsource.
Team augmentation is usually cheaper because you get the expertise of the development team, with an opportunity to provide Machine Learning and AI support for the business side.
This solution is more actively scalable and dynamic than hiring highly skilled, experienced developers in a phase when all you really have are some ideas, and maybe some sort of MVP.
The recently acquired jobseeker platform, JobStep would be a good example for a technical partnership like this where we automate a job finding process.
They've had this conviction, that the usual way of job seeking is way too tedious, and it doesn't utilize technologies that are available. There has to be a better way than uploading your CV and then filling out forms with the exact same information! We should really do better than visiting dozens or hundreds of company pages, all with different formatting, and slogging through their unique application processes.
They wanted to automate it all. Obviously.
But before they could do that, they needed some validation.
When you want to create something like JobStep, you usually do the processes manually at first, to see how the market reacts. Will the people come? You need use cases, and testing, you need real people looking for real jobs.
So, they start small scale and simply take over the tedious tasks of job search and application from the users, and they do it themselves. This is their MVP. They know they want this to become an online solution, but first, they need to 'act' as the solution already exists and do the background work with manpower. Because there is no other way to test the viability of the idea itself.
While they are doing it, they are taking notes and looking for patterns, so they can have an understanding of how this all should be automated.
And then we help them automate it.
Another good example would be the Sidekick, the brainchild of the amazing ballerina, athlete-turned-businesswoman, and startup founder, Rachel Cossar.
After her professional dance career ended due to injury, she started coaching people about posture, movement, and everything they could do to perform well in the social environments of business, like giving speeches, presentations, pitching, and so on. Then the pandemic hit and now people needed to learn how to actually behave and perform in front of cameras during online meetings. Rachel analyzed the recordings and gave feedback to her clients, and she realized that most of this service could be automated if an algorithm would be capable of learning the most common mistakes people make while on a video call.
In this case, the 'alpha' version of the MVP is just Rachel giving feedback in 1-on-1 sessions. The analyzed videos serve as teaching data for the algorithm. When the teaching sequence is complete and the model is good enough, we need to create the online feedback system. The real product, the app called Sidekick will give feedback ('nudges') to the user in the video call, in real time.
This is when an MVP, which can be made to work with a wide variety of solutions, starts becoming a technical product. Now, not every single idea that can somehow be made real, can actually be automated and packaged as a viable tech solution.
So, when you create an MVP that can test the technical feasibility of your idea, you are working toward what we call the Proof-of-Concept.
A Proof-of-Concept (PoC) is a true working solution for your idea, without the bells and whistles. Only the core mechanics. It exists to validate scalability, technical potential, and the key functionalities of the product that is based on your business idea.
In Sidekick's case, we've had some challenging bottlenecks to get rid of. The feed from the video call should be analyzed in real-time. When you are on a call and you start fidgeting too much, you need to be warned about it instantly, not minutes later. So the algorithm needs to do its work right inside the browser, which demands considerable resources. It turned out that it can be done with the right prioritization, but it wasn't obvious. So, the concept needed to be proven in a technical sense as well.
The PoC is part of the MVP phase, when the technical feasibility is not obvious, when there are challenges to overcome.
But what does 'Minimally Viable' even mean? It's different from product to product.
When the technical feasibility is not obvious at first, then the MVP can have a huge influence on the scope of the features.
When your MVP involves Machine Learning, you almost always have to build a PoC version. You need to gauge the complexity of your algorithms and neural networks because things (like your cloud capacity costs) can get out of hand quickly.
UX & UI are usually key components of digital consumer products. Like, you could argue that Tinder is mostly about the swiping experience, although there is a matchmaking algorithm running in the background as well. When the user experience is a key component of viability, then the MVP development needs to continue after the PoC phase as well, because technical execution is not enough for success in this case.
At this point, the 'minimality' becomes arbitrary. Where do you draw the line, how much effort you want to put into the product? It depends on how much of the value is the user experience itself, and how different you can make it to existing products. If your product is a quantum leap from what is available at the moment, you won't need much polish because users and investors will instantly understand the value. If your product does something that already exists, but more simply, easily or elegantly, than UX probably is an integral part of the MVP.
If you have an idea that takes part in the ongoing AI revolution, we are happy to analyze it and come back to you with solution pathways and cost estimates. Feel free to contact us or you can learn more about how to Leverage AI for Business!