Craft

Source: https://paulstamatiou.com/craft/

Highlights

Quality is all-encompassing.
• It’s accessibility so that everyone can use it.
• It’s performance and ease of use so it respects the user’s time and helps them accomplish their tasks when they need.
• It’s reliability so they can feel good about having this tool in their pocket for when they need it.
• It's durability with designs and components that can scale to withstand future needs and uses.
• It’s well-considered.
• It’s the feeling that a lot of time and care went into creating the product: that someone has already thought of you.
• Of course, it can also be a bit extra and bring delight in unexpected places and important moments. (via)

Falling into a cycle of "Ship, then iterate" is a trap. It ends up being more shiterate. Things happen and that "fast-follow" V1.1 release or V2.0 you had imagined probably won't. (via)

(via)

Quality happens throughout the entire project whether you're cognizant of it or not. It happens when identifying the customer problem to solve, designing a solution, validating it, building it, maintaining it, and even when you sunset the product. A focus on quality drives a way of working in which you dynamically either embrace constraints when you need to or challenge them when you see an opportunity. (via)

Don't rely on a future release to clean up today's mess. (via)

People hire services not just based on what they can do but how it makes them feel.
Quality has a direct relationship to that. Quality products can take your users from "I'm merely using this thing to accomplish a task" to "this is something I love using and I'm telling everyone I know about it." (via)

Culture around quality. To maintain a shared, company-wide understanding of the company's specific stance is on quality, how does quality get rewarded, celebrated and prioritized? Is there a process in place for delaying a release and having a retro when the quality bar slips? Who decides when quality has slipped? Who's accountable for addressing it? (via)

Does everything need to have the same level of quality at the company? Are there certain things that need more or less? Unclear alignment around what deserves quality amongst teams can lead to issues. (via)

Liberal use of "MVP" or "it's just an experiment". Does the team use those terms to skirt around typical quality standards and ship something subpar? Does everything worked on, even experiments, demand the same care as a more mainstream release that goes out to all users?
That's a slippery slope because it's all too easy to simply ramp up that experiment to 100% of your users if it performs well, without addressing quality issues that were neglected prior to shipping to that initial set of users. (via)

Ditch the term MVP and use SLC (Simple, Lovable, Complete). (via)

Quality is hard. (via)

I’m not saying designers, PMs and engineers should be holding up their projects for months to “get it right”. I'm saying that teams should be working in a way where everything is considered and there's a framework for identifying, discussing, and prioritizing quality-related issues (via)

Quality is a way of working. It's not something you'll get to later. (via)

It can be prioritizing more complete, well-considered chunks of functionality (goes back to the SLC concept above). (via)

Balance long-term and short-term design (via)

Close the gap between design and engineering (via)

Don't always jump to using existing patterns (via)

With the right team culture, process, tool, education, and incentives, achieving a higher level of product quality should be more attainable without dramatically impacting speed of execution. (via)