In theory, you're right, but in practice that's so, so not the case, especially here in the SF Bay Area, which seems to be neck-deep in the "build-first" mentality of freshly minted MBAs.

Over the last year I've talked with so many startups, mostly "founders" and "entrepreneurs" with Bschool degrees, who seem to be taught that all they need is an "idea/vision". They just need to get someone to build it, because, you know, they've run the numbers and they "know the market" (actual, real-life quote from an actual situation). When I ask, "What problem does this solve, for whom, and how do you know this?", they scoff and tell me that they don't need to do any user research and besides, that'd slow things down.

Now, there may be actual pressures on startups to start building without ever observing a single potential user. Certainly if you're going to present at Y Combinator, they want to see code, a product, and tons of "confidence" (again, actual quote from actual situation). Showing them serious research on populations, data on engagement, prototypes... that'll get you laughed out.

But, side note: 75 to 90% of all startups fail. Go figure.

As a UX professional, this really grinds my bacon, six ways to Sunday. It's like seeing a kid whinge that the test was hard when you know they didn't do any of the homework. Perhaps they think that user research means months, and 100s of pages of specs (and, to be fair, it could), but I think a lot of this comes not just from stakeholder pressure but a misreading or Ries's "Lean Startup". Sure, it helps to get something in users' hands quickly, but this is based on research first. Know who your users are, what problems they face, how they think. At least an idea of it. You can rapidly prototype, GOOB, test, iterate, all within cycles of days or weeks. But you HAVE TO KNOW THE USER (who is NOT YOU) first.

There's a great example of how this can be done for $40, to save $10Million: http://vimeo.com/24749599

You're missing something (no discredit to you; a Google project manager recently made basically the same mistake). You can conduct many kinds of user research (UX) that are far more insightful and reliable than "asking customers what they want".

I'll agree with you that it's a loser's game to ask customers and potential customers what they want. First, people will try to help you, and thus give you bad data (examples: "I love what you did" focus groups, asking people what TV shows they watch). Second, they may not really know what would solve their problems. Third, if you just translate this to feature requests, you end up with Microsoft Office.

Real UX observes populations, seeing what real-world problems they actually face, where their face frustrations, how they think about themselves, their tools, their problems. This informs the process of discovering user needs and use cases. Science!

Usability testing of prototypes bends itself into knots trying to correct for these natural propensities of people. And still, it requires some n of testers, evaluation of the qualitative and quantitative info generated from this, and expertise. And it can still get things wrong.

But it's so much better than marketing-driven design (Facebook pushing ads, fill in your example) or engineering-driven design (a Google engineer builds a "cool" tab feature, or finds how Gmail can share all your contacts with all your other contacts).

Mod parent up... as a UX person, I can never seem to remind people often enough that they are not the user. Sure, you know what everything does and why, because _you built it that way_. Every other person, not so much.

You have to laugh at how the core of Ferriss's time- and effort-saving plans all seem to involve variations on, "have other people do it", "have expensive devices that can do it for you", "take advantage of other people" (in this example, ruining a hotel's iron so that nobody else can use it) -- all, basically, "first step: HAVE LOTS OF MONEY".

I get up damn early, get on the bike for a few hours at least. And refuse to work insane hours. If a project or product "requires" all hands for 80 hours a week, it's already too late.

All "human AI" interactions will have a PvP mode, of course.

(Written as someone who is not a believer in Kurzweil.)

You're sure? Why is that? Any data? Or is it just you?

Actually, the upgrade/adoption rate for iOS is amazingly good, in both absolute numbers and in comparison to Android. (Note: I am not making any "this OS is better than that OS" statements, just talking about documented statistics.)

iOS 3.x usage looks to be in the single-digit range, while iOS 5.x was quickly adopted by up to 75% of iOS users. Source: http://thenextweb.com/apple/2012/03/06/why-do-developers-prefer-ios-over-android-try-75-adoption-of-ios-5-while-ics-is-stuck-at-1/

