Ask HN: How to do market research for product?

Having dealt with the very problem and market you’re thinking of penetrating I would actually walk away right now. Go talk to 5 engineers from POS, delivery, or QR companies. Restaurant owners will tell you whatever you need to hear. This is an exception industry, where I highly recommend talking to industry veterans over restaurant owners. This problem is a siren song to optimistic entrepreneurs and bright eyed engineers that haven’t had their hearts ripped out by one of the most hostile industries to startups.

The whole restaurant industry tech stack is built on closed APIs and POS systems that sometimes have no API. Plenty of POS and delivery services will not even consider granting API access until you have a substantial number of restaurants on your platform. Or charge you 10k-50k for a license to their sdk.

That’s just starting with access.

The next obstacle your product is going to have to deal with is a complete lack of standardization across products and platforms. Omnivore tried to solve this but ended up with a joke of a product.

Menus look easy right? Here are some of the nuances to consider. Does the menu support options or price variations? Variations are things like large medium small. Modifier groups are things like temperature, sides, etc. some POS systems support nested mods, Doordash for example let’s you have up to 7 mods in their API. Consolidating this with a POS that has no support for nested mods, will not be trivial. What about combos? Toast, and Square deliberately chose not to support combos due to the complexity but anyone coming from a Micros systems will demand combos. Are you going to support chits? If so do you have experience with esoteric kitchen printers to test kitchen and receipt printing with? Oh yeah, everyone writes their own proprietary drivers for printing shit, so good luck there. What about when restaurants have entirely different schedules for their delivery menu vs in house menu. How do you plan on handling things like deliberately out of sync holiday menus. Then you have the whole thing of access control. Some items are meant to only be orders by managers and not appear on digital menus. Are you thinking of doing enterprise? Great, you’re going to need to deal with inventory management systems too. Not only, you have to convince those players to integrate into you. These are small examples. If you try to build a universal machine for menus, you are going to have to come up with a generalized menu format that spans nearly 40 years and tens of millions of lives of code of feature creep. Then you’re going to have to deal with convincing everyone to work with you in an industry that’s main form of competitive advantage is anti-interoperability. If you crack this problem, let me know, I wanna invest.

The last thing you’re going to have to contend with is the user. Unless you are going extreme SMB (no margins). Who you sell your tech to will not be who uses your tech. This introduces a myriad of problems. Restaurants are revolving doors. The cost to retrain a new manager and not have your system ripped out by someone who hasn’t used it every 6 months is not a joke. Oh also, get ready to lose your nights and weekends to tech support.

I think so many tech people have walked into the restaurant space with a simple view of the space only to get burned. Myself included. I wish someone on the tech side had sat me down before I started one of these particular projects. The source of truth in a restaurant is whatever is in stock and whatever the manager feels like. Tech wise, it’s mostly the POS and they are extremely verticalized for a reason. Good luck! Hope this helps.

And don't ask friends or family.

Elicit feedback by starting with the premise of "How does this suck right now?"

Our goal is to help people discover, test and validate startup ideas. We believe that a powerful free-text search engine is the best way to achieve this.

At this time, we focus on helping people find companies via their product and service offerings and not so much on 'who they are' (i.e. company characteristics, investors etc..). This is a fundamental difference to those platforms you mention.

In your particular case, you have identified a problem (restaurant owners finding it difficult to keep their online menu's up-to-date).

Is the problem real? How did you find out? Talking to a few restaurant owners (who are keen to discuss) is the starting point. This will also give you insights into other adjacent problems (eg. why should I have to update my menu on my internal database and web portal?).

Is the problem worth solving? How often the restaurant owners need it? Is it important enough that they will pay for it? Do you believe you need to bill for it, or give it out for free to build the base for a future paying product?

As pointed out in the comments, go-to-market is really important. In your particular case, you have the opportunity for self-service acquisition, or via affiliates, or via partnership with Uber Eats, Yelp etc. to simplify on-boarding for restaurants. Go-to-market becomes a deal breaker as soon as you have a good product-market-fit.

First, forget about whatever thing you're planning on building. It's almost certainly the wrong thing. Second, get a job at a restaurant that deals with delivery apps. Third, observe restaurant owners and think about how you might sell to them. Fourth, based on your time at the restaurant, consider what product you might build to sell to them. Last, build a product.

Source: Me, having wasted years and countless thousands getting it wrong before starting to get it right.