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 and monthly review #1 introspection and lessons learned.
tl;dr Last week was quite social in various aspects — attending Hackers and Founders lunch, MVP clinic at Hacker Dojo, meeting with two advisors and taking a break on the weekend with some friends. There were also some productivity issues but getting out of the building and showing my MVP to four people so far has been completely worth it.
I felt I didn’t get much done last week. A lot of “social events,” if you will. Of everything I’ve done, I’d say buying a laptop stand and conducting user/usability testing with four potential users has been the most useful.
I. Hackers and Founders lunch, MVP Clinic at Hacker Dojo, talking to advisors
II. Building and shipping the MVP
III. User and usability testing: getting out of the building
IV. Productivity dips and tips
V. Social events
VI. Next week and lessons learned
You can be so bad at so many things… and as long as you stay focused on how you’re providing value to your users and customers, and you have something that is unique and valuable… you get through all that stuff.
– Mark Zuckerberg
I. HACKERS AND FOUNDERS LUNCH, MVP CLINIC AT HACKER DOJO, TALKING TO ADVISORS
Hackers and Founders lunch
In my on and off quest to search for a technical cofounder, I’ve heard a lot of good things about Hackers and Founders. They hold bi-monthly lunches — in my past experience, I RSVP’d to one in Mountain View but backed out at the last second, as it was on a Wednesday of a week when I was prepping to pitch Greylock Partners in several days on Friday. I then signed up for the next Hackers and Founders lunch held in San Francisco.
My goal in attending the lunch was to hopefully find a technical cofounder — though I know a technical cofounder wouldn’t magically fall into my lap, I wanted to build some connections. I had a couple meaningful conversations with two developers there, one who worked with an acquaintance of mine in the past and another who was also working on a food-related startup, though more so on nutrition labels and grocery stores. Since I’m working for myself now, the price for the lunch was a bit steep — $17 for everything included — and I normally try to stay at $8 or under for a meal if I go out.
At any rate, I plan to stay in touch with those two developers and overall it was a good experience. I’m just not sure I will do it again, given the cost of the lunch and cost of time not spent on working on my startup.
As part of Moz’s 7 Unlikely Recommendations for Startups & Entrepreneurs, he says to not worry too much about getting a technical cofounder:
#6 Don’t Obsess About Getting a Technical Co-Founder
There are other options. Here’s four – and I’ve seen all of these models work:
- Most obviously, you can learn the skills you need to develop early-stage software yourself.
- Using contract labor isn’t ideal, but if you pick up enough skills to maintain and make slight tweaks/upgrades yourself, it can be a reasonable substitute.
- Choose a way to attack the market/problem that isn’t wholly engineering/development-centric.
- Learn enough to be able to judge technical decisions, and lean on mentors/advisors, but hire technical folks rather than forcing yourself to get a co-founder or nothing. The co-founder bar is a high one, and sometimes you can get good talent without.
There’s nothing wrong with finding a great technical co-founder, but there’s a lot wrong with finding a mediocre one, or one who doesn’t work out long-term and creates a messy situation for the fledgling business. One bit of advice that everyone gives that I agree with is that choosing a co-founder must be like choosing a marriage partner – and its breakdown can often spell the end of the company.
As Moz mentions, don’t obsess about getting a technical cofounder. Earlier on, I was a bit worried about it — not that I immediately needed a developer to help me build Cusoy — but that it would look bad to investors and incubator/accelerator programs if I didn’t have a cofounder.
I’m not going to waste any time to try to go to networking events, even recommended ones like Hackers and Founders, to find a technical cofounder.
MVP Clinic at Hacker Dojo
Silicon Valley has numerous Meetup groups, especially for startups and entrepreneurs, as you will soon find if you try to explore all of them. Aside from Hackers and Founders, Hacker Dojo is one of the more highly recommended resources as a community and event space for “hackers,” so to speak. You probably won’t find a lot of non-technical, business types here.
One of the events last week was an MVP Clinic at Hacker Dojo with Sean Murphy, a facilitator whose business and focus is on early customers and early revenue for startups.
This was interesting, since I initially thought we were presenting our MVP’s and doing a roundtable critique of them; instead, it was more of a brown bag lunch discussion about each person’s MVP issues and discussing each person’s MVP situation with helpful suggestions and questions.
I’d say this was somewhat helpful, as I heard some repeated feedback from others, and also fielded the (somewhat irritating) question of how I was going to make money with Cusoy. I know I want to make money at some point, since I myself am going to run out of money in the near future, but I don’t want to ship an ugly product with zero value to others. My #1 focus is creating a valuable product for others that is beautiful and well-designed… well, as beautiful and well-designed as my non-designer self can make it.
Talking to advisors
I had the opportunity to chat with another advisor who’s gone through three startups of his own before now working for a well-known tech startup. It was great to get his advice, as well as keeping in touch with another advisor who works directly with restaurants.
However, I think I might slow down a little in terms of meeting with advisors at this point. Since none of them are my targeted user, their advice is limited to an extent, unless they have domain expertise. I am starting to rely more on direct user feedback and plan to install analytics to measure user actions and track metrics.
Back to what I mentioned before in listening to advice but making your own decisions, Techstars cofounder Brad Feld mentions that contradictory feedback is a good thing and that sifting through conflicting advice and messy data is an entrepreneur’s main job:
At Techstars, we view mentor whiplash as a positive attribute. We talk about it openly – all the time. I believe that if you ask five mentors the same question you’ll get seven different answers. This is especially true early in any relationship, when the mentors are just getting to know you and your company.
That’s good. That’s how business works. As an entrepreneur you get an endless stream of conflicting data on every issue. Your job is to sort the signal from the noise… As the business grows, there are more points of stimuli, more agendas, more exogenous factors, and more potential whiplash. If you don’t build your own muscle around collecting, synthesizing, dealing with, and decided what to do with all the data that is coming at you, then you are going to have massive problems as your company scales up. So learning how to do this early on your journey is very powerful.
– Brad Feld, Why Contradictory Feedback is a Good Thing
Don’t get too paralyzed by analysis. Trust in yourself and your decisions — set measurable metrics for your hypotheses and act upon them to make data-driven decisions.
II. BUILDING AND SHIPPING THE MVP
One of the problems I’ve been having is building and shipping the MVP. It’s been tough to be satisfied with what my MVP is right now — it’s usable, but not as beautiful or well-designed as I’d like it to be. As Pablo Fuentes mentioned in his fantastic article Seven dirty, gritty, real startup lessons that cost me $2 million — Reid Hoffman once said “If you are not embarrassed by the first version of your product, you’ve launched too late.”
I kept making excuses that I didn’t have enough restaurant data in there yet, and kept prolonging “building” it and refrained from reaching out to meet with users and getting out of the building for about 1-2 weeks. Yes, I cringe now at the thought of waiting that long.
I actually still don’t have all the restaurant data in there — it takes a lot of time and effort — but I had enough to be able to draw meaningful feedback and enthusiasm from users that I met with.
Done is better than perfect. Just ship it.
When you build an MVP, be sure to have some sort of hypothesis (even as simple as an if-then statement) of what you’re trying to test and discover about your users. What are the most basic minimum features you need to get the most meaningful input from users? What kind of metrics do you want to measure?
Your early adopters are passionate about your product and how it’s going to solve their problems! Don’t worry so much about having things a little broken here and there — they understand it’s very early but do expect you to listen to their feedback on things they noticed or wish existed.
I hope to “ship” a new build every week and continually reach out to users — more on reaching out to users in the next section.
Delaying “shipping” my MVP, even though unfinished, for 1-2 weeks made me feel even worse after reading Vinicus Vacanti’s The Shortcut We Took to Build Yipit in Three Days:
How to Find Out if Your Idea is Good or Bad
My main pieces of advice are:
- Build a very simple prototype for your idea and get it in front of potential users. You’ll learn more the day you talk to your first user than the months you’ve spent pontificating
- Don’t be afraid to do things manually at first like we did
- Build a landing page with screenshots that describe your future product and see if people will sign-up for your invite list. Dropbox did that before they had a product and signed-up 100K people. Clearly, they were solving a problem people had!
- Cut every feature except for the core feature. Seriously, you don’t need any of those extra features.
- 95% of startups are able to have a prototype built in less than two weeks.
- Don’t write a business plan.
It’s very likely your idea is bad. Find that out as soon as possible so you can evolve it to a better idea.
The way he and his team executed their MVP was excellent and well-documented. Unfortunately, I’m not quite sure their approach is directly compatible with my MVP.
While his main pieces of advice are on point, I somewhat disagree that a landing page is a “surefire” way of determining interest for your product. Again, back to what I mentioned of listening to advice but making your own decisions, this strategy certainly worked for Dropbox and many others, but I am not convinced it’s a universal indicator of interest.
In Ian Cackett’s 10 Things I Learned by Going It Alone, he mentions that MVP is all that matters:
Prior to getting an MVP out there and qualifying your idea, any time you spend optimising, polishing, working on non-essential features (or a pet feature that you like for the sake of it) may be wasted time, as the product may not go anywhere. Why optimise for more than 100 users if you don’t find 10? Figure out the best way to optimise when you see a growing user base. Add the paid plan when you see someone wants it, etc. All of these tasks can be on the backlog list, but they probably aren’t in the MVP.
In addition, the need to get out of the building and to show your idea off as much as possible:
When you’ve worked on something alone, there’s a tendency to avoid showing your idea off until you’ve checked that it’s “good enough”. In small teams, you feel you’ve already had some feedback by virtue of working alongside others, but when working alone you fear that you’ve somehow got it wrong and yet by checking, checking and checking again you postpone the moment when you have to show it to someone and risk that they’ll say “What’s this?!”. I’ve learned just to get it out there. Email, Tweet, share the link and ask people what they think of it. The worst that can happen is that they’ll hate it, or not reply… but even then, you learned something.
I often took a laptop demo and showed it to someone over lunch, or an iPhone demo and, best still, handed the phone to them. Get it out of your hands and into theirs! Scary, but that’s precisely what will happen with real users.
And with that, let’s talk about my experiences of user and usability testing, of getting out of the building and connecting with real users in real life.
III. USER AND USABILITY TESTING: GET OUT OF THE BUILDING
User and usability testing
I wrote user and usability testing — back at Evernote, they called it “user testing” while at RetailMeNot, they called it “usability testing.” Either way, it means to get out of the building and talk to real users in real life.
This past week I showed my MVP to four people and had in-depth conversations about it — three potential users and an advisor at Rock Health. I hope to talk to more users either this week or next week.
How did I get users? As I mentioned in my first post Week #1: Choosing an idea, validating a market need and bridging focus, I mostly used Meetup to reach out to real people who I knew had a high chance of being interested in my startup idea and be invested in its success, as it would try to solve their problems. What’s really compelling here that I thought I’d share is I completely cold-messaged over 200 users and received a solid 23% response rate so far (slightly down from 25% from before, but I’m reaching deeper into more dormant, inactive users) that involved users voluntarily emailing me due to their interest. It’s so easy to delete an email from your inbox these days, that having someone actually proactively compose a new email and email you back is a great sign and validation of interest and implication of user demand and a market need.
If you’re having trouble of thinking of ways to reach users, I highly recommend you read Jason Evanish’s 95 Ways to find your first customers for customer development or your first sale — excellent piece and resource (it also features my blog post on customer development and Cusoy 😉 — thanks Jason!).
Steve Blank and customer development
Here is a helpful little diagram on listening to your customers from Steve Blank:
Moreover, I love his Customer Development Manifesto:
A Startup Is a Temporary Organization Designed to Search for A Repeatable and Scalable Business Model
1. There Are No Facts Inside Your Building, So Get Outside
2. Pair Customer Development with Agile Development
3. Failure is an Integral Part of the Search for the Business Model
4. If You’re Afraid to Fail You’re Destined to Do So
5. Iterations and Pivots are Driven by Insight
6. Validate Your Hypotheses with Experiments
7. Success Begins with Buy-In from Investors and Co-Founders
8. No Business Plan Survives First Contact with Customers
9. Not All Startups Are Alike
10. Startup Metrics are Different from Existing Companies
11. Agree on Market Type – It Changes Everything
12. Fast, Fearless Decision-Making, Cycle Time, Speed and Tempo
13. If it’s not About Passion, You’re Dead the Day You Opened your Doors
14. Startup Titles and Functions Are Very Different from a Company’s
15. Preserve Cash While Searching. After It’s Found, Spend
16. Communicate and Share Learning
17. Startups Demand Comfort with Chaos and Uncertainty
Lesson here? Talk to your users! Get out of your building (office, home, whatever) and show your users what you’ve built so far! They’ll either love it or hate it or show enthusiasm with feedback for improvement — but seriously, they will be ecstatic that you are creating a product to solve their problems and if they reached out to you in the first place, like I mentioned above, they probably are more than willing to help out in whichever way they can.
Enjoying user and usability testing and talking with people
I’ll be the first to say that I really enjoy user testing. It’s so incredibly interesting to see someone interact with your product and puts a human face to your user. Whether it’s good or bad, it’s just absolutely fascinating to me at how much someone can get so excited and happy about certain features or even vitriolic about features they hate or things they dislike 🙂 It’s also extremely gratifying to know that you are working on a product that helps solve others’ problems and know that you’ve made a difference in their lives.
I first experienced usability testing at RetailMeNot, where we would bring people in and watch via a video conference call of a user going through either tasks or answer questions and either stumble through a product or glide through it seamlessly. With users of all backgrounds and demographics, it was quite eye-opening to see people’s tastes and preferences, their mindsets and actions that were so different than mine.
At Evernote, I was responsible for the vast majority of user testing for a number of our products and some major cross-functional features, and it was a great experience to learn more about different products, since I mostly focused on the Evernote Mac product.
So all in all, I come from a very user-oriented and user-centric background from RetailMeNot and Evernote. User/usability testing is one of my favorite aspects of product. A product manager represents the user’s voice, after all.
Meeting with these users was incredibly helpful! It was so great to get their perspectives and suggestions, especially since they asked for different things (ha) but definitely had overlapping requests and suggestions. One of them was in the restaurant business for 10+ years with parents of international chefs, so her feedback was extremely amazing. It was somewhat of an inconvenience to travel all the way to East Bay to meet with her, but her feedback was worth all of it and more.
Interesting tidbit: all of them disliked the “Cusoy” name, since most gluten free people are also soy free… hmmmmmm. I actually might consider rebranding and changing the Cusoy name, but will keep it for now.
I’m certainly glad I didn’t wait another week before I met with users and showed them my MVP. I’m actually still shocked by the generosity of people willing to help and give advice in person. Probably because no one has ever cold-messaged them before 😉 always a first time for everything, right?
All in all, it never, ever hurts to ask. What’s the worst that can happen? That they say no? No big deal. Move on.
A couple issues and lessons within user feedback that I wanted to mention:
- Shutting up and listening
- Fighting confirmation bias
Shutting up and listening
As Hayden Williams mentioned in his latest post The best way to take feedback: Keep quiet as “the seventh in a PandoDaily weekly series that chronicles the experiences of a young entrepreneur as he bootstraps his startup,” you really have to shut up and listen to your users when seeking their feedback.
During my Rock Health office hours, I really had to stop myself from interjecting the advisor’s advice and refrain myself from pointing out contradictory evidence. I nodded a lot and said, “That’s interesting.” or “Hm, okay.” or “Great point.” Sometimes, he was a little over-enthusiastic and over-analytical on some things and requested features that were not essential nor technically feasible for my bandwidth and time — to be fair, I wanted complete, unadulterated feedback — and I think overall he did point out some great UI feedback, even if he wasn’t my targeted user.
With the three other targeted users, I spent a lot of time sitting back and listening to them speak. You have to be careful to not ask leading questions or manipulate answers into what you want to hear, which I’ll talk a bit in terms of fighting confirmation bias.
On a side note, it’s sort of interesting to read the series Hayden has written for PandoDaily and his startup Treatings. There’s not much actionable advice, but it’s more of an interesting narrative week by week. I don’t have the exposure of PandoDaily’s audience, but I do hope my blog posts have been helpful and insightful for my readers so far 🙂
I do admit I wish I had a cofounder, but I think I’m doing fairly well working my butt off, myself.
Fighting confirmation bias
Teresa Torres recently wrote a piece on fighting confirmation bias in Why You Only See What You Want to See, and gave some great insights to help fight confirmation bias:
1. Make it easier for people to disagree with you.
2. Ask questions that surface contrary information.
3. Consider the opposite.
Again, I want to emphasize that at the end of the day, it is your job to be decisive and while listening to others, make your own decisions.
IV. PRODUCTIVITY DIPS AND TIPS
Carpal tunnel syndrome
Something interesting happened last week that was somewhat scary — I experienced a tingly feeling and numbness in both my hands, though it soon left my left hand and mostly centralized on my right hand (my dominant hand). I was really scared of the potential onset of carpal tunnel syndrome, which is extremely common in employees who spend a lot of time on the computer, sedentary at their desks.
It got to the point where I honestly felt relatively useless for a couple days since my hands felt so tingly, numb and weak and I could hardly concentrate on anything else. It was really disturbing and awful, let me tell you…
At Evernote and RetailMeNot (and I assume almost all tech startups out there), I was given an mStand to hold my laptop in conjunction to an adjacent external monitor. I don’t have an external monitor at home, just a laptop, so I bit the bullet and bought an iLevel to help, even though it cost $79.90, not including shipping or taxes. It took a couple days but I think I’m benefitting from it now — I no longer feel any tingly or numb feelings. I’ve also been careful to routinely stretch out my hands and arms.
Lesson here? Please take care of your ergonomic needs!
Productivity set up
So, as you know, there exist about a bajillion productivity apps out there — yes, I even worked for one of the biggest productivity apps — and I just wanted to share some of my current setup and experiences with them. I currently use Trello, Google Calendar, Evernote (obviously! BTW, I use Evernote to write blog draft posts — best thing ever) and Inbox Pause. I like Siasto’s calendar integration as well as Todoist’s self-quantification, but Trello’s Kanban board nature has been truly helpful in helping me tackle my roadmap and divide and conquer my tasks to do.
I also use an abnormal amount of post-it’s and notecards. Something about writing things down helps me to focus directly on the task at hand. I may be in a minority here, but I never use a mobile app or my phone to stay on top of things to do.
Have any good productivity tips or apps that really worked well for you? Shoot me a note!
V. SOCIAL EVENTS
Admittedly, I spent an inordinate amount of time this week doing “social events” — meeting with fellow Rice kids, both undergrads and recent alumni, at a dinner at Facebook. Also spent some time at the San Francisco Exploratorium this weekend, a place I’ve always wanted to visit.
Couple the above with Hackers and Founders lunch, MVP clinic, talking with two advisors — doesn’t really leave me much time for building my MVP, and I’m making sure to really focus and put my head down to work six days of the week and have one day off just to keep sane and reconnect with my friends.
As Stammy so eloquently put it in his piece First-Time Startup Entrepreneurs: Stop Fucking Around, his main pieces of advice:
- Your workdays are sacred.
- Get ready for ups and downs.
- Find your thing to avoid burnout.
- What’s your plan? Pick some sort of task/project management tool and use it.
- Get more feedback, more often.
- Be decisive.
- Move on if you can’t figure something out in 20 minutes.
- Respect the zone. Figure out how you work best.
I’m going to have to be better at saying “no” to things to stay productive. Also, for some reason, I work best starting in mid-afternoon to the night… I’m going to try my hardest to be a morning person. Bad habits die hard.
VI. NEXT WEEK AND LESSONS LEARNED
Next week (or more like, this week — since it’s a Tuesday and I posted a monthly review a couple days ago) will be spent tweaking my MVP based on user feedback as well as doing direct outreach to restaurants. I mentioned reaching out to restaurants before, but was a little lazy and shy and instead opted for online information that was readily and easily available.
Key lessons learned:
- Take care of your ergonomic needs. Don’t get carpal tunnel syndrome. Buy tools if you need to and have good posture.
- Don’t obsess over finding a technical cofounder.
- Stay focused. Your workdays are sacred — don’t go to tons of social or networking events. Focus on your startup.
- Build and ship your MVP, ASAP! Done is better than perfect. No one expects a masterpiece.
- Get out of the building and show off your MVP. Early user feedback is super, super, super useful!
- Shut up and listen to your users. Fight confirmation bias.
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.