When product managers, developers, and designers talk about The Weeds, they are usually talking about one of three areas:
The creative process (ideation, experimentation, exploring options)
Definition (specification, work decomposition)
Project management (coordination, project steering, and “driving”)
So, for example, a designer or developer might say something like:
I hate it when the product manager gets down into the weeds. They try to micromanage my design explorations. I enjoy thinking about these details.
A product manager might say:
I spend so much time in the weeds. Messing around with Jira. Writing tickets and specs. Running the Scrum meetings, and generally doing project management. I need more time to be more strategic and to connect with customers.
A designer or developer might say:
I’m so happy that the product manager gets into the weeds with all the different stakeholders, so we can get into the weeds with this experiment.
The fact that there are different definitions is important. Why? Sometimes The Weeds refers to things we want to get into! We want to focus, and not have people meddling and interrupting. Sometimes The Weeds is what we want to avoid so that we can focus elsewhere. Sometimes people are grateful for weed work. And sometimes people are dismissive. It is second class work. Overhead. The boring stuff.
Here’s something I see often. An organizations wants to “free up” product managers. But getting product managers out of the weeds to focus more on strategy and the “big picture” could go either way.
As a product manager, are you planning to release control over the creative process and definition? Are you empowering the team to do the creative work they are capable of doing? Are you inviting them into your work?
Or, are you leaving an engineering manager to deal with mind-numbing project management (and process) overhead. While you work on an island. Sayonara Jira.
We might visualize these two extremes like this:
Note how hat wearing in Scenario #1 is more distributed. By getting “out of the weeds” the product manager isn’t shutting people out. There is less pressure on the engineering manager. Note in Scenario #2 you have much more rigid role boundaries. The engineering manager is taking much of the burden. My guess it that they’ll crack somehow.
There are a couple lessons here.
A successful product team requires many hats. I could have added more to this diagram.
Specialization and rigid role boundaries help with some things, and hurt with others. While it might be more efficient, a team will develop a level of learned helplessness when one person hoards a particular hat. Similarly, some things like research very much benefit from diverse perspectives. Exposure helps.
Yes, we have our preferences and happy places. But great product teams spread product thinking, design thinking, and technology acumen around.
It is easy to forget (or overlook) the other hats worn by a team member. Product managers often wear the team supporter hat. Engineering managers thrust into project management might also coach, mentor, and support the team. It can be too much to juggle.
There are VAST differences between teams in terms of the “project management” required to work effectively. Some teams are drowning in process. Other teams reduce that overhead, and figure out how to distribute the burden.
Before making big org/role shifts, really focus on the source of the overhead.
I wanted to end with an observation.
In most companies, you see a natural ebb and flow. There’s a push for more collectivism and shared responsibility. And then a swing back to more specialization and boundaries. Everyone gets excited about strategy. And then there’s a swing back to getting into the weeds and craft. Developers want to be involved in discovery. And then a swing back to “you know, it would be better if the product manager and design lead focused on discovery.”
We need more high level context!! No wait, that’s not actionable.
Everyone decide. Oof. One person decides. Wait! No! Everyone decides again.
The trick then is riding that wave in the healthiest way possible.
Embrace The Weeds as something positive, not something you “get out of”. Or at a minimum, get out of one set of weeds to get into another set of weeds :)
"The trick then is riding that wave in the healthiest way possible."
This is such a great framing. After being at an org for a while I've seen these shifts at multiple levels, and I've always had a visualisation of a pendulum swinging between polar opposites destined to eventually repeat.
I love that riding a wave suggests the ability to adapt and course correct as opposed to being strapped to the front of a giant ball with no ability to influence direction or velocity.
I am a bit "bright" on the aspect of Opportunity Mapping being a one step above Systems Thinking or Strategy. You have yourself placed 2 designs(pixels+not pixels) so I do not want you to think of this as identifying opportunities aspect which I feel is much more tactical in nature. It's not also any other insight I have, but a major breakthrough types, thinking on a very bright technology area of conversational AI. Any clarity you could provide reading this.
I was instantly trying to find your article but couldn't find Opportunity Mapping in it