No focus on a structured product definition and leaving it to engineers to 'figure it out' does not bode well for the end user or business itself.
This is a real experience in a FAANG company - we were developing a new product in enterprise space targeted to small enterprise IT admins who may not be highly trained or experienced.
One of tiny feature was the ability to download and self manage security certificates (upload again if any issue with security), it took literally weeks to define this feature by the engg and UX team. From tiny things like how to name the downloaded security files.. should we have the app name in the file or not - otherwise how would IT admin locate the file when they search, should file have time stamp because later we discovered that these d**n things expire, is there a 'standard' to begin with that defines the naming convention of these things, and so on..
All this because? The detailed level of spec is never written by product managers. Which I think is a very foolish culture, particularly in enterprise space.
I think there is certainly a middle ground between "engineers do all the decision making" and "engineers do none of the decision making." I'm not sure the author was advocating the former. Rather, I think the author was saying that the possibility to influence the decision making at a fundamental level is what makes the SV-like companies great.
This follows my experience. Even at a FAANG, product managers aren't going to get every detail and edge cases are going to pop-up, so requirements are going to come from a back-and-forth between product and eng throughout the process. That back-and-forth is the key, not expecting engineers to figure out all the requirements, nor from product managers either.
This actually just sounds like a successful example of agile design...
A subtlety complex feature took a couple sprints to iterate on stakeholder feedback and fully define the business need. The story doesn't seem that bad to me.
In this particular example, the engineer and designer had very little incentive to make it bulletproof (as there was no check), and there was no guarantee that the decision taken were not wrong (ex. not complying to Security Standard XYZ.NNN)
There was no "stakeholder" feedback as there is seldom an owner for these kind of decisions. If PM is the 'stakeholder' then these folks would have asked her "why are you not defining this?"
Do you believe the product managers would have defined the spec both faster and equally correctly in all the details, if they'd done it in advance before getting the engineers involved? (My guess from experience of comparable situations would be no, but keen to hear alternative perspectives)
This is a real experience in a FAANG company - we were developing a new product in enterprise space targeted to small enterprise IT admins who may not be highly trained or experienced.
One of tiny feature was the ability to download and self manage security certificates (upload again if any issue with security), it took literally weeks to define this feature by the engg and UX team. From tiny things like how to name the downloaded security files.. should we have the app name in the file or not - otherwise how would IT admin locate the file when they search, should file have time stamp because later we discovered that these d**n things expire, is there a 'standard' to begin with that defines the naming convention of these things, and so on..
All this because? The detailed level of spec is never written by product managers. Which I think is a very foolish culture, particularly in enterprise space.