Principles for product velocity
ssoready.com
Principles for product velocity
1–10 of 138 posts
Re: Principles for product velocity
#2Good 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.
Re: Principles for product velocity
#3> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?
Also, work tends to expand to occupy alloted time. That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
So by not limiting what should be done in 60 days, they are more likely to avoid this pitfall.
Re: Principles for product velocity
#4Good 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 “…
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.
Re: Principles for product velocity
#5I really enjoyed this. I try to run my team similarly.
Where I disagree slightly is vendors. If the need filled by the vendor is well-defined and low-complexity, sure, I'll go for it. Otherwise, I'm doing it in-house nine times out of ten.
Where this starts to get tricky is when some worthy competitors emerge, utilizing your foundation to scale quicker and more effectively. Then you might wish you had hired more people earlier. But overall, I think starting from this perspective is a lot safer than the opposite.
Re: Principles for product velocity
#6Good 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.
Re: Principles for product velocity
#7These guys do security software.
You don't find out if security software is badly broken until you're attacked.
Re: Principles for product velocity
#8Good 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.
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.
Re: Principles for product velocity
#9Good 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 “…
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.
Re: Principles for product velocity
#10Good 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 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=55...