The Objective Blog

Keep up with what we're thinking, reading, and doing.

MVP is a Relative Term

April 27th, 2018 - by Brett Derricott - Salt Lake City, Utah

We talk to a lot of potential clients who have heard or read about the concept of a Minimum Viable Product (MVP). Thanks to the lean startup methodology, starting your new venture with an MVP is no longer a new, innovative approach; it has become the norm. In some ways that’s a good thing and in some ways it’s problematic.

First, the Good

Entrepreneurs are usually visionary people who dream in big, expansive ways. The lean startup movement has done wonders in countering the natural tendency of entrepreneurs to overthink and overbuild the first version of a new software product. Rather than spend all the money building what the entrepreneur believes is the right product, the lean startup methodology says to build only the minimum product that is necessary to prove viability. Entrepreneurs are now being taught to attempt smaller, more reasonable iterations of their product and I say that’s a good thing.

Now, the Problem

MVP is a relative term. A product’s viability is directly determined by the maturity of the market into which that product is entering. A product that is defining a new market can be viable at a much earlier point in time than a product entering a more mature market where healthy competition already exists.

Here’s an example to help illustrate:

One of our own products, a robust PTO tracking system, is called Built for Teams. When we launched our MVP version of the product years ago, the market didn’t really have any products dedicated to PTO tracking. There were some HRIS products that had a basic PTO tracking module, and there were some time tracking products that could record days off, but there was a lot of opportunity to define a new niche in the market.

Because of this open niche, we were able to launch Built for Teams with a fairly basic PTO tracking feature set. Our MVP quickly attracted customers who were willing to put up with the “minimum” state of our product because the few things we did were so valuable to them. In solving a few real problems, these early customers were happy to accept that our product didn’t yet do everything.

Fast-forward to the present and the market is quite different. Quite a few competitors have sprung up and, like any maturing market, we’re now in a race to do more and be better. To enter this market now, a new competitor has to build an MVP much more complex than we built for our MVP.

Your MVP

As you consider your own MVP, be sure to study your market and make sure you have a good read on what it truly takes to be viable. If you’re charting new territory, your MVP might succeed with just one feature and a poorly-designed UI. If you’re entering a competitive market, your MVP either needs to have a very unique value proposition or needs to be more complete in order to provide a compelling alternative to the established players.

Continue reading: I recently wrote about the product-market fit that an MVP sets out to accomplish.

Software is Never Done

September 22nd, 2017 - by Brett Derricott - Salt Lake City, Utah

For first-time software entrepreneurs, the realities of creating and owning a software product can be a shocking eye opener. The trouble is, most have to learn the hard way. My hope is to give you some insights, gained after 15 years of designing and creating software for hundreds of clients, that will help inform you as to what you’re really getting into when you set out to create a new software application.

Incorrect Expectations

Most people who’ve never created nor maintained software are somewhat unreasonable in their expectations of what it will cost to create software that can achieve product-market fit, and unreasonable in their expectations of what it will cost to maintain that product after launch.

Based on my experience, expectations are often off-base because of the following reasons:

  1. The entrepreneur has never done this before. How could they know any better? If I decided to build a boat, which I’ve never done before, it’s safe to assume the project would take longer and cost more than I naively think it would. The same holds true for a first time software entrepreneur. We don’t know, what we don’t yet know.
  2. They’ve been conditioned to this thinking. There are many other things in business, even within a loosely-related category, that are more “pay $X and then you’re done”, such as a logo, computer, or brochure. Software, unfortunately, is not at all like this.
  3. Historically, software was a bit more of a static product. We bought software on discs and in the pre-Internet dark ages it was rare to get any updates for that product. I think this gives some precedent to the notion that “I’ll build an app and then sell it.” We still buy mobile apps that way, in fact, even though our mobile apps are constantly being updated.

The Dawn of Awareness

One of my favorite conversations with new-ish entrepreneurs is the one we have about a year after they’ve launched their app or SaaS product. By that point in time, the entrepreneur has usually started to realize that they will be working on this app (translation: spending money) continually for as long as they are in business.

