Tag Archives: Quicken

MVP Minimum Viable Product Fails For Two Reasons

mvp minimum viable productEveryone wants to start validating the idea for their startup by creating an MVP minimum viable product. However, very few people get it right because they overcomplicate the process of picking features that go into the MVP minimum viable product.  Here are two reasons MVPs fail:

  1. You haven’t figured out how to provide a simple value proposition that differentiates your product from your competition.
  2. You haven’t identified who the early adopter for the product is.

Let’s Start With The First Reason An MVP Minimum Viable Product Fails: Value Proposition

Before you build anything you have to know what is already out there, otherwise you’re not really innovating.  I make it a point to understand why people love and hate as many of my competitors as possible.  The reason you need to do this is because potential customers are going to ask you one very basic question: “How are you different from your competitor?”  If you aren’t prepared to provide a quick response then you’ll lose the sale. Keep in mind they aren’t asking how are you better than the competition, they are only asking you how you are different.

To be different you have to work backwards. I start by knowing all the features that my competitors offer that their customers just absolutely love i.e. they will never come and try my product out unless I offer these features. Even then I’d have to do a much better job offering them than my competitors. Before moving on to what my competitors customers hate about their product, I go interview people whom I think should be using my competitors product, but aren’t.

Why do I do this?  Plain and simple: zero switching cost.  I don’t bother wooing customers that are using my competitors product.  Instead, I go after the bucket of people that either don’t know about my competitor or don’t like them.

I fixate on the needs of those who aren’t using my competitors product.

This requires having conversations with people to understand what their needs are.  From these conversations patterns of problems that users experience will emerge, the solution to those patterns is where you can start to spot the features needed in your MVP.

For example, at my first startup, Mint.com, we knew that  a number of customers of people were quite happy using Quicken, and were even willing to pay for it.  They loved Quicken so much they didn’t mind all the hours of their lives it consumed syncing accounts, categorizing transactions, and providing them analysis on their investment portfolio.

We didn’t even bother attracting those Quicken lovers.  Instead, we looked at all the people who weren’t using Quicken.  The young 20 and 30 somethings who wanted to spend less time managing their finances.

We launched a whole year after our competitors at the time: Geezeo and Wesabe. Our key differentiator was that our MVP downloaded transactions automatically from your bank and credit card accounts, and automagically categorized them.  Was it perfect?  No.  Did everyone want to sign up even though it was a free service?  No.  But did people understand our value proposition through our MVP as compared to our competitors?  Yes.  Automation was the key differentiator for us.

The Second Reason An MVP Minimum Viable Product Fails: Casting A Wide Net For Early Adopters

In August 2010, I launched an alpha version of BizeeBee my second startup.  No one except my team and myself knows how much this product tanked.  Why did it tank?  Because we cast a freakin’ huge net!  We went after all small businesses that offer services.  We built a tool that no one wanted to use.

It was a valuable lesson, and we quickly corrected our mistake by doing just one thing differently figuring out who our early adopter was.  We went after a niche inside a niche market: small independent yoga studios who weren’t using our competition.  Between September and December of 2010 we built our real MVP, with our very targeted early adopters, and launched in December with paying customers.

Our value offering was simple and targeted. Small independent studios could stop losing money on expired memberships and know how much they were making with 3 basic features adding members, recording purchases, and taking attendance. BizeeBee would handle tracking the memberships automatically.  Starting to see a theme here?

There is more that goes into making a product mainstream.

What often happens is that people conflate success with an MVP.  With an MVP you should be testing adoption, engagement, and possibly monetization depending on your user base and growth goals.  Most products including the successful ones that have grown virally had their beginnings amongst a small subset of early adopters like Facebook appealing to college students, and Groupon solving a big problem of marketing for small businesses.

People forget this and think they need to design for the mainstream from the beginning, and that’s what ultimately obfuscates the initial value proposition and throttles even eager early adopters.

Want to learn how to build an MVP minimum viable product that succeeds?

Check out our upcoming Ship It Course here.

Timeline: Mint.com – 2005

