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.

It creates more generic-looking interfaces that may perform well in numbers but fall short of appealing to our senses.

It’s easy to make data-driven design decisions, but relying on data alone ignores that some goals are difficult to measure. Data is very useful for incremental, tactical changes, but only if it’s checked and balanced by our instincts and common sense.

It became clear to the team in that moment that we cared about more than just clicks. We had other goals for this design: It needed to set expectations about what happens next, it needed to communicate quality, and we wanted it to build familiarity and trust in our brand.We could have easily measured how many customers clicked one button versus another, and used that data to pick an optimal button. But that approach would have ignored the big picture and other important goals.

Not everything that can be counted counts. Not everything that counts can be counted.Data is good at measuring things that are easy to measure. Some goals are less tangible, but that doesn’t make them less important.While you’re chasing a 2% increase in conversion rate you may be suffering a 10% decrease in brand trustworthiness. You’ve optimized for something that’s objectively measured, at the cost of goals that aren’t so easily codified.

Design instinct is a lot more than innate creative ability and cultural guesswork. It’s your wealth of experience. It’s familiarity with industry standards and best practices.

Overreliance on data to drive design decisions can be just as harmful as ignoring it. Data only tells one kind of story. But your project goals are often more complex than that. Goals can’t always be objectively measured.

Generalists can pursue broader themes, questions, and lenses which, across their interests give them a deep perspective from breadth.For example, a specialist is someone who is obsessed with chess and spends their waking hours practicing, playing, and studying.A generalist is someone who is obsessed with the idea of game-play, and has researched and gone deep on sports, childhood psychology, board games, and philosophy.

Embracing being a coordinate on the map for a point in time is about allowing yourself to be seen as something specific. Generalists can feel trapped by that but the truth is being specific, and being on the map for others is a way of being in service. If you never pin yourself down (just for a time) you miss the benefits of being connected or in service.

there are dozens of companies that remix some combination of lists, tables, charts, tasks, notes, light-weight databases, forms, and some kind of collaboration, chat or information-sharing. All of these things are unbundling and rebundling spreadsheets, email and file shares.

LinkedIn tried to take the flat, dumb address book and turn it into both structured flow and a network of sorts. But by doing that for everyone, it has the same problem as a spreadsheet, file share or email - it’s a flat, lowest-common-denominator canvas that doesn’t capture the flows that many particular professions or tasks need.

There’s clearly a point in the life of any company where you should move from the list you made in a spreadsheet to the richer tools you can make in coolproductivityapp.io. But when that tool is managing a thousand people, you might want to move it into a dedicated service. After all, even Craigslist started as an actual email list and ended up moving to a database. But then, at a certain point, if that task is specific to your company and central to what you do, you might well end up unbundling Salesforce or SAP or whatever that vertical is and go back to the beginning.

every application category is getting rebuilt as a SaaS web application, allowing continuous development, deployment, version tracking and collaboration. As Frame.io (video!) and OnShape (3D CAD!) show, there’s almost no native PC application that can’t be rebuilt on the web. In parallel, everything now has to be native to collaboration, and so the model of a binary file saved to a file share will generally go away over time

an entire generation now grew up after the web, and grew up with smartphones, and assumes without question that every part of their life can be done with a smartphone. In 1999 hiring ‘roughnecks’ in a mobile app would have sounded absurd - now it sounds absurd if you’re not. And that means that a lot of tasks will get shifted into software that were never really in software at all before.