A lot has been written about lean startup methodology, minimum viable products, and quick iterations in general. There’s a lot of focus on speed, quickness, agility, and making sure that you’re launching as soon as the minimum has been met. That’s all very well and good. In a web environment where the cost to iterate and fail is so low, this is sound advice. Taken at face value though, it is too easy to blindly follow the “move fast and break things” mantra and to use it as an excuse to deliver a subpar product.

“Who cares if the product is not fully baked,” you say. “That’s exactly the point! The point is to get the product in our customer’s hands, gather data, and iterate. I know we don’t have X, Y, Z features today but that’s precisely why we need to get our product out there! Without customer feedback, how will we know if X, Y, and Z are even valuable? Better to let customers teach us what they want.”

You’re a startup, trying to create a new market — there isn’t an apples to apples comparison to what you’re trying to do. You’ve done your customer interviews, your market research, and you’re starting to have a pretty good idea of what your customers want and how certain features will fit into the overall product to fulfill this need. So obviously, the next thing to do is to prototype as fast as possible and get this in front of them, right?

This is exactly what we thought when we were raising our Series A.

Lessons from a failed MVP

Ryan, our co-founder and CEO, was using SeedInvest to execute our own Series A. As a platform built to help entrepreneurs fundraise, we got to experience first-hand our customers’ journey. As in any fundraise, there were a lot of moving pieces. To keep track of all the investors he was talking to, Ryan was using a combination of Excel, Outlook, and Evernote; it seemed overly complicated and highly inefficient. There had to be a better way. “We should solve it,” we thought, “and then provide this tool for entrepreneurs on our platform. That’d be awesome!”

Our plan was to create a feature we called the “Pipeline”. In the Pipeline, Ryan would be able to add investors he was talking to into the tool and be able to add notes for himself. He would also be able to move investors across different stages of the investment process. This would be integrated with the rest of our platform. If an investor expressed interest on SeedInvest, they would automatically be added to the Pipeline. If an investor invested, the Pipeline would automatically move the investor into the “Invested” state and seamlessly update relevant metrics.

We had the different stages an investor can go through on the side of the page, while listing all the investors in a particular stage on the main part of the page. We realized early on that there would be a lot of investors at the very top of the funnel, so we thought it would be good to have the stages stick on the side and as you scrolled down, you could drag and drop the investor to the desired new stage.

But then we thought that drag and drop would take a lot of time and effort to build if we were to build a robust version of it, so we cut it.

We mocked up the tool, figured out with Ryan how he wanted it to work, and iterated on it until we all agreed this is the tool we should build. Soon afterwards, the prototype was built and Ryan excitedly began using it.

After two days (ok, maybe a little longer), Ryan stopped.

What went wrong?

In theory we had created an MVP:

• Theoretically, all the necessary features were there.
• Theoretically, all the features worked as they were designed.
• Theoretically, this set of features all worked together to solve the problem that Ryan was having.

But in reality:

• The bare minimum features were there but were overly cumbersome to use.
• The bare minimum features all worked together as they were designed but the UX was clunky.
• The bare minimum features together did not deliver delight.

Lesson 1: “You only get one chance to make a first impression”

This overused cliché is overused because it is true. Word of mouth is driven by a user’s first impression of the product.

Lesson 2: “The whole should be greater than the sum of its parts”

The different pieces need to work well together — otherwise, there’s no additional value in bringing them together. Each distinct element must work better together than apart, like well-balanced flavors complementing each other in a dish.

Ultimate Lesson: “V is for Viable”

The key lesson that we learned from the failure of the Pipeline product was that for us to actually have a MVP, we needed “V” the most. For a product to be viable, the utility the user derives must exceed the pain involved, i.e.:

Viable product = (utility derived + reliability + usability + delight) — (utility of existing option + reliability of existing option + usability of existing option + emotional value + functional switching costs + emotional switching costs) > 0

The “M” in MVP should operate on the “V”, i.e. the “M” should stand for the minimum utility that your product must create for your user BEFORE you launch the product. The “M” in MVP is the gatekeeper of whether to launch a product or not, not an excuse to launch before you are ready.

How to strike the balance between minimum and viable

Part of it is experience. You could simply hire an experienced product manager and hope that they get it right. Here is the approach that I’ve taken instead.

The key to making the right tradeoffs and determining which features to cut is thinking about what the customer wants. In a startup, it’s often the case that the engineer and the PM is the same person. Because of this, one can easily end up simply minimizing engineering time instead of carefully and consciously minimizing customer utility.

Here’s what a typical thought process may look like and how you can easily end up optimizing for the wrong thing:

First, I figure out what product to develop. Then I break the product down into its individual features and start estimating the time it will take to build. Inevitably, this is going to be much longer than the time we have. I have to find a way to simplify. Next, I tend to think of how much a feature would “cost” in terms of engineering time, how that would affect the product, and whether it should be cut. Simplifying is always good right? By simplifying and cutting features, I have focused the product, trimming the time to market. Ergo a better MVP!

Notice how the customer was never even mentioned in this initial trade-off decision. I have just committed a fallacy where I equated minimizing time to market with strategically minimizing utility generated, while the two are obviously not equal.

Instead of focusing on engineering cost, I should have considered:

• What the customer does not care about,
• What the customer might be okay with removing, and
• What critical elements must be present for the product to delight the customer and to outweigh the pain of switching.
• Having just the list of critical elements is necessary but not sufficient.

Recall lesson #2, where we realized that the elements must work in concert with each other and meld into one holistic product. When the disparate elements start fading into a single experience and your UX starts feeling cohesive, that you are on the right track.

By figuring out the correct MVP and having a delightful and uncompromising UX, you finally give yourself a decent chance of making a good first impression.

The version of Pipeline that we used for our Series A is now, thankfully dead, but we are still iterating on it internally. As we build new features for our product, we are now applying what we learned from our past mistakes. Many of the tactical things that we learned about what works and does not work when laying out an investment funnel are fortunately applicable to other features we that are currently building as well. For example, we are not cutting drag and drop this time and taking more design cues from the tools that we use internally on a daily basis. While it is taking us longer to finish, the initial testing of the new UX seems to suggest it will enjoy greater success when launched.