Larger/louder/more voices drown out smaller/quieter/fewer voices -- regardless of the authority or quality of comment. (Unlike on /., which has moderation and meta-moderation based on content.)

True story: My sister and brother-in-law left their kids with their grandmother and escaped to see a movie and relative peace for a few hours. My sister came back, really angry with her husband. "But sweetie," he said, "_2012_ got a good score on Metacritic!"

Really. Happened.

Ha! No, I'm old. And Spartacus.

No, I'm not insisting a journalist is like a scientist/engineer, nor am I insisting a journalist is like a fine artist. Why does a journalist have to be like either?

The parallel I was attempting (poorly, it seems) to draw is one of accountability. Which was the answer to your question. It's not tied to writing or expression, but in trust and confidence (perhaps the sociological technical senses of these terms are best here). You need to have a way to track back to the person writing the article or coding the software, because that's the primary mechanism to protect the user/reader from either incompetence or maliciousness.

I hope that makes it clearer. (And I'm not being passive-aggressive! I'm really trying to engage and be expressive.)

The difference is accountability. I should think this is obvious.

Journalism -- real journalism -- relies existentially on correction, whether self- or outside. The whole thing depends on being able to track who was responsible for reporting what and track records. Your name, your byline, is your career in journalism not just because of narcissism (though that happens) but because you have to put your name on each story and, if you screw up, each correction. If you can't trace where bad info came or _regularly comes_ from, it's not journalism and not reliable info.

Since you're on /. and have a low ID, I'll guess you're involved in... software, perhaps? Do you install unsigned software or buy from developers you've never heard of, have no reputation, and no contact info?

Journalist here.

What you're missing is the strong definition of "cover". In that very example, IIRC, the Journatic stringer just rewrote an agenda for the meeting, published before the meeting. The report that got published did not reflect what actually happened at the meeting, had no context of whether citizens questioned, applauded, or rioted. The Journatic stringer did not contact anyone to get a second source.

Think if this model were replicated on a larger scale. "Official government press releases said that the Congress is functioning smoothly and all citizens are happy" or "Microsoft press releases stated that Office 2018 is a must-buy and everyone loves Windows."

First off, I'll say that I have little to no direct experience working in this system, as I am not a developer. But as has been pointed out to me by many Agile-experienced managers and developers, what I have done -- worked at monthly, weekly, and daily newspapers and news sites -- is very similar in structure. That is, we have daily meetings about what we're working on and where that is, the editorial goals, checking in on longer-form projects, and then going off and working our asses off.

Of course any snake-oil consultant can come in, propose a "just-add-water" buzzworld-compliant solution, and screw up any endeavor. See also: metaphors about having only hammers.

But I think the key is that at least in journalism, we had an existing superstructure and larger mission, and regular content that we delivered, so that kept us on track and gave us regular learning feedback. Think of it as daily iteration based on user research.

Do software/hardware projects have that sort of thing? Is the superstructure in place, and does Agile fit into that, rather than imposing Agile because... well, it's Agile?

I kind of take exception to a phrase and assumption used here: "pushing the edge" (if I will).

What makes you assume that someone doing work -- writing, editing, painting, thinking, developing, accounting, philosophizing -- can't "push the edge" on even outdated computer equipment? Sure, if you're are doing specific work that requires a lot of computing horsepower, you can be more efficient on a newer computer. You can also churn out more unimaginative, derivative crap.

Perhaps I'm reading too much into this, but I'd like to point out that the quality of most (probably 99%+) thinking is not dependent upon, and does not require, faster and more configurable and more fun-for-you-to-build computers with multiple monitors. Again: _you_ may be more productive that way, and feel more deep thinkin' coming on when you have a hardware stiffy, but please do not look discount others who can kick all of our asses in thought with even a paper and pen (logicians, creatives, and too many examples to count).

(Just want to make clear the tone of this isn't an angry "you insensitive clod!" -- just want people to think about how tools do not make the quality of thought, but are, you know, TOOLS.)