<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

Understanding the MVP

Software Development


A Minimum Viable Product is the smallest thing you can build that delivers customer value.

While creating a product, it can be immensely valuable to gain feedback about what you are producing before you are done producing said product. This is the basic thought process that goes into creating a MVP. But creating an outline for your MVP can be difficult because you need to make sure you're keeping it to a true minimum, while also providing enough to gain feedback from. Essentially, don't forget about the viable part while creating the minimum.

I feel that engineers often find themselves in one of two groups while working on MVPs: 

  1. The "I really want to add this feature and it won't take me too long" group.
  2. The "I don't know if this is going to be enough" group.

As an engineering student, I have taken quite a few classes that focus on product and engineering management. These classes tend to escort you through the entire engineering design process, while focusing on how to work effectively on a team. For my latest engineering class project, we created an arcade style matching game for children. For the start of the project, we focused on finding out what our MVP was. We knew that we had a few electrical components that needed to communicate with the code that I would be writing.

This brought up an interesting challenge for me that I hadn't yet faced; finding a true minimum in the MVP. Because, as you start to build anything, you can very easily see things that you want to add later as you come across where they belong, for instance, in the arcade game code, I wrote function that would handle the logic for an incorrect match, and the electrical engineering member of my team was dead-set on adding a small sound effect for an incorrect match, adding to the user experience. But we also knew that this feature would only add to the time required for us to create our MVP. This was just a classic case of me placing myself into group one.

Now, as I get into Atlassian development, just like any other engineering project, I am finding the same issue. For instance, there was an opportunity recently where I could have added to the look and feel of a GUI element. But attempting to make this one small element look and feel as I think it should posed a few problems for the overall project; first off it could easily cut into the timeline allocated for the project, because it could have had me looking into stylistic features that are arguably subjective. Next, adding this feature could have possible cause a bug that may not have been in the MVP of this project, meaning I now have more pieces of code to debug.

In creating a MVP, you often have to pull the reigns back if you will, because as someone who is stamping your name on a product, you want to do everything in your ability to make it the best it can be. But you often fail to take in account the bigger picture. This behavior may be very hard to notice, because as a programer you may think "oh it's only a few more lines" while not realizing the speed bump you could be setting your project on course for.

As this is something I'm learning how to get better at, I would like to provide some general steps to follow while creating a MVP:

  • Figure out your customer and problem you are solving for them.
    While developing, at times and can be difficult to imagine all the ways someone may interact with your product, but it is imperative that you find put what your most basic customer interaction may look like, and be sure that your MVP solves their problem.
  • Think about usability.
    Event though it is an MVP, it should still be usable. Your testing phase shouldn't be interrupted by cut corners or bugs, this means you should provide a MVP that has the look and feel of the final product.
  • Lay out needs vs. wants.
    This is arguably the most imperative part of the process. Make sure you know what minimum means, as I mentioned above, finding yourself in group one can wreak havoc on your project and can often be hard to notice. Laying out the needs and wants of your product with your team can alleviate the potential of your MVP no longer being the minimum.
  • Build it, test it, change it.
    After you create a MVP you should be changing and updating the MVP using results found during your testing phase. Using this process effectively will allow you to see the effectiveness of features you are implementing.

Managing JIRA at Scale White Paper

TAGS: Software Development

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts