I thought I’d deviate from the normal ramblings about the industry to explain a bit about how product development works in general, and why changing things isn’t as easy as you might think.
All products begin with an idea. The idea is rarely formed by consensus, but rather the dream of one or a very small group of people. Malcolm Gladwell wrote a bit about team size and product creation in a New Yorker article last year. Too many cooks in the kitchen can literally ruin a good idea.
Once a product is developed and released to the masses, the typical company will collect feedback in one form another. This might be a directed survey, or it might be unsolicited feedback like “[insert camera manufacturer] when are you going to get your act together?!!? Your noise suppression at high ISO suck!”
Impetus to change a product by altering a feature or adding a new one is generally market driven by three guiding principles. 1) Does it increase market share? 2) Does it make more money? 3) Does it reduce costs?
In a mature company, the person articulating the requirements for the product (but not necessarily the implementation) is a marketing person that is concerned with satisfying one of the three principles. After the bigwigs approve the idea and the marketing assumptions, it gets handed over to some engineering group to satisfy those requirements.
“Make me a chocolate chip cookie that is soft, under 50 calories, has a 4 year shelf life, and costs $0.25”
The process of articulating the requirements, doing the research and development, testing, and rolling out of the product is part of a lifecycle. It stands to reason that if you’ve gotten to testing, and then the requirements change, you’ll derail the project schedule because more development has to occur. This is disaffectionately known as “feature creep.”
The product lifecycle is no different if you’re building a cookie, a space shuttle or PhotoShelter. The team sizes may vary, the requirements may be vastly different, but the conception of ideas, the feedback loop from various “constituents”, the “research and development,” testing and roll out are the same from a conceptual point of view.
Companies also typically have a “road map” and plan releases several steps ahead of their actual deployment. Intel, for example, has a road map for their chip development that extends many years into the future. This is necessary because it sets a vision for the company. Would Apple switch to Intel chips if they didn’t know that the next generation of chip would be more powerful and use less energy? Would people want to work there if Intel didn’t articulate how it would continue to be an industry leader for many years to come?
What does this have to do with PhotoShelter? Here’s where I open the kimono.
When you e-mail a suggestion to PhotoShelter, we put the suggestion onto a list. Some suggestions we hear a lot (those are good suggestions), and some are very specific and obscure (those aren’t so good). A bad suggestion doesn’t necessarily mean that it’s a bad idea per se, but that it’s too specific for the wider audience.
Suggestions get bundled into releases. Releases usually have a theme (e.g. lightboxes!), and a cool code name because we’re geeks. Releases have rough dates associated with them, and as the release moves into development, the dates get firmed up, and then the documentation, press releases and newsletters get written.
You probably don’t think of PhotoShelter as a product the way you do with something like Photoshop. But we do. We have very specific release schedules and internal versioning. If we’re near the end of a development cycle and you come up with a great idea, we most likely won’t implement it until the next cycle because it causes too many problems to jerry rig the thing into the release.
Sometimes a change to the system has wide ranging dependencies. In these cases, we have to “regression” test the entire system. If we change something to the billing system, we have to test the whole sign-up process, cart checkout process, rebilling process, etc. Very rarely are changes so isolated that you can just unit test them and be done with it. Testing is really boring, but a necessary and often long part of the development cycle.
In the same way that the average person assumes that taking a picture is just about pressing a shutter button, the average person assumes that making a website is just typing in some HTML. But we know that taking a good picture involves planning, travel, set up, post production, archiving, distribution, marketing, etc.
Suffice it to say, developing a product is a multi-phasic process. And although Jack Bauer can save the world in 24 hours, and Chloe can “open a protocol” with a few keystrokes, the world doesn’t really work that way. So if your suggestion isn’t implemented within 24 hours, now you know why.
Now, I will attempt to answer a few pressing questions in photography. I have no inside knowledge, but I’ll just use my common sense.
1. Why doesn’t Nikon develop a full frame sensor camera like Canon?
The only people that really care about full frame are a segment of pros and some serious hobbyists. Last year, about 3.5MM DSLRs shipped, and I’d venture to guess that maybe 50,000 of those were actually full frame. Compare this to the approximately 65 million point and shoots that shipped last year. Even though the DSLR market is the most rapidly growing, the economics of the situation don’t make developing a FF sensor a logical conclusion for a smaller company like Nikon.
I’m not a Nikon apologist. I’m just saying that my photos aren’t any better with a full frame camera.
2. What’s up with Foveon?
The concept is cool, and the sensor does really well at avoiding things like mosaic patterns, but the noise and overall chip performance will probably keep it a niche product (read: hello Sigma) for at least another generation.
3. What does the photo industry look like in 3 years?
It’ll be harder and harder to be a full-time photographer. A backlash will occur against the larger stock houses, which will change the landscape. I don’t think it will necessarily cause a revolution, but I think the economics of the game will change.