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!
Tidak ada komentar:
Posting Komentar