Yes, the way the product is sold has a huge impact on the development process.
In one company I worked for, the product was sold as a "service", meaning all the software ran on our servers and clients connected to it via a web interface. In this company, updates were pushed to the "live" site sometimes within minutes of a bug being found.
We did try to stage our updates as much as possible (for example, we would advertise the fact that 3pm on Tuesdays was the "maintenance time" and the site might down during that time) but in reality, laziness or expedience would get the better of people and some of the guys would never wait for that time to do their updates: they'd go live as soon as they were ready.
On the other hand, in another company I worked for, we sold our product pre-packaged to "enterprise" customers (governments, banks and so on). In this case, even a simple bug fix could take months to get to the customer site because they'd never go out without a round of in-house testing and they would usually get bundled into "service-pack" style releases.
This was a much larger company as well, and while I sometimes felt rather stifled by the enormous amount of process that went into every release, it was pretty important that anything we released to the customer was good... when you're a bank, even a short down time can cost millions of dollars.
However, in terms of the actual work environment, I found the latter to be rather more relaxed and flexible. When your release schedule is in the order of months, working from home a few days a week, or taking extended leave isn't such a huge problem. It might also have to do with the number of people working there (i.e. one person out of 50 is not as big a detriment as one person out of a team of three).
But the downside is that there's also the temptation to stagnate somewhat, in terms of you get a little too relaxed, perhaps...