Business Requirements are Bullshit
Some CEO emailed me the other day. I don't remember who it was; people mail me all the time about their blah blah yawn product service thingy, and on the rare occasions I bother to read mail from strangers, I don't usually remember anything about the email, even if I respond to it. I can remember broad categories of questions I get, but everything else is just a blur. That's senility for ya.
But this dude, or possibly dudette, asked me a really good question. One that made an impression. And by "really good", I mean it was one of the flat-out wrong-est business questions you could possibly ask. It was like asking: "How can I get the most out of my overseas child laborer pool?"
There's no right answer to a question that's just wrong.
But his question, well, people ask it a lot. In fact there are whole books that give answers to this inherently-wrong question.
His question was:
And my answer was: Business requirements are bullshit!
Well... actually it was: "gathering business requirements is bullshit", plus a bunch of accompanying explanation. But the shorter version sure is catchy, isn't it?
The rest of this little diatribe expands a bit on my reply to this guy. (I actually sent him an email with much of this material in it. When I do reply to strangers, I still try do a thorough job of it.)
Before we dig into the meat and potatoes of today's meal, let's talk about my credentials, and how it is that I am qualified to offer an opinion on this topic.
My Credentials
If you're a business person stumbling on my blog for the first time, welcome! Allow me to introduce myself: I don't matter. Not one teeny bit. You shouldn't care about my credentials! All that matters is the message, which is hopefully so self-evident that if you hadn't already realized it, you'll be kicking yourself.
It's OK, though. Kick away! In fact, give yourself an extra kick for me. Kicking yourself is a great way to remember a new lesson down in your bones. When you get actual bones involved, the painful throbbing for the next few days provides just enough of a reminder that you'll never forget again.
In any case, I make no claim to any credentials whatsoever, and this advice is all straight from my butt. Do what you like with it. The advice, that is.
With my credentials out of the way, let's see about this guy's question.
By the way, I'm specifically addressing this rant towards you only if you (or your team, or company) are building your own product or service offering, or at least defining it. If you're asking consultants to define the product for you, well, you're on your own. Good luck. And if you're a consultant, well, you don't get much choice about what to build, so you're also (mostly) on your own. Although I'd advise you to try to find work that fits the strategy I outline here, as you'll have more fun with it and do a better job overall.
Gathering Requirements 101
It's the first thing everyone wants to do! It's the first thing they teach you in Project Management Kindergarten: the very first thing you should do on a new project is look both ways before crossing the street to your building. Assuming you parked across the street. And the next thing is: start gathering business requirements!
Ah, the good old days of Project Management 101. Life seemed so easy back then.
The requirements-gathering process they teach you typically involves finding some "potential customers" for your product, and interviewing them in a nonscientific way to try to figure out what they want out of your proposed product. Or service. Or whatever. It doesn't really matter.
Potential customers can be hard to come by, especially since you're building something that nobody will ever, EVER want. Well, that's getting ahead of myself. Let's just agree that when you're setting out to Gather Business Requirements, your potential customers usually aren't already sitting in the room with you.
Sometimes it's a lot of effort to go find real customers and bring them in and get them to agree to be grilled for hours. Hence, requirements-gathering sometimes takes the form of "role play", where you get some poor saps in Accounts Receivable to pretend they're Potential Customers for your product, and you interview them instead.
You might be laughing about those poor Role Playing schmucks, but in reality it doesn't much matter who you interview, because by the time you get to this phase in the project, you've already screwed it up beyond all hope of repair.
That process of looking around for customers? It's a plot device that novelists like to call foreshadowing. If you don't have any readily available customers now, then they sure as hell won't be readily available when your product launches.
Allow me to illustrate with a Case Study.
An Illustrative Case Study
See? Credentials or no, I sure can talk the lingo, eh? I also like my incisive use of the popular business term "schmuck" in the previous section. It's a term that can apply to people in all phases of project catastrophes, not just Requirements Gathering.
For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.
Let's say that our Ideas Department has decided that we should get into Personal Nose Hair Grooming devices, because there's clearly a huge unmet need for nose hair grooming, as evidenced by Karl, our accountant, who has a thatch of nose hair that's almost long and thick enough to be a mustache, if only he would groom the thing a little. And we've seen lots of people like Karl. Clearly a nose-hair grooming kit would be the ideal addition to any man's personal grooming lineup, which typically consists of spitting into the sink and thinking he should get the mirror fixed someday.
So we need to gather some Business Requirements. Unfortunately nobody wants to talk directly to Karl, because, well, nose hair can sometimes be a mildly sensitive issue in some cultures. Plus nobody wants to make eye contact with him. So instead we hire some people to go out and do focus-group studies on the subset of people who are comfortable talking publicly about their nose-hair grooming problem, notwithstanding the fact that everyone in this tiny category is obviously too crazy to trust with important business questions.
The focus groups find a few nut-jobs who say: "Yeah, I'd love a nose-hair grooming appliance! Plucking your nose hair is painful, and trimming it involves jamming a small whirly Osterizer thing all the way up to your brain. Maybe if I just combed it into a mustache, nobody would notice!" And behold, we have the makings of some Business Requirements.
The product is a complete failure, of course. The project postmortem reveals that the user studies and focus groups failed to realize that only certain men, namely "men with significant others", ever even notice their nose hair, even when said hair becomes long enough to interfere with tying their shoelaces. The significant other must forcibly remove the nose hairs with garden shears at least twice before the man gets the hint and starts attending to the problem himself.
Not to mention the fact that a nose-hair mustache would be even more obvious and comical than a comb-over. Well, almost.
In the end, it doesn't matter how great a Nose Hair Groomer we build, because we failed at the business-requirements gathering phase: nobody actually wants this product. The people who might want it don't know they have a nose-hair issue, and the ones who do know just trim it.
The thing that might surprise you is that this fictitious (and yet eerily familiar) Case Study isn't just an illustration of how gathering business requirements can go afoul. We're not talking about a failure mode for Gathering Business Requirements (GBR). We're talking about something more fundamental: the GBR phase of a project is a leading indicator that the project will fail.
Put another way: GBR is a virtual guarantee that a project is building the wrong thing, so no amount of brilliant execution can save it.
From Business Requirements to Bad Idea
I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.
People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.
Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.
The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.
That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."
So the experts give you all sorts of ways to try to get at the Right Thing, the thing a real customer would actually buy, without actually building it. You do mockups and prototypes and all sorts of bluffery that the potential customer can't actually use, and they have to imagine whether they'd like it. It's easy enough to measure usability this way, but virtually impossible to measure quality, since there are all sorts of intangibles that can't be expressed in the prototype. I mean, you can try — we sure tried on the OmniGo products — but in this phase nobody "imagines" that the thing will weigh too much, or be too slow, or will go through batteries like machine-gun rounds, or that its boot time will be 2 minutes, or any number of other things that ultimately affect its sales.
And even if you do a world-class job of prototyping and getting at the "real" desired feature set, it still goes through a series of iterations with the engineers and product team, who aren't the actual customers and have little interest in building what the customer really wants (because they're not being measured or evaluated on that — they're evaluated on delivering what everyone ultimately agrees to deliver). During each iteration they push back on things the customers asked for. As the proposal degrades, the customers like it less and less, but they want to be helpful, so eventually they say, "Yeah, I guess I could use that." (Which means: I wouldn't take one of these even if they were giving it away.)
Don't get me wrong: I'm not saying that usability teams can't do a good job. It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as "pretty good" come out "just plain bad."
So I'm tellin' ya: gathering requirements is the Wrong Way To Do It. At best, it results in mediocre offerings. To be wildly successful you need a completely different approach.
The investing analogy
Warren Buffett and Peter Lynch, both famous and successful investors, say pretty much the same thing about investing. Peter Lynch's mantra sums it up: "invest in what you know."
If you actually take the time to read Lynch's books (which I have), you'll see that this pithy mantra is a placeholder for something a bit more subtle: you should invest in what you know and like. You should invest in companies that make products or services that you are personally excited about buying or using right now.
When you invest with this strategy, you're taking advantage of your local knowledge, which tends to be more accurate than complicated quantitative packets put together by analysts. And your local knowledge is definitely more accurate than the reports produced by the companies, who want to paint themselves in the nicest light.
Warren took a lot of heat in the 1990s for not investing in the tech sector. But hey, he didn't feel comfortable with tech, so he didn't invest in it. One way to look at this is: "ha ha, what a dinosaur, he sure missed out, and now he's, uh, only the richest person in the world by a small margin." But another, more accurate way to look at it is this: he's the richest person in the world, you asshole. When he gives you investment advice, take it!
And Warren's advice is: don't invest in stuff you don't understand! Even if it seems like a sure thing.
That's the hard part. Sometimes it looks like a surefire winner for some large group of people that doesn't actually include you personally at this particular moment. But it's a really large group!
Let's say, for instance, that you hear that Subway (the sandwich franchise) is going to do an IPO. They've been privately held all these years and now they're going public. Should you invest? Well, let's see... the decision now isn't quite as cut-and-dried as it was in their rapid-expansion phase, so, um, let me see, with current economic conditions, I expect their sales to, uh... let me see if I can find their earnings statement and maybe some analyst reports...
No! No, No, NO!!! Bad investor! That's the kind of thinking that loses your money. The only question you should be asking yourself is: how many Subway sandwiches have I eaten in the past six months? If the number is nontrivial — say, at least six of them — and the rate of sandwiches per month that you eat is either constant or increasing, then you can think about looking at their financials. If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule of Buffett and Lynch.
The investing analogy is an important one, because if you're a company or team planning to build something, then you're planning an investment. It's not exactly the same as buying stock, but it amounts to the same thing: you're betting your time, resources and money — all of which boil down to money (or equivalently time, depending on which one is in shorter supply.)
So when translated into project selection, Buffett's and Lynch's advice becomes: only build what you know. The longer, more accurate of the version of the investing rule — only invest in what you know and are excited about using yourself right now — has a simpler formulation for products and businesses. That formulation goes like this:
ONLY BUILD STUFF FOR YOURSELF
That's the Golden Rule of Building Stuff. If you're planning to build something for someone else, let someone else build it.
Building stuff for yourself
You can look at any phenomenally successful company, and it's pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water.
And the key leading indicator that they're getting ready to head off course? You guessed it: it's when they start talking about gathering business requirements.
Because, dude, face it: if it's something you want, then you already know what the requirements are. You don't need to "gather" them. You think about it all the time. You can list the requirements from memory. And usually it's pretty simple.
For instance, a few years ago I announced to some friends: "I sure wish someone would make a product you can spray on dog poop to make it, you know, just dissolve away." My friends laughed loudly and informed me that this was (apparently) the premise of some Adam Sandler movie I hadn't seen.
Well, OK, sure, but... I mean, they kinda missed the point. I still want the product. Its requirements list is pretty simple. Here's the business requirements list:
a) It should dissolve dog poop.
Gosh. Can that really be the entire list? You bet! Sure, there are lots of implicit requirements: it shouldn't cost a fortune, it should be environmentally friendly, it shouldn't kill kittens, etc. But those kinds of requirements are true for all products and services.
If I knew how to make this product, then Adam Sandler movie or no, I'd probably try to make it. The target market is larger than just pet owners; anyone living near a park would probably own a bottle or two. I would use the stuff like it's going out of style. I'd attach it to my shoes so that every time I took a step it would spray the area in front of me, like a walking garden hose.
Building a product for yourself is intrinsically easier, since you don't have to gather requirements; you already know what you want. And you also know, for any given compromise anyone suggests, whether it will ruin the product. If someone says, "I have a product that dissolves dog poop, but it takes 18 hours", then you'll know you've entered into "prolly not worth it" territory. You don't have to go ask the focus group. You just know.
The Mistake of Imagination
Despite its obvious advantages, following the rule of building stuff for yourself is actually really hard to carry out in practice. Why? Oddly enough, it's ego.
For one thing, people like to think they're unique and special, and that their tastes aren't necessarily widely shared by others. This is what drives fashion: the need to differentiate yourself from "the crowd", by identifying with some smaller, cooler crowd.
The reality is that for any given dimension of your personality, there are oodles of people just like you. If you want something, other people want it too. You define a market: a bunch of them, in fact.
You just have to be smart about which of your needs you want to fulfill, since if it's building yachts, well, it's not exactly going to be mass-market, unless you find a way to build a mass-market yacht. Which would be pretty cool, incidentally. I'll buy one if you make it.
It's also really easy to fool yourself into thinking that this is a product or service you would use, because, hey, you have a great imagination. When you lose your car keys, you can picture them in all sorts of places: the kitchen drawer, the coffee table, on top of the fridge, and when you picture them there, it's just as vivid as a memory. So you wind up looking for them everywhere! Your powerful imagination is pretty much your worst enemy when it comes to deciding whether you'd like something enough to use it yourself.
We all made the Mistake of Imagination on the OmniGo projects. "I could see myself using this product," we'd tell ourselves, "if, that is, I were the kind of person who used this product, which I could sort of envision." You'll tell yourself almost anything to justify the work you're doing. Giving up in mid-project is a big loss of face for an individual, harder for whole teams, virtually impossible for most companies. The OmniGo had four companies involved, making it the hardest possible project to back out of, even though by the halfway point virtually everyone involved knew the product would kind of suck.
What we really wanted, while we were building the OmniGo, was summed up by our brilliant product manager Jeff Peterson. We were having beers one day, and he said, "You know, this thing is just getting way too complicated! It doesn't need a 12C calculator emulator! It doesn't need a spreadsheet! It doesn't need a database application! I mean, come on! All it needs is a notepad, a simple calendar, an alarm clock, and maybe a pocket calculator, and it should fit in your front shirt pocket, and it should be a phone."
It was 1994 and he was describing the iPhone. And you know what? He was right! That was what we wanted. But HP was driving the spec, and they weren't building it for themselves. They were building the product specifically for this imaginary group of high-power on-the-go consumer accountants who use 12C calculators and want a whole desktop suite crammed onto their 1994-era mobile device. And that's just who bought the thing: pretty much nobody. (They sold a few thousand units, which in mass-market terms is "pretty much nobody.")
Trimming the Requirements
Who was it who said that you're done writing not when there's nothing left to add, but when there's nothing left to take away? Was it St. Exupéry? I promised not to do any research for this rant, but I think it might have been him.
Ideally the product you're building for yourself should be simple to describe, so that other people can quickly evaluate whether they, too, want this thing. It's often called the "elevator pitch", because you should be able to describe the product in the time between when the cable snaps and the elevator hits the ground. "Dissolves dog poooooop!!! <crash>" It used to just be the time for an elevator ride, but those investors keep raising the bar.
You can almost always make a product better by trimming the requirements list. We're talking brutal triage: throwing out stuff that's really painful to lose, such as the ability to change the battery.
If you're lucky, you should be building a product that so excites everyone involved that everyone has an opinion, and you wind up spending most of your time in triage.
When you're trimming the business requirements, then you're exhibiting healthy project behavior. This contrasts directly with gathering requirements, which has both the connotation that you're clueless about the product and the connotation that you're inflating the requirements list in direct conflict with schedule, usability and fashion. Trimming: good. Gathering: bad.
Trimming the requirements list is a leading indicator that you're a smart company who's about to launch something major. An ideal requirements list looks something like this:
a) It should dissolve dog poop.
As a great real-life example, consider the the Flip camcorder, which kinda came out of nowhere and "stole" 13% of the camcorder market (although I'd bet good money that it actually created new market share). Does it dissolve dog poop? Well, no, but it's still pretty cool:
1) it costs $150 or less. (A lot less, actually.)
2) it has no cables or wires. Just one flip-up USB connector.
3) it has one big red button: RECORD, plus a teeny one for playback.
4) it doesn't take cartridges or cassettes or discs or cards or anything
5) it doesn't have any controls or settings or anything
6) it stores one hour of video and has roughly one hour of battery life
7) it's about the size of a cell phone
8) it records videos that work well with YouTube
9) it comes in pretty colors
I mean, DAMN, those guys knew what they were doing. We always used to joke about a product so simple that it only had one button, which we pressed for you before it left the factory. That's how simple a product needs to be in order to make the mass market. One button, pretty colors. They nailed it. Talk about a missed startup opportunity. (Flip guys: if your equity plan is still reasonable and you want someone to make your desktop software not suck, and yes, it really sucks, please give me a call.)
You don't need an original idea to be successful. You really don't. You just need to make something that people want. Even if someone else appears to be making something popular, it's usually possible to improve on the idea and grab market share. And it's painfully counterintuitive at times, but the best improvements often come from simplifying.
The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away.
In any event, originality is overrated. Coming up with something completely original isn't just hard to do: it's also hard to sell, because investors (and possibly customers) will need to be educated on what this new thing is and why people would want it. And when it comes to buying stuff, nobody likes to be educated. If the product isn't immediately obvious, investors and customers will pass it up.
It's easy to come up with new product ideas if you start with the understanding that everything sucks. There are no completely solved problems. Just because someone appears to be dominating a market with an "ideal" offering doesn't mean you can't take market share from them by building a better one. Everything can stand improvement. Just think about what you'd change if you were doing it for yourself, and everything should start falling into place.
If nothing else, building things for yourself is more fun, so you're successful regardless of what happens. But it also has great product-survival characteristics, because people can't bluff you into making something lame.
Sometimes you just can't win
By way of don't-sue-me disclaimer, I should point out that building something for yourself doesn't guarantee success. Even if you build a product that most of your target market really really wants, and you hit the right price point and release date and everything, your product can still fail catastrophically.
The example that leaps to mind is that company in the 1990s (can anyone remind me of the name? I've forgotten) that built a mountain-bike seat extender. I ride mountain bikes, yes, on actual mountains, so this product made immediate sense to me. I really wanted one. Sounds like a winner, right?
The basic physics problem this company was solving is that a lower seat position gives you better balance, and a higher seat position gives you more power. It's a trade-off. You generally want more power when you're grinding uphill, and you want more balance when you're speeding downhill. But during a race you would have to give up precious seconds to adjust your seat between every uphill and downill transition; you'd get your butt kicked. Even as a casual rider, adjusting your seat height all the time is annoying enough that most people just don't do it, resulting in some sacrifice of balance, power, or both.
So this brilliant, innovative company came out with a well-made product that lets you adjust your seat height "in flight", as it were, without slowing down, and without adding much (if any) weight to the bike. I don't remember exactly how it worked, but it was a reasonable implementation.
Interestingly, it didn't matter how it worked. It could have been actual magic: a product that read your mind and raised or lowered your seat by exactly the right amount, at exactly the right speed (you don't want it to rabbit-punch you in the nuts, for example — remind me sometime to tell you about how I found that out), as frequently or infrequently as necessary to strike the perfect trade-off of balance and power for any slope, at any time.
And it still would have failed, even if 90% of the mountain biker population, like me, secretly coveted the product. It could have cost fifty cents, been available everywhere, and been installable by a four-year-old with one hand in under two seconds. It could have come pre-installed on all bike models, via a brilliant channel deal with all the main manufacturers (or retailers), and bikers would have ripped the thing off the bike faster than their kickstand (which is usually the first thing to go.)
So, uh, what happened, exactly? Wasn't I just ranting that building a product for yourself, one that you know is the Right Thing for some well-defined audience consisting of people just like you in some dimension — wasn't I ranting that this would always work?
Well, no. It's just the best way to pick projects. But they can still fail for surprising reasons.
In this case, the fundamental marketing force that the company failed to take into account was fashion. People don't often think of mountain biking (or programming, for that matter) as a fashion industry, but failing to understand the role of fashion is a recipe for random disasters.
What happened was this: while they were hyping the product — by demoing it at trade shows, letting bike magazines check it out, and generally working their way towards getting retailer shelf space — the pro bikers took one look at the thing and said: "Hey, looks pretty cool. Maybe I'll get one for my girlfriend. Or my fugging grandma. How much is it?"
At which point, everyone (me included) who had been ranting about standing in line to buy one when they came out, we, ah, we were very quick to point out that we were also excited to buy them for our grandmothers, whom we loved just as much as the pros love their grandmothers, thank you very much. In fact, our grandmothers are too macho to use this thing. Maybe we'll put one on our kid's stroller! So there!
And that's how a great product, one that probably would have changed biking nearly as fundamentally as the derailleur, was doomed from birth because the trendsetters of Mountain Biking Fashion pronounced it a Product for Sissies, and that was that.
Heck, even derailleurs are falling out of fashion in some circles. Go figure. Someone took the time-tested "solved problem" of bicycles, removed something, and wound up creating a new market.
Fashion is generally hard to predict, but it usually means "sacrificing comfort or convenience for the sake of style". Take another look at the iPod: it has almost no features. It doesn't have an "off" button. Heck, you can't even change the battery. Not exactly convenient in many ways. But it sure has style!
Fashion's not the only way your otherwise perfect product can fail, but it's definitely one to keep an eye on.
Less is more... more or less
OK, fine, I haven't exactly been following my own advice about minimalism. But I have been writing my blog the way I like it, haven't I? So even if nobody reads it, I'm still having fun. If you're going to create something that has a nonzero chance of failure — and believe you me, it's nonzero — then you might as well have fun doing it, right?
Anyway, there you have it: the slightly expanded version of the email I sent that CEO guy. Gathering business requirements is hokum. Hooey. Horseshit. Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.
If you can't think of anything in your company's "space" that you personally would use, then you should think seriously about (a) changing your company's direction, or (b) finding another company. This is true no matter what level you're at. You should be working on something you love, or failing that, at least working on something that you know really well.
"But... but..." I hear you saying. I hear you! You sort of get what I'm saying, but you have all these reservations and objections and questions and stuff.
Well, that's what the comments section is for. I'm sure you can think of some other explanation for why Warren Buffett is the richest person in the world. Let's hear it!
But this dude, or possibly dudette, asked me a really good question. One that made an impression. And by "really good", I mean it was one of the flat-out wrong-est business questions you could possibly ask. It was like asking: "How can I get the most out of my overseas child laborer pool?"
There's no right answer to a question that's just wrong.
But his question, well, people ask it a lot. In fact there are whole books that give answers to this inherently-wrong question.
His question was:
"Hello, blah blah, I'm the CEO or C-something-O or whatever of a company that blah blah BLAH, and I read your blog about Agile from almost 2 years ago, which kinda resonated with me in a scary way, inasmuch as I realized perhaps belatedly that I was being duped, BUT I was sort of wondering:(Note: not a verbatim transcript. But close enough.)How do you go about gathering business requirements, so you know what to deliver to the customer?
Signed, blah blah blaaaaaaaaaah."
And my answer was: Business requirements are bullshit!
Well... actually it was: "gathering business requirements is bullshit", plus a bunch of accompanying explanation. But the shorter version sure is catchy, isn't it?
The rest of this little diatribe expands a bit on my reply to this guy. (I actually sent him an email with much of this material in it. When I do reply to strangers, I still try do a thorough job of it.)
Before we dig into the meat and potatoes of today's meal, let's talk about my credentials, and how it is that I am qualified to offer an opinion on this topic.
My Credentials
If you're a business person stumbling on my blog for the first time, welcome! Allow me to introduce myself: I don't matter. Not one teeny bit. You shouldn't care about my credentials! All that matters is the message, which is hopefully so self-evident that if you hadn't already realized it, you'll be kicking yourself.
It's OK, though. Kick away! In fact, give yourself an extra kick for me. Kicking yourself is a great way to remember a new lesson down in your bones. When you get actual bones involved, the painful throbbing for the next few days provides just enough of a reminder that you'll never forget again.
In any case, I make no claim to any credentials whatsoever, and this advice is all straight from my butt. Do what you like with it. The advice, that is.
With my credentials out of the way, let's see about this guy's question.
By the way, I'm specifically addressing this rant towards you only if you (or your team, or company) are building your own product or service offering, or at least defining it. If you're asking consultants to define the product for you, well, you're on your own. Good luck. And if you're a consultant, well, you don't get much choice about what to build, so you're also (mostly) on your own. Although I'd advise you to try to find work that fits the strategy I outline here, as you'll have more fun with it and do a better job overall.
Gathering Requirements 101
It's the first thing everyone wants to do! It's the first thing they teach you in Project Management Kindergarten: the very first thing you should do on a new project is look both ways before crossing the street to your building. Assuming you parked across the street. And the next thing is: start gathering business requirements!
Ah, the good old days of Project Management 101. Life seemed so easy back then.
The requirements-gathering process they teach you typically involves finding some "potential customers" for your product, and interviewing them in a nonscientific way to try to figure out what they want out of your proposed product. Or service. Or whatever. It doesn't really matter.
Potential customers can be hard to come by, especially since you're building something that nobody will ever, EVER want. Well, that's getting ahead of myself. Let's just agree that when you're setting out to Gather Business Requirements, your potential customers usually aren't already sitting in the room with you.
Sometimes it's a lot of effort to go find real customers and bring them in and get them to agree to be grilled for hours. Hence, requirements-gathering sometimes takes the form of "role play", where you get some poor saps in Accounts Receivable to pretend they're Potential Customers for your product, and you interview them instead.
You might be laughing about those poor Role Playing schmucks, but in reality it doesn't much matter who you interview, because by the time you get to this phase in the project, you've already screwed it up beyond all hope of repair.
That process of looking around for customers? It's a plot device that novelists like to call foreshadowing. If you don't have any readily available customers now, then they sure as hell won't be readily available when your product launches.
Allow me to illustrate with a Case Study.
An Illustrative Case Study
See? Credentials or no, I sure can talk the lingo, eh? I also like my incisive use of the popular business term "schmuck" in the previous section. It's a term that can apply to people in all phases of project catastrophes, not just Requirements Gathering.
For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.
Let's say that our Ideas Department has decided that we should get into Personal Nose Hair Grooming devices, because there's clearly a huge unmet need for nose hair grooming, as evidenced by Karl, our accountant, who has a thatch of nose hair that's almost long and thick enough to be a mustache, if only he would groom the thing a little. And we've seen lots of people like Karl. Clearly a nose-hair grooming kit would be the ideal addition to any man's personal grooming lineup, which typically consists of spitting into the sink and thinking he should get the mirror fixed someday.
So we need to gather some Business Requirements. Unfortunately nobody wants to talk directly to Karl, because, well, nose hair can sometimes be a mildly sensitive issue in some cultures. Plus nobody wants to make eye contact with him. So instead we hire some people to go out and do focus-group studies on the subset of people who are comfortable talking publicly about their nose-hair grooming problem, notwithstanding the fact that everyone in this tiny category is obviously too crazy to trust with important business questions.
The focus groups find a few nut-jobs who say: "Yeah, I'd love a nose-hair grooming appliance! Plucking your nose hair is painful, and trimming it involves jamming a small whirly Osterizer thing all the way up to your brain. Maybe if I just combed it into a mustache, nobody would notice!" And behold, we have the makings of some Business Requirements.
The product is a complete failure, of course. The project postmortem reveals that the user studies and focus groups failed to realize that only certain men, namely "men with significant others", ever even notice their nose hair, even when said hair becomes long enough to interfere with tying their shoelaces. The significant other must forcibly remove the nose hairs with garden shears at least twice before the man gets the hint and starts attending to the problem himself.
Not to mention the fact that a nose-hair mustache would be even more obvious and comical than a comb-over. Well, almost.
In the end, it doesn't matter how great a Nose Hair Groomer we build, because we failed at the business-requirements gathering phase: nobody actually wants this product. The people who might want it don't know they have a nose-hair issue, and the ones who do know just trim it.
The thing that might surprise you is that this fictitious (and yet eerily familiar) Case Study isn't just an illustration of how gathering business requirements can go afoul. We're not talking about a failure mode for Gathering Business Requirements (GBR). We're talking about something more fundamental: the GBR phase of a project is a leading indicator that the project will fail.
Put another way: GBR is a virtual guarantee that a project is building the wrong thing, so no amount of brilliant execution can save it.
From Business Requirements to Bad Idea
I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.
People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.
Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.
The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.
That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."
So the experts give you all sorts of ways to try to get at the Right Thing, the thing a real customer would actually buy, without actually building it. You do mockups and prototypes and all sorts of bluffery that the potential customer can't actually use, and they have to imagine whether they'd like it. It's easy enough to measure usability this way, but virtually impossible to measure quality, since there are all sorts of intangibles that can't be expressed in the prototype. I mean, you can try — we sure tried on the OmniGo products — but in this phase nobody "imagines" that the thing will weigh too much, or be too slow, or will go through batteries like machine-gun rounds, or that its boot time will be 2 minutes, or any number of other things that ultimately affect its sales.
And even if you do a world-class job of prototyping and getting at the "real" desired feature set, it still goes through a series of iterations with the engineers and product team, who aren't the actual customers and have little interest in building what the customer really wants (because they're not being measured or evaluated on that — they're evaluated on delivering what everyone ultimately agrees to deliver). During each iteration they push back on things the customers asked for. As the proposal degrades, the customers like it less and less, but they want to be helpful, so eventually they say, "Yeah, I guess I could use that." (Which means: I wouldn't take one of these even if they were giving it away.)
Don't get me wrong: I'm not saying that usability teams can't do a good job. It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as "pretty good" come out "just plain bad."
So I'm tellin' ya: gathering requirements is the Wrong Way To Do It. At best, it results in mediocre offerings. To be wildly successful you need a completely different approach.
The investing analogy
Warren Buffett and Peter Lynch, both famous and successful investors, say pretty much the same thing about investing. Peter Lynch's mantra sums it up: "invest in what you know."
If you actually take the time to read Lynch's books (which I have), you'll see that this pithy mantra is a placeholder for something a bit more subtle: you should invest in what you know and like. You should invest in companies that make products or services that you are personally excited about buying or using right now.
When you invest with this strategy, you're taking advantage of your local knowledge, which tends to be more accurate than complicated quantitative packets put together by analysts. And your local knowledge is definitely more accurate than the reports produced by the companies, who want to paint themselves in the nicest light.
Warren took a lot of heat in the 1990s for not investing in the tech sector. But hey, he didn't feel comfortable with tech, so he didn't invest in it. One way to look at this is: "ha ha, what a dinosaur, he sure missed out, and now he's, uh, only the richest person in the world by a small margin." But another, more accurate way to look at it is this: he's the richest person in the world, you asshole. When he gives you investment advice, take it!
And Warren's advice is: don't invest in stuff you don't understand! Even if it seems like a sure thing.
That's the hard part. Sometimes it looks like a surefire winner for some large group of people that doesn't actually include you personally at this particular moment. But it's a really large group!
Let's say, for instance, that you hear that Subway (the sandwich franchise) is going to do an IPO. They've been privately held all these years and now they're going public. Should you invest? Well, let's see... the decision now isn't quite as cut-and-dried as it was in their rapid-expansion phase, so, um, let me see, with current economic conditions, I expect their sales to, uh... let me see if I can find their earnings statement and maybe some analyst reports...
No! No, No, NO!!! Bad investor! That's the kind of thinking that loses your money. The only question you should be asking yourself is: how many Subway sandwiches have I eaten in the past six months? If the number is nontrivial — say, at least six of them — and the rate of sandwiches per month that you eat is either constant or increasing, then you can think about looking at their financials. If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule of Buffett and Lynch.
The investing analogy is an important one, because if you're a company or team planning to build something, then you're planning an investment. It's not exactly the same as buying stock, but it amounts to the same thing: you're betting your time, resources and money — all of which boil down to money (or equivalently time, depending on which one is in shorter supply.)
So when translated into project selection, Buffett's and Lynch's advice becomes: only build what you know. The longer, more accurate of the version of the investing rule — only invest in what you know and are excited about using yourself right now — has a simpler formulation for products and businesses. That formulation goes like this:
That's the Golden Rule of Building Stuff. If you're planning to build something for someone else, let someone else build it.
Building stuff for yourself
You can look at any phenomenally successful company, and it's pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water.
And the key leading indicator that they're getting ready to head off course? You guessed it: it's when they start talking about gathering business requirements.
Because, dude, face it: if it's something you want, then you already know what the requirements are. You don't need to "gather" them. You think about it all the time. You can list the requirements from memory. And usually it's pretty simple.
For instance, a few years ago I announced to some friends: "I sure wish someone would make a product you can spray on dog poop to make it, you know, just dissolve away." My friends laughed loudly and informed me that this was (apparently) the premise of some Adam Sandler movie I hadn't seen.
Well, OK, sure, but... I mean, they kinda missed the point. I still want the product. Its requirements list is pretty simple. Here's the business requirements list:
a) It should dissolve dog poop.
Gosh. Can that really be the entire list? You bet! Sure, there are lots of implicit requirements: it shouldn't cost a fortune, it should be environmentally friendly, it shouldn't kill kittens, etc. But those kinds of requirements are true for all products and services.
If I knew how to make this product, then Adam Sandler movie or no, I'd probably try to make it. The target market is larger than just pet owners; anyone living near a park would probably own a bottle or two. I would use the stuff like it's going out of style. I'd attach it to my shoes so that every time I took a step it would spray the area in front of me, like a walking garden hose.
Building a product for yourself is intrinsically easier, since you don't have to gather requirements; you already know what you want. And you also know, for any given compromise anyone suggests, whether it will ruin the product. If someone says, "I have a product that dissolves dog poop, but it takes 18 hours", then you'll know you've entered into "prolly not worth it" territory. You don't have to go ask the focus group. You just know.
The Mistake of Imagination
Despite its obvious advantages, following the rule of building stuff for yourself is actually really hard to carry out in practice. Why? Oddly enough, it's ego.
For one thing, people like to think they're unique and special, and that their tastes aren't necessarily widely shared by others. This is what drives fashion: the need to differentiate yourself from "the crowd", by identifying with some smaller, cooler crowd.
The reality is that for any given dimension of your personality, there are oodles of people just like you. If you want something, other people want it too. You define a market: a bunch of them, in fact.
You just have to be smart about which of your needs you want to fulfill, since if it's building yachts, well, it's not exactly going to be mass-market, unless you find a way to build a mass-market yacht. Which would be pretty cool, incidentally. I'll buy one if you make it.
It's also really easy to fool yourself into thinking that this is a product or service you would use, because, hey, you have a great imagination. When you lose your car keys, you can picture them in all sorts of places: the kitchen drawer, the coffee table, on top of the fridge, and when you picture them there, it's just as vivid as a memory. So you wind up looking for them everywhere! Your powerful imagination is pretty much your worst enemy when it comes to deciding whether you'd like something enough to use it yourself.
We all made the Mistake of Imagination on the OmniGo projects. "I could see myself using this product," we'd tell ourselves, "if, that is, I were the kind of person who used this product, which I could sort of envision." You'll tell yourself almost anything to justify the work you're doing. Giving up in mid-project is a big loss of face for an individual, harder for whole teams, virtually impossible for most companies. The OmniGo had four companies involved, making it the hardest possible project to back out of, even though by the halfway point virtually everyone involved knew the product would kind of suck.
What we really wanted, while we were building the OmniGo, was summed up by our brilliant product manager Jeff Peterson. We were having beers one day, and he said, "You know, this thing is just getting way too complicated! It doesn't need a 12C calculator emulator! It doesn't need a spreadsheet! It doesn't need a database application! I mean, come on! All it needs is a notepad, a simple calendar, an alarm clock, and maybe a pocket calculator, and it should fit in your front shirt pocket, and it should be a phone."
It was 1994 and he was describing the iPhone. And you know what? He was right! That was what we wanted. But HP was driving the spec, and they weren't building it for themselves. They were building the product specifically for this imaginary group of high-power on-the-go consumer accountants who use 12C calculators and want a whole desktop suite crammed onto their 1994-era mobile device. And that's just who bought the thing: pretty much nobody. (They sold a few thousand units, which in mass-market terms is "pretty much nobody.")
Trimming the Requirements
Who was it who said that you're done writing not when there's nothing left to add, but when there's nothing left to take away? Was it St. Exupéry? I promised not to do any research for this rant, but I think it might have been him.
Ideally the product you're building for yourself should be simple to describe, so that other people can quickly evaluate whether they, too, want this thing. It's often called the "elevator pitch", because you should be able to describe the product in the time between when the cable snaps and the elevator hits the ground. "Dissolves dog poooooop!!! <crash>" It used to just be the time for an elevator ride, but those investors keep raising the bar.
You can almost always make a product better by trimming the requirements list. We're talking brutal triage: throwing out stuff that's really painful to lose, such as the ability to change the battery.
If you're lucky, you should be building a product that so excites everyone involved that everyone has an opinion, and you wind up spending most of your time in triage.
When you're trimming the business requirements, then you're exhibiting healthy project behavior. This contrasts directly with gathering requirements, which has both the connotation that you're clueless about the product and the connotation that you're inflating the requirements list in direct conflict with schedule, usability and fashion. Trimming: good. Gathering: bad.
Trimming the requirements list is a leading indicator that you're a smart company who's about to launch something major. An ideal requirements list looks something like this:
a) It should dissolve dog poop.
As a great real-life example, consider the the Flip camcorder, which kinda came out of nowhere and "stole" 13% of the camcorder market (although I'd bet good money that it actually created new market share). Does it dissolve dog poop? Well, no, but it's still pretty cool:
1) it costs $150 or less. (A lot less, actually.)
2) it has no cables or wires. Just one flip-up USB connector.
3) it has one big red button: RECORD, plus a teeny one for playback.
4) it doesn't take cartridges or cassettes or discs or cards or anything
5) it doesn't have any controls or settings or anything
6) it stores one hour of video and has roughly one hour of battery life
7) it's about the size of a cell phone
8) it records videos that work well with YouTube
9) it comes in pretty colors
I mean, DAMN, those guys knew what they were doing. We always used to joke about a product so simple that it only had one button, which we pressed for you before it left the factory. That's how simple a product needs to be in order to make the mass market. One button, pretty colors. They nailed it. Talk about a missed startup opportunity. (Flip guys: if your equity plan is still reasonable and you want someone to make your desktop software not suck, and yes, it really sucks, please give me a call.)
You don't need an original idea to be successful. You really don't. You just need to make something that people want. Even if someone else appears to be making something popular, it's usually possible to improve on the idea and grab market share. And it's painfully counterintuitive at times, but the best improvements often come from simplifying.
The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away.
In any event, originality is overrated. Coming up with something completely original isn't just hard to do: it's also hard to sell, because investors (and possibly customers) will need to be educated on what this new thing is and why people would want it. And when it comes to buying stuff, nobody likes to be educated. If the product isn't immediately obvious, investors and customers will pass it up.
It's easy to come up with new product ideas if you start with the understanding that everything sucks. There are no completely solved problems. Just because someone appears to be dominating a market with an "ideal" offering doesn't mean you can't take market share from them by building a better one. Everything can stand improvement. Just think about what you'd change if you were doing it for yourself, and everything should start falling into place.
If nothing else, building things for yourself is more fun, so you're successful regardless of what happens. But it also has great product-survival characteristics, because people can't bluff you into making something lame.
Sometimes you just can't win
By way of don't-sue-me disclaimer, I should point out that building something for yourself doesn't guarantee success. Even if you build a product that most of your target market really really wants, and you hit the right price point and release date and everything, your product can still fail catastrophically.
The example that leaps to mind is that company in the 1990s (can anyone remind me of the name? I've forgotten) that built a mountain-bike seat extender. I ride mountain bikes, yes, on actual mountains, so this product made immediate sense to me. I really wanted one. Sounds like a winner, right?
The basic physics problem this company was solving is that a lower seat position gives you better balance, and a higher seat position gives you more power. It's a trade-off. You generally want more power when you're grinding uphill, and you want more balance when you're speeding downhill. But during a race you would have to give up precious seconds to adjust your seat between every uphill and downill transition; you'd get your butt kicked. Even as a casual rider, adjusting your seat height all the time is annoying enough that most people just don't do it, resulting in some sacrifice of balance, power, or both.
So this brilliant, innovative company came out with a well-made product that lets you adjust your seat height "in flight", as it were, without slowing down, and without adding much (if any) weight to the bike. I don't remember exactly how it worked, but it was a reasonable implementation.
Interestingly, it didn't matter how it worked. It could have been actual magic: a product that read your mind and raised or lowered your seat by exactly the right amount, at exactly the right speed (you don't want it to rabbit-punch you in the nuts, for example — remind me sometime to tell you about how I found that out), as frequently or infrequently as necessary to strike the perfect trade-off of balance and power for any slope, at any time.
And it still would have failed, even if 90% of the mountain biker population, like me, secretly coveted the product. It could have cost fifty cents, been available everywhere, and been installable by a four-year-old with one hand in under two seconds. It could have come pre-installed on all bike models, via a brilliant channel deal with all the main manufacturers (or retailers), and bikers would have ripped the thing off the bike faster than their kickstand (which is usually the first thing to go.)
So, uh, what happened, exactly? Wasn't I just ranting that building a product for yourself, one that you know is the Right Thing for some well-defined audience consisting of people just like you in some dimension — wasn't I ranting that this would always work?
Well, no. It's just the best way to pick projects. But they can still fail for surprising reasons.
In this case, the fundamental marketing force that the company failed to take into account was fashion. People don't often think of mountain biking (or programming, for that matter) as a fashion industry, but failing to understand the role of fashion is a recipe for random disasters.
What happened was this: while they were hyping the product — by demoing it at trade shows, letting bike magazines check it out, and generally working their way towards getting retailer shelf space — the pro bikers took one look at the thing and said: "Hey, looks pretty cool. Maybe I'll get one for my girlfriend. Or my fugging grandma. How much is it?"
At which point, everyone (me included) who had been ranting about standing in line to buy one when they came out, we, ah, we were very quick to point out that we were also excited to buy them for our grandmothers, whom we loved just as much as the pros love their grandmothers, thank you very much. In fact, our grandmothers are too macho to use this thing. Maybe we'll put one on our kid's stroller! So there!
And that's how a great product, one that probably would have changed biking nearly as fundamentally as the derailleur, was doomed from birth because the trendsetters of Mountain Biking Fashion pronounced it a Product for Sissies, and that was that.
Heck, even derailleurs are falling out of fashion in some circles. Go figure. Someone took the time-tested "solved problem" of bicycles, removed something, and wound up creating a new market.
Fashion is generally hard to predict, but it usually means "sacrificing comfort or convenience for the sake of style". Take another look at the iPod: it has almost no features. It doesn't have an "off" button. Heck, you can't even change the battery. Not exactly convenient in many ways. But it sure has style!
Fashion's not the only way your otherwise perfect product can fail, but it's definitely one to keep an eye on.
Less is more... more or less
OK, fine, I haven't exactly been following my own advice about minimalism. But I have been writing my blog the way I like it, haven't I? So even if nobody reads it, I'm still having fun. If you're going to create something that has a nonzero chance of failure — and believe you me, it's nonzero — then you might as well have fun doing it, right?
Anyway, there you have it: the slightly expanded version of the email I sent that CEO guy. Gathering business requirements is hokum. Hooey. Horseshit. Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.
If you can't think of anything in your company's "space" that you personally would use, then you should think seriously about (a) changing your company's direction, or (b) finding another company. This is true no matter what level you're at. You should be working on something you love, or failing that, at least working on something that you know really well.
"But... but..." I hear you saying. I hear you! You sort of get what I'm saying, but you have all these reservations and objections and questions and stuff.
Well, that's what the comments section is for. I'm sure you can think of some other explanation for why Warren Buffett is the richest person in the world. Let's hear it!
posted by Steve Yegge at 12:57 AM
94 Comments:
I find that a lot of Free Software is terrific for exactly this reason — the authors built it for themselves. Their software works for me too because I am very much like them, and if it's not quite right I'll send an email with a patch + diatribe.
The recent fracas over 'usability' in Open Source Software shows that a lot of hangers-on still don't get it. The last thing the community needs is more middlemen: affected 'designers', managers, marketers.
No, that's confusing usability with requirements. To stretch the investing analogy perhaps too far, you should only invest in what you know, but you should let the financial experts tell you if the terms of the investment vehicle are bad.
It's a narrow but important distinction: lots of other people may have the exact same need you do. But it's an unjustified assumption that therefore their brains work exactly the same way as yours and (for example) have no problem remembering your idiosyncratic obscure command-line option syntax.
Thank you for a good portion of laugh and brainfood! :)
Buy this stuff now! It dissolves dog poop. I think I would pay for something that made baby poop not stink. Or maybe stink less.
Your article reminds me of 37signals..
I have HP-15C and HP-16C emulators on my iPod Touch. They sounded cool when I saw them on the jailbreak app list.
I've had the thing for two months, and I've never used those HP calculators.
How did Rock Shox get the cool as the seat extender lost? Now it's difficult to find a decent bike that doesn't go bouncy bouncy...
And this is why every developer who strikes out on his/her own for the first time decides that what the world really needs is either (1) source control or (2) bug tracking.
But it's an unjustified assumption that therefore their brains work exactly the same way as yours
Assuming that other people's brains work differently than your own, and tailoring your work to the model that self-styled 'usablitly experts' imagine they have is even more unjustified.
If you write it for yourself it's perfectly usable for at least one person, and if like the rest of us you're not unique, it's going to be great for a lot of people. If you're writing it for a pretend user, it can easily be perfect only for someone who doesn't exist.
have no problem remembering your idiosyncratic obscure command-line option syntax.
This trope is getting old, and furthermore it's unclear whether you:
a) Are incapable of using CLIs, unwilling to read a paragraph of of documentation, intolerant of a non-flat learning curve, totally dependent on wizards and menu-grazing — ruminant computing.
- or -
b) Have strongly-held beliefs about short vs. long options, whether -- for long options is preferable to -, the use of a solitary -- as an option terminator, the balance of interactivity, the charms of getopts and readline packages, the importance of letting the shell do it's job, --help vs. man vs. info vs. html — enlightened crankiness.
Well, obviously, Warren Buffet is the primary beneficiary of the Berkshire-Hathaway pyramid scheme! ;-)
@ bladself: "If you write it for yourself it's perfectly usable for at least one person"
This assumes an uncomplicated relationship between your observations of yourself and reality.
In fact, people convince themselves all the time that they've created something perfectly usable when in fact they're wasting time and driving themselves crazy.
Or at any rate, I know that I'M not a very reliable observer of my own self. But perhaps I'm making an unjustified assumption there.
Assuming that other people's brains work differently than your own, and tailoring your work to the model that self-styled 'usablitly experts' imagine they have is even more unjustified.
Well, actually, no. Usability can be objectively analyzed and evaluated, and developers are notoriously bad at it.
But that's not really the point I was trying to make. Steve's post is not really about software construction, but about requirements, and you conflated the two. Building a tool that meets a need you have is one thing. Making that tool easy-to-use for a lot of other people who have the same need is a different discipline.
The problem with everyone eating their own dogfood is that there will always be some class of people with product needs that cannot make dogfood. Who speaks for them?
Usability in open source projects is a real problem, since nobody incapable of building software themselves will be able to use it. You may not care as a software snob. You may even call these people idiots. But you can't deny that there's unmet market need.
The real key is the the presence of the really talented designer (a la Steve Jobs) that can actually step into someone else's mind and figure out what they want. As of right now, this process is magic; hell, we call it "taste". Steve is right that interrogating potential customers to gather business requirements doesn't work for this purpose. (See Malcolm Gladwell's Blink.) However, saying that we shouldn't even try is wrong. We need to do the work to distill "taste" into craft, and then into engineering discipline.
One thing missing about the 1994-iPhone: it needs a decent keypad. My phone technically does everything listed, but I only use it as a calculator and phone, because 10 keys just aren't enough for text.
Most software developers (like me) are in-house programmers that develop products for other people. We can't all quit our jobs to start companies like 37Signals because... well... we are needed! Sure, we are unappreciated and underpaid, but we are soooo in demand!
It's like that movie where all the Mexicans disappear from California overnight and the state basically screeches to a halt.
Anyway...
I think the solution for us is to actually get to know our "customers" and work with them, using their software. Basically, we need to eat our own dog food. Only then can you really build something for yourself.
…there will always be some class of people with product needs that cannot make dogfood. Who speaks for them?
Nobody is, and noone ever will. Using 'user stories' and the like is just pretending, writing software for a lie. At least writing software for yourself is honest.
The real key is the the presence of the really talented designer (a la Steve Jobs) that can actually step into someone else's mind and figure out what they want.
That's just the thing, the developers at Apple are making software for themselves. They happen to mostly have good taste, and generally prefer to avoid using a terminal emulator for everything. This leads to great GUI software, because they use it themselves — they put a lot of effort into engineering a clever system of objects and messaging to enable their construction.
Steve Jobs does not have any particular insight into average people, he and his colleagues are just good at expressing their own taste.
We need to do the work to distill "taste" into craft, and then into engineering discipline.
That is simply not possible. Apologies.
That I guess neatly sums the whole thing up
People will use a tool that meets their requirements, but they will prefer a tool that is wonderful to use.
The first you can solve yourself by being the first to market a tool you want but no one else can give you. (this is also one of the successes of opensource - there is no market for free (beer) software product before the first open source effort. Even if a dozen companies sell it)
The second requires that you are a talented, fanatical insanely obsessive designer and have 'taste'
Chances are you aren't.
So omnigo could have taken the market for a barely-usable phone and contact book because no one else was doing it then. One mans requirements could have built a whole market.
Now, you have to have taste, style, sheer X factor. ie you need that one man to be Steve Jobs.
It was actually a Ben Stiller/Jack Black movie with the dog poo thing, not Adam Sandler.
Requirements are really just a by-product of analysis. The farther you personally are from the problem the more likely you'll mis-interprete what you're seeing.
More things are far more irrational or random than people think, or want to admit. This causes heavily biased requirements to be useless or incorrect. The trick, I think, isn't to not do them, it is to be very careful that all of the underlying facts are really just facts. And to know that even if you understand the problem, and the domain, there still might be unexpected side-effects that keep the idea from be accepted.
Paul.
http://theprogrammersparadox.blogspot.com
NAMING the product is as important as PLACING the product. Literally everyone who bikes knows about RockShox (even if they misspell or mispronounce the name as RoxShox), because it has a cool, catchy name.
But, someone who I guess bikes as often as Steve claims he did (does?), who cannot remember even a single detail of the seat adjuster's marketing attempt, however feeble, has no chance of vindicating itself in the market place.
Is there a real need for a seat adjuster? I'd say yes -- I'd buy one too. But, they had a non-memorable product.
This ties right into fashion of course -- they failed to make their product fashionable.
So, the question is whether everyone on the team has to be building the product for themselves or you'd get by with only a couple of people who want it. Or maybe even just one person. But it has to be someone you respect who is in charge of product decisions and can argue the team out of stupid compromises.
And, just maybe this is what the XP folks meant by having an on-site customer. Originally it was someone building a financial app and they got a real stock analyst to sit with them and built what he wanted because he was obviously smart and knew what to build. (And what not to build. The other big part of it is that you make the customer do triage.)
And that worked, so they made that a rule and it got watered down to "gathering business requirements" from not-so-smart customers or making the product manager pretend to be a customer, because actually finding a smart customer and making him or her part of the team is too hard for most people to bother with. (Or else they're building something nobody wants and can't find one.)
The quote you're looking for is indeed from Antoine de Saint-Exupéry. It's not specifically about writing, but about airplane design, the airplane being something that Saint-Exupéry not only used and loved, but wrote passionately about. The quote is from his memoir, Wind, Sand, and Stars:
"In anything at all, perfection has been attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness."
IMHO Once you abstract yourself away from a clear motivation you're inevitably screwed as:-
a. It's the small things that count when it comes to quality - there's absolutely no way you're going to get that right if you don't have an intimate understanding of what you're after,
b. Since most software projects end up pear-shaped there's no way developers who simply don't know what will make the product work are going to know what to cut and what not to cut at the crunch stage of the project.
I'm probably repeating what you've said, but that's my perspective regardless!
That was a long post, and I read the whole thing. Why? I enjoyed it, and it resonated with me. I think you nailed it. Good job!
@Larrik Jaerico:
I believe that was part of the joke about how little research he was putting into the post.
I love a good rant, thank you!
One has to be careful when dispensing such advice, of course. In my time with software I've learned to value people over process. A great process will not allow a mediocre team to produce a great product.
So, when folks ask about process, you need to ask the tough question. Are you asking about process for great people, or mediocre people? Of course, you can't win, because everyone will tell you they have great people. Most mediocre people I encounter can't recognize their own mediocrity. An ability to do so would almost immediately make them great. Interesting, huh? (BTW, I am *very* mediocre <g>). But I digress.
Is there any advice we can imagine that would enable Mr. or Mrs. Clueless Executive Overlord to transform themselves into a Caring Eloquent Orator capable of assembling, inspiring, empowering and rewarding creative product teams? Is it just my cynical side believing that we must deliver a cruel diagnosis? "I'm sorry, the fact that you've even asked this question indicates you don't have the capacity to understand the problem. You are afflicted with terminal mediocrity. There is no cure. We're sorry."
The late animation director Chuck Jones, whenever asked about the enduring popularity of the great Warner Brothers cartoons of the 40s and 50s, would always respond, as in this interview:
Interviewer: You never really made them for children. You made them for a general audience.
Jones: We didn't make them for anybody, we made them for ourselves, which was probably the most sensible way to do it anyway.
The mountain bike seat adjuster thingy is called a Hite Rite and was produced by Wilderness Trail Bikes (a/k/a WTB) in Marin County, CA. WTB would be Steve Potts, Mark Slate & Charlie Cunningham, all pioneers in the "mountain biking" "industry". Here's a link to what appear to be dead stock Hite Rites.
Also, I think the device is from the 80s not the 90s.
The seatpost extender gizmo was called a Hite Rite.
While you say collecting requiremnets is bullshit you are actually advocating collecting requirements... from yourself. It is true that this is the best and most pain free way of collecting requirements... because you are the requirements.
It might be more helpful instead of saying you should throw out the whole requirements gathering process and instead tell people you should "become the requirements" Cultivate the ability to step into the place of the customer/user/whatever and see the world from their eyes. If you can do that, you don't need to explicitly gather requiremnets from them. The requirement gathering is an internal process.
If everyone followed your advice nobody would be willing to take big bets just a string of minor improvements on smallish stuff. Who is going to design the next power plant, jet engine or even the next printing press? If you want to limit the discussion to software, are circuit designers going to design the generation of circuit design software?
Stevey
This is a mail a consultant project manager sent us on the day the project went LIVE!
Hi XXX,
I really need to focus on finishing the requirements document. Because of this, I will be working from XXX today in a conference room where I won't be distracted. I feel that we all know what needs to be done today and tomorrow so I may not be needed.
If anything comes up, please give me a call on my cell phone.
Thanks,
--
Name Withheld, PMP
Project Manager
XXX Global Services, Microsoft Practice
I don't see how to apply this device to many non-software areas like pharmaceuticals or cars.
In the case of medical products, I may not be the beneficiary of the end result, the patient is. The doctors are usually the customers who know what kind of product they need, but the doctors may lack the technical expertise to design and implement the product itself (e.g. an ultrasound machine, or MRI scanner)
Even in the case of cars, there is a problem. Cars are not designed and built for one person, nor engineered by small teams. The cost of the process from end to end is too great, so a car is in fact, the intersection/union of many people's desired features.
Thus, your advice makes sense for small software projects, where the time horizon to implement, and cost of implementation is low, but it doesn't make as much sense to spend 5 years and lots of $$$ on something only for yourself unless a) you are only doing it for fun or b) it delivers a staggering productivity boost for yourself.
I think this is just another version of the dogmatic Paul Graham school of thought, which is that the best way to run a business is to just hack on stuff and hire hackers. Sometimes it works, but there is no evidence that it is more effective than other techniques, just more palatable to geeks who hate business types.
Your advice is fine for a consumer product, like a hand held organizer or web search, but what about products where the engineers are not the domain experts? Medical products, weapon systems, aircraft cockpit instruments, dentist billing systems, analog RF simulation software etc. etc. You can find knowledgeable people in all these areas but they are rarely the same people that build the software.
Considering the amount of companies who has no chance to build their own software - yes, it sounds weird, but there are a lot of those -, and for that reason they actually go to companies who can build softwares, your "build for yourself" part does not work all the time.
And then, if a company comes to you and says "hey, I want some software that helps me to do my work" you would say, "ok, I don't care what you need, 'cause requirements are bullshit, here is a rubber duck I bet it will be good"?
Your idea work really, really well in case you have an internal department to build software, unfortunately it is not that widespread at the moment.
I agree you on the bit where you start to gater requirements for an imaginary market and then try to sell the result somehow, but I guess when an actual client comes to you with an actual problem, you should let him explain their business and other requirements.
Like the guy who builds your kitchen furniture lets you explain what you want, and does not just pop in a general and ugly black and white hack.
I guess I'm one of the few thousand people that bought an Omnigo. I was working at HP as an intern at the time and I had a modest employee discount, but I really did want it. I fiddled with it quite a bit and used it to take notes in college classes. I used all the features, etc. I still have it somewhere.
Looking back, the only reason it failed to hook me was lack of seamless PC integration. Losing memory once a week or so (at least that was how it felt) was a real drag, and entering information on it was painful (would have been much easier on a PC). I didn't mind the size, since I usually had a backpack but perhaps that was a limiting feature for many. I don't remember 12C emulation, I'll have to turn it on and look at that!
Anyway, I think this post raises a good point, but if successful product design could be boiled down to a blog post the world would be a cooler place.
One thing that Steve doesn't highlight but that I think is crucial to understand is that with physical products, it hardly matters how good the software is. The physical interface makes or breaks most products. You can't code up a cell phone. The difference between an IPod and dozens of competitors is that they picked a simple physical interface and then did the best job they could with the software given the limitations and capabilities of that interface. MP3 players with fidgety little joysticks and multi-purpose undifferentiated buttons didn't stand a chance once the IPod came out, even if they had more features, better sound, and much, much longer battery life.
As an example, I have a bluetooth phone with Windows Media Player Mobile and a 4GB micro SD card. I had to buy a $15 dongle to turn the proprietary jack into a stereo mini-jack. After the initial exploration period wore off, I stopped using it as a music player. Why? Because there were no dedicated buttons for music, the app took many button presses to launch, and the phone was liable to dial some random number if I put it in my pocket unlocked, meaning that I had to unlock and re-lock the phone every time I wanted to interact with the player.
However, I later bought a stereo bluetooth headset with dedicated forward/back/pause/answer call and volume buttons, and now my phone is a joy to use for music (when I have the headset.) The headset doesn't work with sunglasses well, but that's another issue! It's amazing that some MP3 player makers haven't learned this 6-year-old lesson about portable device usability.
Cool, agile, minimal, etc.
But does requirements-free, spec-free really work when building a complex multi-part system with dozens of dependencies?
Your argument works for the Flip, or a streamlined minimal apps like Basecamp, or Twitter, but does it work for a Mars rover?
Recently read Beautiful Code (http://oreilly.com/catalog/9780596510046/)
Looks like to build Mars rovers you absolutely need Enterprise JavaBeans!
You, sir, have absolutely NAILED it. People get so caught up in thinking about wat to build that they lose sight of the actual problem space. Without a definition of the problem you are trying to solve, anything you build/design/thnk about will be wrong.
Thank you for this post.
"Even in the case of cars, there is a problem. Cars are not designed and built for one person, nor engineered by small teams. The cost of the process from end to end is too great, so a car is in fact, the intersection/union of many people's desired feature"
Ray, not really. The 'what I want role' for a complex endeavor can be filled by a Chief Engineer or an Architect. Chief Engineer how Toyota roll for the mass market; for marques, there is usually one person that owns what the car will be and everyone else works to that vision. Architecture is how industrial design, building and big works engineering gets done. It's how Apple do things, mostly via Ive and Jobs.
In software, we would like to have that, hence there is a discipline of architecture, but software architects don't really work like actual Architects, mostly because they don't take total ownership of the end result.
What Stevey hasn't figured out here is how it's possible for great work to get driven by people who can't actually build it. But this happens *all the time* and the excellence of the rant can't paper over this ugly fact. So when he says hire domain experts, he's nearly not wrong - it should be - hire domain experts who care enough to learn how to code. That way you get things like Rails.
Great, brilliant post. Thanks for sharing.
It seems to me that sometimes an idea simply appears before its time, before the public at large is ready for it, and suffers accordingly. (The Newton versus the PalmPilot come to mind.)
Come to that, the adjustable seatpost is not quite as dead as you think it is. It has returned, now anodized, and from a different vendor (who apparently licensed it from the original).
It's the Crank Brothers' Joplin, its history outlined by Competitive Cyclist. I just received one, but haven't had a chance to put it through its paces yet.
Lots of people have already pointed out that if everyone followed this advice literally there would be few advances in the medical field or software for running stock markets or many other products that the world obviously needs. However, in rant form this is a great bit of advice. One simply has to read through the rant to get to the underlying idea: If you need to gather business requirements, then you have already lost.
How does that work? Well, no matter what you are building, if you don't already have more business requirements than you can shake a stick at, then you are the wrong person to build it. It isn't required that you use the product. But if you are going to have a successful project, you need a pretty strong opinion about what you are building, and ideally a customer or three who are not just willing to talk to you, but positively demanding that you deliver them the product right now.
If you have to go looking for your requirements, apparently you don't know what you are building, you don't know anyone who wants what you are building, and anyone you do know doesn't want it very much.
You don't have to personally be the customer. But if you have to form focus groups in order to talk to people you hope are something like customers, you are in trouble.
Do what you like with it. The advice, that is.
Classic.
Great post, Steve.
"At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts."
I don't think this is an "at least." You said the bike seat failed because of fashion. Don't you think that if someone bothered to ask the guys at the magazines what they thought of their product, they could have found this out ahead of time?
This is what everyone is TRYING to do when they "gather information," and the mistake they make is asking the wrong people for advice.
Well Dehora already kind of said this, but I wanted to expand.
IMHO this idea *does* apply to cars, airplanes, medication...it doesn't matter. Why? Well, if you're working on a dashboard for a F150 Truck - are you someone that likes trucks? If you think trucks are for rednecks as you sip your latte, then LET SOMEONE ELSE work on the dashboard for the darn truck, because YOURS WILL SUCK!
Power plant? What would you want in a power plant that you would have to live next to? Should it be noisy? Big 'ol honkin' power poles everywhere? Maybe buried cables? (Sure, there's budgets involved, and you can only do so much, but you can try - which most people building power plants don't even attempt)
Medication? Easy - "Cure the illness such that the cure is better than the illness". I think we've all taken medication. We know good from bad, and we all know why. So - you're a research scientist working on a cure for an illness something you've never had? Bet you'd do a better job if you had - or if your mom had it.
Actually, I think the real issue with this method is you run the risk of making *too* good of a product. In medicine, if you create a perfect cure, the patient only needs one dose. If you only kinda solve the main symptom, people will need to take it daily for the rest of their lives. You're the CEO - which do you prefer? (Same for cars. Build a perfect car that lasts forever and is perfect-in-every-way, and it'll never get replaced).
So, I absolutely agree this method will work for *ANY* product, success doesn't guarantee profitability.
Nice post. I actually built a 92ft boat. Wouldn't call it a yacht but it is a successful business. Like you said no need for bullshit, already had customers and wanted a bigger boat.
Absolutely brilliant post, I love it. The emphasis no building things for yourself, and being excited about things that would make _you_ excited is dead on.
Blasdelf your comment is very good. I'm a fan of Linux/FOSS, and they're great for that very reason.
The most successful software I've written I wrote for myself. Others observed me using it, and wanted to use it themselves. Remove my idiosyncratic personalizations and it was complete. Everyone was after it.
You've taken the prevalence of bad analysis and design practices as evidence that they simply don't work. Doing it correctly requires a deep understanding of the problem domain, of the people who will use the product, and what technology can do. Yes, most practitioners are terrible, but it's brazen ignorance to state that analysis and design (requirements being the output thereof) are bullshit.
My experience with developers (and I include myself when I was one) has been that they are good at building things right, and not so good at building the right thing, except in the narrow space of products that programmers use. They can build what they want, and they can build what a customer says they want, but they are not effective at listening to what a customer says they need and figuring out what that actually means.
Because most clients, if you ask them directly what they want, will describe a solution based on their own flawed assumptions about technology, and they often don't understand their own problem very well.
If your sales force is saying they need a new order entry application because the one they have is slow, and you take them at their word and start building one, that's just plain stupid. Maybe it is simply difficult for them to use. (They are sales people, after all, and they use the system infrequently.) Why the fuck are the sales people entering orders anyway? Is that something customer service can do? Can the customers enter their own orders? Your going in assumption should be that whatever solutions your clients propose are at best illustrations of some of their concerns and not the actual requirement. You have to look at their business, at what they do, at the people and processes surrounding it, at the larger context in which it all happens. Otherwise you're just wasting time.
My experience has been that people who can do this well are rare and they aren't programmers at the same time they are analysts. Many were programmers, and some may go back and forth, and on small projects it doesn't matter so much, but for complex requirements it is damn near impossible to keep both models in your head at the same time and retain the necessary objectivity. If you're thinking about the code, you're going to gravitate to solutions you want to build and not the solution best suited to the problem at hand. You need to be grounded in an understanding of what is technically possible/feasible, but at the same time you need to forget about that and pretend you have magic fairy dust and anything is possible. This paradoxical thinking tend to hurt your brain and the end result has to be something doable, but it allows you to explore a solution space much larger than a "what can we build" mindset will afford. There are some developers who can do both, but you don't get many opportunities to hire them.
In the consumer space, it is the same, just fucking harder still because consumers haven't got a clue what they actually want or what technology can do and if you only target those products that developers would use and understand, then you're severely limiting your target market.
Look at a company that does this for a living well and you'll see that it can be useful. Apple gets it. How their process works exactly I don't know, but I promise that someone is doing "business requirements" in the sense of thinking deeply about what problems they are actually trying to solve for who, and how the product will actually be used in real life. When I saw the iPhone for the first time, my immediate reaction was "Apple is going to make a big pile of money" because they were the first company to really nail the requirements in the cell phone market. Everyone else previously was just building what their developers thought would be doable/cool or under the sway of designers who didn't know what they were about.
Or if you want a more generic example of someone who at least has a chance of getting it right, look at Cooper design. They have some concept designs posted on their website that are, in my opinion, examples of what a "business requirement" should look like. Note that while the designs could be built, there's nothing in the requirements about how they should be built and there are some interesting business and technological challenges that would need to be overcome. I would suggest that many or most successful technology products (iPhone, again, for example) are the result of solving such interesting challenges and therefore one benefit of good requirements is that they can direct our attention to the problems worthy of solving if we want a successful product. Too often we invest time in optimizing or creating features that nobody actually cares about.
Anyway, aside from being completely wrongheaded and misinformed, nice post.
I sort of see what you're saying, but how does it fit with the way we work;
I work within a large software company, working on a single piece of enterprise software that is used by hundreds of clients, all paying for developments to the software. These modifications are agreed months in advance of scheduling for development, through a process where requirements are discussed with the client, estimates given, specs drawn up and negotiated over etc. If the clients aren't going to give us their requirements of how they need the software to work slightly differently in some area of functionality, where are we supposed to get them from - guess? / run their business for them so we have the same issues?... The way our business works just doesn't fit with what you are saying.
Enjoyed the rant tho, ta
@Michael Head - You can find fully rigid bikes, but it's a niche market. Same as single speed or fixed gear bikes. The reason suspension caught on is because it had a direct and undeniable benefit to riding more extreme terrain faster. The seat extender is really just about convenience.
@entaroadun said...
"Usability in open source projects is a real problem, since nobody incapable of building software themselves will be able to use it."
Are you serious?
By the way Jobs is very skilled at persuasion and salesmanship, but he has not so much to do with the design of the latest apple products.
Okay, how many of you kids would like Itchy & Scratchy to deal with real life problems like the ones you face every day?
And who would like to see them do the exact opposite, getting into far-out situations involving robots and magic powers?
This comment has been removed by the author.
that's just awesome.
I'd love to translate it to Russian if it wouldn't so lengthy. ;)
I don't understand. My previous job, I worked on a transaction processing system for our company. Our demands were unique, so bespoke software was the only viable option (previously we'd tried using off-the-shelf systems but they were a poor fit, hence the internal development).
None of the developers were accountants. We knew how the business worked in broad terms, but there were specific details which we didn't know, and had to learn from the accountants. They were business requirements, and I cannot understand how they are "bullshit".
I think also it would be pretty retarded to demand that everyone at a pharma company has cancer or AIDS or whatever else before they look for a cure. If other problem domains can establish business requirements successfully, it suggests that the problem is not business requirements at all.
As mentioned in the very first comment, make-what-you-want has been how good Open Source projects start since AFAIK forever. This blog kept sounding to me like a pithy distillation of The Cathedral And The Bazaar.
Great post, very succintly put.
I think Steve's premise makes sense in the context of creating products, but not all projects are about creating products, as drpizza's comment demonstrates.
If you are building a custom solution for a company that has a specific need, it is far easier (and obviously far more necessary) to gather business requirements, or whatever you want to call them. I generally prefer to call them business rules, because it helps the customer to visualize that what they tell me is going to be enforced or carried out in the system--in as precise a manner as they are capable of explaining to me.
But a product is more of a general thing, and much harder to nail down if you don't "own" the concept. I have worked on projects to create products, and projects for specific business solutions, and I agree completely that building a successful product HAS to be a labor of love, and no amount of focus groups and marketing consultants is going to change that. I suppose the one exception to that rule would be those who get a real kick out of duping the gullible with pointless products that do nothing but extract money and dignity from the customer. But that's another story.
Voltaire said that a book is finished not when nothing more can be added but when nothing more can be taken away.
Well...I at first had to double check where I was reading this from...this is a guy I know who only says smart things right?
Well after reading in between the lines I 'got' what you were saying, but I can definitely see where those of us involved in the IT shops out there could read this wrong if they don't know Stevey from previous posts or read this post in its entirety.
Don't forget - we're not writing software for us and we have to hold people's hands and bring them to a room and write everything down for them to sign off on (otherwise they'll never say that's how they wanted the system to work and it's a bug). IT is a whole different animal from writing the type of software mentioned here; in my opinion at least - and in IT you need business requirements to CYA and keep projects from going on indefinitely.
Steve, it seems that after praising rails you continue to borrow from the 37signals book:
Build less and
Solve your own problem
By the time every knucklehead in the production chain has Chinese whispered their agenda into an original idea that shoulda worked the end result is a coding camel that will never work. Like ... [insert example that just came to mind here]. You know the one.
Solution - remove all the knuckleheads and/or remove their effect.
Everyone keeps pointing to the medical field as somewhere where this wouldn't work, but that's not true at all. If you look at the history of medicine, the different imaging modalities were all created by people playing with awesome/fun tech (plain x-ray, CT, ultrasound, MRI, SPECT, and PET) and they managed to figure out a way to actually use it to help patients AND make their work easier. In fact, pretty much all the major advances in medicine worked this way (vaccinations, penicillin, coronary artery bypass graft, coronary artery stents, etc.) The general thought process is "how can I best help the patients who I'm taking care of." And to have the highest likelihood of succeeding you probably have to implement the process or prototype the machine yourself, because no one else will care.
Surely what Steve says sounds like crazy talk to many but it rings true for me. Could it be that a major contributor to this "requirements" problem is a wrongheaded approach to education? I happen to think "modern" education from preschool right up through university is broken because we concentrate on preparing people for jobs they "do" instead of firing peoples' passions.
Requirements are just the future features. You have to imagine them.
So you can't gather them, you have to design them. The future features are always desirable once they are seen. Show the customer the features and they will immediately claim: "Yes, I want that. That's a requirement. So it must have that little slider for the energy level, and a dial for the timer, just like an egg timer...."
Otherwise you are going to build a yet another microwave oven with an digital watch logic interface that can reheat fried camel's liver with one touch.
*Someone* has to build software for people who have a need and can't build it themselves -- see Alan Cooper's The Inmates are Running the Asylum for some good ideas on how to do it (and it takes more than just focus groups).
I see where you are coming from. But unfortunately, not everyone can write software that they are going to use. I write software for radiology and the last I studied biology was 12 years back, let alone any radiology. Yet we have to get into the brains of the radiologists and understand business requirements. What do you have to say about this?
Swati
(http://differentworld.blogdns.org)
This reminds me of something I derived from an article by John Gruber, and it's something I am sure others have "figured" out as well. But the way I see it whoever is in charge get what they ask for / demand. If you ask for status reports, you get status reports, if you ask for business requirements, you get business requirement, and if you demand a kick ass product, you might just end up with exactly that.
This thinking ties in really well with Mr. Yegge's ranty rant. To know what to demand, you need to know what you want, and to know what you want, you must want it.
I also feel that a lot of the comments here seem to think that whoever want the product, and demands it, also has to be the one making the product. I don't think that is necessary. Good old Jobs is a good example of that. He wants to stand on the stage and hold up the latest Apple product and say "we rock, we ownorz you the Dells and Microsofts" and that is what he demands. He doesn't need to know how to manufacture or design an iPod, nor how to best make use of a NSTableView for high performance. He just needs to know what he wants, just like John Cleese as the pope :)
Not to attack anyone personally, but that's the reason why most medical software sucks: unless they are/were practicing physicians themselves, the people doing the programming have no way of getting into the minds of the people who use it, and then we have to endure craptastic EMRs and CPOE systems, until someone complains enough, and then we get something slightly less craptastic, until *that* collapses under the weight of actually usage. Is there a solution? Certainly nothing cheap or easy. But there are plenty of people in the medical field who also know how to code, and it's no surprise that the better packages out there (by no means even close to perfect) come from these folks.
ROFLMAO! This stuff is hysterical!
1. "I find that a lot of Free Software is terrific for exactly this reason — the authors built it for themselves." I find that a lot of free software is unusable for exactly this reason - the authors built it for themselves, and don't give a rat's patoot about documenting for others how they imagine in their genius minds how their product should function.
2. These comments sound like they came from the same mind as that Rails developer who opined that he couldn't imagine an application having more than 20 tables so what's the big deal if Rails can't support large schemas. This faux-libertarian naive hacker mindset, in which everyone can and should "do it themselves" in a world where we all are responsible for doing our own brain surgery ("Why farm this out? After all, it's YOUR brain, isn't it? Take responsibility!"), is just getting old. Some things just are complicated, and no one person gets the whole picture, especially in a real business enterprise environment and not a "look, I made another to-do list app for the iPhone" world.
Does this mean we abandon all complex projects in which (horror of horrors) research and analysis actualy need to be done to figure out and accommodate the needs of multiple interested groups of people, not just other hackers who think your to-do app is neat? I would imagine not, but I could be wrong.
The requirements derivation process is still very broken. But saying "we don't need to have requirements at all" is not an answer, it is an abdication.
undisonus, that cuts both ways. There is also no end of crap software written by "subject matter experts" in this or that vertical industry, and this goes twice for the medical field, I think. ThedailyWTF.com is full of such stories. Think of the kind of software produced when a few doctors get together and decide that they have the expertise, so all they need to do is hire a "computer guy" to make it happen. The problem is, they may have the domain knowledge, but they don't have the judgment to know who is the right sort of programmer to hire. So you will find the vertical software industry rife with misplaced people: someone who did a few Microsoft Access databases suddenly finds himself tasked with creating a full client-server-database system to coordinate records between multiple medical offices, for example, or maybe even an accomplished old-school C coder finds himself struggling to write a web/AJAX application.
This goes back to the programmer, of course. Programmers love a challenge, and it is very tempting to throw oneself into a new field with a fresh set of problems to solve. And of course, you can grow tremendously as a programmer by doing such, and some fields can benefit greatly from a fresh perspective. But that only works when the programmers and the experts have enough savvy to identify competence in each other, and to know that fine line between recklessness and courage.
Chad and Swati make the important point here - imagining that everyone can and should be creating their own software for their own needs is not just native and pollyanna-ish, it's downright dangerous. The genius hackers who don't care whether their software is understandable by others, who shout "then write it yourself!" at people who criticize them, doubtless they get their cars fixed at repair shops, their long distance plane flights conducted by professional pilots and airlines, and their ailments dealt with at doctors' offices. (Unless they choose to be their own brain surgeons...) Perhaps for a small number of such people their sexual needs actually involve interacting with other people, too. :-)
I make light of this behavior and attitude, but the point is that DIY has its limits. We live in a world with other people, and unless your a libertarian militia mountain man type in a cabin in the woords, your life depends on interaction with other people. You cannot and should not (despite what these mountain men may bellow out while beating their chests) be expected to do it all for yourself. That's why we have specialists in the world, and work together with them to facilitate improvements to our lives. As long as this is true, there needs to be interaction between people and communication to convey ideas and requirements for real-world projects. Much as this may upset the anti-social types in our profession, it is the way it is. The process of conveying those requirements, as I said, is far from perfect, but it's all we have for the moment, and in a world where we ARE dependent on each other, improving that process is key to success.
In an excellent book from 1990,
Wicked Problems, Righteous Solutions, the authors say that getting to a righteous software solution requires someone whose head is completely wrapped around the problem and the code. This guy has to know what needs doing, and also how the code is architected and implemented.
Your diatribe against unfocused requirements-gathering seems to reiterate this point.
So, after telling us all what you told this C*O, one question still lingers: did this person respond with an awestruck gasp of epiphanous wonder saying "yes, I get it now, I should stop seeking to have business requirements defined for the projects my company is working on!"
Or... did they ignore you and look for someone with actual real-world experience and wisdom on the imperfect subject of building complex real systems for complex real people?
You didn't say, so I have to assume the latter. :-( The question is, why doesn't this matter to you? Or does it?
Gosh, Dodge, what an ironclad and compelling argument! Thank you for sharing a thimbleful of your boundless wisdom with us, the unwashed masses.
It's true, no one has time to do all these things on their own, but the important thing to realize is that letting someone else do it is a compromise. That compromise involves dealing with crap that you don't actually want. That's life.
So we slog through non-ideal situations where we know there could be something better. Thus, we have things like Windows, and the ancient x86 architecture.
But this disconnect between implementor and user is a significant contributor to the reason why the field of medicine has been slow to adopt new information technologies, and why it hasn't really benefitted significantly from "computerization." There are some young physicians and nurses who sigh with relief when the system actually goes down and we can get work done with simple paper orders and phone calls. It makes documentation hell, but we don't have to fight with the stupid computer.
But if you actually want to make something that'll stand the test of time and actually fulfill the needs of audience/target user/target demographic, you have to do it yourself. Perhaps the best EMR/CPOE system out there is the one deployed by the VA: VistA/CPRS. This was entirely an in-house development and was motivated precisely by the desire to cut the administrative crap and just get something up and running that would actually be helpful, and not a pain-in-the-ass hindrance. Sure, it's got its headaches and its annoying behaviors, and it's absolutely broken in a lot of ways, but I don't think anything out there even approaches it in applicability to clinical practice.
I hate to say this, but I think that what you have done is to distinguish a good requirements gathering process from a bad one. You certainly have to have engineers that understand the domain well enough that they know how to lead implementation of the requirements, but they won't have time to be out and about meeting 1001 customers to get a feel for what should be in the next release, and talking to other business groups you need to integrate with. And, you need to be able to plan with accuracy a launch, and very likely that launch will be coordinated with other complementary product releases so a lot of planning is needed.
So, I agree that requirements gatering can be done badly, and often is. I would say the worst possible scenario is where the engineers don't accept the necessity for and the validity of the requirements, but just go their own sweet way.
FYI, your Subway investment analogy is a poor one. There's a classic business case about investors in the Au Bon Pain bakery chain; since people liked their croissants, they thought they were experts...as it turns out, eating there several times a week didn't give them insight into the company's management problems. A lot of folks lost a lot of money as a result.
See section 4 of this CNN/Money story as reference.
You might even consider this business case to be a general counter-argument to your thesis.
Yes, for every rule there is an exception and the only rule without an exception is 'for every rule there is an exception'. So it in itself is its own exception, which therefore proves its own premise that 'for every rule there is an exception'.
[dizzy]
Your critique of the 'Subway investment analogy' is poor. You are pointing out an exception.
Perhaps the buck doesn't stop at just using the product yourself. Maybe you still need to do your homework on the market but I am still going to stick with Warren Buffets advice over yours 'Latex'.
Back in the 80s a classmate shared a little known beverage called 'Snapple' with me. I thought it was great. And when I was given a chance to invest some savings money I had, along with my older brother, I put about $400 in Snapple. He put his $1200 in IBM. In 2 years we both had $800. ;)
(PS. I am sure you can find an exception ... but IMO don't bother)
I'll second the recommendation for The Inmates are Running the Asylum.
Some of your ideas sound familiar, have you read Maeda's Simplicity?
I really liked your statement about taking somebody else's idea and removing something.
The perfect combination seems like above "Build What You Know/Like/Need" + "You Ain't Gonna Need It" = Nirvana.
I've worked in the past for a few crusty old-timers whose attitudes I regarded as quite Philistine at the time, but whose wisdom I've come to appreciate.
My two product examples couldn't be more different: one was a roofing product and the other was a piece of software.
At Owens-Corning Fibreglas, Al Marzocchi (the inventor of the fiberglass-reinforced tire) had me work on a flexible roofing product. I wanted to do all kinds of lab testing. He wanted to find someone willing to pay for it (with a money-back guarantee), put it on a roof, and see if it worked. In fact, it failed, but we sure found that out a lot faster than we would have by doing a lot of lab testing or by going out and asking for requirements.
Then I did a computational post-doc for Cy Levinthal at Columbia. I was proud of something I had done and commented that I thought it was an "elegant solution." He sniffed and said, "Elegance is for tailors."
Now I write and manage the writing of commercial software. The lesson I've learned is Get the idea; Implement it simply and don't gild the lily; Sell it (don't give it away!) to lead adopters; Respond to their complaints. (Actually, for the last such product I did, I have to be honest and say that I did speak to the prospective lead adopters first and tried to respond to their concerns. But this was to tweak the initial feature list, not to get the basic idea.)
If you ask customers, "Would you like X", they will nearly always say Yes. Why wouldn't they? Having the choice to buy it or not is free to them. You'd be surprised at how honest some of them are when you ask, instead, "Would you pay $Y for X?". But the response is still exaggeratedly positive. If you give the first version away to those who said, "Sure, I'd like it", very few of them will even try it. But if they have to pay, then, on the Maharishi principle, they'll sure try it, and they'll sure tell you what they don't like.
If, before deciding what to produce, you ask customers what they want, they will often come up with something that is either overly specific or underly imaginative; but if you then respond with "OK, but what if I give you this other thing instead?", they will sometimes say, "Wow -- can that really be done?"
For all of us, our thinking is straitjacketed by our experience. Developers and inventors can sometimes see beyond the horizon that limits typical user thinking. By the same token, what's cool to us sometimes turns out to be incomprehensible or useless to them.
Thus, keep the first version simple; sell it; and, based on response, either abandon it or use customer response to guide the next version.
are you summing up the world as a short race for money?
if not, and we all do not HAVE to be Warren Buffet,and life itself being a random-logic play, each player must say his/her line and NOT repeat co-stars lines/actions, because then it would be so downright dull here on earth, ideally then we must invest/act in a way that is uniquely written/wired for us.
but then, i guess ten commandments did work for our species(?), so rules is what man must have craved for..
if you want to get wealthy, do what *Warren does..
if you want to write code, do what *Stevey does..
will we never say our own lines?and stop stepping on our co-stars foot?
to make the certainly random, perfectly disciplined..ah!
i am sorry i am in software discipline, but i guess i fell in love with chaos :-)
Well I'm just going to have to be an ***hole here and point out that gathering business requirements isn't bullshit. In fact it is one of the most important stages in the life of a software project. Just because gathering requirements is difficult doesn't mean its stupid. If you live in the real world, then I'd check out the (rather condensed treatment) in CC/2e and then skim something by Wiegers.
You have made some valid points and provided some nice entertaining reading, but what about companies that have users that want developers to automate a bad process to begin with? Without an objective 3rd party to look at the big picture and determine the impact (to the organization) of what the user "wants", many companies tend to wind up with a hold lot of automated crap.
“It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as ‘pretty good’ come out ‘just plain bad.’"
Thanks, Steve. I enjoyed the rant. To an extent, I agree with part of it, the product of gathered requirements CAN be bull**** if you do it wrong. In a software development environment, an effective Business Analyst must understand the business, customers, development team, systems, processes, constraints, and capabilities. Then, document in language simple enough for a 6th-grader to understand, bringing them all together for a common purpose: push everything past its limit to make them all better. What could possibly go wrong there? Be the best you can closer to perfect than bull**** as often as possible.
"..you're done writing not when there's nothing left to add, but when there's nothing left to take away.."
Please keep that in mind when writing blog posts. Love ya! :)
You're painting in rather broad strokes to say that gathering business requirements is bullshit. In the world so many of us inhabit, where our customers come to IT and ask for a software solution to help them run the business we're all a part of, gathering business requirements is the best way to get something bigger than a small add-on done.
This is not to say you just take whatever the customer says are the requirements as gospel and move on from there. The person gathering the requirements has to understand what the problem is, however that is accomplished, in order then to understand anything about potential solutions.
Business requirements are the bridge between the customer who needs something and the person who can actually create what they need.
I agree there are some valid points in your very amusing blog (and some very amusing posts as well). But I disagree with the overall theme of Business Requirements are bs'; especially in an in-house software development group. I think detailed information about what the customer needs is critical to the success of a project. And I think that there are three major players that are needed for accurate, complete requirements: A customer who knows what they need, a BA who can help the customer realize what the customer needs (if they don't already know) and who can translate those needs into understandable requirements, and a developer who actually cares about what the customer needs and wants to help the custmer and wants to provide the best possible solution FOR the customer's needs. (This is one of the parts that I agree with). I think if developers had the best interest of the customers in mind, and took at least a little time to understand the customer's world and subsequent needs, then they could ultimately offer better options and build better products the the customers could be excited about.
Some of us are building things that are almost by definition not for personal use. That is, there's no way I could actually have a chance to really use the software I'm writing (other than by way of playing out fictive test scenario's, of course), because that function belongs with a specific kind of profession, and I cannot be both a S/W developer and this other profession at the same time. But that being said, clearly it is important to "love" the thing you're working on. If you don't even like it yourself, how can you expect others to...? (OK there are many systems that don't have to be "liked", they must just work - i.e. embedded stuff without any direct user interaction...
Steve,
I enjoyed the walk down memory lane. I still have my OmniGo. Did you know that the Flip was made by Jonathan Kaplan, of Geoworks fame?
Have you had a recent look at Airset, which Brian is building for himself?
I agree with droher. And clean up these spammy posts! I love yer blog.
maybe he just introducing and advertising his product that's why he just emailed whomsoever...
_______
miles
maybe he just introducing and advertising his product that's why he he need to email whomsoever even he doesn't know it..
_____
miles
http://mls.fastrealestate.net
Post a Comment
<< Home