This is What Product Taste Looks Like

Why good product people talk about iteration, taste, and Christopher Alexander, while novices obsess over the trappings of frameworks.

This is a companion discussion topic for the original entry at

This was a very insightful read, thanks Cedric!

It reminded me quite a lot about what one designer drilled into my head early on in my career, which I often reduce down to this mantra:

Shorten the supply chain.

In the world of design, you can understand what is valued by examining its core interaction. In this core interaction, you intentionally group things that you believe need to reside together. By grouping things, you decide what is important. Everything else grows around this core and forms a supply chain - how things get from one place to another.

If the design is too logically efficient, you end up having to cognitively “reach” just to do things that should be easy to reach for. The supply chain of concepts gets stretched way too far. Bloat creeps in. No product development framework is going to protect you from that forever.


Oh that is such a good way of thinking about it.

@kirso @mitko I hope this post helps, as I promised last week.

Also, I couldn’t resist:


Two follow-ups:

I’ve extracted a PDF of Chapter 12 of Founders at Work here. This is the chapter with Buchheit; pay attention to the sequence of iterations that he used to build Gmail (and to discover the ‘three features that matter’)! As far as I can tell, the first version was ‘search for email’, and then ‘ugh, organising email is so irritating, let’s do conversation view’, and then ‘Why do we need to delete email anyway? Let’s give everyone 1GB’.

And of course they had to build it for scale from the beginning, and they were amongst the first to use AJAX, so it was technically challenging all around. So their first version demanded more engineers than most first startups, and still they managed to push it through. Pretty cool stuff.

The second thing is a reflection post by Andy Matsuchak on the limitations of Apple’s demo process:

Worth reading.


Excellent post! You have a knack of pointing out compelling ideas out of the mainstream - thank you for that!

I am a strong advocate of iteration - it is central to the guidance I give clients on how to build any capability. I think of it in terms of the wonderful book Systemantics - A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKED

There are also parallels in the Kano Model notion of must-be (steering wheel on a car), one-dimensional (0-60 acceleration), attractive (self-driving capabilities), indifferent (type of coolant used), and reverse (too many suspension options). As you point out, knowing which is which requires experience, and what is attractive today becomes must-be as a market evolves.

I look forward to more exploration of this topic.


Very interesting post (I also enjoyed Singer’s Alexander “lecture” greatly, watched it a year ago or so).

Just a nitpick which is actually unrelated to the post itself, Hypothesis has done a lot to make property based testing in Python accessible and usable, but Haskell’s QuickCheck and Scala’s ScalaCheck predate Hypothesis by several years each, and already had great ergonomics (each in its language).


Aye, David has publicly written about how QuickCheck was the inspiration for Hypothesis. But (in his words) “it wasn’t widely used because a) it was in Haskell, and b) it was fiddly”, and by fiddly he meant that it didn’t always pick the smallest most useful counter-example of the property being violated. As I understood it, his work (and subsequent attempted PhD) was mostly about how to pick the smallest most useful counter-example.

I believe the techniques that he developed for that that later fed back into the broader noosphere (thought we’ve only talked about this in passing in most of our conversations, to be fair).

1 Like

I have only a passing experience with Quickcheck, but ScalaCheck does failure shrinking, trying to find the simplest subset that fails. I remember reading how Hypothesis does shrinking but at the moment my brain is a bit hazy (yesterday got my first Pfizer and I just broke a fever, fever always messes with my brain)



One thought that occurs to me is that taste is a feedback loop, and a feedback loop is one of the most useful things you can have in developing anything (including cognition, as Dibello might say).

Very often, the conversation about products in tech fundamentally misframes what should be thought about. Fwiw, I wrote about that here:

TLDR: products are the second thing to think about. A founder needs to be a “problem holder” first; i.e. understand the system in which a problem occurs, and where a product might solve something. You could say that’s a reformulation of JTBD. But JTBD seems tactical, still attached to the idea of a product, whereas a systems approach can zoom out more.

In a sense, a product is an afterthought that derives from seeing a slightly modified system that alleviates the problem.

“Taste” in a broadest sense is looking at the repercussions that the product has on that system. That is, it goes way beyond the UI to the purpose of it, and how the user’s life and workflow are reconfigured by it. So ideally, product ideation is a forward-simulation of a modified system.

The iterative process you described for Buchheit shows how a product idea “search for email” can be a trigger to hold an unforeseen problem, the excuse that exposes an engineer to what users experience, to live in their system. And then tackle the main constraints they feel, which leads to a product, Gmail, that is essentially “email without the dumb constraints.”


Ryan Singer has some concrete notes from a recent shaping attempt, and I think it’s worth reading because he takes special care to explicate his entire process:

You can see him grappling with unknowns at each step of the way.


I know there’s something here, but I’m struggling to really comprehend it. Can you provide an example of two to illustrate what you mean here?