Month: September 2016

First off, no, this is not a post about baseball. Well, sort of, but more about the way that the concepts explored in Moneyball (the book more so than the movie) fundamentally changed the professional baseball competitive landscape and how we need something similar in software development. To put it simply, players were not being valued properly in professional baseball. The Oakland A’s noticed, changed the way they valued their players, and became one of the most competitive teams in the nation. A few years later the Boston Red Sox implemented those concepts and used them to break the “Curse of the Bambino” and win the World Series. Today, after more than 10 years, the teams that have failed to implement those concepts (Looking at you, Minnesota!) are no longer competitive.

Check out the companion video to this post here:

Software development in general and Minimum Viable Products (MVPs) specifically are in the same or worse position as pro ball was back in the 90s. There simply doesn’t exist a generally acceptable method of comparing how good they are in relation to eachother. What makes a good MVP? What makes a bad MVP? The effectiveness of the current methods of answering these questions are extremely poor because they are fundamentally flawed in their analysis of how to value a software team and it’s MVP.

Lets take a break to talk about what I mean by value. Value is the ratio between the overall benefit received from something and the cost required to aquire it, compared to the equivalent ratio between similar things. Good value is paying $1 for a coffee when the normal price is $2, bad value is paying $3 for that same coffee, and terrible value is accidentally buying a bottle of water instead of the coffee you wanted. Value is a relative term and can’t exist in a vacuum.

With that definition of value in mind, lets apply it to software MVPs and see if we can figure out how to value an MVP more accurately than methods in use today. Generally we can say that MVPs that have good value have a low cost to high benefit ratio. So what does low cost mean in the context of a software MVP?

Cost isn’t simply the dollar amount payed to a developer to code together your idea into a product. That is too simple and doesn’t take other factors into account. There are other costs besides dollars: time required to develop the product, opportunity costs, security risks, potential negative brand impact, and probably others.

Lets talk about time required to develop the product. An MVP that takes a week from idea to launch can generally considered to be more valuable than the same MVP taking a year to get from idea to launch. This seems fairly obvious so lets move on.

What about opportunity costs? An opportunity cost is missing out on a potential opportunity because your resources are tied up developing the MVP. Opportunity costs are extremely context dependent and nearly impossible to predict accurately, but they must be taken into account. When valuing an MVP one must decide if it is worth it to commit resources now or wait for a better opportunity to arise.

Security risks are another huge cost that many organizations do not properly take into consideration when developing an MVP. The sad reality of today’s technological landscape is that everyone will be hacked eventually. It is a matter of when, not if, and the downsides are immense. Look at the brand impact Target suffered when their credit card database was hacked. Look at the DNC and the exposure of their corruption in the current email scandal: it might cost Hillary the presidency. Look at Gawker Media and the exposure of their staff’s information after it came to light they were storing passwords in plain text. Developers must keep security risks in mind when designing and implementing the MVP.

But how much? Air tight security is extremely expensive and might not be worth it while developing a simple MVP. It depends on the product, and what information has the potential to be exposed, but most if not all MVPs with good value cover the basics of security (Server side input validation, prepared statement database queries, and the proper handling, hashing, and storage of passwords and other personal identifiable information,etc). If the MVP is deemed successful further security should be added as the risk of threats increase over time.

Thats a quick rundown of some of the costs associated with developing an MVP, but what about the benefits? What can you expect out of an MVP in the first place?

The purpose of developing an MVP is to validate an idea. If it turns out to be a bad idea, you can abandon it or start over or pivot without too much lost cost. Similarly, if the MVP turns out to be a great idea, you are in a position to iterate and improve while growing it over time. The transition from the MVP phase to a full product often comes with an increase in the size of the developer team as well as more oversight and control from previously uninterested parties. An often overlooked cost during MVP development is the future cost of executing this transition. For purposes of this article, lets call this cost concept future maintainability. The biggest benefit of focusing on future maintainability while still in in the MVP phase is that it drastically reduces the cost of onboarding new team members as the product grows. Its an investment in the project that potentially pays out at a future date.

An MVP with good value would invest in future maintainability, an MVP with bad value would ignore this completely, and an MVP with terrible value would put their investment in something that doesn’t actually reduce the future maintainability cost of the project.

