5 things I wished I learned earlier about the development process
And how I PM can be successful when dealing with engineers
When I started as a PM, I made a ridiculous amount of mistakes dealing with engineering and the development process. There were 5 things that wouldโve saved me SO MANY headaches ๐
But before: like most PMs, I fell into the role. I had smart PMs around me, but they too were figuring it out as they went. We relied on common sense to deal with the engineers around us.
Hereโs what wouldโve been transformational if I learned it earlier:
[1] ๐๐๐ข๐ฅ๐จ๐ซ ๐ญ๐ก๐ ๐๐ซ๐๐ฆ๐๐ฐ๐จ๐ซ๐ค. The earlier a product stage, the less rigid you should be with the frameworks you implement. Any method or process is intended to create friction, and bring harmony among chaos. The earlier the stage, the less chaos there is. In this case friction only slows you down. Donโt go full theoretical on applying frameworks. Adjust it to the stage of the product.
[2] ๐๐จ๐ฆ๐ ๐๐๐ซ๐ข๐ฆ๐จ๐ง๐ข๐๐ฌ ๐๐ซ๐ ๐๐-๐ฆ๐๐ง๐๐๐ญ๐จ๐ซ๐ฒ. Daily standups and sprint plannings should never be optional for PMs. You might not be the person leading them (you shouldnโt actually), but your presence can help you understand the struggles, remove blockers, and rally the team.
[3] ๐๐จ๐งโ๐ญ ๐ฆ๐ข๐๐ซ๐จ๐ฆ๐๐ง๐๐ ๐, ๐ญ๐ซ๐ฎ๐ฌ๐ญ ๐ญ๐ก๐ ๐ฉ๐ซ๐จ๐๐๐ฌ๐ฌ. When you implement tools and ceremonies, let them show you the progress. Donโt breathe over your teamโs neck. That not only distracts them, but makes them hate you.
[4] ๐๐๐๐๐๐ญ๐ข๐ฏ๐ > ๐๐๐๐ข๐๐ข๐๐ง๐ญ. Itโs ok to โship lessโ in order to have the entire team participating in the product process. Engineers donโt exist just to code. Designers donโt exist just to design. Nor PMs exist only to write issues. Everyone collaborating in discovery, execution, and delivery will bring the best products into the world, even if it feels youโre โshipping lessโ.
[5] ๐๐๐ญ๐ซ๐จ๐ฌ๐ฉ๐๐๐ญ๐ข๐ง๐ ๐ข๐ฌ ๐ฆ๐๐ง๐๐๐ญ๐จ๐ซ๐ฒ ๐ซ๐๐ฌ๐๐๐ซ๐๐ก. 50% of a PMs job is improving the machine that builds the product. Retrospectives are research sessions on the customers of the machine: those building the product. Listen to them, and then iterate away. It will transform your team dynamic.
Every PM has a couple of stories tripping on one of the above. Even if you donโt follow these recommendations, youโll eventually learn them the hard way. Your team will make sure of it (as they should).