<story><title>The hardest thing about engineering is requirements</title><url>https://jaybs.medium.com/the-hardest-thing-about-engineering-is-requirements-28a6a70c4db4</url></story><parent_chain><item><author>aldebran</author><text>This is one of those rare articles that points to the need of good Product Managers.&lt;p&gt;As a PM I’ve seen my fair share of “PMs are useless waste of space”.&lt;p&gt;The article doesn’t directly talk about PMs but the role of gathering AND properly unambiguously articulating them is extremely important. It happens to be the primary job of a PM.&lt;p&gt;The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okayish requirements to good ones is high. You need to take in to account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.</text></item></parent_chain><comment><author>paxys</author><text>The most dysfunctional engineering organizations I have seen are ones where product managers are embedded at the deepest levels of the team and do everything from defining requirements and handling cross team collaboration all the way to planning and running sprints, bug triage and release management.&lt;p&gt;On the other hand, the effective ones have always had way fewer product managers with a lot more individual authority, who are in charge of the overall product direction but will let the rest of the team execute it to completion.</text></comment>
<story><title>The hardest thing about engineering is requirements</title><url>https://jaybs.medium.com/the-hardest-thing-about-engineering-is-requirements-28a6a70c4db4</url></story><parent_chain><item><author>aldebran</author><text>This is one of those rare articles that points to the need of good Product Managers.&lt;p&gt;As a PM I’ve seen my fair share of “PMs are useless waste of space”.&lt;p&gt;The article doesn’t directly talk about PMs but the role of gathering AND properly unambiguously articulating them is extremely important. It happens to be the primary job of a PM.&lt;p&gt;The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okayish requirements to good ones is high. You need to take in to account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.</text></item></parent_chain><comment><author>actually_a_dog</author><text>Absolutely 100%. As a senior dev, I’m fairly decent at considering actual customer problems, business need, and the product roadmap for the near future. Start talking about the market as a whole, cultural shifts, and all that jazz, and I’m in very deep and probably reduced to treading water. I suppose that makes me an okay-ish ersatz PM, which has been good enough for me thus far. Unfortunately, the career path of a dev doesn’t seem to reward going very deep into PM type stuff, so I’m probably going to progress fairly slowly on that axis. :&amp;#x2F;</text></comment>