Throughout my time leading Product, I’ve come to value the concept of MVP the most. When I apply for something, when I think about my day or when I’m planning my week. I even use MVP thinking when writing these articles. The concept is simple, how can I convey so others understand with the least effort and resources the same product/s or intention? How can I remove an effort from this activity and still achieve my goal? Can I get it out now and effectively gain returns while I plan what’s next?

‍

An MVP is the smallest thing I can create or iterate on, and deliver with value.

‍

It’s right here at this point I could end this article and deliver the smallest version of “What’s the point of an MVP” Iteration One. Deliver it, Then

While the MVP is being delivered to users I: Keep writing — Consume feedback — Research — Edit — Publish again, repeat.

‍

The concept is the same at any scale.

‍

The expected outcome of an MVP will vary with the problem you are solving but in the simplest terms, it should target the right market or set of users, solve that user's problem, and in a business use case — generate revenue. The data you receive from an MVP in use then becomes part of the toolset to iterate on the product in the PDLC.

‍

Best Practices for building an MVP

Once you’ve identified the core problem and target market, making sure they’re aligned with company goals consider these thoughts when building an MVP.

‍

• Keeping it simple and focused: Product managers should keep their MVP simple and focused, ensuring that it addresses the most important problem and meets the most pressing needs of their customers.
• Involving customers in the development process: Product managers should involve customers in the development process to ensure that the MVP is meeting their needs and addressing their pain points. This can be done through user testing, surveys, and customer interviews.
• Continuously gathering feedback and iterating: Product managers should continuously gather feedback on the MVP and iterate based on that feedback. This will help them improve the MVP and ensure that it is meeting the needs of their customers.
• Staying flexible and open to change: Product managers should stay flexible and open to change as they develop their MVP. This will help them respond quickly to new customer needs and adjust their product development strategy as needed.
  ‍

I would add too, that an MVP should be revisited in all Roadmap, pivot or persevere, and product alignment meetings. If we are to remain agile we must be emotionally agnostic about the product. That being said, understand and have true alignment on your approach. There can be great data obtained by intentionally getting an MVP to users knowing there will be partial or full failures, e.g. invalidating MVPs - If your hypothesis or assumptions are invalidated partially or fully.

‍

Know what to avoid when building, know when to pivot, and know when to quit. Avoid PITFALL!

‍

• Overcomplicating the MVP: Product managers should avoid overcomplicating their MVP by focusing on the core features that are essential for solving the problem and meeting the needs of the target market.
  - Remember we want to do the most, with the least, and still achieve our goal/s.
• Not involving customers: Product managers should avoid developing an MVP without involving customers. This can lead to an MVP that does not meet the needs of the target market.
  - This should come at any possible junctures in MVP and road-mapping, if the goal is a product for the user, the user must always be considered.
• Ignoring feedback and failing to iterate: Product managers should avoid ignoring feedback and failing to iterate on their MVP. This can lead to an MVP that does not meet the needs of the target market.
  - We’re all guilty of getting attached, especially if a release is near but the data says to wait and change. making hard choices is part of the job.
• Being too rigid in the development process: Product managers should avoid being too rigid in the development process. This can lead to an MVP that does not meet the needs of the target market.
  - Conversely to most of the above, going too far into rigidity and not offering room for the MVP to organically grow or be added to when possible can be a detriment to the PDLC.

Here are some visualizations of how I would start (Personally) Keeping a running board of elements to the MVP where you can see what is needed, not needed, risky, and potential will help both in making your MVP documents robust, your roadmap conversations fluid as well as your milestone mapping with key stakeholders.

‍

‍

Please consider your organization or team will likely have an in-place Product Requirement Document (PRD), and or, a Product Development Lifecycle (PDLC) in which they’ve outlined a specific MVP approach, but here is a simple one for consideration.

‍

Keeping good, well-socialized MVP documents will help you walk into a Roadmap kickoff meeting with greatly reduced friction and have valuable cross-functional team members singing from the same song sheet and narrowing in on development sooner.

‍

Creating an MVP is an essential component of the product development process, as it empowers product managers to validate their product concepts and make informed decisions before committing substantial time and resources to full-scale development. By adhering to the guidelines and best practices outlined in this article, product managers can guarantee that their MVP is streamlined, centered, and aligns with the requirements of their target audience. A successful MVP not only helps product managers to test their assumptions and hypotheses, but it also lays the foundation for creating a product that resonates with the market and meets their needs. Additionally, it provides a valuable opportunity to gather user feedback, fine-tune the product, and iterate on it before launching it to the market.

‍

What MVP ideas do you have? I’d love to hear them!

‍