If you enjoyed this post, share it.

If this is your first time reading, I recommend you start with my 6-month challenge and week #1 choosing an idea, validating a market need and bridging focus.

tl;dr I talked with a startup accelerator and others and plan to build a startup advisory board. Always talk to others about your idea; don’t worry about them stealing it. I received additional feedback from users and am diving deeper into their different personas, tried learning how to use API’s with a developer friend and created a learn-how-to-code schedule (later scrapped all of that), found a way to build an MVP by being resourceful, chose to focus on value versus growth and monetization and struggled with the thought of finding potential technical cofounders and overall uncertainty.

Week 2 is finished and I’m impressed I was able to hack together an MVP! All by myself. More on that later and how I went about it. However, I am more concerned with finding the exact pain point and then figuring out a revenue stream to go along with it, not to mention growth strategies (i.e., is this startup idea scalable?). AKA product-market fit. This process of finding pain points – to the pain point where people are willing to pay for your product to solve their problem – is extremely tough and a lot harder than I expected. Remember, actions speak louder than words.

I. Meeting with others to talk about your idea
II. Additional feedback from users and different personas
III. Building an MVP
IV. Value versus growth and monetization
V. Finding a technical cofounder
VI. Dealing with uncertainty and roller coaster emotions
VII. Next week and key lessons

When a startup launches, there have to be at least some users who really need what they’re making—not just people who could see themselves using it one day, but who want it urgently. Usually this initial group of users is small, for the simple reason that if there were something that large numbers of people urgently needed and that could be built with the amount of effort a startup usually puts into a version one, it would probably already exist. Which means you have to compromise on one dimension: you can either build something a large number of people want a small amount, or something a small number of people want a large amount. Choose the latter. Not all ideas of that type are good startup ideas, but nearly all good startup ideas are of that type.

– Paul Graham, How to Get Startup Ideas


Office hours with Rock Health

One of the themes I really want to hit home is knowing your audience and your target user. It’s a core aspect of meaningful communication and general life principle. This applies not only to your actual product and user base, but also when you want to look for funding and potential investors (also also applies to how I got every one of my internships and job, public speaking, negotiation, etc). Not all investors will have the background to offer you the best help, not even those from the most prestigious VC firms, nor do they all have the same investment interests. What are they looking for? What motivates them? Who do they typically fund? What are some patterns and trends from their portfolio companies? How would you need to best position yourself? How do you align yourself with their objectives? And so forth. You need to find those who will be a “good match” with you, your startup and vision. The more targeted and specific you get, the higher your chances of building a quality relationship.

Since I am very passionate about health (and Cusoy is all about improving health), I sought out Rock Health, a San Francisco-based four-month seed accelerator for digital health startups. I signed up for one of their office hours and had the pleasure of speaking with them and getting additional feedback on my idea. Overall, my idea sounded promising but had several predictable gaps – I have no technical cofounder, I have yet to develop a prototype, I had ideas about monetization but no concrete business model as well as giving me tips on how to best position myself if/when I apply. It was a great meeting and I look forward to meeting with them regularly to give updates and a way to help me have accountability for my idea.

Some words of advice if/when you do something similar (and I highly encourage you to utilize office hours with an incubator/accelerator, if possible) — have something to show them, think of potential questions they might have, prepare answers for those questions (they tend to be basic due diligence questions, nothing too tricky here) and have questions for them as well. All I had at this point were some mockups and wireframes, which apparently are much more than some people prepare. You’d be surprised at how ill-prepared some people are when they go to office hours. Do not waste your time or their time — nothing has to be perfect, but have something to show, especially if you’re non-technical. If not wireframes, a product spec or requirements. Something that’s more visual or explanatory than three or five sentences of what you want your product to do. Also, I obviously had anticipated the business model questions and had several ideas to bounce off the advisor and came away with some good leads and additional ways to look at it. Bottom line: the more you put in, the more feedback you’ll get out of it.

Building a startup advisory board

Over the past year and a half or so in my many informational interviews with people in business development and product management, I’ve built up a decent network of connections in the tech/startup world in both SF and NYC. I’ve refrained from reaching out and asking for help until recently, since I want to first test the waters and do all the steps required before I have anything of value to ask and offer potential advisors. One of my goals this week will be constructing an advisory board for my startup as I strongly need the motivation, feedback and accountability of others – not just random others either, but a small and carefully composed group. Your advisory board should not contain “cronies” who will probably have little more value than a mirror.

