Hacker News new | past | comments | ask | show | jobs | submit login

Because I may not be in the same line of business as my users. For example, my last start-up develops planning software for large agricultural firms. I don't happen to manage a large agricultural firm, nor am I likely to manage one in the near future.

Still think I should be using my own product day in day out?




Nope, but if you can, hang out with the actual users jockeying the software as often as you can. I know that I learn something new almost every time I go out on the trading floor and have a user walk me through the software I'm writing and fixing.


Absolutely! And that was my point-- you need to understand the user's problem-space very well, and there are better ways to do this than the traditional "business requirements gathering" process, which tends to focus on the (sub-optimal) solution the users have already imagined.


It shouldn't be "business requirements gathering." It should be "business requirements refinement."


No, but then I don't think that that was Steve's point. If you work really hard, and really listen to your customers, you'll probably be able to build a reasonable product.

But if you truly want to build a great product, one that does the things that your clients didn't even know they needed until you wrote it, well, there's only one way to find out about those sorts of requirements - do the job yourself. Your software will never fulfill these unrecognised needs, and will hence never be truly great.

It's back to the whole Mac circa 1982 thing again. No-one would tell you that they needed a graphical interface to their computer if you had asked in 1982.


That's a very good point. My company for instance builds project management software for (digital imaging|photography) companies who manage several clients at a time. I literally had to work and breath in one of these companies just to write the software for them.

Had I built that software for myself, it wouldn't had have any traction with the employees in that company.


Ideally yes. Go work for one for a year, then create the software...

Of course this isn't always possible, but it's the way to better products.


I'm not saying that on-the-job experience is a bad thing-- clearly it isn't-- but as you say, it isn't always possible, and it's still a long way from creating software for you yourself to use.

Put another way: I'm not the target user of any of the most valuable (or most lucrative) software I've created-- and I don't think that's a rare condition.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: