Welcome to the third article of our series on developing outstanding Minimum Viable Products. This article examines the crucial elements of technical capabilities, metrics, and feedback, all vital for the successful development of any MVP. As we continue to explore these essential topics, be sure to revisit our previous discussions on Business Vision and Prioritization, as well as Ownership and Team Dynamics. Together, this article series aims to equip you with the comprehensive knowledge needed to create successful MVPs.

Articles in this series:

Part 1: Business vision and prioritization in MVPs

• Lack of business vision
• How not to fail?
• Making everything a top priority
• How not to fail?

Part 2: Ownership and team dynamics in MVPs

• Lack of ownership
• How not to fail?
• Engineers not working closely with the Business
• How not to fail?

Part 3: Technical capabilities, metrics, and feedback in MVP development

• Core IT as a bottleneck
• How not to fail?
• No success metrics & feedback gathering
• How not to fail?
• Conclusion: How do we ensure you won’t fail with your Minimum Viable Product?

Core IT as a bottleneck

You have a combined team of Business and Software experts, who understand the business value of your products - with clearly defined goals, priorities, and success measures. And… you hit a wall. Why? Because your team needs to wait for technical resources. Because your team lacks a security perspective and requirements. Because your team needs to set up the runtime environment, repositories, CI/CD pipelines, observability, queues, databases, API exposition, networking… blah blah blah. All this non-important stuff from your business value perspective. And you wait… and wait… and wait, while your competition is already releasing new features for their product. Sounds like a nightmare, right? And yet, this is a common case for companies who either had no previous experience with Software Delivery projects - or have a traditional, toolset-oriented IT operating model (a team for Kubernetes, a team for databases, a team of admins, etc).

Here are the common mistakes when an MVP hits the traditional setup of IT - or lack of technical capabilities in the organization:

• Time-consuming onboarding: This is a situation where a new Delivery Team needs to wait for all core IT Teams to provide them with the resources necessary to start building, deploying & maintaining their Minimum Viable Product. Each delay here results not only in the missed opportunity for earlier release of your MVP but also a cost of engineers having tied hands and trying to work on local machines or find workarounds for missing functionalities.
  
  
• The Delivery Team focused on configuration and management of runtime, instead of business functionalities delivery: This is even worse than time-consuming onboarding - because this is the equivalent of a missing onboarding. If your Delivery Team needs to “hustle” between multiple core IT Teams collecting tools, and then integrating those tools to even start working on a Minimum Viable Product - it causes frustration, and cognitive load and distracts your Delivery Team from creating business value. Not to mention that the time they spent on tools is time not spent on business features of Minimum Viable Product.
  
  
• User access, Security, and Network Management issues: Especially at the end of Minimum Viable Product delivery. Imagine the situation where the MVP is functionally ready - but cannot be deployed and released to end-users because it’s missing security, authentication, or the network configuration layer. Stakeholders already see the product they need, and yet they cannot provide it to their customers! This happens often if core IT teams are not involved in the Product Delivery at the beginning, or have no procedures or practices for fast Product Releases. Or… core IT teams don’t care about the business at all, focusing only on the toolset and administration.
  
  
• Tied hands with No-Code / Low-Code platforms: This often happens when we use No-Code or Low-Code platforms to avoid those three points/situations mentioned above. Platforms with predefined components, simplifying the development can be a solution for Minimum Viable Products - if those Products do not have business logic with complexity above average. If we have some decision engines, automations, recommendation rules, or algorithms for our customers - at some point No-Code / Low-Code platforms will introduce a headache in implementing such requirements. On the other hand, creating flexible platforms is a long-time investment, so building such a platform only for one Minimum Viable Product is an overkill. It’s better to find flexible solutions… and there are not many of them.

How not to fail?

At platformOS, we decided to take a step forward instead of fixing all those mentioned issues one by one. We have created a platform different than others - on the one hand, handling the runtime, deployment, observability, security, and networking (so we avoid the common problems with missing or badly organized core IT teams) - but also making sure, that the platform is flexible enough for engineers to create a complex, tailor-made applications with custom business logic and customer journey. Our platform allows the engineers to use templating language instead of black-boxed building blocks like Low-Code/No-Code platforms do - so the engineer still creates code but simplifies it with templating and deployment. Also, we have created a set of predefined Minimum Viable Products for marketplace business cases, so we only focus on what is unique about our MVP and develop only that part - having the rest configured and released together way faster than building a solution from scratch.

