![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I was recently informed that in the strange world of mainstream dating, people (especially women) tend to have dating checklists that they consciously or unconsciously go through like an interview on the first date. These checklists may include things like height, race, political views, physical appearance, job, mannerisms etc. Some are astonishingly specific. However, over the years I've seen a lot of cases where people's hard and fast requirements turn out not to be true.
- A woman I knew said she was not into guys with beards or long hair, and would never date a smoker. Two years later she was married to a guy with a beard and long hair who had an occasional cigarette.
- A woman I knew said she was not into older men at all, and ended up dating and falling in love with someone 10 years her senior.
- A guy I knew who emphatically said he was only into super skinny women and is now dating someone who's athletic but quite curvy.
... and lots more.
The situation reminds me of some of the product requirements documents I've seen over the last few years. The product requirements document (or PRD) is typically a document produced by a customer, a marketing department, a business development department, an executive, or a VP of engineering that frames the requirements for a product to be developed. The engineers and designers then set to work to meet these requirements. Often these documents are way too specific. A customer will say
“We want the webpage to have one of those apple deskbar things that lets you select each product in our product line and then drag it in the middle of the screen to learn more about it.” However, what they really want is “We want to encourage the user to browse our full product line and learn more about the specific features of each product via an intuitive interface.”
Fundamentally it's the same problem. People don't know what makes them happy. They get attached to a specific vision in their head, and assume that this is the only way it can be. It's sometimes possible to get past this by taking specific requirements and asking yourself why those requirements are so important. Then ask why whatever you think is important is important. A couple of iterations of this may reveal the true reason. However, with matters of attraction, a lot of reasons are intuitive and defy rational explanation. For those, it may be especially worth pushing on them and trying out the opposite of your assumption to see if your theory holds.
One book, “Stumbling on happiness”, posits that the best way of determining if something will make you happy is not to imagine what your life would be like if you had that thing but instead find someone similar to you who already has that thing and see if it makes them happy. It's backed up with lots of studies confirming various aspects of this. This could be applied to dating preferences (and product requirements) as well. Instead of having a checklist, look at who people you are similar to are dating. Instead of delivering an ultra-precise PRD, talk with other clients of the dev team and tell the dev team what you like about another product they delivered.
In the end you win by having a broader range of options. You're more likely to get what you're really looking for.
- A woman I knew said she was not into guys with beards or long hair, and would never date a smoker. Two years later she was married to a guy with a beard and long hair who had an occasional cigarette.
- A woman I knew said she was not into older men at all, and ended up dating and falling in love with someone 10 years her senior.
- A guy I knew who emphatically said he was only into super skinny women and is now dating someone who's athletic but quite curvy.
... and lots more.
The situation reminds me of some of the product requirements documents I've seen over the last few years. The product requirements document (or PRD) is typically a document produced by a customer, a marketing department, a business development department, an executive, or a VP of engineering that frames the requirements for a product to be developed. The engineers and designers then set to work to meet these requirements. Often these documents are way too specific. A customer will say
“We want the webpage to have one of those apple deskbar things that lets you select each product in our product line and then drag it in the middle of the screen to learn more about it.” However, what they really want is “We want to encourage the user to browse our full product line and learn more about the specific features of each product via an intuitive interface.”
Fundamentally it's the same problem. People don't know what makes them happy. They get attached to a specific vision in their head, and assume that this is the only way it can be. It's sometimes possible to get past this by taking specific requirements and asking yourself why those requirements are so important. Then ask why whatever you think is important is important. A couple of iterations of this may reveal the true reason. However, with matters of attraction, a lot of reasons are intuitive and defy rational explanation. For those, it may be especially worth pushing on them and trying out the opposite of your assumption to see if your theory holds.
One book, “Stumbling on happiness”, posits that the best way of determining if something will make you happy is not to imagine what your life would be like if you had that thing but instead find someone similar to you who already has that thing and see if it makes them happy. It's backed up with lots of studies confirming various aspects of this. This could be applied to dating preferences (and product requirements) as well. Instead of having a checklist, look at who people you are similar to are dating. Instead of delivering an ultra-precise PRD, talk with other clients of the dev team and tell the dev team what you like about another product they delivered.
In the end you win by having a broader range of options. You're more likely to get what you're really looking for.
