In mature markets, the only way to go is the 'Plus One' route, adding something extra to the standard product to differentiate it.
Like cars, the world of PC peripherals has been so long-lasting, become so over-mature, that every possible combination of keyboard-and-x has been tried, retried, and then recycled again in each of the USB and wireless throughout the myriad inscrutable peripheral manufacturers, who are also doing the same thing with lawnmowers, coffee-cup warmers and Xmas toys. Like throwing dice, this is statistical manufacturing, there doesn't have to be a need for it, just design it and throw out there - someone will buy it, and if not, move on. The intelligence behind such massive, wasteful, indiscriminate shotgun-marketing is of a different order to what we are used to in small-scale business-to-business technical product design and sales.
I think it should go farther than that, you should plan the requirements of all of the products in each of your product lines. Then you look for software, hardware and inventory efficiencies and how they map against your market, resources and growth goals. Then plan to adjust rapidly, cause the plan never holds because the market and competitors mess up your plans. But at least, you know why you decided to make a decision and the impact of changing the decision.
Kirstin, I agree with couple of points here. Clear requirements at the beginning of the design makes your destination clear and the way also. Doing this way you can manage all the risks associated in a right manner without unnecessary delays.
:-) I was just pulling your chain, I actually agree with everything you said. I would probably never buy a keyboard with a clock. I even didn't upgrade my monitor when I bought a new PC because I didn't want a glossy screen which was all the rave then but oh so disfunctional. I subscribe to small is good. I once did work for a medical company where the MD was also technical director and we were designing a game changing device. It still hasn't seen the light of day because they burnt all their money adding features.
"And, really, do you think a keyboard needs a clock?"
For me personally, no. But if I'm designing a new keyboard and my high volume OEM customer requires it to have a clock, then absolutely yes, it requires a clock!
As Kristin said, standards like IEC 62304, ISO 26262, and IEC 61508 are driving safety-critical organizations to focus on requirements traceability in the context of a comprehensive risk management process. A recent report by VDC Research makes a couple interesting points that are notable here: 1) Organizations following such standards are less prone to cost & schedule overruns as well as faults and failures. 2) Consumer-facing verticals are poised to adopt processes similar to those used in safety-critical markets. Although device failure in these sectors does not present the same risk of tort liabilities that would be associated with loss of life, the potential financial impact of a product recall or missed market window can be just as debilitating.
Sorry for the self-promotion, but you can access this paper through Parasoft, the company I work for, at http://alm.parasoft.com/embedded-software-vdc-report/
Purely as a calculated trade-off to get a keyboard with the touch and Bluetooth connectivity I wanted, I assure you. It's more a low-grade annoyance than a dealbreaker —mostly I was using it to bring up the requirements issue, which I do think is important. Developing requirements up front with an eye toward risk management and identifying problem areas is key. It's not enough to build the list, though – you have to also manage change carefully. There have been multiple studies showing that for embedded software, alone, requirements changes cause a majority of cost and schedule overruns, not to mention leading to faults and failures. Vendors like LDRA, Visure, and PTC have made requirements traceability and management into big business. With the release of standards like IEC 62304 (for medical) and ISO 26262 (for automotive), you're starting to see more and more companies paying attention to the issue.
How have you handled requirements on the projects you've been involved with? Do you develop an official document or is it something off-the-cuff in PowerPoint slide deck, based on customer input? Or is it a spreadsheet you throw together at the end before delivery?
And, really, do you think a keyboard needs a clock?
I certainly don't like feature creep in a project, doing requirements up front is the real way to go, but that could still end up with something as silly as this keyboard and mouse, but then again, maybe they're onto something, i.e. maybe they actually had this in the requirements, after all you bought this instead of one without the display? :-)
Even seemingly simple, commoditized products like keyboards and mice offer a lot of differentiation. For every user who hates the deep dip where the thumb rests, there is another user who simply has to have that feature. Some hate the scroll wheel, others can't live without it.
I wouldn't assume that what you are calling feature creep was truly a case of losing track of the requirements. Quite likely there was market research and cost vs. revenue analysis that supported the decision to make the thumb depression a requirement on that mouse or to make the small LCD screen a requirement on that keyboard.
Nobody carelessly adds costs to a commodity product that has such a low retail price and such low margins. They add those costs -- and those features -- because they believe they can gain market share or a few extra gross margin points.
Fortunately there is so much variety and feature differentiation that just about everyone's preferences are accommodated by some manufacturer. Clearly in this case you bought the wrong keyboard and wrong mouse for your tastes.
If you mapped all products as a Venn diagram against time, you would see all of the circles swelling to envelop every other circle, and it doesn't matter which industry you're talking about. Everybody wants to move up the value-added foodchain. The problem is that all too often, trying to do everything means doing nothing well. Yes, this is me being a curmudgeon. Excuse me, I have to go back to trying to program my function keys to do something useful instead of their default.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.