4 ms·

Good stuff in here, but be cautioned that the author doesn’t mention their customers are engineers until a bit later in. Which gives a lot more leeway in allowi

Good stuff in here, but be cautioned that the author doesn’t mention their customers are engineers until a bit later in. Which gives a lot more leeway in allowing engineers to make a majority of decisions. In a more complex domain, like maybe selling private securities, collaboration isn’t slow, it helps us not get fined millions of dollars by the SEC. Personally, I also love minimalist process and likewise believe “methodology” is bullshit, but I caution you, the reader, to consider the specifics of the context you’re working in. For me, that means that almost everything goes figma first. Engineers + product work together to build a figma, which allows other parties to see what we’re building and contribute in a tangible and useful way.

ks84 2y ago
Yes exactly. The engineers as users part is important IMHO. I would also really like to see how this whole thing pans out in the long term.
tmarice 2y ago
You can still have domain experts collaborate directly with engineers instead of adding a middleman in the form of a product manager. The more I work, the more I'm convinced that product management is not truly a profession but rather a way for non-technical people to insert themselves into a profitable industry.
- deviation 2y ago
  This might make sense from a high level, but again, the devil is in the details. Realistically you do need someone (vendor or not) to translate 1000's of pages of legal jargon into actual product decisions. There's a tipping point where paying an engineer $x or $y to do that themselves (if they even have the skill to interpret it) is waste of talent.
  - Xss3 2y ago
    Your product decisions are hidden in thousands of pages of legal jargon?
    - capitalatrisk 2y ago
      I only lurk HN but seems that comments such as these are becoming commonplace now. Why the accusatory and negative tone? How does this contribute to the discussion in a meaningful way at all?
- robertlagrant 2y ago
  The point of a product manager is to make a lot of decisions that don't have a clear answer. "Should we use websockets or REST for our chat client?" - easy technical call. "Which market segment should we target with our features?" - not so technical.
  - foldr 2y ago
    There are plenty of technical decisions that don't have a clear answer (e.g. which of 1000 web frameworks should we use?), and plenty of product decisions that do. The separation between roles has nothing to do with clarity but with the (sometimes fuzzy) difference between technical decisions and product decisions.
    - robertlagrant 2y ago
      > e.g. which of 1000 web frameworks should we use? This is fuzzy, but that's because it's not a technical question! It's isomorphic to "what three blog posts on web frameworks did I last read?" (-:
      - foldr 2y ago
        You're right that decisions regarding frameworks are often made for largely arational reasons, but I'm baffled by the claim that these are not technical decisions (unless you're just joking?). If they're not, does that mean that in your model it's the PM who decides which web framework and database the team uses? In any case, even if my example were a bad example for some reason, there are definitely lots of technical decisions that are fuzzy. How could there not be?
        robertlagrant 2y ago
        Oh yes, I agree that there are technical decisions are fuzzy. I'm happy to concede that; just dashed it off too quickly.
robador 2y ago
I'm in a large corp as bridge between development and the business. What i do is minimize process on the dev side, and maximize it on the org side. On the dev side my only ask is predictability, which is hard enough already, but is so important for communication. On the org side, i overengineered process. It focusses on value, and helps to keep chaos away from the developers.
- scotty79 2y ago
  That's genius. Let the workers work and keep busybodies with busywork.
Cthulhu_ 2y ago
While the domain of e.g. private securities may be complex, this usually isn't the main problem for developers; I'd argue this article isn't about legal requirements and the like so much, but about the actual implementation thereof. In the case of a complex domain, stick to writing the requirements and don't try and invent new things or what-ifs, because those may end up causing those legal issues. That said, the reality is that a lot of developers are also expected to be domain experts and work independently, including knowing a lot of the legal requirements. More in my field, that's stuff like GDPR and A11y compliance (WCAG 2.2 level AA will be a legal requirement for most companies come 2025, see the European Accessibility Act [0]) [0] https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=5581&langId=en https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=55...
- hahahacorn 2y ago
  >I'd argue this article isn't about legal requirements and the like so much Yes, it fails to address that other businesses face additional complexity and constraints that they don't have and then broadly over-prescribed their principles. I'm genuinely curious how you're separating "legal requirements" from "implementation" (of either product, or process). When you build things, you have constraints, and you have to respect those constraints, or you built something lousy. If understanding those constraints is part of the building process, then trying to find the fastest way to incorporate those constraints into the product while minimizing time this blocks product development (and thus, velocity), seems like the obvious thing to optimize for. So I don't understand how you're trying to separate those (and to to be overly clear, I'm asking out of genuine curiosity to understand your point better).