Some key qualities to look for when constructing your startup advisory board (also can apply to your personal advisory board):

  • Experience in areas where you are weak
  • Opposite quadrant of personality chart
  • Do business with same target market, but offer different service/product
  • Sell the same thing as you do, but to a different market

Of course, the above are very simple, basic guidelines. It is up to you as well on how exactly you would like to convene your advisory board and receive feedback from them. This topic alone can merit several blog posts on best practices, so I highly recommend you consult Google as a great resource if you’d like to delve deeper.

Don’t worry about people stealing your idea

I always laugh a little in my head when I hear stories of people shoving NDA’s in your face and waiting for you to sign it before they are willing to talk about their idea. Oh, the classic topic of people afraid of others stealing their startup ideas.

First of all, if you have a “great” startup idea, chances are someone is already working on it or it already exists and you have competition. If you get scared stiff at the first instance of a competitor, you shouldn’t be an entrepreneur at all. You should always assume competition. Second of all, really? Where would they even begin? You think talking to someone is really going to inspire them to throw everything aside, magically ESP all of the work you’ve done so far and create a killer app and sell it for a billion dollars? Fat chance. If you’ve been following along, and if you’re in the same situation yourself, you’ll know rather quickly creating a startup is no walk in the park. (At the same time, I don’t recommend giving away all of your secrets — give away just enough to receive meaningful feedback!). Bottom line – the benefits of getting feedback greatly outweigh the cons and chance of someone stealing your idea.

I was just reading an interview from Refinery29 about Alexa von Tobel (founder and CEO of LearnVest) the other day and this quote really resonated with me: “If you know what it takes to start a company, you’ll never start it.”

Take a second for that sentence to sink in and digest its truth.

It’s so true, isn’t it? This isn’t The Social Network. Life isn’t like a movie. Startups are hard. 99% of startups fail, anyways. Moreover, most initial ideas you start out with will iterate based on feedback and probably won’t end up being the thing you started out with… But you already knew that, right?

One of the most compelling blog posts on this topic of people stealing your ideas comes from Jason Baptiste, the CEO of Onswipe:

They cannot steal your long-term vision.
They cannot steal your domain expertise.
They cannot steal your market failure driven pivots.
They cannot steal your talent (at this point).
They cannot steal your analytical insights.
They cannot steal your plans for generating revenue.
They cannot steal your passion for great service.
They cannot steal your passion to make this idea a reality.
They cannot steal your luck.

Be open with your ideas. I suggest sharing your ideas in a blog post to solicit feedback. It worked well for me. They will change by the time they become real businesses. Don’t worry about someone stealing the idea, worry about the things they cannot steal.

– Jason Baptiste, They Will Steal Your Idea, They Cannot Steal What Really Matters

Chris Dixon also has an excellent post on soliciting feedback on your startup idea from others: Developing new startup ideas – highly recommended read.

Always be talking to users and getting feedback

I know I mentioned that I stopped soliciting feedback from users last week because I was getting repeated feedback. Bad idea. I am starting to try to solicit feedback every single day. More on that in the next section. Also, I am planning to chat with two professional nutritionists this week who have gluten free expertise to get their feedback as well.


As of today, I have messaged about 100 potential users from Meetup and received a 25% response rate, which is pretty solid. It’s been very interesting getting different feedback from them, some requesting and mentioning things others have not and things I never even began to think about, while other times there were phrases and requests that kept popping up and were oft-repeated. The challenge here is separating the signal from the noise, and really focusing on things that will make a difference in an app, solve a pain point, which will hopefully lead to monetization and growth afterwards.

Developing personas

One of the key steps in doing user feedback and customer research is developing different personas:

Personas are archetypal representations of audience segments, or user types, which describe user characteristics that lead to different collections of needs and behaviors. We build up each archetype where the characteristics of users overlap.

– Steve Baty, User Research for Personas and Other Audience Models

My initial personas were the four different category types: 1) vegetarians/vegans, 2) gluten free (or gluten intolerant, celiac disease, etc), 3) Paleo and 4) food allergies. It would then siphon down to people who use smartphone apps, go out to eat regularly and then live in the San Francisco Bay Area.

Vegetarians/vegans perspective and consequent removal from user base