I was the second engineer, third employee at Mint.com, and lone femgineer.  Mint.com is  in the midst of being acquired by long time rival Intuit.  This was my first startup, and the past three years have been a very unique and fulfilling experience.  In the following posts I will chronicle the major events in the life of Mint.com that have led up to last Friday’s Intuit acquisition.

November 2005 – Aaron Patzer, turns 25 and starts thinking of his next big career move.  Throughout his life has been an entrepreneur, starting businesses from the precocious age of 16, but his ultimate dream is to start a company that solves problems, which improve life for everyone!  He starts looking for inspiration.  He researchs ideas and problems in the marketplace that he might try and solve; reading literature on neural and bayesian networks to create a learning machine, then skips to thinking about creating software for setting life goals called Carpe Vive.  On one fateful Sunday evening, after becoming increasingly frustrated when trying to balance his personal account with both Microsoft Money and Quicken, he things to himself, “there has got to be a better solution.”  There isnt…  And in that moment he has found his spark, he begins to think of ways he could make a similar product that saves people time and money.

December 2006 – Aaron and Poornima take a ski trip to Tahoe.  The trip is long and I-80 is jammed with snow and cars, they are stuck in the car for 8 hours!  In an effort to amuse themselves they start to think of names for Aaron’s company.  “How about Money Intelligence?”  asks Aaron.  Poornima thinks out load, “Money Intelligence… no thats too long… Money Intelligence…Mintel… how about Mint?  Mint conveys money like making a Mint.”  “Mint…I like it!” replies Aaron.  The conversation continues with how difficult it is going to be acquire a 4-letter domain name…

Aaron proceeds to spend his Christmas vacation creating an initial design for the website, and starting to research personal finance.

Enhanced by Zemanta

Performance: Part I Develop a Monitoring Scheme

Two years ago Aaron Patzer was frustrated with Quicken and Money, because setting up the service alone took over an hour. His painful experience led him to ditch both these products, and create his own product Mint.com, in hopes of delivering a faster and more useful personal financial service. Unfortunately, not everyone is a programmer, who can automate a tedious task, and not all tasks can be automated through software. Hence bad products continue to perpetuate the marketplace, and users are left waiting: in a line, for a site to download, or for a better service to come along. But sometimes their prayers are answered and a better service does come along. However, its only a matter of time till this service becomes plagued by inefficiencies. So how do we keep a web service performant? In the realm of software I believe there are three basic principles to keep a site up and running with crowd pleasing response times:

1. Develop a monitoring scheme
2. Address scalability before its too late
3. Re-write code

The first computer I ever had was a 486. While I initially believed that the thrill of just having a computer was enough, I was soon annoyed with the machine when I installed my first modem, and the damn thing would take minutes to connect. Fortunately, my dad’s frustration for it grew as well, and we soon replaced it with a Pentium I, II, III, and so on. So being a very green software engineer, I believed that a fast CPU makes life faster. However, I learned a very valuable lesson in my graduate computer architecture class at Stanford, what “Intel giveth, Gates Taketh away.” Throwing hardware to improve the performance of your machine is easy, but its expensive and only a temporary solution. And even if your company can buy a faster server it doesn’t mean that the consumer can afford to do the same!

So how does a web service stay efficient overtime? Monitoring! Specifically, monitoring features in the context of data flow. Any given feature fits into one of two categories: it either has data that will be displayed to the user, or as the user uses the feature, they generate data that must be stored. Here are the two simple flows:

a. server -> data -> user
b. server-> user -> data -> server

In flow a its important to get the data from the server to the user asap. In flow b its important to get the data from the user back to the server to process it, store it, and in some cases return the processed data back to the user. Now that we know the areas where the data will be exchanged those are the places we need to monitor.

For flow a, we need to figure out how large of a data set we are dealing with, and how long it will take to retrieve the data set from the server. Once we have the data set we need to figure out how long it takes until the user sees the complete data set.

For flow b, we might need to return data to the user once its processed which is similar to flow a, but the harder part is taking in the data from the user, and processing it quickly, and then responding to the user with the new data. Unfortunately, the round trip associated with this flow is an unavoidable evil. But, there are ways to optimize it …

Enhanced by Zemanta