its always best to start with a minimum target machine in mind - hardware, OS version, and directx version. as you write code, you make sure any API calls you use are supported by the minimum target machine. you can then add options for higher end features on later versions of windows and directx, and newer hardware. then enable them during install if you find later versions of windows or directx or newer hardware. how "backward compatible" your software is will determine the maximum possible installed base, IE how many people have PCs that can run your game, and therefore might buy it.

I'm using vs2012 to write games that are software backward compatible to something like directx9.0c and windows 2000 or maybe even XP. minimum hardware is something like a dual core with onboard graphics chip (about a 2-3 year old baseline machine). Minimum target is a 2 year old baseline pc with onboard graphics only, directx9.0c, and windows 7. But it will probably run on even older PCs (IE Vista machines).

Yeah it's pretty weird. Back in D3D9 days, things were confusing because there were cap bits. With D3D10 MS made everything dead simple, but required Vista and new hardware. With D3D10.1 and D3D11 things got more complicated since there were feature levels, but this was still better than caps bits. With D3D11.1 and 11.2 caps bits are back (but there's still feature levels!), they require a new OS version*, and things are more confusing than ever.

*Technically D3D11.1 was back-ported to Win7, but in a extremely limited way. They basically back-ported everything required for new Direct2D functionality so that IE could use it, but didn't back-port the new D3D functionality since it was tied to a WDDM version. This meant that the new 11.1 interfaces were available, but you couldn't actually use any of the new stuff exposed by them because the 11_1 feature level wasn't supported. So yeah, confusing as hell.