No success metrics & feedback gathering

Finally - our Delivery Team released the Minimum Viable Product to our customers! This is when many organizations are celebrating success. Well… still too early for that. Minimum Viable Products are being created not to be released, but to create a business value for the customers. This value creation and business goal achievement should be a moment for celebration - and rarely that’s a moment when the Product hits the market. You need mechanisms for measuring the business value and goal fulfillment - and you need to know what to measure. And those metrics should be defined not at the end of the MVP journey, but at the beginning!

Here are the common mistakes with the release and feedback gathering of Minimum Viable Products:

• Success measures definition at the end of MVP release: Making success measures at the release date is too late - because success measures should drive the MVP delivery and should be verified with every increment. Also, metrics created at the release date will have a tendency not to measure a real business value, but confirm that decisions made during MVP delivery are correct - even if those lie far from the actual goals.
  
  
• No business metrics: It’s even worse than the first point because still, it’s better late than never. Having no business metrics defined and implemented makes you only guess if your Product was actually successful.
  
  
• Too many metrics: Yes, after the two previous points that may be a surprise - but too many metrics can also obscure the picture of whether we have succeeded or not. When creating an MVP, there should be only a few success metrics defined, and closely related to the business vision, value proposition, and assumed goals.
  
  
• No automated mechanism for metrics collection: Finally, we can define metrics and still have no data or automation on which we will monitor the metrics' values and business goals fulfillment. During Minimum Viable Product development, you should implement simple business metrics gathering and visualization.
  
  
• Verifying the metrics only after the release: This is a common mistake - enabling metrics gathering only once the Minimum Viable Product is released. You can define some metrics and mechanisms of their collection, which will allow you to check how likely you are going to succeed before the big release. For example, you can test some parts of Product functionalities internally with business stakeholders, or “friends & family” - small groups of trusted users.

How not to fail?

First, we strongly encourage our Customers and Partners not to wait till the release to present the outcomes of Minimum Viable Product delivery. Our platformOS MVP Blueprint for partners assumes frequent demos of increments and a necessity for business stakeholders access to the product in the test environment as soon as possible, after the first increment. Second, during MVP workshops, where we support our customers in creating their business vision, and defining their value proposition and priorities - we also define success metrics and agree on collection methodology. We finally do not recommend our partners treat the release as a success - but instead, treat business value delivery as one, and feel accountable for it.

Conclusion

How do we ensure that you won’t fail with your Minimum Viable Product?

Minimum Viable Product journey can be a bumpy road, where the fast delivery of software products with business features is only a part of the process. Technical success of software delivery is only one of the factors - that is why in platformOS we have created a complete analysis and a delivery guideline, supported by the platformOS toolset. We provide our partners and customers with:

• platformOS MVP blueprint, timeboxing, and scoping analytical phase to define an MVP scope quickly.
• platformOS composable platform, allowing customers and partners to build their solutions fast with composable applications, template language, and runtime managed by platformOS.

The platformOS MVP Blueprint is a methodology that allows you to avoid all the common failures underlined in this article. To avoid a lack of business vision and prioritization deadlock, we have created Business Workshops - from the results of which we create MVP Scope, Delivery Plan, and Detailed Backlog with priorities. We also define business success measures at the very beginning of MVP delivery. We strongly advise that engineers participate in this workshop - to avoid a lack of business value understanding. Then we encourage our customers and partners to collaborate closely on iterative increments, making Delivery Teams responsible not only for scope delivery - but also for business value creation. We, platformOS, finally provide all necessary DevSecOps toolset as a service - together with managed runtime and predefined application templates, so the Delivery Team focuses fully on business features and value creation. Having all that, we ensure that your Minimum Viable Product does not wait too long - and is released to the market fast, conquering the hearts of your customers! In platformOS your business success is ours.

This article series looked at the multifaceted approach that should be taken to develop a Minimum Viable Product successfully. The development and launch of your MVP require good business planning, technical skills, and strong teamwork. Everything goes on with each other, making successful development. Remember that the MVP is mainly to help you learn fast and improve according to the honest feedback you get. By really keying in on those factors, teams can take on the challenge of developing the MVP that enables them to reach and even exceed their market's expectations by influencing their field dramatically.

Previous article in the MVP series:

• Part 1: Business vision and prioritization in MVPs
• Part 2: Ownership and team dynamics in MVPs