One of the most important things that I’ve learned when it comes to building technology products, especially at the super early-stage, is the reality that designing a real MVP (Minimum Viable Product) is incredibly difficult to do.

I’ve already talked about this once or twice on this blog before…

The challenge of keeping things MVP-ish is real and they mostly stem from these two issues / challenges:

  1. The availability of robust frameworks and APIs make it far too easy to (accidentally) scale a simple experiment based on a simple hypothesis into more than just a simple MVP.
  2. It is psychologically difficult to minimize, constrain, and limit our “vision” of what could be with what should be, especially with so many existing examples to compare to (and the availability of great tooling – see #1).

Practice, a shit-ton of discipline, and a hyper-judicious pragmatic framework are necessary to stay trim, stay lean, and to execute the smallest technological experiment possible.

And having an exceptionally-focused cofounder / partner / team is also a very useful and practical counterweight to keep one from moving beyond what is absolutely, fundamentally necessary.

Consequently, in my own practice, I’ve started to internalize a particular mantra that I haven’t really heard before… maybe I’ll coin the term and see if anyone challenges me on it… 😅

The term is “Features as Apps” and it is the philosophy and practice of building single-serve apps to see if real users will, in fact, use that particular “feature” that might exist in the much larger, future-state application.

I’ll give you an example…

After we had built a small-yet-growing community @ The Bitcoin Pub we began to hear from our users that they wished “this” and “that” existed within the forum itself. Some examples were:

  • Charting tools for technical analysis for cryptocurrency
  • More communication tools (e.g. real-time chat)
  • Notification systems for pricing data
  • Deeper integration with news sources
  • Calculators and conversion tools
  • Buying / Selling of cryptocurrencies
  • And many, many more…

Instead of spending a significant time building additional features within the larger framework of software we decided to deploy “Features as Apps” into the wild, putting together much smaller apps and websites to validate if these requests were real and true.

As a result, we built things like CoinPuffs and CryptoYum (soon to be released) and even experimented on the “Features” themselves, essentially, Features of Features as Apps.

A great example is CoinPuffs where we recently added a small site off of the main site that allows users to create and establish email alerts for cryptocurrency pricing:

You can easily create a new email alert via the button and then manage them in a simple backend interface:

The question, of course, is whether folks would actually use it (or not). If they do, then, we can roll this feature into the much larger application layer of either CoinPuffs or even The Bitcoin Pub.

There’s not a lot of risk associated with creating these super-small, single-serve apps that serve as features for much bigger software projects. It just takes time and a serious commitment to testing one’s hypothesis over a given amount of time.

If it works out well then you’ve created more goodwill with your customers, deeper lock-in, and hopefully a high return on investment.

I like this model and it allows us to experiment with high-velocity too which, in turn, creates a lot of momentum. These things, of course, are our greatest strengths and it is our greatest asset as a early-stage startup.


Also published on Medium.