Most companies operate on a "double square model": have an idea, build it, then get the next idea. This linear process lacks the divergent and convergent thinking of the Double Diamond, leading to poor product outcomes and features solving non-existent problems.
Service design connects software interfaces with the "world of atoms"—the messy, real-world human actions and operational tasks required to deliver a service, such as employees queuing for government forms to enable a feature.
The common B2B goal of a "consumer-grade" simple interface is misguided. Complex business processes require powerful tools. The designer's job is not to hide this complexity but to make it understandable and controllable for the user.
Stakeholders often demand dashboards to feel "data-driven." However, these are rarely designed with a clear user purpose, resulting in a collection of impressive-looking data that is ultimately unactionable for the end-user who needs to make decisions.
The belief that 100% self-service is infinitely scalable is a myth. A purely automated system is limited by its pre-designed exception handling. Adding one human touchpoint dramatically increases scalability by efficiently managing the long tail of user exceptions.
Instead of fighting product managers for ownership of vertical product domains, designers can gain more influence by focusing on the end-to-end experience. They should identify and fix the unowned "seams" between silos where decisions are being neglected by default.
Standard empathy maps are insufficient for complex systems. To truly understand a user's role, add two crucial sections to their persona: "Inputs" (what they depend on to do their work) and "Outputs" (who depends on their work), revealing critical process dependencies.
When executives push broad, substance-less ideas like "add AI" or "users want personalization," it's often a setup. If the project fails, the idea is deemed great while the team's execution is blamed, despite the original directive being meaningless or misguided.
Frameworks like Agile and Scrum focus on adapting to changing requirements but completely ignore their genesis. They operate as if requirements simply "appear fully formed," neglecting the most important part of product work: designing the problem and generating valid ideas.
When a stakeholder proposes a specific feature (a "form factor"), don't debate it directly. Instead, "ladder up" the conversation by asking a series of "why" questions to uncover the user behavior, desired outcome, and ultimately, the root problem being solved.
The word "prototype" is dangerously ambiguous, meaning different things to different roles. To avoid confusion, stop using the term. Instead, start by articulating the specific decision you need to make, then determine the cheapest artifact needed to inform it.
Allowing every PM to conduct their own research seems faster but is dangerous. Without standardized methodology and central synthesis, teams return with conflicting "research-informed" results, creating a "kaleidoscope of multiverses" that breaks any shared understanding of the customer.
Using LLMs for "synthetic user" research is a shortcut to mediocrity. These models provide generic, probabilistic responses available to all competitors. A durable competitive moat is built on unique, hard-won insights from real people, not from commodity data.