Something interesting I’ve found while doing user research and feedback is that vegetarians/vegans see themselves differently than gluten free and Paleo. Disclaimer: I am not a vegetarian/vegan myself and to be quite honest, can never imagine myself to be one (I love chicken too much!). I got the lowest response rate from vegetarians/vegans and noted how they saw their lifestyle choice as liberating and against animal cruelty, not one of “dietary needs” or “dietary restriction.” Interesting choice of language that I did not find at all with the gluten free and Paleo crowd.

Moreover, it increasingly seemed like vegetarian/vegans are much more “mainstream” and “established” in the food/diet space as opposed to gluten-free and Paleo (both very recent “trends”), making it much more difficult for me to break in and deliver value in a new way. Restaurants have embraced vegetarian/vegan options to such a large scale now. And I mean, it’s really not that hard to be a vegetarian or vegan — you obviously know what to look for and it’s really easy and clear. But gluten free? Or Paleo? A lot harder (more so for gluten free). But the key point here is that I honestly cannot relate to vegetarians/vegans but had thought to include them initially, simply to just fit the overall “different dietary needs” archetype, but given some initial feedback — ultimately decided to not target them after all.

Mish mash of dietary types

At the same time, I also found there are many people overlapping dietary needs — a mishmash of sorts, if you will. One person would be Paleo and gluten free but no dairy, while another would be vegan and gluten free but no soy. It sounds counterintuitive, and maybe it’s selectively biased in my sample, but there didn’t seem to be many people who were just gluten free (but not Paleo or not dairy free or not soy free, etc). I myself am Paleo and dairy free.

Struggle with expertise in gluten free versus Paleo

One of the hard things I’m struggling with is narrowing down my user base even further, to either gluten free or Paleo. Paleo is a lot easier to deal with, it’s a much more flexible and versatile spectrum and one that I could easily gather the data myself (through brute force, even) — but it’s a lifestyle choice and not so much a pain point for people, in my opinion. Whereas for gluten free, it’s somewhat the opposite — it’s a huge pain point that users would probably gladly pay for (who wants to get sick and possibly die? no one!), but it’s also really hard to do myself since I’m not gluten free myself, nor have celiac disease or am gluten intolerant, and I’m not a healthcare professional or nutritionist who could provide expertise on that.

I am still thinking about how to best approach this and in the process will continue soliciting user feedback.


Building an MVP was the overarching goal of week 2. Thankfully, I was able to scrap one together myself.

Let’s start with the definition of what a minimum viable prototype (MVP) means, according to Eric Ries of Lean Startup (bolded text for emphasis):

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.

Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense. As I talked about in a previous interview, IMVU’s original MVP took us six months to bring to market. That was a pretty big improvement over a previous company, where we spent almost five years before launching. Yet in another situations we spent two weeks building a particular feature that absolutely nobody wanted. In retrospect, two weeks was way too long. We could have found out that nobody wanted the product a lot sooner. At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was.

– Eric Ries, Minimum Viable Product: a guide

Though I had interviewed a lot of potential users about their thoughts and feedback on my app idea, I had included features that unfortunately were not feasible to make in an MVP.

I had a clear idea of what tools I could use, user interaction flows, mockups, wireframes, etc. The basic MVP app is fairly simple and straightforward to build (or so I thought) — it’s basically a huge database of nutritional and dietary information, and the main interaction is the user filtering by criteria and retrieving that information from the database. Simple, right? The hardest part is getting that data, and making sure it is accurate for the user.

I met with a developer friend in Palo Alto for a couple hours earlier this week to try to figure out how to utilize an API (which shall go unnamed) to help fill in that database of data so I didn’t have to reinvent the wheel and build it from scratch, so to speak. Well, it was tough, especially given some of the Github documentation was greatly lacking and at some points, just wrong. I had been oscillating between learning Ruby on Rails or Node.js, and decided on Ruby on Rails — even though Node.js client had “better” documentation for this particular API — simply because it is the recommended backend for an app that I want to build for web and mobile web (JS slows down in mobile web, it seems).

After that night, I left somewhat dejected that we hadn’t really gotten any progress done; I immediately restarted my Treehouse account and quickly made a schedule this week to relearn how to make a simple Ruby on Rails microblogging app.

…I actually didn’t learn any Ruby on Rails this week. Why?

