This could well be to help prevent sms pumping — where someone makes money by receiving smss to a particular set of numbers. Requiring the user to first send an sms breaks the economics that type of fraud.
I do like watching these comparisons however it reminds me of a conversation I had recently with my 10 year old.
Son: Why does the croissant cost €2.80 here while it's only €0.45 in Lidl? Who would buy that?
Me: You're not paying for the croissant, you're paying for the staff to give it to you, for the warm café, for the tables to be cleaned and for the seat to sit on.
[edit: I retract my comment that it's bad advice to not cancel holidays to work hard. I misread the comment that I replied to -- I had thought the commenter was saying don't work extra hard in your role as it's never worth it. That's not what the commenter said though. In my experience, people who produce more value in the world are more valuable and get rewarded more than those who don't.]
I think this is poor and dangerous advice for anyone who wants to get ahead in life. If you are happy to coast by and not achieve much in life, sure, don’t work hard. But if you want to be one of the few who either rise to the top in your field or to create value in the world, then don’t feel bad about wanting to work hard. People generally learn by doing and those who do a lot learn a lot.
Of course, don’t prioritize it over things that are important to you (physical health, family etc) but don’t feel it’s wrong to prioritize it above stuff isn’t important to you (eg Netflix and YouTube shorts).
Unicorn tech founder here.
Google — if you are reading, it’s stories like this and examples where you c.10x the price of products overnight like Google Maps that I would never let our team use GCP. Your reputation is losing you business here.
Thanks arnon.
This makes lots of sense for software. Did you change SKUs based on changing pricing for hardware? If so, did this confuse or annoy 3rd party logistics providers who were asked to change labelling on boxes and have different SKUs for the same product?
If the codebase is ginormous and hard to decipher then you could use the magic source control to go back in time to an early point in the codebase. It’s probably going to be easier to understand a codebase that is 3 months old vs 6 years old, so you could go and check out that version, understand it and then jump forward a few years.
This also gives you the benefit of understanding the evolution of the code and understanding why it is not just what it is.
This sounds like a problem you will face many times in the future and therefore you may benefit from finding a solution that will solve for both this request and all similar future requests.
For example, instead of writing any customised response, you could write a blog post / make a webpage that explains your approach to these types of request and then simply link to it in a reply. Then every time this comes up you can simply paste in “Thank you for your request. Please see [URL]”.
I find doing this type of thing (creating nice canned responses, creating reusable answers) nearly always pays off in the medium and long term and find that it’s much easier to put the effort into a response knowing that you’ll get long lived value from it vs it just being useful for one person.
Similarly, I often find others have done similar and if their thoughts align with mine I don’t need to write the answer myself but instead can refer to someone else’s blog post etc.
Co-founder of https://flipdish.com here (Unicorn whitelabel online ordering provider).
We felt very similar to the author in 2015 — utterly frustrated needing to enter email address, be asked for a DOB!!, create a password etc before being allowed place an order. We set out to design an app that required a minimum number of taps from opening app to placing an order. By using geo-location, using a phone number for authentication instead of email (delivery drivers are going to want a phone number), having sensible defaults (like presuming you want to order for ASAP unless you say otherwise), we build an app where people can open it for the first time, register, order and pay in under 20s.
We initially automatically logged people in silently on Android by detecting their phone number, sending a verification SMS and intercepting it in the app. This was viewed as more spooky than good UX, so we had to reverse course a little and add another manual step in that case. But other little UX niceties remained, like extrapolating the customer’s name from the name of their iPhone (chances are you phone us called “[first name]’s iPhone”) to save them typing it in.
I think it would be quite difficult to manage a production system that lets people pay with cash but not log in, as it would be so easy for a single script kiddy to take all your restaurants offline by placing fake orders over and over.
You would be amazed (or maybe you wouldn’t) at how little business owners think about UX. We get so many requests to require a DOB before being allowed placing an order so they can send birthday messages to customers.
There’s definitely value in a shared driver pool but it does not need to come hand in hand with a consumer facing marketplace. Doordash offer access to their driver pool for orders placed through any channel (Doordash Drive), Uber offers on-demand drivers in a similar way. Companies like Stuart solely offer a B2B last mile delivery service with their pool of drivers.
This isn’t new either — DPD, UPS, DHL have all offered a shared delivery network (for retail) without anyone expecting that anything that is delivered by DHL must be ordered via DHL.com.
You nailed it — the primary value of these marketplaces is the consumer facing ordering technology, not the fact that it’s a marketplace.
This is an excerpt of a recent article that explains my thinking on it a bit better.
There is little (or even negative) value for restaurants from marketplaces in this industry. In many industries marketplaces like this make sense.
Typically, they make sense when discovery is very important, when there is little repeat usage of the discovered service or when there are multiple disparate services involved.
Travel is a good example here: it makes good sense for a consumer to use a marketplace to discover a hotel and a car rental company when they book a trip to a city they’ve never been to and likely won’t go to again for a few years.
And it makes sense for a hotel to list on a marketplace as it’s impractical for them to market directly to consumers from around the world in the off chance that they will visit the city the hotel is in.
There are very different dynamics at play in hospitality. People tend to order from two or three takeaways in rotation as opposed to discovering a new one each time they order.
They also tend to order from one located physically close to them, and they usually can be efficiently marketed to by this takeaway directly, both via offline methods such as walking past the store each day, getting flyers in the door, and online via search and brand marketing.
It is also rare that a consumer needs to make multiple purchases from separate services to order their food (they don’t, for example, usually need to order a taxi to collect the food after ordering it).
The value that restaurants get from joining a marketplace is the consumer-facing online ordering technology that they get access to, but not from the fact that they are getting it from a marketplace.
There is a lot of negative value for a restaurant in joining a marketplace (i.e., it causes them harm) as they end up sending their existing customer base away to a 3rd party who is incentivised to move the consumers away from that restaurant and over to one who will pay the marketplace more for the orders.
Disclaimer: I’m cofounder of flipdish.com that provides direct ordering tech to restaurants.