Hacker News new | ask | show | jobs
by throwawaaarrgh 1119 days ago
Note he doesn't mention a user story. Large technical projects apparently let you ignore what the user wants, use cases, dependencies, stakeholders, design reviews, feature changes. Instead you just decide what you want and wait to see if the user wants it too.
7 comments

What users want and User stories (in the agile iterative software sense) are different things. At their best user stories represent problems to solve for the end user, but rarely have I been able trace back a user story to something that an end user actually wanted because nobody bothered to ask them.

Not talking to customers is extremely common. Everyone’s just too busy, including the customer. It’s kind of the “eat healthy and exercise” of business: Everyone knows they should do it, yet few actually do.

> At their best user stories represent problems to solve for the end user, but rarely have I been able trace back a user story to something that an end user actually wanted because nobody bothered to ask them.

This is such a universal problem in the industry. It's also the source of the endless reinvention cycles we go through.

Everyone hates user stories now because no one actually does the other work involved - talking to the users to get the stories in the first place. So it becomes an unproductive chore and people grow to hate it. Someday, someone will discover talking to the user and they'll have their own favorite little way of writing down the conversation and they'll come up with their own title for it. It will start getting hyped and eventually we'll all be doing it - except we still won't be talking to the users and the next generation will hate it. And it will repeat.

It's the same with User Stories, OOP, and every other concept in computer science since the 50s.

> It will start getting hyped and eventually we'll all be doing it - except we still won't be talking to the users and the next generation will hate it.

By the way, user stories are an iteration of that. I remember:

- when user stories were a novelty, everyone hated actors and use cases,

- when actors and use cases were a novelty, everyone hated functional requirements.

It's not like the users know what they really want though. You talk to a bunch of Salesforce users and they'll tell you that what they want is Salesforce+. This may not be what you want to be building as your product.
Base on my experience (product leadership role) when talking to customers it's most important to focus on their problems and challenges. They will obviously suggest solutions but you will want to be super careful with following these - think your Salesforce+ or the famous "faster horse".
My impression is that the article's advice is more fundamental than all of that (e.g. it could just as easily apply to personal passion projects), yet can easily be integrated with it (e.g. iterative work->demo->feedback phases).
He mentions something far better: getting the product into the hands of users ASAP so you can iterate on it.
Two thoughts, one, his approach is orthogonal to that. This is a way to move yourself forward on any project, no matter where the design comes from.

Two, he IS the user! His example is the terminal emulator he is writing for himself. He says to write something that you will use yourself, as a good way to generate your own interest and involvement in it. Also, it seems like good practice to write something for the user you probably have the best communication with!

I used some of these ideas to get over the hump on a project today. Just get the simplest thing going to give a useful result, and that helps break the log jam!

Describes basically all of my large technical personal projects. Definitely the happiest I have ever been writing code and building things.
Well, he write stuff for developers so he might know the space well enough to start his work,

unlike the recent story of a developer trying to disrupt coffee delivery

Sounds nice!