I was frustrated and agitated that it might take me three weeks to simply “properly” learn the basics of Ruby on Rails, let alone months to attempt to master it, and who knows if an MVP could materialize from that. I thought, there’s GOT to be a better way! Can I make this even simpler? What other resources can I use? Does it have to use this API? Yes! Well, actually… no. Do users have to be able to change their password? No, they don’t. (But it’d be nice!) Is X feature and Y feature really going to make a difference? And so forth — taking a good, hard look at my tentative spec/requirements and heavily focusing on the bare essentials and prioritizing them over every “wish list” feature that wouldn’t move the needle and make a difference.

By pure stroke of luck, I was able to find some tools and apps to scrap together an MVP and showed it to some friends. They were pretty impressed with how realistic looking it was and even asked what stack I used (ha!) until I told them, actually… it just took me a couple hours to put together 😉 Felt like cheating, almost.

You gotta be relentlessly resourceful.

Don’t get me wrong, I do encourage and recommend teaching yourself how to code, especially if you’re not technical. It helps you build your product and build rapport with your developers. However, if you’re able to find something quicker and faster to hack something together — don’t waste months learning to code when you could be iterating and getting feedback on what exactly you should build. I will also continue trying to learn Ruby on Rails on the side.

I won’t post a link to my MVP here because while the technical framework is essentially in place, the data and content are not there yet (I’m still working on fleshing them out).

Kevin Dewalt’s piece Your MVP is About Discovery – Not Product offers great insights on how building your MVP will help you discover your business, customers, commitment and passion


I have been struggling a lot with what to focus on when thinking about my idea – do I want to solve a big problem for a small set of users? How do I even scale this product, if it works? More importantly, how will I make money from this?

Nobody seems to want to make money any more. I remember just a decade ago in 2003 when we all laughed at how dumb people in the 90′s were talking about the race to “capture as many eyeballs as possible” before your competition. You would figure out how to monetize later.

I say ring the freaking cash register. I have said so for years.

Not everybody agrees and in some cases they’re right so you have to decide for yourself.

– Mark Suster, Why You Need to Ring the Freaking Cash Register

Reading that made me much more cognizant of figuring out ways to make money.

Then, I read Paul Graham’s essay again with the quote I put above:

When a startup launches, there have to be at least some users who really need what they’re making—not just people who could see themselves using it one day, but who want it urgently. Usually this initial group of users is small, for the simple reason that if there were something that large numbers of people urgently needed and that could be built with the amount of effort a startup usually puts into a version one, it would probably already exist. Which means you have to compromise on one dimension: you can either build something a large number of people want a small amount, or something a small number of people want a large amount. Choose the latter. Not all ideas of that type are good startup ideas, but nearly all good startup ideas are of that type.

– Paul Graham, How to Get Startup Ideas

And then, coupled with the sage advice below (bolded text for emphasis):

When you first start out the only thing that matters is finding a cohort of customers who truly value what you offer. Growth alone means next to nothing.

In their seminal books on entrepreneurship, Steve Blank and Eric Ries explained how this works: You must first develop and test a value hypothesis and then move on to your growth hypothesis. A value hypothesis is an attempt to articulate the key assumption that underlies why a customer is likely to use your product. A growth hypothesis represents your best thinking about how you can scale the number of customers attracted to your product or service.

Identifying a compelling value hypothesis is what I call finding product/market fit. A value hypothesis addresses both the features and business model required to entice a customer to buy your product. Companies often go through many iterations before they find product/market fit, if they ever do.

Steve and Eric recommend that entrepreneurs first nail their value hypothesis before tackling their growth hypothesis. After all, if the dogs don’t want to eat the dog food then what good is attracting a lot of dogs? You can waste a lot of money if you don’t follow their prescribed order, because you’ll spend more money on growth than determining value.

It might be easier to pursue your growth hypothesis first, but that doesn’t mean it’s the right thing to do. I have seen many entrepreneurs spend a lot of money on attracting traffic to their site or app only to see low conversion rates. Hope springs eternal, and many in this situation believe they have found product/market fit because they have traffic. But traffic without conversion doesn’t mean much. In fact, growth may seduce the entrepreneurs into believing they have achieved their value proposition when they actually haven’t.

– Andy Rachleff, Why You Should Find Product-Market Fit Before Sniffing Around For Venture Money

…I’m now content to simply focus on finding product-market fit for my very niche set of users before worrying about growth and monetization. But I do have some ideas about monetization, but they aren’t the core focus of my thinking now.

