2 ms·
I have worked in GTM/PM consultancy for some time now. This is the patterns I often observe: - Have a vague understanding of the problem - Architect an ove
by wqtz 6d ago
I have worked in GTM/PM consultancy for some time now. This is the patterns I often observe:
- Have a vague understanding of the problem
- Architect an overcomplicated solution thinking of all possible contingencies
- Pitching the overcomplicated solution to someone else
- Ask them to come up with a simple solution. Ask questions to "birth" to the solution.
- Not providing any feedback as that would mean need you to be accountable for the work
- Trying to convince them they should work out the solution because they are the expert and much smarter then you
- Taking credit for solving the problem
- leoc 6d agoGo To Market/Project Management?
- chrisvls 6d agoYes, I think this is an anti-pattern is similar to the one I often see, basically getting the order wrong like this: 1. Define the problem. 2. Gather information about the problem. This seems reasonable. "We need to know what we're trying to solve, not boil the ocean." But it is really common that the information tells us that the problem definition is slightly or really wrong. Hence the importance of gather information, then define the problem... and iterate. "First define the problem" also feels reasonable because picking the right problem requires a lot of context and experience. Some would add "taste." So in group discussions, people often suggest bad problem definitions. Others then want to get focus and traction. That impatience often results in committing too early to the problem definition.