They now know first hand that creating and maintaining software isn’t quite as simple as they originally expected. What leads them to this new understanding? It’s first hand experience of the following truths:

  1. All software has bugs. A hallmark of an inexperienced entrepreneur is that they believe in bug-free software. It’s a myth. Certainly, everyone strives toward that mythical goal, but no amount of money or expertise will prevent 100% of bugs. Get used to bugs, learn to prioritize them, and accept that they’ll cost you some money.
  2. Devices, operating systems, and browsers change…and they change often. Each change represents a potential problem for the software product, and some amount of effort must always be dedicated to keeping the software product up to date with the devices with which it must interact.
  3. Technologies become out of date or obsolete. Protocols get updated, libraries and frameworks evolve, APIs change, security patches need to be applied, and on and on. Your mobile app or web app lives within an ecosystem of other code and as that other code changes yours must change along with it.
  4. Your market changes. Even if you could build your product perfectly, your market and your customers are evolving, and that means your product has to keep pace. Your competitors are improving their products too, so forward movement is essential to stay relevant. You will need to invest heavily in your product for this reason alone.
  5. Your success will drive change. As you succeed in winning customers, their needs and the impact they have on your product will drive you to refactor code, optimize queries, build new administrative and reporting tools, etc. Your own success will demand further investment (which is a good problem to have).
  6. Technical debt must be addressed. Technical debt is an uncomfortable concept for product owners. Technical debt comes from tradeoffs developers have to make in order to meet timelines and stay within budgets. If you demand that your developers incur no technical debt, not only are you being unrealistic but you’ll never launch your product because you’ll forever be chasing the mythical perfect product. Technical debt will always exist, but you must devote some resources to keeping the amount of debt reasonable. Ignoring technical debt is also a good way to alienate your developers, by the way.

Avoiding Some of the Pain

Some of what you need to know is only going to be learned through experience. Some of what I’m telling you may not resonate until you’ve gained some mileage. But I do believe it’s possible to save you from at least some of the pain inherent in learning the hard way about the cost of creating software, and the following tips are offered with that goal in mind:

  1. Welcome the adventure. Have the humility to recognize that your expectations are probably a bit off, and welcome the experience of learning what it really takes to launch and own a software product. Like doing anything new, having an open mind and an eagerness to learn will turn your journey into an adventure rather than a frustration.
  2. Start small and conserve budget for the future. Even though you may feel like you have a perfect vision of what you want your app to do, start as small as possible, and iterate your way to that vision. If you do this, you’ll spend less money making the mistakes you will inevitably make. In other words, learn cheaply.
  3. Spend money on quality. While my previous point said to learn cheaply, the point is more about reducing the scope of your initial versions. Don’t go cheap on the quality. Cutting corners on quality increases your chances of having to start over or do a major rewrite of your software later. At least once a month we talk to a company who hired an inexperienced web developer (or an ad agency) to design and build an app for them, and the project is failing. It’s heartbreaking to have to educate them on why the money they’ve spent was nearly all wasted by an unqualified vendor.
  4. Get validation early and often. Validate your assumptions about the market as much as possible before you invest heavily in a product. Part of that market validation does require designing and building one or two versions of your product, but don’t spend hundreds of thousands of dollars trying to build the perfect product right out of the gates. Get validation first.
  5. Educate yourself about technology. You don’t have to become a developer, but if you’re going to own a software product you need to gain some technical knowledge so that you understand enough to manage those who will write the code. The more knowledge you have, the more effective they’ll be, and the more equipped you’ll be to avoid major issues.
  6. Find trusted advisors and vendors. The lowest cost vendor (or developer if you’re hiring internally) is rarely going to get you the quality you need. Avoid the siren song of anyone who tells you it can be done for significantly cheaper than what the other qualified sources are saying. Chances are they cheap vendor won’t deliver what you really need, and the technical choices they make will cause you major headaches and expense down the road. The best development firms are always going to give you a healthy dose of honesty and reality, which is often at odds with what you want to hear. If you’re tempted to ignore their candid advice, read #3 above, and then read it ten more times. You don’t want to be the firm calling us to find out if we can fix the mess you’re in. A reputable firm will also help guide you in terms of how you spend your budget so that you can balance quality with affordability.