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

31–40 of 138 posts

Re: Principles for product velocity

#31

Post by pflenker »

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…

Agile and Scrum was great when it was introduced bottom-up and then accepted top-down.

"We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together.

The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely. The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database). Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.

The top-down recognition was useful - not only did projects go noticeably better, managers could also boast that they, too, are now doing this new Agile thing! And they didn't even need to do something!

That was all before Scrum of Scrums, SAFe, LeSS, you name it.

As you said, we've come full circle in many aspects. It's ironic.

Re: Principles for product velocity

#32

Post by irjustin »

> Pay vendors to do it

Generally I agree with this for 90% of startups. If it's a solved problem, you should not be doing it. Don't reinvent wheels just pick wheels off the street and use them. Then an axel then a frame, etc etc until you've got something that moves because it's literally held together by zipties.

The key is that a number of people are willing to pay you for the moving ziptie vehicle because it solves their particular problem - whatever it is.

Most recently I tried Cursor app. it helps me be a faster coder and uses something i already know - i really like it (except that they shit all over the hotkey bindings).

Re: Principles for product velocity

#33

Post by robertlagrant »

foldr wrote: post #26
robertlagrant wrote: post #23

Earlier quoted context omitted.

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.

> 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?" (-:

Re: Principles for product velocity

#34

Post by f1shy »

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…

What is BS is a fixed, one size fits all methodology. As fast as you write it down and proclaim „this is out procces”, it starts to be BS.

Re: Principles for product velocity

#35

Post by foldr »

robertlagrant wrote: post #33
foldr wrote: post #26

Earlier quoted context omitted.

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.

> 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?" (-:

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?

Re: Principles for product velocity

#36

Post by hahahacorn »

foldr wrote: post #24
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…

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.

Re: Principles for product velocity

#37

Post by Quimoniz »

xiphias2 wrote: post #29

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

This really hinges on 'velocity':

> .. simple implementation won for velocity ..

How do you specifically define velocity in this context?

(I am asking because I tend to favor speedy velocity in quick iterations; which is another story, than say velocity for change...)

Kind regards

Re: Principles for product velocity

#38

Post by scotty79 »

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…

> So it sounds like we've come full circle.

I think the issue with Agile was that it was named. After something is named and codified it becomes a thing and everyone can mangle the thing to fit their desires until it becomes antithesis of the initial intents.

This guy doesn't name or codify his approach. So it's fine, there are only intents, there's barely anything to mangle.

Re: Principles for product velocity

#39

Post by bantunes »

ChrisMarshallNY wrote: post #14

Basically, I agree … but … In my experience, to successfully reduce process, you need to have really good people . That usually means a heterogeneous mix of skilled, smart, experienced, and creative people that work well as a team, and teams like that, don’t come easily. People (and teams) are really important, and I believe it’s a mistake to think of them as some kind of interchangeable modules (as is the norm in th…

That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced.

But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell to end users.

Post reply on HN