A product design blog on interface layers, jobs-to-be-done, minimum viable products, and designing in the open.
HN links it in discussions of product design tradeoffs, such as shipping speed versus quality, where a founding designer relates to its themes.
This is something I struggle with thinking about too as the founding designer, and generally most quality-driven person, at our company. The simplified version of the spectrum as I see it is:
1. Shipping quickly with a shitty solution.
2. Shipping slightly slower with a polished solution.
3. Shipping very slowly because minor details took over.
The frustrating thing is I can generally feel the difference between #1 and #2 myself, but I'm not sure how to distinguish between #1 and #2 enough to argue my point to the rest of the team. Instead I usually have to result in vague responses about quality and reputation and such, or just go into the UI or codebase and tweak things myself.
But on the flip side, I also know that I bring up issues that, at first glance, I think are must-haves for quality, but really aren't. Instead the scope should be decreased not to include the feature at all. But my credibility each time I bring up something like that is diminished, rightfully so.
I often struggle with this when giving friends advice about their MVPs too. Everyone has gotten so wrapped up in MVPs and they equate the MVP to throwing quality out the door, but MVPs are much more about throwing away scope in my opinion. I actually think quality can actually break or break an MVP, but it's hard to convey this properly to non-design-focused founders because they might not see the difference between certain purely-aesthetically-driven decisions and the more general and…