Wednesday, September 11, 2013

Zero To Product: How I Built My MVP

This is part 6 of a retrospective on vizipres: A product I began and worked on for a few months. 
part 1part 2part 3part 4, part 5, part 6, part 7

Stacking Up

It would take a little time before I had some results from my experiments. In the meantime, I would begin building my MVP. Before going onto how I built my MVP, I'll briefly talk a bit about the process of deciding what would go into it.

Designing The MVP

Designing MVPs is another topic which has been discussed ad nauseam; so I'll sum up, in general terms, my expectations for the MVP. 

It should:
  • Test my hypotheses
  • Deliver customer value
  • Observe customers using it and give clues to what they do & don't like
  • Allow me to take my interviews to the next level

With these goals in mind, I began to expand upon my spike by filling in the blanks of my UI ( remember in my spike, I just focused on exploring the known unknowns ) and also came up with a list of functionality:
  • View on mobile devices, edit on desktop
  • Add cards 
  • Remove cards
  • Open and close cards
  • Label cards
  • Have different card templates
  • Edit cards with text and images
  • Create different vizis
  • Share vizis publicly
  • Login with Google 

Next it was time to start coding the front end.

The Tech Stack - UI

My spike had already proved to me that I could build the UI in HTML/JS/CSS and if I went with a responsive design I could also have the same codebase work for mobile. I don't think every application should use the responsive design concept; however, for vizipres I found that the layout I chose worked very well on phones & tablets. I also found that if I used Twitter Bootstrap, I would already have built in responsive design functionality.

When I created the spike I did it all with HTML/CSS/JS and it relied very heavily on JQuery. Below is a little sample of the code I wrote. Here is the entire Javascript file.

One of the problems with this approach is that JQuery was proving to be very heavy and the Javascript I wrote worked OK for desktop, but was really slow on mobile...and it was getting bloated. I figured the problem was due to me hitting the DOM so much, keeping a lot of references to DOM objects in memory and some repainting issues.

To get around this I sniffed around and remembered AngularJS. I had tried out Angular several years before when it was just a side project of Miško Hevery. Now that I revisited it, it has matured quite a bit and now was a fully supported Google product - awesome. Below is an example some AngularJS code for vizipres:

AngualrJS's declarative style drastically reduced the side of my codebase while also making very performant - especially for mobile devices. The final line up for my UI tech is now:


  • HTML
  • Javascript
  • CSS

Supplement libraries:

The Tech Stack - Backend

For the backend, I had to research a little bit what would be the simplest solution for me. I considered rolling my own...but I wanted to get up and running fast. I also considered some solutions which handled backend for me, such as Rails and Django. Python is easy to work with and I haven't done any heavy lifting with Ruby yet, but I know a lot of people are productive with it - plus there's a lot of support for it.

That last bit is something that is important to me when I choose I tech stack. I prefer using technology that is well established, well documented and has tooling / library support. Besides being more reliable, these technologies usually have some way to get up and running fast - either with built in solutions or some 3rd party add ons. This was key, I needed to get the backend up and running ASAP. This is because backends are quickly becoming commoditized. Fast internet speeds and fast cloud computing mean that products will gain their competitive advantages through better product design. 

After some more research, I decided to go with Kinvey, a BaaS. Interestingly, I had just been working with startup which was entering the BaaS market, so I was quite familiar with the space.

Kinvey offered some great solutions - especially when using OAuth. This was great! I could use a Google login for both security / validity & customer management. Awesome.

The Tech Stack - Analytics & My One Metric That Matters

When it came to analytics and getting quantitative information about my MVP, I kept it simple. I determined that the MVP would help me determine stickiness. Even though in the beginning, many of the people using vizipres will be customers I personally signed up ( which means I could likely count on them for oral feedback), I still needed precise measurements of how they used it.

To do this, I went with adding some simple tracking to the application.  All I did was piggyback some extra calls to my database when:
  • A user creates & deletes a card
  • A user creates & deletes a vizi
  • How many vizis they shared
  • What days they sign in
At this point, I had no need to build anything fancy so I just collected it all into a NoSQL collection.


Creating a list of Nintendo games

A close up of directly editing a card with HTML markup
A close up of a lot of cards stacked up on top of each other
Another close up of editing and expanding cards 

The above screenshots show most of the MVP. I no longer have it live ( see why in the next part 7 ) so I don't have a version for anyone to try out.

In the end I was very happy with my MVP.  It did take me several weeks to finish but that was acceptable to me. Besides working on it in-between my consulting, travel and life responsibilities, I had to learn how to use Angular proficiently along with Kinvey's service. It wasn't hard, but it did take some time. 

My next step was to push it live and once again engage customers and invite them to use it; however, things started changing for me which eventually caused me to re-evaluate my commitment to visipres.

Learn all about it in part 7.