Why good product people talk about iteration, taste, and Christopher Alexander, while novices obsess over the trappings of frameworks.
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:
https://www.patreon.com/posts/43912546
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).
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)
Thanks.
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?
