Building a prototype is fun.
However there is limited threshold for failure. You are the end user. Building a product is a healthy mixture of alchemy, magic, and elbow grease. You will make mistakes, embrace them. There will be bugs, learn from them. Nothing is obvious. Just because it makes sense in your head, doesn’t mean that it makes sense on paper.
There are more robust resources and accelerators for building products:
With the advancement of 3D printing technologies and rapid PCB prototyping, the era of new hardware is upon us. Anyone with an Idea and Arduino can hack together a prototype with staples and glue bought from a dollar store. Taking that demo and building a full-fledged product takes much more than a Sunday afternoon.
Here are a few guidelines we’ve learned along that way.
Nothing gets done without them. Every step of the way you will need help. Blog posts, tweets, and comment sections are great. Nothing can replace a solid conversation where you can ask questions of all shapes and sizes. Nothing is better for the product than talking the product through. These people can be partners, advisors, employees, freelancers, and even clients. Everybody’s point of view matters.
People also require systems and tools to aid their success. We all know that email is broken. Product management tools, Google docs, code repositories, or whatever works make sure that it’s in place. Lead by example. Be transparent and engage in the systems and tools. Accept that there will be bottlenecks of communication, but when people have access to the tools to succeed these bottlenecks are minimized.
This cannot be stressed enough. Make sure that you have user cases illustrated written down and clearly described where everyone can access. Don’t overlook any detail. From LED light colors on powering on and off, to beeps, to the entire UX – this spec should be a living and breathing document that everyone contributes to. Always remember without user stories your product has no life.
No different than a shopping list, you need a component breakdown. It’s best to work backwards here. Imagine an unboxing video of your product that goes all the way down to the metal. Draw out an exploded view checklist and make sure that everything is there. Your factory will require this for a bill of materials, but you should have prepped way before then. This exercise is a great way to bring all members of your team together because everyone has a degree of insight, experience, or opinion. A graphic designer will not know what caps to use on a PCB layout, but they’ll be sure to have some thoughts on the packaging.
Also keep in mind the decisions you make here, especially on the metal, you’ll be stuck with. If your product requires Bluetooth, the chip you use will have a lasting effect on your full development cycle. The framework it requires. The developers whom understand the chips stack. The on boarding process required to bring everyone on the same page from your engineering team.
All of these factors will effect the ultimate miniaturization and best practices for how to design your PCB layout. All of this can be a huge burden on your overall cost and resources if not properly thought through. What may initially appear, as a simple shopping list is actually the whole product plan for your vision.
If you try to make a chicken salad out of chicken shit, your help, guests, and neighbors will be unimpressed.
We all love it. Design is pretty. It has charm. It is classy. It also is the make and more often the break of great companies and businesses. We’ve been mislead by Apple that has a design-focused culture and Google that puts engineers first. It is possible to allow a give and take between both sides. No one wants a product that is either ugly or doesn’t work.
3D printed enclosures before and after sanding.
The problem with design is that it can lack accountability. Great UI and UX is beautiful to look at, but if the code and engineering behind it cannot make it happen, is that the fault of poor engineering or bad design? Usually we blame the engineers.
We challenge or engineers to work with great design to make it work. More importantly we hold design accountable if it doesn’t work. Accountability is the best design. Both sides need to make sacrifices when it comes to accountability and fulfillment.
We also end-up going back to the storyboards. What is 100% necessary on the start to prove market fit? Everything else is secondary and should be added to the product roadmap. This can affect everything from the people to the team and most certainly the components.
No one is going to use your product more than you are. So bend it, break it, freeze it, burn it, and record every step of the way. This is how you QA a product. There is a huge difference between running a demo and delivering a fully tested and scaled product. This works both ways. If members of your team are not testing the product find out why.
QA and testing can be the most challenging aspect. The vision may be clear in your head, but not clear enough for your engineers, or designers to grasp. Why is that? Is the process too complicated? Is something over-designed? Is the spec wrong? Can it work better? It’s best for you to iron out all of these questions before you move to manufacturing.
The good news is that you can turn debugging into content. The process and controls are fascinating especially if your storyboards are compelling enough. The component list is essential here. Every component had a reason to make the final cut. Test it and test it again to make sure that it works in a variety of environment variables.
A clean spec is everything. Make sure that the stack language is one where it is easy to sub people in and out. Utilize open source everywhere you can. Try not to re-invent the wheel. Software has become the glue that binds all of our devices and communications today. Borrow wisely architecturally and you’ll find stability.
Less is more. At least with software you have control. As long as you build and test in incremental steps, it aids with debugging. With hardware there are an exponential amount of issues that can cause a glitch. The simpler the embedded system, the less likely it’s causing interference. Out of the box, remove everything that isn’t essential and you’re onto a great start. Maintain focus on the essential builds and design. Focus on completing (and debugging) what is 100% necessary first before you embark on another feature.
Never go cheap on pix axes and shovels. 3D printers, resin, cables, connectors, coffee or whatever it is the team needs. Whatever you think you need double-it. The real cost center with products is not materials it’s time and labor. Nothing is more infuriating than encountering a bottleneck that is within your control to avoid. People are only as good as their tools. So budget and plan for overages.
Attitude is everything. The journey to build a product from start to finish is not for the faint of heart. You need to celebrate small wins. Be patient with delays. Accept that it takes at least three to four explanations before everyone is on the same page. Remember that you can always go back to the spec and storyboards. Also be realistic. The people you surround yourself with all have different agendas and dreams. Be tolerant and invest in them the same way that they’ve invested in your product and vision.
A product is a marathon not a sprint. No two products are the same or alike, but with the many resources currently available it’s easier than ever to transform a scribble on a piece a paper into a full-fledged gadget. Hopefully the above few pointers help.
From One Ear To Another,