How to Align Product and Operations and build an MVP

At Martian & Machine, our strongest suit is building up whole startups from scratch. First and foremost, this means we can realize ideas all by ourselves. We set everything up from zero: product definition, idea validation, business model, brand strategy, corporate design, landing page, MVP (minimum viable product), user app, dashboard, operations, marketing, and whatever else is needed in the respective case. We have specialists for all the areas and basically provide the perfect founding team - this core team builds one startup after another. 

This way of working is not very widely used yet but gives us many competitive edges. For me, one of the biggest advantages is the possible communication and potential symbiosis between the operations and development departments during the MVP phase.

Have you ever heard of the fake it until you make it approach? Willingly or not, almost every newly-founded startup is using it and the more you embrace the approach, the more positives you can get out of it.

Fake it until you make it is merely a description of the state in which the technical side of a startup as it was once thought of in the ideation and business modeling phase is simply not existing yet. Even with the fastest process and team, it will always take some weeks or months to have a good MVP. With the MVP you will want to try out if your idea can actually generate some traction on the market, as well as collect valuable user feedback - in some cases, we were even able to generate some revenue with MVPs, but this is another story. 

The real purpose of the MVP (minimum viable product)

The focus is not to make the MVP as efficient as possible in terms of operational workload but to achieve the highest possible quality of insights. An early example of this was German startup GoButler (later Angel.ai, now scrapped) a few years back. In their plan to provide a ‘24/7 on-demand assistant’ that can order flowers for your mom, reserve a table at a restaurant, or book your next holiday via SMS, there was simply no artificial intelligence to actually do all those things yet when the service went live in 2015. The fake it until you make it solution was to just hire students and other low-maintenance and low-budget employees to process every request that came in manually. Eventually, this also was one of the reasons for the business model not to work out as planned - the idea just is not scalable as long as the technology is not ready to take over most of the core work yet. 

This story reveals the approach’s most significant weakness: its cost. And certainly, there are cases in which it will most likely be clear from the start that temporarily replacing artificial intelligence with humans will just not work out financially. In this case, it probably makes more sense to just launch with a landing page, generate as many signees as possible and then hope for the best once the technology is (close to) ready to go. 

The actual operational part of the work when using this approach is manyfold and kind of tricky, too. You need people who are reliable, diligent, quick learners and have an excellent understanding of how the final product is supposed to work. Whenever your technology would be supposed to connect a customer and a seller, a human has to make the calls and transfer the money. Whenever there are documents to be checked by AI, a human has to take a close look. Whenever there is a flaw in the system, a human has to be on top of it. I know, this sounds like tiring work. That’s because it is tiring work. However, there is no other scenario I know of in which you can improve your idea, business model, and, most importantly, your idea as well as in this way.

By doing the work your product is supposed to do later on, you gain the most valuable insights about what operational bottlenecks, market specifics, and user needs there are for your niche and how your product-to-be can address them, maybe even be a step ahead of the more conventional competition, once you enter the market on a larger scale.

Once your product is running as planned, these insights are much harder to gain and your product might have developed in a technical direction that is not ideal but also not easily changeable anymore. Most times, it will not be possible to make a product direction or logic completely based on operational preferences or practicalities. But an important thing to always consider in this regard is that a user of the product will most of the time not care about how well thought out the product’s inner logic theoretically is but how many practical advantages it can add to their daily life. And for this it is unavoidable to do the operational work, gather qualitative and quantitative data, and iterate based on it - go the extra mile.

Let’s assume you want your product and operations to form a symbiotic relationship - how do you do it? One part of the simple but correct answer is communication. As obvious as this sounds, product and operations can only benefit from each other, if there is a constant flow of information between product and operations managers. What makes sense operationally may not always be possible technically and vice versa. The more a product manager learns about operational bottlenecks and demands, the more he can steer in the right direction; the more an operations manager knows about the product status, the more he can take into account how much capacity for improvement or change of direction there is.

Data before perfection

The other part of the answer is called data. Both operations and product managers will always have a subjective view of their work on a specific project. They will also have interests and motivations, such as keeping the workload for their team on a manageable scale and not iterate their planning more than necessary. So whenever a situation in which a decision of what is right or wrong to do is needed occurs, the best consultant is data. Data is less biased and most times smarter than gut feelings or opinions. Not only, but especially when conflict arises, data should be the decisive element in the process. The respective data can and should be collected on both sides and teams to build up the most meaningful collection of data that is possible. 

In the end, it all comes down to how well two very different kinds of teams can collaborate, how they can bring out the best in each other. At Martian & Machine, we are constantly trying to improve this process by even more communication, feedback sessions, and trying to get everyone to think further than their official role.