exitb 2y ago
Most domains lie somewhere between serving engineers and doing something really complex and sensitive. It's always a nice goal for your engineers to gain significant proficiency in the product domain, so they don't have to defer all decisions to other people. It's a "cache miss" equivalent in product development process.
foldr 2y ago
> Engineers + product work together to build a figma I'm not going to tell you that what works for you doesn't work for you, but just to contribute another perspective, elaborate Figma mockups are a bit of a red flag for me. They show that a significant amount of time has been invested in a high-fidelity design of a complex UI that has never once been used do to any actual work. It's impossible to know if a UI is any good if you haven't used it in anger. A rough functional prototype might take longer to make (and, crucially, doesn't look as good in company-internal slide presentations), but it's vastly more valuable IMHO.
- hahahacorn 2y ago
  That’s a good point. The figmas we build are not high fidelity. But they’re more than wireframes. The point is to get everyone on the same page conceptually as to what is going to be built, but the details are still left as an iterative process for the engineer implementing. The point of the figma is to answer the question “what visuals will help ops, legal, and engineers be on the same page when discussing” and NOT “the button should be 48px down”. UX specific “extras” like confirmation modals, etc. are never added because that doesn’t answer the first question.

ks84 2y ago

Yes exactly. The engineers as users part is important IMHO. I would also really like to see how this whole thing pans out in the long term.

tmarice 2y ago

You can still have domain experts collaborate directly with engineers instead of adding a middleman in the form of a product manager. The more I work, the more I'm convinced that product management is not truly a profession but rather a way for non-technical people to insert themselves into a profitable industry.

deviation 2y ago
This might make sense from a high level, but again, the devil is in the details. Realistically you do need someone (vendor or not) to translate 1000's of pages of legal jargon into actual product decisions. There's a tipping point where paying an engineer $x or $y to do that themselves (if they even have the skill to interpret it) is waste of talent.
- Xss3 2y ago
  Your product decisions are hidden in thousands of pages of legal jargon?
  - capitalatrisk 2y ago
    I only lurk HN but seems that comments such as these are becoming commonplace now. Why the accusatory and negative tone? How does this contribute to the discussion in a meaningful way at all?
robertlagrant 2y ago
The point of a product manager is to make a lot of decisions that don't have a clear answer. "Should we use websockets or REST for our chat client?" - easy technical call. "Which market segment should we target with our features?" - not so technical.
- foldr 2y ago
  There are plenty of technical decisions that don't have a clear answer (e.g. which of 1000 web frameworks should we use?), and plenty of product decisions that do. The separation between roles has nothing to do with clarity but with the (sometimes fuzzy) difference between technical decisions and product decisions.
  - robertlagrant 2y ago
    > e.g. which of 1000 web frameworks should we use? This is fuzzy, but that's because it's not a technical question! It's isomorphic to "what three blog posts on web frameworks did I last read?" (-:
    - foldr 2y ago
      You're right that decisions regarding frameworks are often made for largely arational reasons, but I'm baffled by the claim that these are not technical decisions (unless you're just joking?). If they're not, does that mean that in your model it's the PM who decides which web framework and database the team uses? In any case, even if my example were a bad example for some reason, there are definitely lots of technical decisions that are fuzzy. How could there not be?
      - robertlagrant 2y ago
        Oh yes, I agree that there are technical decisions are fuzzy. I'm happy to concede that; just dashed it off too quickly.

robador 2y ago

I'm in a large corp as bridge between development and the business. What i do is minimize process on the dev side, and maximize it on the org side. On the dev side my only ask is predictability, which is hard enough already, but is so important for communication. On the org side, i overengineered process. It focusses on value, and helps to keep chaos away from the developers.

scotty79 2y ago
That's genius. Let the workers work and keep busybodies with busywork.

Cthulhu_ 2y ago

While the domain of e.g. private securities may be complex, this usually isn't the main problem for developers; I'd argue this article isn't about legal requirements and the like so much, but about the actual implementation thereof. In the case of a complex domain, stick to writing the requirements and don't try and invent new things or what-ifs, because those may end up causing those legal issues. That said, the reality is that a lot of developers are also expected to be domain experts and work independently, including knowing a lot of the legal requirements. More in my field, that's stuff like GDPR and A11y compliance (WCAG 2.2 level AA will be a legal requirement for most companies come 2025, see the European Accessibility Act [0]) [0] https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=5581&langId=en https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=55...

hahahacorn 2y ago
>I'd argue this article isn't about legal requirements and the like so much Yes, it fails to address that other businesses face additional complexity and constraints that they don't have and then broadly over-prescribed their principles. I'm genuinely curious how you're separating "legal requirements" from "implementation" (of either product, or process). When you build things, you have constraints, and you have to respect those constraints, or you built something lousy. If understanding those constraints is part of the building process, then trying to find the fastest way to incorporate those constraints into the product while minimizing time this blocks product development (and thus, velocity), seems like the obvious thing to optimize for. So I don't understand how you're trying to separate those (and to to be overly clear, I'm asking out of genuine curiosity to understand your point better).

exitb 2y ago

Most domains lie somewhere between serving engineers and doing something really complex and sensitive. It's always a nice goal for your engineers to gain significant proficiency in the product domain, so they don't have to defer all decisions to other people. It's a "cache miss" equivalent in product development process.

foldr 2y ago

> Engineers + product work together to build a figma I'm not going to tell you that what works for you doesn't work for you, but just to contribute another perspective, elaborate Figma mockups are a bit of a red flag for me. They show that a significant amount of time has been invested in a high-fidelity design of a complex UI that has never once been used do to any actual work. It's impossible to know if a UI is any good if you haven't used it in anger. A rough functional prototype might take longer to make (and, crucially, doesn't look as good in company-internal slide presentations), but it's vastly more valuable IMHO.

hahahacorn 2y ago
That’s a good point. The figmas we build are not high fidelity. But they’re more than wireframes. The point is to get everyone on the same page conceptually as to what is going to be built, but the details are still left as an iterative process for the engineer implementing. The point of the figma is to answer the question “what visuals will help ops, legal, and engineers be on the same page when discussing” and NOT “the button should be 48px down”. UX specific “extras” like confirmation modals, etc. are never added because that doesn’t answer the first question.