4 ms·

> Pick three key attributes or features, get those things very, very right I think the trouble with this advice is, when you’re developing a product, isn’t not

> Pick three key attributes or features, get those things very, very right I think the trouble with this advice is, when you’re developing a product, isn’t not really clear which attributes are key. You have a hypothesis, but you could easily be wrong. Or perhaps this advice could be interpreted as: decide on your hypothesis, and go all in on it, and only it. If you’re right, it’ll turn out well (as discussed in the article) and if you’re wrong you would have failed anyway and you probably fail quicker following this advice.

tomhoward 6y ago
The supplementary advice (which I guess is left out of this post for brevity but which I've heard PB say in public talks) is that you should work very very hard, both before and during the dev project, to determine what those three key attributes should be. It can change over time. In the case of Gmail, he spent countless hours sitting next to Google colleagues at their desks, watching them use MS Outlook throughout their work day, and asking them why they were using it the way they were and figuring out what could be improved. Then when he had a first working version of Gmail, he'd get people to use it and watch intently to figure out how they responded to it, what they liked/disliked, and how it needed to be improved further. (The first version was mainly just a search box for PB's email inbox. The first thing he was told that needed to be improved was that it should be able to search the user's own inbox instead. But it was still a useful test; they loved the search experience enough to want it for their own inbox.) Anyway, there was every opportunity to chop and change what the three key attributes should be along the way; the point is to not try and be all things to all people and build every feature anyone ever asks for, lest you end up with your own equivalent of the Homer car.
k__ 6y ago
"isn’t not really clear which attributes are key" If that isn't clear, you're missing the "doing deliberate research" part of such a venture.
- ullify 6y ago
  Part of the reason Agile/XP/etc. exist is to argue against this line of thought. Iteratively putting a working product in front of people is more effective at getting you high quality information than millions of dollars of upfront research.
  - pfraze 6y ago
    Agree but it's not really a dichotomy. From initial conception to final release, you should be researching by iteration. Eventually that means user-testing prototypes, then betas, then RCs.
    - k__ 6y ago
      "you should be researching by iteration" This! Research doesn't just mean to read stuff.
    - ullify 6y ago
      Agreed but part of that process is forming and re-forming your goals. It's ok if you aren't exactly sure what the goal is or if it turns out that the ones you thought you had were wrong.

tomhoward 6y ago

The supplementary advice (which I guess is left out of this post for brevity but which I've heard PB say in public talks) is that you should work very very hard, both before and during the dev project, to determine what those three key attributes should be. It can change over time. In the case of Gmail, he spent countless hours sitting next to Google colleagues at their desks, watching them use MS Outlook throughout their work day, and asking them why they were using it the way they were and figuring out what could be improved. Then when he had a first working version of Gmail, he'd get people to use it and watch intently to figure out how they responded to it, what they liked/disliked, and how it needed to be improved further. (The first version was mainly just a search box for PB's email inbox. The first thing he was told that needed to be improved was that it should be able to search the user's own inbox instead. But it was still a useful test; they loved the search experience enough to want it for their own inbox.) Anyway, there was every opportunity to chop and change what the three key attributes should be along the way; the point is to not try and be all things to all people and build every feature anyone ever asks for, lest you end up with your own equivalent of the Homer car.

k__ 6y ago

"isn’t not really clear which attributes are key" If that isn't clear, you're missing the "doing deliberate research" part of such a venture.

ullify 6y ago
Part of the reason Agile/XP/etc. exist is to argue against this line of thought. Iteratively putting a working product in front of people is more effective at getting you high quality information than millions of dollars of upfront research.
- pfraze 6y ago
  Agree but it's not really a dichotomy. From initial conception to final release, you should be researching by iteration. Eventually that means user-testing prototypes, then betas, then RCs.
  - k__ 6y ago
    "you should be researching by iteration" This! Research doesn't just mean to read stuff.
  - ullify 6y ago
    Agreed but part of that process is forming and re-forming your goals. It's ok if you aren't exactly sure what the goal is or if it turns out that the ones you thought you had were wrong.