.svg "bes-logo (1).svg")
Hardware design can be difficult, so we try to mitigate any risks or difficulties associated with it as early as and whenever possible. However, we have come across some daredevils out who like to turn the dial up to 11. These are the clients who pepper in extra challenges thinking that the impact will be negligible, but wind up with an inflated budget, blown schedule, reduced sanity, or some combo of the three. Let's see if we can characterize some of the patterns, so you can identify these "saboteurs" in the wild...
Not Providing Sufficient Requirements
Give me any one page description of a product and there are probably at least hundreds of ways to design it. If you want your product designed efficiently, download your expectations for it from your brain onto "paper" (or an e-document) so your engineers can get up to speed as quickly as possible. It doesn't need to be pretty, just informative. By writing down absolutely everything you know about a product -- from the most obvious functionality to the most obscure detail, the critical features to the wouldn't-it-be-nice list -- you’re removing ambiguity about the final product so your team can make quick, educated decisions as they encounter design choices throughout development. This also allows your team to better estimate the scope (read: cost and schedule) of the project, so you will be better equipped to set realistic expectations for peripheral teams, vendors, investors, and customers.
Changing Specifications
If you're designing a new product, it's likely that you'll encounter design premises that you thought were true, but are dismissed during user testing, market validation, patent searches, or fundraising. This is expected and hopefully you have an engineering team that is nimble enough to adjust course. However, this can result in redesigns. Before making any changes to the understood specifications, discuss the implications with your engineering team and make sure the casual "we'll just swap out this charger for a cheaper one" doesn't require an extra PCB spin or worse: an overhaul of the core design. As you might expect, the farther down the rabbit hole you've gone, the harder it is to dig yourself back out, so make sure you're voicing possible adjustments as soon as possible so you can navigate those red flags with the least amount of budget and schedule expansion.
Overriding Recommendations
Your engineering team is in the business of seeing you succeed, but ultimately they answer to you: the product owner. If you decree that a certain part number is sufficient or a particular feature implementation is non-negotiable, then that's what you'll get. Of course, you may (and should) receive push back from engineers who have the experience to suspect otherwise, but if you don't give your team the leeway to explore other options or validate the preferred method, then you shouldn't be surprised if down the road you discover that you have extra hoops to jump through. Your technical team can be only as valuable as you allow them to be, so seriously consider their intuition. Even better: invest extra time up front to wade through the seeming technical minutia to reduce the overall program cost in the long run.
Ignoring Technical Communications
Regardless of whether your team is in-house or an external consulting firm, you should be receiving some sort of updates from your engineers. Whether it's a couple line email or a ten-page technical report read and absorb it. Very few engineers enjoy documentation (spoiler alert: we'd rather be designing!) so it's being provided to you for a reason. That intimidating wall of text is probably walking you through a design choice that needs to be made or requesting additional information so your team can move forward. If you don't answer, your team will either be forced to make a "best guess" decision without your approval or be paralyzed until you can provide feedback. Your project is your baby -- devour, consider, and timely respond to all communications so you don't find your project stagnated.
Speeding Through or Skipping Testing
Have you looked at our process graphic? You'll notice that during Prototyping testing is the largest piece of the pie for each iteration. That's no accident: it takes time to validate feature sets, get hardware into the hands of customers, put prototypes through environmental, life cycle, and emissions testing, and notice where it's not quite up to snuff. Of course, you're anxious to meet investor and customer deadlines, but those same parties will likely be less pleased if the product they've been waiting for doesn't meet the mark. Remember the comment on setting realistic expectations? The more complex your design, the more you time you should dedicate for in depth testing on each iteration. Hardware doesn't have the luxury of pushing updates as quickly as pure software projects -- there are lead times and costs associated with building physical devices -- so make sure you capitalize on every opportunity to put your design through critical evaluation so you can best direct the next round of changes.
We understand that you're anxious to get to market -- we want you to be there too! But there's a method to our madness, a reason we want to spend time and effort validating concepts, testing designs, gathering data, and sharing our results with you: if you don't put in your due diligence along the way, you may sink a lot of resources or burn some relationships for a subpar result. Let iterative product design work for you by striking a healthy balance of theoretical and practical validation, and dedicating your resources where they count.
