Signs You Aren't Really Building a Minimum Viable Product

With the popularization of lean startups, minimum viable products (MVPs) have recently entered into business and software lexicon. Who can argue with building more than you actually need?

Many people seem to interpret MVP as the first iteration of their product. Once they build that version, they can add more features, and users of the product will be even happier than before. Businesspeople sometimes talk about needing to build an MVP so they can launch and raise more funding.

If you are building out a half of a product as your first stab, you might as well just call it version one or iteration zero or something like that. No sense in polluting the MVP term.

In this article, I will argue that most so-called "MVPs" are not really MVPs because they are not focused on the process of learning, and as a result, wasteful. I think that there is a lot of value in not trying to build too much. This low-hanging fruit likely accounts for the proliferation of the term. But I think that a lot of the value of an MVP is testing the risky assumptions every startup has.

Definition of minimum viable product

Well, what is a minimum viable product, anyway?

A Minimum Viable Product has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Read on →

What are Some Great Posts on Debugging Tough Problems?

Even if you are not running the same technology as someone else, you can gain insight into how they solve hairy problems by reading through their summaries of strange fixes.

Today there was a great post on debugging CSRF problems in Rails. I thought it was interesting and had run into something similar but not nearly as convoluted. It was useful to see the steps that the post author took to figure out what was the root cause of the problem, tracking back to what the change in the Rails code base was that caused him to have invalid assumptions.

Read on →

Rails Raw SQL Insert -- Time Wrong

If the time is incorrect on something that you insert directly into the database when using Rails (off by several hours), try ensuring that you are using the correct modifier to get it into the right time zone. For example, instead of doing DateTime.now, try DateTime.now.utc if you are using UTC as your default timezone.

Converting ERB to Slim

I looked around and there was seemingly no easy way to convert Rails apps to use Slim instead of ERB. There was a gem out there, but it didn't seem to work for me.

The general process I used was to first convert ERB to Haml using Haml's haml2html. Next, convert Haml to Slim using haml2slim.

Convert ERB to Haml

Ensure you have Haml installed, preferably using your Gemfile if using Bundler. You can probably remove Haml when you are done with this process.

Read on →