Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principles for product velocity

ssoready.com

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Principles for product velocity

#21

Post by capitalatrisk »

Xss3 wrote: post #19
deviation wrote: post #8

Earlier quoted context omitted.

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.

Your product decisions are hidden in thousands of pages of legal jargon?

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?

Re: Principles for product velocity

#22

Post by hahahacorn »

Cthulhu_ wrote: post #10
hahahacorn wrote: post #2

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 “…

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 rea…

>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).

Re: Principles for product velocity

#23

Post by robertlagrant »

tmarice wrote: post #6
hahahacorn wrote: post #2

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 “…

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.

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.

Re: Principles for product velocity

#24

Post by foldr »

hahahacorn wrote: post #2

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 “…

> 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.

Re: Principles for product velocity

#25

Post by jdsalaro »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.

At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.

Re: Principles for product velocity

#26

Post by foldr »

robertlagrant wrote: post #23
tmarice wrote: post #6

Earlier quoted context omitted.

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.

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.

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.

Re: Principles for product velocity

#27

Post by davedx »

Absolutely on point and matches my experience (20+ years in software). The hard part is not software delivery; the hard part is stopping all the unnecessary technology and process and people inexorably creeping into everything everywhere.

Re: Principles for product velocity

#28

Post by baq »

jdsalaro wrote: post #25
alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand. Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to appl…

management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one.

IOW they're trying to do their jobs (manage employees) but engineering is a high trust profession and some managers just don't have the trust (not to say that all engineers have the integrity...)

Re: Principles for product velocity

#29

Post by xiphias2 »

I love The Rise of Worse is better, and this sounds just like that:

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins.

In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementation no matter how modular / reusable code I'm trying to write.

As my velocity increases testing becomes more important as well (especially integration testing), as there are more features interacting in a small amount of code.

Re: Principles for product velocity

#30

Post by cjfd »

alentred wrote: post #20

I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…

Much of this has, I think, to do with mutuality. If person A and person B need to work together both need to change their preferred way of working to accommodate each other. In larger groups there is a problem if one person gets to decide on too much and does not have to take other people seriously.
Post reply on HN