What does it take to get a Thingie done, part #1

Let's say You are an inventor, and came up with a great new method of measuring something important and valuable. All it needs is a simple handheld device, that does the measurement and gives the results for the User. And perhaps wirelesly to a Cloud Service also.

Now You need the thingie that does it. Okay, there are some steps first, like verifying that the Invention actually works, getting some money for the development, perhaps starting a company...

Now, how can the Thingie be developed ?

In a modern world, You can use a Partner to make the project, especially the stuff that You don't have competence in Your company. Usually this means at least the necessary mechanics, embedded software, analysis software, user interface SW, electronics and software for cloud services or mobile software.

But is that how it goes ? Just tell the Design Partner what the Thingie is and wait for volume production to start ?

Well, no... Really not. Or depends a bit on the Partner.

Problem is, the engineers are usually really good in implementing a Customer need to a working device according to Customer specifications. But thre are two catches here : What really is the Customer Need, and what is a Working device. If we come back to the thing that measures something important : What is the device actually, and when is it done ?

Usually the Brand Owner (inventor) has a good or sometimes a vague idea of what are the important features for their new Product to be developed. And it is somehow described on paper as requirements, pictures and stuff like that. There's usually an idea how much it can cost, and for what cost it will be sold, and some estimations of how many will be sold per year. It can be taken as a specification of the work and get the project going on. Problem is, that this doesn't necessarily create the right kind of Thingie. It may of course. All depends on how well the Thingie idea and service has been developed and tested with real users.

But here's the thing : I'd say that it is typical to start making detailed design work before there's good enough understanding of what really is suitable for the intended use. And that is because thoroughly considering the Use cases, perhaps testing the concept with real users, preferrably with good pilot or mockup takes some time and costs some money, and also because it's easy to think that there is nothing unclear in the concept or to imagine that everything is understood of the users and their needs. A good pilot is small project in it self, and takes some effort in making. But may give invaluable insight into how possible users see the future device and it's value. And today it's quite easy to print a 3D model and use a Raspberry Pi or Arduino to make a Pilot functionality

Another thing is, that it's more than likely that the Design Partner doesn't really understand everything that goes on in the Customers mind. They understand the most important features, but there is usually a lot of secondary, but still valuable features and goals that are hard to be described in enough detail in paper. And if it's only described in talking, some of it is not understood and some is just forgotten.

So what is a good way to start a project ?

First of all, be sure that You understand is the purpose of the Thingie. And what are nice to have features, or things that can be implemented for next generation.
Write Use Cases and specifications with the Design Partner - Understanding Your needs is a process, not a read-only task. Anything can only be understood by time and some sweat. Target at making early prototypes and pilots for testing the concept with real users

There are lots of upsides for making the design in smaller steps, and piloting the Thingie. There's high likelyhood that understanding of what is really needed improves as the work progresses, and feedback from real users and real use environment really is easier to take into account. A good way of making the design is getting real functionality as soon as possible, moving to the real target, but if possible with proto & pilot steps. And the first prototypes usually don't need all the bells and whistles of the final product. Maybe even the end product really don't...

This approach also reduces risks, as any risks related to the product should be implemented and tested early on.

Downside ? Well, it may look like more work to be done. And possibly it also is. But in the end the odds are, that making a product in smaller steps, and testing it soon prevents major hiccups in later stage of product design.

Next time, some more stuff that should be considered early on when designing a Thingie :)

Networking in Product Development

As I'm leading and selling services for subcontracted Product Development, I'm naturally pro networking in R&D. I've been on the consulting side of R&D for 16 years now, and before that some years in R&D on the Customer side of the fence. I don't think there's many companies these days that are relying solely on their own resources in bringing up new products to this world.

But how does it show in my own work and in my own decisions ? OK, selling the subcontracted work of course and providing the best possible experts for my Customers. But in addition to having my own resources, and those within Espotel, I'm also drawing from a range of our own Partners or subcontractors, some of which have been our close cooperators for years and some new ones. It also gives a rationality check for our own work, as the way I see the subcontractors performance, the same way our Customers see us. We want flexibility, easiness and of course prompt and good quality delivery from our Partners, and that's what we must deliver also.

We have about 300 persons at Espotel, all doing R&D design work in projects or at the Customer site. And even so, we still use a lot of resources (don't have the exact numbers, but let's say over 10%) from outside of the Company. Why's that ? Quite frankly, because sometimes there are better experts for a specific task or we just don't always the persons available for a given competence area. And then there are skills needed in projects that we just don't want to hire to our company for several reasons. A fine example is Industrial Designers. ID is needed for most projects, but it is a different market still compared to engineering work, and would need a large pool of talents inside a company before we can say that our service in that area is in a professional level. There are companies focused on that area, with a replacing designer if something happens for a projects designer, and with help and a second opinion available in-house when needed. We can get that service when needed, so no need for us to get into that.

But we also use Partners for our core design competences, namely Software Design in several layers and for Electronics design and Mechanics design. Why ? Well, sometimes there's need for a very dedicated narrow competence that just isn't available at Espotel and sometimes we just don't have designers available in a needed location or at all. So it's pool handling, no need to have personnel for the maximum possible load always and for all specific competence areas.  And it's talent handling also, not all wisdom will ever be in one company.

Those reasons probably don't differ that much from our Customer's reasons for using subcontracting in R&D :)

With the help of our network, we are able to offer a one-stop project delivery to our Customers, with the best possible team, and also handle our own pool of designers effectively.