MVPs: Inside the whisk of business risk

As a product manager, one of my key responsibilities is guiding my teams through the inherent risks and uncertainties of launching new products. This is especially true when it comes to developing and releasing Minimum Viable Products (MVPs), the initial core versions of a product designed to get early feedback from users.

The core essence of developing MVPs is based on two main pillars: one is the early user feedback that we need to have in order to minimize the efforts to develop a feature that might not be in the users’ priorities or needs; the second is the business drive. The runway of any business is based on time; it is the most important and valuable element in life; hence, developing positive increments is crucial to the business.

But this is from a product management point of view, what about the developers? Engineers and designers? Their main goal is to produce perfect increments, not just usable, for them, a feature should be perfect and fully developed, and this takes time, maybe weeks and maybe months, while this is a perfect scenario, it only exists in a perfect utopian world, which is not the case and here is why:

As money is power, and time is the most valuable element one can possess, these two elements are the drive of every business decision, and having a Minimal Viable Product saves both, while having the user in mind to have early feedback. While mastering and perfecting a feature will come in the roadmap, it can not be the start point, you start from a Minimal Viable Product and add increments as you go. 

Launching MVPs can feel like navigating a whirlwind of business risks. There are technical challenges, market uncertainties, competitor threats, and pressure to meet quite ambitious deadlines. It's easy for product teams to become stressed and overwhelmed, especially if there is a gap between business goals and product development.

This gap can lead to frustration, missed deadlines, and products that fail to achieve the original business objectives, and it is one of the main responsibilities as a product manager to delicately master the art of achieving business goals while building the product in a healthy environment.

Also, this contrast between perfecting features vs MVP is quite obvious. I have personally met product owners with engineering backgrounds who decided to completely take the developers' side of the debate and work on mastering the features as starters. This way, they not only miss deadlines but also put their businesses at huge risk, as not having user feedback on a highly frequent basis is a real killer.

However, I've found that with the right mindset and approach, MVP development can be an exciting and inspiring process, one that allows us to rapidly learn, iterate, and build fantastic products for our users.

One key element to encouraging the developers and boosting their enthusiasm is highlighting their progress. Seeing some ideas that were just scribbles on the board in the meeting room come to life and get used by real customers is a powerful freight train, carrying loads of excitement to the team.

Personally, I have learned this the hard way, but keeping your team excited is more important than the MVP itself. A happy team equals a great product equals a happy customer, and this happy-happy situation can boost the team's productivity, keep the stakeholders satisfied, and keep angry risks at bay.

Below, I will illustrate more using an example I faced in my career. A sudden opportunity appeared, the client wanted to develop a new feature that was not discussed before in the sprint planning, and the marketing team captured a great opportunity that the business should hammer on.

We were in the middle of a two-week sprint already, and we only had one week left. At first, the developers and designers were devastated and were not encouraged to engage in this battle, as one week was not enough from their initial point of view on the feature, and the estimate was three sprints.

When we examined the feature definition, we found that the feature had many specs that could be delayed for future improvements and that the MVP would just need some tweaks in the feature's definition. With a second review of the MVP planning, the engineering team found a key to solving the problem and only worked on the needed definition to both achieve the definition of done and produce a testable and viable Product.

The key to the planning activity was fostering an environment that balances the need to move quickly and get user feedback, with thoughtful risk mitigation and a focus on our core business goals.

In the sprint review, the developers and designers were very happy with the outcome of their work, and were very excited to present the developed feature, not only as a presentation for the stakeholders, but they gamified the demo, and used the feature to produce cool outcomes themselves, as our product teaches STEM education in a gamified experience, they not only tested the feature, but also 3D printed the first outcome in a frame that was later on hanged on the wall as the first actual product from the feature.

If I can give a piece of advice to product managers; always try to celebrate small wins and maintain a sense of momentum. Launching an MVP, even in an imperfect state, is a major achievement, and try to make sure the team knows how proud you are of their work. These positive reinforcements help keep everyone energized and inspired, rather than stressed.

Ultimately, the role of a product manager is not just to deliver business results, but to create an environment where the teams can thrive. By balancing ambition, business rationalism and fostering a culture of shared ownership and mutual support, always aim to transform the "whisk of business risk" into an exhilarating, productive process of rapid innovation and learning.

After all, that's what great product development is all about.