Not everything you can build should be built

I recently had the opportunity to try a “smart cart” shopping experience at a local grocery. As a concession to the companies involved, I’m not going to name names. And frankly, the problem wasn’t the execution, it’s the product idea.

The idea is…interesting. Scan items, and use their weight to confirm items as they go into your cart. Keep a running total of the items in the cart. Check out by paying the cart.

But…it’s a “who cares?” Is it really worth it to try to use a camera to catch the customer trying to spoof a cart? Most of the time, this is just bother for people trying to shop. It certainly wasted more of my time than it saved.

Between the time that I started writing this article, and when I went back to the store, the smart cart product had failed and been withdrawn. There’s a lesson there: when products are purchased for one group, but their actual acceptance depends on others, the odds of acceptance are low.

There are many ways to think about this, but here’s how I see it. Make sure you have real user acceptance before you build it.

Remembering SoftQuad

I came to Canada to work on an innovative startup, as a programming language implementation and embedding expert. SoftQuad was a terrific play of using open standards to represent documents and sets of documents, publish them, and transform them to other formats while keeping a vendor-independent source format. (SGML, HTML, and XML).

What started out as a 6 month consulting gig ended up being a leadership position, an SDK for making new editors, the world’s first commercial web page editor (HoTMetaL)…

It was a fun time, and a great team.

https://en.wikipedia.org/wiki/SoftQuad_Software