We’re hearing that lousy times are good times for creativity, for building new things, precisely because the mainstream things aren’t working. Well, and maybe you’re out of a job too. If you’re building something new, who should you build it for? [This is part of the Tough Times series.]
Build It For Yourself! · This is a point I’ve made before in this blog, but recently, Steve Yegge made it again, brilliantly I thought, plus he’s funny. On the other hand he’s extremely long-winded and it took him several thousand words. So I’ll summarize here; but I’m nowhere near as entertaining as Steve.
How BigCos Do It · When big organizations sit down to design new products, they put in huge amounts of time obsessing about who the users are and how to meet those people’s needs. One common practice—strongly identified with Microsoft—is inventing some fictional “real people” who are going to be the users, giving them names and personalities and strengths and weaknesses, then reasoning about product features in terms of how these people will react to them and use them.
All of which mostly doesn’t work. Most successful innovative new products aren’t produced by large organizations, they’re cooked up by little startups or, if in a big company, by guerrilla groups in skunkworks mode.
Who Do You Really Know? · It’s like this: There’s only one person in the world whose needs and problems you really understand and whom you know exactly how to satisfy: that would be you. So build something that you use all the time, and, unless you’re really weird and different from everyone else, you’ve got a potential winner.
I can relate to this message myself. Everything I’ve done over the years that’s worked out well—software, standards, writing—everything, without exception, was something I did for myself. I’ve done the other thing too: built things based on guesses about what people out there might want or need. Never worked, not once.
I bet if you did a survey of successful musicians, artists, writers, or any group of creatives, you’d hear the same story. Sometimes you can guess what people want, and you might get lucky. But probably not, so go ahead and build what you know for sure one person needs.
Contributions
Comment feed for ongoing:
From: Patrick Mueller (Oct 23 2008, at 17:12)
We call it "eating your own dogfood", though folks closer to customers sometimes change it a bit to "drinking your own champagne".
Most folks don't have that luxury though.
[link]
From: John Cowan (Oct 23 2008, at 19:29)
TagSoup, oddly, isn't something I did for myself, at least in the sense that I was going to use it myself -- I have never once used it in anger. But it was "for myself" in a different sense: it was an interesting challenge to work out how to fix HTML with a dead minimum of ad hoc code. And it's one of the most popular things I've done.
[link]
From: Fred Blasdel (Oct 23 2008, at 20:26)
I'm a staunch advocate of the "Build for Yourself" school of design, but it isn't complete — you can't simply build Social Software for yourself.
It's evident in a good definition: "Software that's only useful to you if other people use it with you" (Twitter is, but Twitteriffic isn't)
[link]
From: Gerrit Kaiser (Oct 23 2008, at 22:07)
The practice you are describing as “strongly identified with Microsoft” is known in the Interaction Design community and well beyond as the Persona technique. It’s been around for a while (see http://www.cooper.com/journal/2003/08/the_origin_of_personas.html). But as far as I can see it’s certainly not how most “BigCo”s do things (we’d be lucky if it was, though).
Personas are also as far from “guessing” and “inventing” as it gets. They are rooted in previous user research (see http://www.interaction-design.org/encyclopedia/personas.html)
I’d be interested how you came to the conclusion that methods like this “mostly don’t work”.
[link]
From: Michael O'Brien (Oct 24 2008, at 03:19)
"Build for yourself" reminded me of stories I'd read of the original "Looney Tunes" writers, and the creators of "Mystery Science Theater 3000". Both have said in interviews that they created material that they liked, and figured that a fair number of folks would come along for the ride.
In both cases, the strategy worked famously.
[link]
From: Erik Engbrecht (Oct 24 2008, at 05:29)
You have to ask: Why do BigCos do what they do?
Hmmm...well...how many software engineers start sit around scratching their chin thinking they could really use a better ERP system.
So having engineers "build for themselves" puts severe limits on the product space and the number of engineers suitable to working on products.
[link]
From: John Blackburn (Oct 24 2008, at 10:38)
The Polish composer Witold Lutoslawski said in interviews that he wrote his music for himself, because that way he knew that at least *one* person would like it.
[link]
From: J. Pierce (Oct 24 2008, at 11:18)
I really agree with your statement here in most contexts - I think the flip side of this attitude is the perception that "what's good enough for me should be good enough for the user" - which on occasion can result in some really awful UI/usability choices.
Granted, a developer has no obligation to tailor their app to me or anyone else, (particularly in the case of free or open source apps where as a user, I have invested little or nothing in the software.) but I feel like sometimes an app strikes a chord with users, and there's an opportunity to broaden it's appeal or streamline it that's not always capitalized on.
I guess I'm saying you've got a great point, but for the sake of both the users and any profit to be driven from the app, please don't let that theory drive the entirety of the product cycle!
[link]
From: Peter Maurer (Oct 24 2008, at 12:58)
I couldn't agree more.
BTW, apart from being more successful, building things for yourself has an additional perk -- you end up having the nice piece of software/art/whatever you've always wanted. That may sound trivial, but to me, it's not. I really enjoy using my own products, and if I had enjoyed a competitor's product the same way, I wouldn't have started creating my own in the first place.
[link]
From: Daniel (Oct 24 2008, at 17:36)
A few of the commenters are missing the point.
'Build for yourself' doesn't mean disregard everything that makes a product usable. The premise is much higher level than that. It's about the stratigic choice to sit down and solve a problem you think other people have vs solving a problem you have yourself.
[link]
From: JulesLt (Oct 27 2008, at 15:53)
To make an Apple related observation on this point - it strikes me that a lot of Apple's Cocoa frameworks seem to be code that has been extracted from their applications, rather than speculatively APIs created for third parties.
Compare that with MS - their developer tools division is fecund with creativity in terms of tools and frameworks and programming languages, but it's hard to tell which ones are actually being used in anger. Which ones are MS betting on, and which ones are really public betas?
I also often think that has been the problem with desktop Java - it was solving a problem of cross-platform GUI development that Sun didn't actually have, because Sun didn't sell application software.
You can also see something similar with Rails and 37 Signals too - Rails is a framework that was a consequence of development, rather than a framework development project.
(Even HTML and the initial browser).
I think what I'm getting at is that by developing something for yourself there is a good chance you'll produce something useful to others as a side-effect, by nature of the fact that it is well-tested and works.
[link]