Hacker News new | ask | show | jobs
by gopalv 94 days ago
> Increased speed only gets us where we want to be sooner if we are also heading in the right direction.

This is a real problem when the "direction" == "good feedback" from a customer standpoint.

Before we had a product person for every ~20 people generating code and now we're all product people, the machines are writing the code (not all of it, but enough of it that I will -1 a ~4000 line PR and ask someone to start over, instead of digging out of the hole in the same PR).

Feedback takes time on the system by real users to come back to the product team.

You need a PID like smoothing curve over your feature changes.

Like you said, Speed isn't velocity.

Specifically if you have a decent experiment framework to keep this disclosure progressive in the customer base, going the wrong direction isn't a huge penalty as it used to be.

I liked the PostHog newsletter about the "Hidden dangers of shipping fast", I can't find a good direct link to it.

3 comments

Thanks! Great link.
Don't wait for feedback from "real users", become a user!

This tayloristic idea (which has now reincarnated in "design thinking") that you can observe someone doing a job and then decide better than them what they need is ridiculous and should die.

Good products are built by the people who use the thing themselves. Doesn't mean though that choosing good features (product design and engineering) isn't a skill in itself.

Too often that isn't possible. There is a lot of domain knowledge in making a widget there is a lot of domain knowledge in doing a job. when e complex job needs a complex widget often there isn't enough overlap to be experts in both.

sure 'everyone' drives so you can be a domain expert in cars. However not everyone can be an astronaught - rockets are complex enough to need more people than astronaughts and so most people designing spaceships will never have the opportunity to use one.

I find that this argument is used too often to refrain from using your own product.

Yes you're right not anyone can be a domain expert. But anyone in the company needs to at least try to use the product as much as possible.

I worked in companies where even the CEO had never used the product but was telling us what to implement.

I am not asking anybody to be an expert in both (although I am sure such people exist, however rare); I am saying people should ideally have some skill in both. Also, people can collaborate, and learn new skills.

If you're bottle-necked by waiting for the users of your product to give a feedback, you clearly need to spend more time learning how to be a user yourself. Or hire people with some domain skill who can also code.

Have been there, we got pushback from users and we had to back off with releases. Users hunted product owner with pitchforks and torches.

As dev team we were able to crank the speed even more and silly product people thought they are doing something good by demanding even more from us. But that was one of the instances where users were helpful :).

People use dozens of apps every day to do their work. Just think about how are you going to make time to give feedback to each of each.

> Just think about how are you going to make time to give feedback to each of each.

That's pretty much solved by the size of the audiences. You won't give feedback on 12 apps, but 11 other people will probably do so on 11 different apps.

Of course, the issue with my domain is that there's plenty of feedback, and product owners just dismiss it. Burn down your entire portfolio to get that boosted shareholder value for the next earnings report.

And how do you solve that when you are one of those 11 apps when no one wants to talk to you because they have their work to do? Where you don’t have power to say that kind of thing.

Well by asking repeatedly of course but you just piss people off.

Have you ever given feedback to Atlassian, Google, Microsoft?