Early user feedback is so logical, and its importance is supported by data but in practice, we see that it is a rare mindset and skill. Also, sometimes it is challenging to convince business stakeholders to do MVP releases or early user testing. Laimonas Vainoris, Business Operations Manager at Adroiti Technologies, shared his experience and solutions on how to manage that.

There is no point in launching something unfinished. There is not that much value in user research; we should know better than the users. There is no time for user research. On the one hand, these statements could reflect the attitude of those who are not familiar with the peculiarities of developing and releasing a digital solution; on the other - this could be challenging even for the most experienced product development team as it requires skill and time to get a useful user feedback.

Stakeholders who do not have experience with technology want not only a complete but often a perfectly polished product, even though, in practice, very often is not the best approach. Also, very different considerations are needed for B2B and B2C products. And sometimes, there are good reasons not to release unfinished products to the wider market, but very few reasons exist not to do prototyping or release to a limited number of trusted users to gather feedback. The tremendous importance of IT and product managers' communication skills is revealed on this path. Our task is to try to explain everything in as much detail as possible and to balance the situation in such a way that leads to the best decisions for the business, product and its users", Laimonas shares his experience.

Unrealistic expectations could be expensive

At Adroiti, we follow the Lean philosophy that states that the product with its core features should be developed and released for user judgment as soon as possible with a minimum investment. The final judgment for product-market fit and usability is the users but not the entrepreneurs or the product team. In essence - the sooner we give the product to users, the sooner we can receive useful feedback and finalize the product. The opposite is also true. Or, in fact - it is as important to fail fast and pivot if needed.

Neglecting the MVP approach to releasing software may lead to problems that look something like this:

• Extended time to market if the product is developed for a very long time. Time is significant - it can determine the relevance of a product that can be used by competitors to their advantage, not to mention the fact that the market is changing fast.
• Futile investments - it's when money is directed at assumptions that can not be tested until the full release.
• Lost opportunities to engage early adopters and gather their feedback early.
• Delayed execution of various corrections that could have been done earlier, also occasionally leading to more difficulties in carrying them out.
  Is MVP always the best approach to go live?
  Short answer - no. When launching utterly new software, releasing MVP often helps to save time, costs, and resources. And yet, big-bang go-live to market may be the required approach in some cases from the business perspective:
• Complex products. If the product is complex and requires a lot of technical expertise, it may not be feasible to release an MVP that effectively showcases its capabilities.
• High-risk industries. In some sectors, such as medical devices or aerospace, releasing an MVP may not be possible due to strict regulations and safety requirements.
• Crowded markets. If the market is already crowded with similar products, more than an MVP may be needed to differentiate your product and capture market share.
• Limited resources. If your company has limited resources, you may need to invest more time and money in a complete product release to ensure its success.
• Market demand. If there is high demand for a product, releasing an MVP may be optional.

However, even when a big-bang release to market is the way to go, the minimal release mindset should be embedded in the software product delivery process. Whatever the approach to the final release, the benefits of early user testing are clear and difficult to dispute.

Balance

Every product specialist must explain all this to the investor or any other stakeholder. After all, why invest more money than necessary to release a product if you may later have to re-engineer much of the same product after receiving consumer feedback?
Still, you should not concede even if this argument is insufficient to lead the client to make the right decision.

We usually address such cases like this:

• Introducing an additional step in the design phase - create prototypes to conduct limited user research. It is the minimum that every product manager could do.
• Breaking the big bang release into parts. For example, we could make it available to a certain group of users with limited functionality, even if that’s internal users (friends, acquaintances), to get some feedback.
• When it makes sense, the team could attempt developing minimal viable functionality under the hood even if stakeholders do not want to release MVP to the market. Ultimately, even if stakeholders want to go live big bang, it should not divert the product team from breaking down the release and pursuing the MVP approach.

Our responsibility is to educate stakeholders about the significance of the MVP approach. We can create a more efficient and successful product by avoiding unnecessary investments and potential re-engineering.

Follow our latest insights on Adroiti Linkedin!