The third part of the diagram we started from is the “technical” sphere of Product Management. This is the place where Product Managers tend to struggle the most.
The ones who come from an engineering background struggle not to over-specify how things should be build. The solution is to be as hands-off as possible. If you’re an engineer transitioning into Product Management, draw yourself a hard line. The Product Manager defines what is being built; the engineer gets to define how to architect it.
The ones who do not come from engineering struggle with how to get respect from their engineering team and effectively understand technical limitations. This solution is more complex.
Here are three simple ways PMs can start to play into this process:
1) Work with the same tools that engineers use. Stay away from dictating a solution that “works for you” instead of one that works for the 10+ engineers you may be cooperating with. If the team is all set up to use bugs in Github issues, make a Github account and figure out how to use Github issues. If you’re needed to test early builds before they’re on a device, figure out how to get the simulator. Don’t be afraid to ask for help.
2) Figure out how to make simple changes yourself. If you find yourself constantly needing to ask for changes that seem simple (e.g., marketing wants to update copy on that landing page again), figure out how to do that yourself. This is particularly effective at smaller companies.
3) Ask good technical questions. The most important piece of building technical knowledge and respect within a company is to ask good questions. If something is hard and you don’t understand why, ask. If something you thought would be hard is easy, ask why there too. The best thing you can do is to ask questions that will help you build better intuition for understanding the technical limitations of your product.
Share with friends