What can be done to reduce future maintainability costs? This is the domain of software engineering and coding best practices and is a fairly well explored area. Good investments are version control, having design documents and keeping them up to date, commenting standards, code review processes, bug tracking, and many others. Entire books have been written about these concepts so they won’t be covered in this article. Lets just leave it that an MVP with good value will implement many if not all of these practices in their development processes and an MVP with bad value will ignore them. Terrible value in this domain is a bit context dependent, and difficult to cover in the scope of this article, but a simple example would be having design documentation that is out of date or just plain wrong: Its like being given bad directions on your way to your destination and will cause confusion and headaches while onboarding future developers to the team.

Value isn’t simply about reducing costs it is also about maximizing benefits receieved. Each MVP is going to provide a different benefit depending on what idea it is attempting to validate, but there are some general concepts that can be evaluated to see how much benefit can be derived from an MVP.

An often over valued concept during the MVP phase is that of scalability. Many people often front load too much of their development efforts into scalability and don’t really receive any benefit from it. Why put in the effort to make your product scale to 10 million concurrent users if you don’t even have 100 people using your software yet? Why worry about having 99.99999999% uptime if nobody uses your product after normal working hours?

Simply put an MVP doesn’t have to scale because the generally accepted initial market size for most MVPs is only the first 1000 users. With the power of today’s processors and the ubiquitiousness of cloud hosting it is extremely easy to be able to handle this level of scalability. The MVP obviously can’t be unreasonably slow, but at the same time it doesn’t have to handle the same level of traffic as Google or Netflix. An MVP with good value covers the basics (using efficient algorithms, minimizing network calls and database querries, compresses any images, etc) but doesn’t worry about more in depth optimizations. MVPs with bad value don’t optimize at all, and MVPs with terrible value put effort and sink resources into unneeded scalability and premature optimizations that aren’t needed.

Overall the software development shops that provide the most value for your dollar are going to be the ones that focus on keeping the above costs low while also ensure that the software is positioned to provide the most benefits. The good ones focus on the important aspects and don’t put extra effort into anything that doesn’t need to be included in an MVP. They don’t take too long to develop your code, they implement good security and don’t focus too much on scalability. They also ensure that they follow excellent software engineering and code development practices all while charging competitive market rates for their work. They are rare, but they do exist.

Joe Ryan

Joe is the owner of Creative Ape Studios, a software dev shop that focuses on providing the most value for your development dollar. He keeps the costs lower than a limbo bar and maximizes the benefits of your MVP.

Execution is the oft-cited distinguishing factor between a successful company and a failure of a company. It is the magic ingredient that distinguishes between a successful company and a failure of a company. But what is it? Well, here is what I have learned it is NOT:

Execution is not the ability to build and ship a product. Anyone can do that. 3 people have built your exact idea as their weekend side project and think they are going to get rich with it. Their product is probably better than yours: it looks nicer, has better features, and runs faster. And yet they don’t have any users and aren’t making any money off of it. They are not executing well.

Focusing on code development and feature development and polishing your product design is not good execution. It is something that surely needs to be done, but it should be kept to a minimum while you focus on execution. It is entirely probable that most companies that are bad at execution are focusing too much on improving their product.

Execution, to put it simply, is getting people to use the product. That is it. Nothing else matters. Companies that execute well have lots of users. Think about it, can you name a single successful company that doesn’t have users or customers? Good executors focus on gaining users. Bad executors focus on improving their product instead of getting people to use the product. They are putting the cart before the horse.

The very first step in getting people to use your product is to make them aware that your product exists. This is so obvious that many companies forget how important it is and therefore don’t focus on it. They are so busy building and improving and iterating on their product that they forget to let their customers know it is for sale! They don’t market their product at all. Good executors know that this is one of the most important things to focus on, and so they do: they put forth a large percentage of their efforts towards marketing.

The next step in getting people to use your product is to actually get them to sign up for it. Whether that imeans creating an account, signing a contract, or making a purchase depends on what your company is doing. This is commonly called sales and is the very reason that most companies exist: exchange goods and services for money. Good executors make sales. Bad executors don’t. Simple as that.

My personal recommendation, based on my experiences, is that founders and new companies should put about 1/3rd of their efforts towards marketing, 1/3rd of their efforts towards sales, and the rest of their efforts divided up between whatever else that needs to get done. This is a very good ratio of efforts for companies that want to execute well and be successful.

Joe Ryan

Joe is the founder of Creative Ape Studios, a Minneapolis based software development firm that both executes well and builds great software products. From Apps to Investment Algorithms to Websites, Creative Ape will get it done for you so you can focus on execution. Reach out today and lets talk!