MVP Case Study: Maerker.nu - Part I

A Minimal Viable Product (MVP) is the smallest working version of a product that will provide value to the customer or user.

These case studies follow my thoughts through the development of MVPs, from idea to implementation.


The Pitch #

There are several scout associations in Denmark (DDS, DGP, KFUM), and each of these have their own badges. There are groups within these associations that make and sell their own badges. For example, there is no association-backed badge for staying in a sleeping bag for 24 hours, but Rungstedspejderne, DDS made a custom one.

There is no central place to overview and find possible badges. Maerker.nu is going to be that place.

There is no monetary motivation for this project[1]. I see it as a kata in product development: an attempt at building a product to see how it goes, to learn from doing, without the risks usually involved. I am working full-time, while running this project on the side, so I find zero-profit acceptable. The economic goal will be for Maerker.nu to be economically self-sustaining (the income cancelling out server and domain costs).

Finding the MVP #

That’s great! We now have a fairly simple (albeit abstract) idea of a project. However, it is far from concrete enough to be a minimal viable product.

Finding Inspiration in Tiny Products #

Amy Hoy and Alex Hillman over at 30x500 have made it their living to teach people how to bootstrap their business, and they sure have some interesting ideas.

Amy and Alex tell you that you shouldn’t start with an idea, but with research of an area. I am cheating a bit here, as I know the market very well and I am scratching my own itch. The research has not been done specifically for this case, but over several years as a scout: I know it’s hard to find possible badges; I know people are buying badges, association-backed or not; and I know that there are people who use very inefficient channels (Facebook and bank transfers) to sell their badges. I could help them sell their custom badges more efficiently!

You should build a Tiny Product first, Amy and Alex argue. Tiny Product sounds a lot like Minimal Viable Product, but there are some key differences: Building an MVP means looking for the smallest amount of functionality required to provide value. Building a Tiny Product sometimes means looking elsewhere, to build trust with your targeted community, and to make money from Day One. A Tiny Product can be a different product targeted at the same audience as your main product.

A Tiny Product could, for example be an ebook, a tutorial, or a bit of help in some other way. Tiny Products are supposed to come at a price, but as we are not interested in monetization, we are basically looking to drop ebombs, bombs of knowledge, on our audience, to build trust.

… back to our product #

In order for a platform like Maerker.nu to succeed, we will definitely need the trust of the community. Getting only early-adopters is simply not viable. A critical mass of badges on the platform is a necessity for success. A Tiny Product sounds great!

This realization makes us look in an entirely different direction: let’s build a newsletter about badges. We can contact some of the independent badge-makers and get their story. We can tell stories of people taking the badges (ie. spending 24 hours in a sleeping bag). We can get them to share the link to our newsletter. That should give us at least a bit of an audience.

Our MVP has ended up being a Tiny Product. This newsletter will solve much the same problems as the originally pitched platform at a lower cost, but also less efficiently. It will provide us with an audience when the full-fledged, more expensive, more efficient platform launches.


Read more #

Amy Hoy’s blog Unicornfree is an absolutely fantastic resource for thinking about creating products.

Notes #

[1] Monetization is not desired — which is good! The market for badges in Denmark is so small that it would be impossible to earn the cost of work.

 
1
Kudos
 
1
Kudos

Now read this

System Personalities

In Software Is Never Finished and Code Can Always Be Improved I mentioned that you get to know systems better as they grow: You get to know a system as you are building it, and, in the process of doing so, realize what fits and what... Continue →