You need to make your case for what the problem or opportunity is—most often validated with at least directional data and/or research insights—and why your specific solution could work. You need to ensure it weaves into broader company initiatives as well as goals for your team and org. And you need a plan to get your product out there in a timely manner along with ways you'll further learn and validate your approach. An executive team won't be thrilled to hear you want to spend a year building something based solely on a hunch.

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."

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?

What does quality mean to them? How does it tie into the career ladder, promotions and prioritization frameworks? Do they focus more on execution speed over quality?

Is quality baked into the normal product development process, or is it often relegated to low priority "polish" tickets that pile up.

Do different roles (like engineering, product, design) have different motivations for getting their work done? This, again, ladders up to what the org thinks about quality.

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. No one wants a slice of cake that is just a piece of the bottom layer. You need to have a taste of each layer with each bite, including the icing. So even if it’s not your entire vision, it has all the right pieces involved. Ditch the term MVP and use SLC (Simple, Lovable, Complete).

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 so that quality is a bit less of a sisyphian task.

Does your team have the skills and incentives to identify and adequately fix those issues? Does the organization continually reinforce and celebrate work that ladders up to quality, craft and great design?

Let’s say you present 3 directions to a client: directions A, B, and C. These are our initial 3 branches. You have a client review, direction C is the winner, and so you iterate again. 3 more branches: C1, C2, and C3. Another review, another winner, another round of iterations: C2.1, C2.2, C2.3. Branch out, choose one, zoom in, branch out, repeat.

Sometimes, the design process requires us to zoom out. Let’s say you present those 3 creative directions, A, B, and C, but nothing lands. Back to the drawing board. You might keep pushing forward with branches D, E, F. Nothing lands. You’re forced to zoom out and realize that you’re not even on the right parent branch.

Sprints don’t help organize things, they’re not a useful organizing tool, and if we were all honest with each other then we’d admit they’re designed for managers who don’t trust their employees

Good teams don’t need sprints to get good work done. They don’t need to point tickets or file receipts away once something is complete. This always leads to an endless backlog of crap anyway which is also a waste of time since they too only serve managers who are scared to say “ah yes, we have listened to this complaint and we believe it’s not important.” That’s what a backlog is; a list of useless tasks that makes people feel better.