However, there are some nuances involved here. Depending on your runway and how urgently you need to make money, you may want to adjust your approach, idea etc. I don’t really know and don’t have an excellent answer for this — I have enough runway to last me 6-8 months but of course don’t want to delay making money if I can make it sooner. The challenge here is making money at the right time and at that intersection of offering a solution so valuable to a user that he or she will gladly pay for it… after you have achieved product-market fit.


tl;dr I don’t have a great answer to this dilemma. I used to attend startup tech talks and events — now I think they’re (mostly) a giant waste of time. All I know is I need to find a technical cofounder sooner or later — not only for best chances when applying to an incubator or accelerator, but also just for the sake of the best possible chances for this startup to succeed.

I have a confession to make — I actually had a technical cofounder several months ago, but he was more of a UI/UX designer who got lured away by Google contract work; he wasn’t really committed to working on the idea either, but wanted to partner with me given my background, passion and due diligence on this idea — and I was genuinely flattered when he asked to work with me! Haha. And another iOS developer friend who graciously offered to help code an iOS app together over a weekend, provided I gave him high-quality mockups and assets. Except, I was distracted by my job then and wasn’t able to deliver those to him when he still had the time to help me.

And now I’m working with me, myself and I.

…Working by yourself is hard work! What else is new, right? I already wrote about my struggles with focus — it’s hard to jam pack double the normal workload on yourself each day when, if you had a cofounder, you could lift some of the load off your shoulders. At this point, I am not overly concerned with finding a technical cofounder — don’t get me wrong, that doesn’t mean I don’t think it’s important (far from it!), but again — prioritization, MVP and product/market fit. If you’re able to hack together a MVP by yourself, don’t waste your time going to startup tech talks and events in the hopes of luring a developer to work with you.

Earlier this year, I was that young, bright-eyed and bushy-tailed whippersnapper who wanted to attend at least five events each month (yes, I actually set monthly goals — what a nerd) to meet others who work in tech and startups, not only for natural networking but also for potential cofounders. Bad idea — and actually, I don’t go out to those events anymore, with limited exceptions when I know it’s going to be a high-quality, high-signal audience. The resounding example I can think of is this past April’s conference called How to Build Great Products co-hosted by Greylock Partners and Samsung — a conference hosted by product managers, for other product managers. It was the highest quality conference I’ve ever been to (I’ll refrain from namedropping, but every name brand startup and tech company you can think of in the San Francisco Bay Area, and some who flew in from NYC, attended the conference) and worth the price many times over.

Back to going to events to find technical cofounders — other startup events I attended were very hit-or-miss in terms of the quality of people; in my personal experience, there were many business and non-technical types in attendance, many wannabe entrepreneurs who had no idea what startups were about and seemed to be there only wanting to cash in on the startup bandwagon. I found them to be a colossal, gigantic waste of time and have stopped attending events since. Sorry, I’m now pickier with my time and how I spend it.

Going back to one of the life principles I mentioned earlier of knowing your intended audience and target user — I thought to myself, where would the developers go? What would attract them to work with me? What are they looking for? What motivates them? It’s tough because at face value, I have nothing to offer a developer — I don’t have salary, I don’t have funding, I don’t have users… but I have found a pain point (I think), I have talked to users, I have product management and sales/marketing experience at three top pre-IPO (correction: one of them recently IPO’d!), ~$300+ million funded startups… and I have a rough MVP built by myself. Also, developers aren’t always motivated by money but can be incentivized through idealistic motives, working on interesting problems, etc — especially if they’d actually want to personally use your app and it would solve one of their problems.

Not to mention… the potential situation that if and when you do find a technical cofounder, don’t immediately jump for joy. Make sure he or she is a “good fit” for your team and startup — in terms of the technology stack and software engineering background, time commitment, work style, similar values and vision, etc. Getting a front-end developer won’t solve your problem if you really need someone to help build your back-end.

My strategy now is doing everything possible by myself that doesn’t require coding. Market research, competitive landscape, user interaction flows, mockups and wireframes, product specs, feature requirements, customer research and feedback, teaching myself how to code and so forth — but more importantly, building a usable, feasible and valuable MVP. Nothing impresses developers more than seeing you try to build something for yourself and showing an appreciation for being technical. Also, asking around and friends of friends. Quality of your network matters a lot here.

Another way you can approach it is to outsource technical work to remote developers — I don’t have enough money to do this and can’t speak from experience, but it is certainly another avenue to go about it.

If you know any iOS and/or Rails developers who might be interested in working with me, send them my way! 😉


