If this is your first time reading, I recommend you start with my 6-month challenge, week #1 choosing an idea and market validation, week #2 talking to others, building an MVP and focusing on value vs. growth and monetization, week #3 narrowing focus further, learning about gluten free, social shopping and eating experiments, week #4 building out my MVP, talking to advisors, learning how to pitch VC’s and pitching Greylock, monthly review #1 introspection and lessons learned and week #5 shipping my MVP, getting out of the building and staying productive.
tl;dr This week has been mostly been spent iterating on my MVP from version 1 to version 2 based upon feedback from users. It’ll be short and sweet – and since I’ve gotten some requests on what my MVP looks like, this post will include some screenshots for your viewing pleasure 🙂
Surprisingly, coding and hacking takes awhile to do! Sometimes I feel like coding is kind of like being bipolar — it’s slightly depressing and very disappointing when you accidentally break something in your code and have absolutely no idea what just happened (and it may take four hours or more of Googling to find out why, no joke); on the other hand, it’s the greatest feeling ever if and when you find out what happened and fix it. Am I right, or am I right? 🙂
Let’s first briefly revisit what a minimum viable product (MVP) is from Eric Ries himself.
First, a definition: 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.
Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.
– Eric Ries, Minimum Viable Product: a guide
I. MVP assumptions
II. MVP version 1
III. MVP version 2
IV. Some development advice and thoughts
V. Next week and lessons learned
I. MVP ASSUMPTIONS
What would I like to accomplish with my MVP?
I want the MVP to answer three questions when a user launches it:
- (to the user) Which restaurants can I eat gluten-free food? Where are they?
- (to the user) What exactly can I eat at those restaurants that is gluten free?
- (to me) Are reviews/ratings truly necessary for users to find it valuable? (ideally the app would be filled with valuable reviews, but at this stage, is static information sufficient?)
Things like filtering by cuisine type, location, price, etc. are nice but not necessary at this early stage.
Some informal questions and things I want to continually test is whether or not reviews/ratings are actually necessary for users to use it, or if just having gluten free information on restaurants and exact gluten free menu items are sufficient. Some users said it was necessary, while others said it was not as much – that even a simple list would do. But my user testing sample last week was too small to have any statistically significant answers, so I’m going to continue testing that assumption.
Some questions I’d like to test when talking to users:
- Is the information I have on each restaurant (right now only restaurants with dedicated gluten free items) adequate for users? If not, how much more information would they like (and by extension, would they be willing to pay for that information)?
- UI/UX aside, how does this rate on the scale of solving their problems? What else would they like to see?
When talking with the users last week, some were more demanding than others. Some asked for things the others did not, and vice versa. The key here is to find the overlap of features that will move the needle and satisfy most users and move your product forward.
I. MVP VERSION 1
When you click on More Information on the Zpizza featured box:
And then scroll down to see more information:
It is adequately usable, though the user experience is not as great or seamless as I would’ve liked. Certainly not the best user experience ever, but it’s OK, especially since I’m not an engineer.
There is also a ratings/review section below, which I didn’t show, since there aren’t any users currently on the app now. I’ll fill in some dummy data later, perhaps.
Good list of features:
- Clear map view of gluten free restaurants
- Featured box of selected restaurant on homepage (can scroll through)
- Search filter by drop down menu at the bottom of the page: Listing type (gluten free pizza / bakeries / restaurants / desserts, etc); All locations (Mission, Castro, Potrero Hill, Marina, Noe Valley, SOMA, etc neighborhoods in SF); Any ratings (1-5 stars)
- Search results triggered by list on the far right (unfortunately, none of the users found this)
- Review and rating system on each restaurant
Bad list of lack of features:
- No introductory blurb on what Cusoy actually is or does (all three potential users were turned off by the “Cusoy” name — I don’t think I’m going to change the name due to the “soy” inclusion, but definitely need a one liner or something explaining the purpose of Cusoy)
- Very clunky mobile UI (it’s responsive, but needed a lot of extra attention) — this is a big, high priority for me for MVP version 2
- Very clunky map – not very responsive when you try to double-click to zoom in and out
- List of search results is extremely hidden, example of terrible UI (my apologies)
- Lack of comprehensive restaurant data related to gluten free (individualized information that can only be gathered manually through direct outreach to restaurants, not just online scraping of information)
- Lack of vetted gluten free reviews and ratings (which will come once I get more users using it)
- No user management system (anyone can post comments without having to sign up for an account first)
- No way for users to submit restaurant suggestions themselves
- No way for users to give feedback to the webmaster (me)
As you can see, the “bad” outweigh the “good” — but nevertheless, it’s still a good start! And great feedback for me to work on for the next iteration.
II. MVP VERSION 2
This is what I’m currently developing:
I’ve found ways to get the map (powered by Google Maps) to be much more responsive than before, filtering is much better (in real-time, no less!), as well as search results are not obscured in the side like the previous version. Cusoy will be a free product, but I’m also going to add additional premium pricing plans to test if there’s any interest (of course, there will be premium goodies per plan).
There’s more below the fold, but I’m still developing it.
Mobile will be a huge UI/UX point for me in terms of version 2, and I want to also add that “current location” feature so you can easily see where you are first in comparison to where gluten free listings are.
This version 2 is going to be 100x better than version 1, I guarantee you.
IV. SOME DEVELOPMENT ADVICE AND THOUGHTS
So again, I am not a technical software engineer, but as you can see from above, I am doing just fine developing an MVP on my own and testing my assumptions and even directly interfacing with users and gathering valuable feedback.
Key thing here is don’t waste months trying to learn the sexy languages everyone is using: Ruby on Rails, Python, node.js etc — learn just enough to build your app.
If you can develop something on your own without needing a technical cofounder, then do it.
Honestly, I’m getting tired of getting questions about “Are you an engineer? …No” and “Who’s on your team? …It’s just me right now” — I know, they’re natural and harmless questions — but I feel like once people learn I’m non-technical and the sole founder, they automatically think I just set myself up to fail.
…Not so fast.
It’s been just over a month and — aside from interviewing 50+ users, pivoting from a broad base to just gluten free, even doing pitch practice with Greylock Partners and office hours with Rock Health — I’ve cycled through one MVP iteration and beginning my second MVP iteration, with some preliminary user testing mixed in-between.
I think that’s pretty awesome progress for a single non-technical founder, don’t you think? Sometimes I wish I had a cofounder, even just for the morale support.
And, I’ve honestly tried looking for a technical cofounder, but at this point, I just don’t think I need one, at this point. But I’m tired of constantly feeling like I have to “apologize” for not trying to go to every single Silicon Valley startup meet up out there trying to find developers.
Come on guys, you’re founding a startup. Trying to be an entrepreneur. Some things you just gotta be relentlessly resourceful and figure it out on your own. Don’t wait around for anyone else.
Get shit done.
It’s a ton of work, but it’s doable. You have to work hard.
- Ruthlessly prioritize what you want your MVP to be and what questions you want to answer and things you want to discover with your users.
- Don’t try to reinvent the wheel. If something will take a lot of time to develop, something that’s better off given to someone else for his or her expertise or something you can outsource or find in open source software, then do that. Don’t waste hours spinning your wheels. Time is money!
- Learn how to code. Codecademy is touted a lot, but I honestly don’t like them that much. Go for project-based online lessons that will teach you to build something, not just random snippets of code. Treehouse is great, so is Code School. Quora has lots of good links on particular resources (if you really want to get in the weeds about the best Ruby on Rails resources, etc), as well as Google. Google actually is your best friend, as well as Stack Overflow.
I am experimenting with using Pivotal Tracker for MVP development (using Trello as a general roadmap) and am using Sublime Text 2 as my text editor. Sorry I don’t use Vim or Emacs, to all the “true” engineers out there 😉
V. NEXT WEEK AND LESSONS LEARNED
I hope to complete MVP version 2 by the end of this week and even do a potential landing page MVP. We’ll see how this week goes!
Key lessons learned:
- Understand what your MVP is and what you’re trying to accomplish. What are you trying to discover about your users and what is your hypothesis?
- Ship your first MVP as fast as possible and get some preliminary user feedback. This will be extremely useful for next iteration.
- Make sure your MVP iterations will address user feedback. This is a given.
- Ruthlessly prioritize for MVP development.
- Don’t try to reinvent the wheel. Be relentlessly resourceful.
- Learn how to code — if you haven’t heard this a million times already 😉
P.S. I’d love to meet you on Twitter here.
And if you enjoyed this post, please consider sharing it on FB or Twitter.