The PROBLEM With Software Development (Episode 1: The MVP)

The PROBLEM With Software Development (Episode 1: The MVP)

Software development has a big problem. This series of articles is going to help you solve that problem.

This big problem has been around for decades, and we still see some of the biggest names in software struggling with it.

So what is the problem?

Software development is almost always late, over budget, and yields irrelevant, incomplete, or incompatible products. For that matter, a good portion of software development projects never see the light of completion. As a result, businesses and organizations have developed an aversion to creating custom software that could really be helping them help the people that they serve.

The purpose of software, after all, is to make people’s lives easier. However, over the last couple of decades it seems like software has been doing the exact opposite by creating more headaches, and most of these headaches come from actually developing the software in the first place.

This doesn’t have to be the case.

Software development may seem like a daunting and complicated process, but it should, and can be, simple. For software development to be simple, people have to learn to work smarter, not harder. In order for this to happen, a basic shift of perspective is required for all parties involved, from the product stakeholders all the way down to the development team members.

Let’s call the new perspective “SMART” software development, and define it this way:

S: Start Small: Define an MVP around what is most helpful to the end user and ditch the “nice to haves”.
M: Measure Value: Define development value by the throughput, not by the hours spent coding.
A: Allow Changes: Reprioritize work every two weeks to make sure the most important features are always top of mind, and front of development.
R: Review: Review shippable deliverables at the end of every sprint with in depth demos, demonstrations, and the power to accept or reject.
T: Test: Let your end users and stakeholders become a part of the QA/AB process with access to periodic builds and updates.

This “SMART” perspective is centered around the principles of Scrum, a revolutionary methodology that encourages an evolving product development. Scrum tells project managers to ditch the in depth pre-project planning demanded by the Waterfall approach to product development in favor of ongoing planning fueled by the feedback of the people who actually care most: the end users.

In this episode of "The PROBLEM with software development", we are going to  talk about the first step in developing “SMART” software, defining something called the MVP. And, no I’m not talking about the Most Valuable Player, I’m talking about the Minimal Viable Product.

The idea behind the Minimal Viable Product is simplicity.

Software is notorious for falling victim to the fact that most users only utilize 20% of a software’s features and functionality. With that said, when building software from scratch, it is important to try to define that 20%, and build only those features first. This responsibility falls to the product owner.

The product owner should be able to determine what the overall vision and purpose of the product, and then decide which essential features and functionalities need to be included in the MVP to ensure that the initial product has value to the first group of end users. This isn’t always an easy undertaking, since a product owner can’t always accurately predict what end users will value most about a product. For this reason, as a product owner, it can be worthwhile to bring a select group of end users into the initial discussion of what the MVP of the product should include.

At the end of the day, no MVP is going to be a perfect product-market fit. This is why every good product owner should have continuous feedback channels in place to allow communication with end users about what features and functionalities they value most and what should be included in a future release.

The MVP approach can save massive amounts of time and money in the development of a software product, and coupled with the rest of the SMART software development perspective, will ensure that your product gets off the ground faster, better, and for less capital.

Episode One Takeaways:
1.) Work SMART, not hard when creating software.
2.) Always start with an MVP when creating software from the ground up.
3.) Center your MVP around what adds the most value to your product for the end users.
4.) Let your end users help you determine important features/functionalities for your MVP.
5.) Have feedback channels in place with end users.

Note from the writer: I hope that you all enjoyed this first installment in the “Solving Software Development” series, and were able to learn something new! We hope to release a new article every week in this series, and would love to hear any questions or feedback that you may have about the SMART software development perspective, scrum, project management, or really anything else!

Now, if you’d like to develop a superior product and not worry about the hassle of doing it yourself, give us a shout!

要查看或添加评论,请登录

George Orlin的更多文章

社区洞察

其他会员也浏览了