Abstract: Divorcing a product design’s key technical characteristics from its shape, feel and market appeal sets your company up to develop a product that works badly, even if it looks great. Product development requires a broader developer skill set than straight-forward coding. Saving pennies on product design, which will determine the fate of your company, is stupidly suicidal.
I’ve done a lot of full lifecycle product development, in my time, going from back-of-the-envelope concept, to refined minimum viable product definition, through to prototype models and onward to shipping product. Most engineers that work for software product development companies have not. It’s an important gap in their knowledge. There’s much more to developing a great product than coding well.
When a company designs a new product, there is usually a lot at stake. For one thing, the company’s entire future prospects may hinge on how successful the product is and how quickly it establishes itself in the market, after launch. There is an entire product design discipline that goes under the banner of “New Product Introduction Processes”, which is necessary to ensure that the right product for the market is built, with the right characteristics, to make the product a runaway success. Failing to do any one of the necessary new product introduction process steps has the potential to make the product fail in the marketplace.
A crucial part of the new product introduction process is the up-front ideation and product definition. This is where the design tradeoffs are made. Here, product marketeers and engineers gather to determine what product characteristics will be offered and a first cut at how those might be realised is contemplated. Technology has limitations, but it also makes incredibly worthwhile and attractive product features easy to implement, if you choose the right technology. Choose the wrong technology, or be forced into a compromised technology choice, for bad reasons and you may create a product that just doesn’t work in a way that is satisfactory to your customers.
Product design has to start somewhere and often, that’s in the design studio of an industrial design firm. They will produce sexy, three-dimensional drawings and photorealistic renderings of a beautifully sculpted object, which will be the thing you ultimately ship as your product. It can be a device (and often is), or else the visually appealing designs of some fancy web or mobile applications. In both cases, some electronics and/or software will have to go into the design, to make it actually work, but industrial designers know little about user interaction, software and electronic components, in the main, so this tends to be an afterthought. (N.B: The better design agencies do have electronic design and user interaction design capabilities!)
If the industrial design agency is permitted to characterise the minimum viable product (MVP) on the basis of meeting the functional requirements in the brief, independent of any software and electronic engineering design input, a product release disaster can ensue. A “look alike” prototype has been produced, but so far it looks good and doesn’t do anything. Sure, tooling up for the sexy case or the fancy graphical design has long lead times, so you have to get there early, but what about the non-functional requirements of the product, which are an essential component of the product’s actual appeal to paying customers?
In stupid product design, it’s after the look-alike prototype has been designed and the MVP feature set determined by the agency that the technical staff are hired. This is where the trouble starts. Usually, to save costs, an outsourced development house is chosen. The risk is seen as smaller, because the money spent on development is less than for a dedicated, in-house team. It isn’t. Here is what you sometimes (often) get:
Firstly, the developers will have no clue about your company, your market or what the product has to do. They will share little of the cultural context and know almost nothing about the products that compete with yours. In essence, they can code, but code what?
Satisfying the requirements of a user story in an MVP product backlog can be done multiple ways. The solution can be elegant and make customers delightedly happy, or else it can be kludgy, awkward, and bass-ackward, causing endless annoyance and frustration to users. Both solutions tick the agile development “done” box, but only one of them makes your company’s new product sell and maintains the goodwill and loyalty of the user base. How can the remote developer tell which solution is which, with so little context and immersion into the world your company serves?
User stories require elaboration, but this becomes much harder to accomplish, if the product definition people are remote from the coders, in different time zones and with language issues to navigate. Essentially, you are setting your product up for failure, because the high bandwidth, rich, frequent communication that needs to take place, between the developer implementing a feature in a user story and the person who wrote the story, as part of the MVP definition, is exceedingly difficult to schedule and accomplish.
Then, long after the industrial design agency has disengaged and moved onto other clients, it is discovered that the look-alike prototype is too small to put a big enough battery in it and there is no way to dissipate the heat generated by the electronics. There will be a lot of software running in the background, you learn, so the unit will always be draining battery and running hot. Even the sexy “home” button will have to be used much more often than anticipated and there isn’t the room to put in a switch with the rated number of switch actuations actually required. There’s no room for a beefier switch.
Because nobody wants to redesign the sexy outer shell and scrap all the expensive tooling, at this late stage, a smaller battery is the compromise and the switch will, for certain, wear out within a few months of ownership. Sadly, for sexiness reasons, the case is snapped together and bonded with superglue, in the factory, so there is no possibility of changing batteries in the field. Suddenly, you have created a product with too short a battery life, which runs way too hot and which has a switch that fails within a few months that cannot be user-serviced or serviced at all, in the field. Bravo! Your product has gone from being a winner to being a dog last loser.
In product design, I always advocate a “work alike” prototype, before the “look alike” is made. Why? Well, it’s a chance to test the non-functional requirements that will be the difference between your product being viable or not. You can test the battery life and heat dissipation. That will tell you how big a battery you must include for the product to be saleable and successful. You can also put in the switches, connectors and other things that the product needs to have, rated to a suitable lifetime of normal use.
For software applications, a work-alike prototype gives you the chance to run usability labs and make the software easier to use, before you freeze the wrong design in fancy, brochure-quality graphics, placing key functionality in terrible on-screen locations.
Having written some software to exercise this dog-ugly prototype and measured what’s going on, you now know how to constrain the sexy case design, so that it not only looks sexy, but it also provides a suitable enclosure for a product which actually works the way your customers need it to. The sexy case is designed around the essential performance-determining technical components. It doesn’t constrain them.
If you employ engineers that know about new product introduction processes, they also use the work-alike prototype to get preliminary EMC compliance and electrical safety tests done. It complicates the new product release, but in so doing, it ensures that the product shipped will not have to be recalled, that everything works correctly, right out of the box and that the earliest adopters will not be product guinea pigs. They can be first in line to buy the product and rely on the fact that it does what it says, in the marketing blurb.
From a software point of view, creating work-alike prototypes of the software, outside of the final shipping case design, allows early iterations around working product features. They can be exercised, at an early stage. You can discover that you don’t need that second front panel switch after all, or else determine that the product will be useless unless it has one. You can also guide the look-alike prototype designers regarding human affordances, so that nobody tries to ship software with a cursor that is too small to actually touch, on the final miniature touch screen, or else places key functions in places that are inaccessible, unless you happen to be double jointed.
Product design is not a series of separated, isolated, serial operations. It’s iterative, messy and interconnected, so different disciplines have to be prepared for resets in their progress, because a dependency discovers something unexpected, in their design work. Product characteristics are not a gloss coat painted over a neutral technology platform. They interact intimately.
To the customer, how the overall product works, what it is like to live with and how useful and relevant it is to their real lives is what counts most. Putting lipstick on a pig doesn’t achieve the desired result.
It’s a form of self-inflicted, self-destructive, delusional insanity to try to shave pennies off the cost of your designers and developers, during the design of the very thing that is supposed to sustain the company. If you cut your design effort to the bone, using the cheapest of everything, you get a crippled, vandalised product. Given how much depends on the success of the product, it’s plain stupidity to think you can get away with throwing vital aspects of your key product’s design over various anonymous walls and hope for a coherent result. It’s like shooting yourself in the foot, before you even launch.
Above all, use seasoned research and development engineers, with new product introduction skills. Just being able to code isn’t enough.
Arcturus Mentoring 