Intuit co-founders Scott Cook and Tom Proulx called random households to ask what financial tasks they actually did and what single improvement they wanted most. Users wanted to save time. They timed themselves with stopwatches against pen-and-paper bookkeeping, their real competition, and iterated the UI until they won.
Chapters
Pretty much all of our competing products had been built by people who had financial backgrounds, and so they weren't for civilians. They were designed for people who think financially, and we were designing for civilians, for the rest of us.
But how did you get the domain knowledge? Did you hire people who have domain knowledge? Think about it. I mean, anybody in this room already has the domain knowledge that we have. We were going for what What do average— what does the average household do with their finances, right? So we already knew what they did because we had to do it. You had to pay bills, otherwise they turn the lights off. You had to maintain some tracking of your spending so you didn't overdraw your bank account, which most people do, but not everybody.
Right.
And at tax time or periodically, you want to know how much money did you spend on charitable deductions for the year because you need to report that on your taxes. There's not a whole lot more than that that average people do. And so we didn't really need much domain knowledge beyond that.
And as we progressed, what we found is generally you could learn the important things about the problem to be solved from customers. And generally we wound up solving a different problem than the domain experts had imagined because we focused on the problem in the customer's eyes. And then if you have smart people, they can figure out the required Domain expertise. But your compass is understanding the customer much more deeply than the other guys do.
I think one of the things that we did as a company very differently than what technology companies were doing at that time, which is what Scott brought, was applying a consumer products approach à la Procter Gamble, where Scott used to be Straight out of school, he had been a brand manager at Procter Gamble. Procter Gamble has a way of developing products for the market, for consumer products, that he recognized was not specific to consumer products. It would work for anything. Scott was the first person to figure out that you could take this consumer products approach and apply it to a technology product. By that, what Procter did, does to this day, and what we did in the early days at Intuit was you start with research to really understand the customer, what the customers want, what the benefit they're looking for is. He actually did it with his sister-in-law. He and his sister-in-law would get on the telephone and call random people out of the phone book and ask them questions about their household finances. The questions were kind of really 2 major things that he was looking for. One is, what are the things that you do? As I mentioned, we knew that everybody had to pay bills, but what else do you do? We found there's a very short list of of tasks that most households do. Then what was the one single improvement that they most wanted? What was the key benefit that households were looking for in this area of improving their personal finances or their household finances? What we found from that was an overwhelming number of households, the one improvement they wanted above everything else was save time. That was the key insight that we got from that early customer research. Then we used that research to shape the product. We knew from that research what features we had to include, and we knew that we had to deliver that key benefit of time savings or else we didn't have a product. The time savings benefit had to be better than all alternatives, not just better than other software products, because in fact when we looked at the other competitive software products on the market at that time, they all were worse than doing it by hand. Those products which were designed by accountants and engineers and folks like that, they were designing products that were for people like them. So if I'm a real technical accounting type person, I have this vision for all the great things that I can use a computer to do. And so I designed this product to do all this extra stuff. And that's not what the mass market wanted. The mass market said, I don't want to do extra stuff. I want to do the stuff I have to do, which is about this long of a list, but I want to get it done faster. When we actually looked at the competitive products on the market at that time, and there were quite a number of them, every one of them took longer to do those routine sorts of monthly tasks than doing it by hand. We realized that we've got to— our real competitor was not other software products. Our real competitor was pen and paper, people doing their finances by hand. We had to be better than that. That took us quite a number of iterations on the product. We actually, in the development of the product, we would do a design of the product and we would actually bring people into our offices and we would give them some routine tasks to do. Here's a set of bills to pay, for example. We would time them with a stopwatch and see how long it took them to do that. We'd time them by hand and we'd then iterate on our design to get it easier and faster until we got to the point where we were cutting the time by half for the average monthly set of household tasks. And that's when we knew we were onto something.
Because I think a reality that we faced, some of you will face, is there were over 2 dozen competitors already in the market. We had the last mover advantage, or maybe the last mover disadvantage. After we entered, only one other company followed. So we were— and that was Microsoft. So how do you win in a market which is crowded with dozens of other competitors? And I think you've got to make a decision about whether you're building for yourself and people just like you, or whether you're building for people who may not be fundamentally like you. If you're building just for yourself and people just like you, then you probably don't need a lot of user testing and all that sort of stuff and user understanding, because you understand yourself.
Yeah.
And that works in some categories. We were trying to build, yes, for ourselves, but we were trying to build for everyone. So we needed to understand how typical people behaved. And the key thing you're trying to understand are the 2 questions Tom mentioned. What do they actually do? Not what do they say they do, what do they actually do? And then what's the problem? What's the problem they have? Because if you don't solve a big problem, it's unlikely anyone's going to change their habits to use your stuff. So understanding and nailing what that problem in the customer's mind is, is really important. Particularly in our company, we tend to build for people who are not ourselves. So you really got to immerse yourself in the customer. And that's part of the key to this, how do you filter criticism? One criticism we got all the time was, oh, that's already been done. Look, there's this product or that product or that product that's already in the business. Which was an accurate observation. But what we had done is to understand what does the prospective customer really want, and then we'd gone and measured how well those products actually delivered the time savings, which is what people really want. They don't want to do this stuff. They want to spend less time. And the existing products never delivered that. They took longer. So that's one reason— one way you filter out the criticisms by getting underneath it to what's the foundation, why people Will buy, and how does your product, or how does the competitor's stack up with data? So we'd actually time trial stopwatch tested the rival products on our own, and we kept working on ours to get faster, faster, faster. So one way to filter criticism is with facts.
