The Power of Making the Implicit Explicit
In many startups I’ve worked in, or that friends of mine have worked in, there’s a familiar frustration: teams don’t seem to be moving fast enough toward their goals. Leadership feels the team isn’t delivering. The team feels micromanaged, overcontrolled, and frustrated by changing priorities. Trust erodes on both sides, control increases, and a vicious cycle begins.
Those are big, systemic problems. Today, I want to focus on something smaller, more controllable, and surprisingly impactful: misalignment within teams. The reason is simple. Unlike org design or incentive structures, this is something we can start improving. The macro problems I’ll save for another day 😉
Since I’ve worked with many designers (and used to be one myself), I want to zoom in on the product and design phase, before we even get to engineering. A familiar scenario goes like this: product, design, and engineering get into a weekly alignment meeting and decide on priorities. A week later, they regroup, only to realize the designer worked on something completely different from what everyone thought they had agreed on. Another week gone. No real progress. Everyone feels frustrated.
This is painful. And more often than not, it’s avoidable.
So why does this happen?
#1 Not Making the Problem Explicit
There’s a Charlie Munger quote I like:
“We’re trying to be consistently not stupid, instead of trying to be very intelligent.”
I don’t write this to say we are stupid but to remind us that the simplest and most obvious steps can sometimes be the thing that’ll fix seemingly big problems.
Oftentimes the “three legged stool” gets together to talk about the metrics, next experiments, the roadmap, etc. thinking everyone is aligned. But beneath that apparent agreement, people might be holding very different interpretations of the problem they are addressing at the moment. A PM might say something like, “Engagement is low, we probably need to fix the dashboard.” So the designer goes off and redesigns the dashboard without really knowing what problem to actually fix.
A week later, there’s a brand-new beautiful dashboard but the original problem is still there.
What’s often missing is the explicit statement of why we’re doing this, what problem we’re solving, and what hypothesis we’re actually testing. So while details are debated, the foundation remains shaky. Even short, basic documentation of goals and problems can go a long way in creating clarity.
#2 Not Confirming Priorities
There are always many valid things to work on in a product team. Meetings often surface several of them at once. But not all work is equally urgent and important right now.
Failing to confirm priorities can lead designers to optimize for the wrong thing. I’ve seen designers work on long-term vision when the team actually needed a quick fix in the current experience. The result is frustration on all sides and time that feels wasted. A simple recap of what matters most at the moment can be a lifesaver.
#3 Not Asking the Question
I’ve talked to many designers (and have been one myself) who didn’t ask the question that could have saved hours of wasted effort and energy spent on speculating why a certain metric (or goal or fill in the blank) is important. The reason is usually the same: fear of asking a “stupid” question.
We assume everyone else understands something we don’t. We don’t want to slow the meeting down. So we stay quiet and hope clarity will emerge once we start working.
In psychologically safe environments, there are no stupid questions. More often than not, the question one person is afraid to ask is exactly what others were also unsure about. If nerves get in the way, preparation helps. Writing down questions beforehand gives you time to think, and even form a point of view you can test in the meeting. I’ve used that many times, especially going into high-pressure meetings (but more on that later). Hopefully recurring team meetings are not high-pressure :)
#4 Not Communicating Before the “Reveal”
One of the best designers I’ve worked with over-communicated throughout her process. She shared early thinking in the project Slack channel, posted sketches as they evolved, and made her reasoning visible long before anything was “done.”
This made misalignment hard to miss. It also created a sense of shared ownership in the work. Adjustments happened early and other team members were able to bring in their ideas before she polished the work. As a bonus, she was also funny and pleasant to work with, which never hurts.
One of the principles for design teams I’ve come to truly find valuable is “Design is not a black box.” It gives the designer more power and makes them a more trusted member of the team whenever this is in action.
There are many things that can go wrong in tech companies. Solving problems together in uncertain, fast-changing environments is not easy. But these small techniques can be a good starting point if you’re seeing wasted work emerge early in the product development process.