Oh boy. One of the hardest things I’ve had to deal with is myself (self-doubt, pessimism, negativity, etc) and the overwhelming uncertainty, daily grind and rollercoaster emotions. Some days I get mildly depressed with myself, regret not working for a fast-growing company and learning from others smarter and more knowledgeable than me and think I’m stupidly crazy for doing this; then on other days I’m extremely content and happy with the way my life is now — this is really what I want to do. If I wasn’t doing this today, right now, I’d be doing it 5-7 years down the road (that’s right, Mom). Life is not a dress rehearsal. Don’t delay on your dreams. Life is too short to not do what makes you happy.

And I knew coming into this that startups are freaking hard. Turns out you need to be really, really, really mentally tough to slog it through. I’ve only finished my 2nd week and have so much to learn and do before I am satisfied with myself.

At the end of the day, what is motivating me to do this? I want to start my own company. I want to fully embrace this challenge of founding a startup head on and succeed. I want to create a beautifully designed application that will help solve my problem as well as those of others. I want to work for myself. I want to prove to myself that I can do this.

…and yet, I’m so scared of failing, for irrational reasons like I’m not competent enough or smart enough to “make this work,” even though I know there is a terribly high chance of failure generally speaking and all the odds are stacked against me. I’m so scared that I’ll have nothing to show for this at the end of the six months. I’m so scared I’m going to work towards one hypothesis, throw myself into it, and turns out users don’t want that at all — causing me to go back to square one. I’m scared I won’t learn anything at all and am bound to repeat my mistakes.

I’m so scared of uncertainty and ambiguity. I like to know what’s going to happen and plan for it. I like knowing all the answers, and not just all the questions. But uncertainty is something that is always present in startups. It’s tough to learn how to live with so much uncertainty and ambiguity. Even as a product manager, you don’t have all the information you need to make the right decisions all the time, and you have to make do with what you have and be comfortable in the face of uncertainty. I still have yet to master this — I guess it comes with experience.

One of my biggest weaknesses is that I often suffer from paralysis by analysis.

What is paralysis by analysis? Here is how Wikipedia defines it:

Analysis paralysis or paralysis of analysis is the state of over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome. A decision can be treated as over-complicated, with too many detailed options, so that a choice is never made, rather than try something and change if a major problem arises. A person might be seeking the optimal or “perfect” solution upfront, and fear making any decision which could lead to erroneous results, when on the way to a better solution.

– Wikipedia, Analysis by paralysis

Due to analysis by paralysis, I have a lack of self-confidence at times. Not because I don’t have self-confidence (given my track record, I think it speaks for itself), but sometimes when I have so much information in front of me to process, it’s hard for me to decide on any one thing and stick with it — since another part of me says, hey, this other aspect may completely negate that. Then I’m frozen in place and delay making a decision, afraid it will be the wrong one.

It’s something that I need to work on — Done is better than perfect. Just ship. (But don’t forget to ship the right product… given the information you have at the time. Don’t haphazardly throw something at users and hope it sticks. It probably won’t and you’ll just have wasted your time.)

Celebrate the little wins as well. A friend of mine was helping me think of business model scenarios and gently chided me to not be too hard on myself and reward myself for incremental, small wins.

Great advice that I’ll keep in mind.


I am proud to say I accomplished my goal of building an MVP this week by myself — something I had dreaded would take me weeks, if not months, since I am non-technical and a single cofounder (for now). I’ve also thought of potential product differentiation and monetization strategies, but still need more time to think about it and put it on the side as I focus on product-market fit first. Next week I hope to build a startup advisory board, continue talking to users and others (i.e., healthcare professionals) which hopefully will include restaurants as well, continue developing an MVP and trying to get closer to the ever elusive product-market fit.

Key lessons learned in week 2:

  • Always be talking to others about your idea and get different perspectives and feedback (VC, tech startup employees, potential users, etc). Don’t worry about people stealing your idea.
  • Build a startup advisory board for yourself.
  • Focus on a small cadre of people who your startup will solve a pain point and achieve product market fit. Don’t worry about monetization or growth yet. If the dogs won’t eat the dog food, why waste your time, money and energy on trying to attract many dogs?
  • Build an MVP that is usable, feasible and valuable. Do your best to hack something together and make sure you know what metrics to measure.
  • Finding a technical cofounder is extremely tough and something I need to tackle sooner or later.
  • Uncertainty will always be there; learn how to deal with it. Don’t forget to celebrate the little wins.

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.