|
|
|
|
|
by sethammons
2242 days ago
|
|
That is my takeaway: PMs and non-developers - you must think through the entire workflow. When you don't, your engineers will and will either pepper you with questions that you are not prepared for or they will decide for you. |
|
A large fraction of the time, the PM just goes "that is correct", and the spec / ticket / whatever gets updated. When the answer is not "that is correct", you do lose out on whatever work you've done since sending that message, but writing code you eventually throw away isn't the end of the world. Also "that is not correct" responses often highlight areas where either the developer misunderstood what the PM was envisioning or the PM has a misunderstanding of what the system can do or how their proposed feature interacts with something else.
For this to work, you need:
1. Some variety of asynchronous channel that the developer can push stuff into at whatever frequency they want, and that the PM periodically catches up on entirely.
2. The developer to have a working understanding of how existing systems work and the system as a whole, from the business level.
3. The flexibility to modify specifications between the initial conception and implementation.
If you have all of those things, the PM doesn't necessarily need to think through the entire workflow beforehand -- it's nice if they can do that, but you can still ship working features without that and sometimes that is the pragmatic way to do it.