6 ms·

> In that scenario, who is driving product requirements? The developer teams, who else? You build it, you need to know what you are building, right? I find it

• alistairSH 3y ago
  Every time I’ve worked on financial aid, HR, or financials, the PM has been an expert in those areas. I couldn’t do my job otherwise (or, I have to fill their shoes).
  • ath3nd 3y ago
    I work in the medical field which is fairly heavily regulated as well. My teams have been able to do our job without having a dedicated medical compliance expert as their PM. We just have a medical compliance team and ask them for input, but they most certainly don't tell us what to build nor drive the product direction. In short, I question the need of a PM, not the need for domain experts (law,financials,etc).
    • mike_hearn 3y ago
      If you've had good results without a PM you probably had someone who was doing that work, but under a different job title. Or the results weren't as good as you thought. Good PMs are often engineers or ex-engineers themselves. But a good PM will do a much better job than just sticking a bunch of engineers in a room and asking them to manage the product. A lot of developers really hate tasks like: - Designing UIs - Thinking through complex workflows to simplify them (unless they're developer workflows) - Writing documentation - Often also, identifying and fixing small quality issues like bad error messages - Figuring out what the customer's actually need vs what they say they need Some devs are naturally talented and capable of doing all the above, plus banging out the code too. That's great, maybe they don't need a PM or more likely maybe they will become one themselves in future. But left to their own devices a lot of dev teams will rapidly lose the plot and start producing features nobody cares about, or doing endless refactorings, or produce something that's too hard to use.
      • Feathercrown 3y ago
        I kinda like doing those things
  • marcinzm 3y ago
    Why does the domain expert have to be the PM versus someone the engineers consult directly?
    • johannes1234321 3y ago
      Why shouldn't engineers consult with a PM? Isn't that a key part of the role - to break down external requirements into engineering needs?
      • ath3nd 3y ago
        Yes! But imagine if the developers themselves could break down the external requirements into engineering needs! Or are developers grug brains that need a bigger, superior brain to simplify scary real world into simple, safe engineering needs? Or developer grug so busy, must write code, no time look at feedback form, no time think client request, need simplified instructions, must slap keyboard, clack, clack? Context: https://grugbrain.dev/ https://grugbrain.dev/
      • marcinzm 3y ago
        Breaking down requirements and being the domain expert are not the same role. Engineers can break down requirements perfectly well given they have context of the code and systems and possibilities. A even bigger advantage is that there are multiple developers on team which means they can review each other's work. Just like a lone dev tends to go off the rails eventually so does a lone PM and almost all PMs are lone if they're the sole domain expert.
• lol768 3y ago
  > The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place. Absolutely this. And the engineering teams should have visibility of customer support and other functions to understand common pain points, causes of churn and opportunities for additional revenue-generating functionality. That doesn't mean answering run-of-the-mill questions or doing refunds all day, but it does mean talking to prospects, looking at escalated problems and keeping an eye on the wider industry.
  • bingemaker 3y ago
    This. Most of the developer teams are nothing but feature factories. There will be a point where what developers want to build and what the product needs will diverge. It is very hard to strike a balance IMO.
    • growse 3y ago
      This tension is why it's a good idea to align everyone's incentives. Bonus the product team on reliability (as well as velocity), and the ops/sre team on feature velocity (as well as reliability), and it'll balance itself out.
      • ath3nd 3y ago
        Who is bonusing who? I think some people simply can't get rid of the idea that there has to be some external paternalistic figure that looks over developers' shoulder and guides the poor hapless saps and their incentives. Do they give candy to the good boys/girls and coal to the bad ones? You might be thinking of Santa. The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product. Management types insisting to compartmentalize incentives is them trying to have an excuse for their own existence. We should all drag ourselves kicking and screaming to the reality that we can do much more with much less management layers. Even big companies, which are bloated beyond saving, are waking up to that fact. PMs are the first to go, just look at what Meta, a notoriously inefficient company is doing to their non technical PMs. Think for a second why nobody has had the idea of letting an engineer be a 'Marketing Project Manager' of the marketing team and be calling the shots what campaigns to run, what marketing materials to produce, and make marketers estimate with poker cards how many of their leads will turn to a sale. Sounds stupid, right? Yet this is exactly what you want us to accept the other way around. Not gonna happen. There is no excuse to have non engineers embedded in and actually calling the shots on behalf of an engineering team with the patronizing though that the engineers can't decide for themselves what to build and how to prioritize it.
• growse 3y ago
  It seems like you're arguing that the dev teams should spend some of their time managing the product. In other words, it's a 'hat' to be worn occasionally by some team members. Nothing wrong with that, except what typically happens at larger scales is that some people enjoy wearing the hat more than others, then the team realises that it's better if those people spend most of their time doing product management, and then they tweak their job titles ever so slighty.... > How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies? In my (highly regulated) industry, always? They'd be bad at their jobs if they didn't have this. Edit actually, I walk that last bit back slightly. They don't need to be experts in those things, but they need to know enough about the broad landscape to understand what tradeoffs need to be made and set direction. Similar to a CEO not needing to be an expert in product, marketing, engineering, finance etc. to be effective, but they do need to have enough knowledge to know how to balance competing requirements across these things.
• tashoecraft 3y ago
  Sounds like you haven’t had a good PM or a job that supports having one. Saying it’s often some new grad is like saying there’s no point having an on shore dev team because the devs are often fresh out of university. If you continually hire terribly you’re going to have a bad result. A PM should become the subject matter expert in the product they are developing. They should be able to field questions on most every part of it, and be able to build a roadmap of features. Communicate with all teams associated with it. Having the programmers plan all features is a recipe for disaster if your product isn’t designed for developers. It’s like saying you don’t need a qa team because the developers tested it.
  • dickersnoodle 3y ago
    >It’s like saying you don’t need a qa team because the developers tested it. Strangely enough, that's happening at a few companies (run by Amazon refugees IIRC) where they think that making devs do QA and removing QA/QE roles will speed delivery. I'm in one of those companies now, and I'm waiting for the #FAFO loop to happen.
    • pdimitar 3y ago
      That really depends on what does QA entail at these companies. If it's just increasing test coverage and adding integration tests then yes, devs should be doing it. If it's just clicking UIs all day long then obviously a QA should do it. Or have an UAT environment where a few more enthusiastic customers are willing to test and report bugs.
      • dickersnoodle 3y ago
        It's more than that. In an org with an architecture of silo'd teams that all work on their own independent federated services, you'll need people to test out all of the variations on content, timing and error handling for the software as a whole. Depending on automated testing to handle all of that, in a live environment, is a fool's errand no matter how much it makes the development cycle seem to go faster.
  • 3y ago
• tristor 3y ago
  > How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies? > Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time. I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else. I have long advocated that PMs /must/ be technical to be successful and, maybe more importantly, useful. If you’re in an industry that is compliance encumbered, you should absolutely expect that your PMs are experts or at least professionally competent in the compliance standards you need to meet, or at minimum intellectually and contextually capable of getting there rapidly. Hiring someone just out of college to be a PM is a huge red flag that your organization doesn’t understand the role of a PM, and that your upper level management is likely incompetent also. Without significant prior experience in some related facet to the product, it is not possible to be successful as a PM, and I wouldn’t expect a new grad to be able to do much more than push papers. PMs should always be former practitioners, if possible, but at least technically competent at minimum.
  • pdimitar 3y ago
    I agree with your comment and upvoted it, though this part: > I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else Makes me wonder if you're saying that these cases are the exception. In my career they have sadly been the rule. Not 100% literally, i.e. my PMs have never been 22 years old, but they were, 99% of the time, grossly incompetent. And yes they were a management / hiring failure, absolutely, but it seemed that nobody cared... :(
• satvikpendem 3y ago
  Devs generally don't want to talk to the experts, they want to build. Talking means more meetings, which takes away from building. Ironic, as without knowing what to build, they can build nothing.
  • ath3nd 3y ago
    Ah, yes, avoid meetings with experts so you have to wait until a non expert who talked to the experts tells you what to build! Pesky, asocial developers, avoiding talk at any cost! It's a well established fact developers love building things so much and hate wasting their time with useless meetings! The hero PM saves the developers so much thinking by being brave and talking with the scary outsiders. The PM's selfless bravery gives the developers the time and space so they can focus on the really important part of building. The really important part of building is, of course, being in a 2 hour meeting where the PM is repeating (badly) what the experts said, and making you play card games where you pick some numbers, very much unlike a nursing home for the old playing bingo. I love your take! You totally treats engineers as responsible adults who have multiple skills and abilities besides coding, and not at all like autistic children that would flip out as soon as somebody touches their crayons.
    • aprdm 3y ago
      The assertiveness of your replies implies to me that you never worked in big companies
    • satvikpendem 3y ago
      > It's a fact developers love building things so much and not wasting their time with useless meetings! Correct. Most engineers dislike meetings, so much that they complain that they don't get enough focus time in the day and are constantly interrupted. > like autistic children that would flip out as soon as somebody touches their crayons No one said this, you're arguing against a strawman. But even still, how many devs do you know that willingly want to talk to customers?
• dagw 3y ago
  How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies? Maybe not an expert, but literally every project I've been involved with where those things are relevant, the PM knew more than most of us, knew who to talk to, and was responsible to make sure we did the right thing. It is pretty much what half the role was about. They were often pretty senior people with long experience working in a relevant field.
• aprdm 3y ago
  The PMs I’ve worked with have had many decades of experience in the area of their product and knew much more than our dev team about the business domain