Lessons in Product Development

New Product Development

In Product Development Process we looked at all the steps in Product Development. The need can vary a lot and so it is also useful to hear from those who have bright new products to market. So it is with pleasure I can direct you to an excellent resource with 8 lessons from top executives.

 

Here is the list of lessons:

 

  • Melissa Perri: Learn what your users want before shipping
  • Marc Rubner: Deliver a tangible impact for your customers
  • Christophe Gillet: Assess market viability
  • Brian Tubergen: Prioritize the best opportunities
  • Andrea Schneider and Lauren Gilchrist: Educate stakeholders on modern best practices
  • Jeff Gothelf: Define objectives in terms of business problems
  • Jeetu Patel: Build teams that are motivated to execute
  • Eric Ries: Prioritize experimentation

The collation is by Mike Fishbein who interviewed each executives and there are also podcasts expanding on the ideas.

Mike Fishbein

Mike Fishbein

So check out New Product Development: 8 Lessons From Top Executives and enjoy. And thanks Mike for bringing it to my attention.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2018 Successful Endeavours Pty Ltd.

 

 

Electronics Design: Prototype

What is a Prototype?

A Prototype is done in order to explore some aspect of a new opportunity without having to fully commit to it yet. Prototype has a number of potential meanings including:

 

  • the original or model on which something is based or formed.
  • someone or something that serves to illustrate the typical qualities of a class; model; exemplar:
  • something analogous to another thing of a later period:
  • Biology. an archetype; a primitive form regarded as the basis of a group.

So a Prototype is either an early model or a smaller scale development to test a new idea.

 

Why Prototype?

So for engineering, we Prototype to reduce risk, and we learn from Prototypes to improve the likelihood of project success by being better informed for the next round of design. So a Prototype is a core Product Development Process Risk Management strategy.

 

Product Development Process

Product Development Process

A Prototype can also reduce other risks such as financial risk or market risk and isn’t always done for technical risk reasons.

 

Financial risk can be managed by breaking a project up into a series of stages and only committing funds to a stage when its predecessor has been successfully completed. A Prototype is often done ahead of a major block of Product Development to test whether the technical approach is likely to succeed and provide early warning of unexpected problems or interactions.

 

Market risk can be managed by trialling a new product idea with a smaller group of candidate customers to gauge their acceptance of the product. This has to be well managed however as history has shown that this approach, especially in the case of focus groups, can often just elicit the outcome the company hoped for and not a real example of how the market will react. Just look at all the failed Coca Cola new flavour launches.

 

And of course, technical risk can be managed by making Prototypes that implement the highest risk features as early as possible. We covered this in Improving Product Development.

 

A Prototype can often be used during Engineering Analysis in order to evaluate the effectiveness of different options for addressing the Requirements. This is covered in Electronics Design Process.

 

Successful Endeavours Development Process

Successful Endeavours Development Process

And then having designed a product it is normal to build a Prototype to ensure the final solution works as expected. This manages the risk that production tooling might need rework or even redesign.

 

How to Prototype?

This depends on the problem you want to solve. For this section we will focus on technical risks. A Prototype is very useful to allow you to measure some essential elements of the final product without committing to a final solution. So you can explore:

 

  • modelling a problem and simulations
  • noise and interference
  • power consumption
  • performance versus cost (compare several different prototypes)
  • responsiveness
  • system resources required
  • hardware versus software solutions
  • temperature rise
  • materials properties
  • shape and usability / ergonomics
  • fit (especially PCBs in mechanical housings)

And the list can go on. The key is to determine where the risk is and manage that. In Project Management Pre-preparation we looked at using a Prototype to reduce both technical and financial risk at the same time. In this case, other developers hadn’t been able to produce a working product so the client had a clear risk to manage. And our approach was to make a jig that allowed us to explore the sensing that was needed and get real data to then analyse and develop a solution. The same jig allowed the solution to then be tested before we designed the Electronics PCBs and Embedded Software needed for the final product. And the client was able to authorise each next level of expenditure with confidence based on us having delivered against the requirements for the previous stage.

 

Simulation

Simulation

And of course, 3D Printing for Electronics has enormously expanded the possibilities for mechanical prototypes by allowing anyone to quickly build and test the fit of objects together. It is also a viable option for low volume manufacturing.

 

3D Printed Spacer

3D Printed Spacer

3D Printed Spacer Fitted

3D Printed Spacer Fitted

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2017 Successful Endeavours Pty Ltd.

Design Led Innovation

Design Led Innovation

Traditional Product Development comes up with the product idea, does the development, gets it into production and then tries to find customers to sell it to.

 

Design Led Innovation tries to turn that process around so the actual needs of the customer or user become part of both the product definition and the business model development. If you haven’t already heard of it, check out the Business Model Canvas.

 

I get the opportunity to present on topics like Innovation to Business Groups and even MBA programs and one of the interesting statistics I use is that the number one area for Innovation in the world today is the Business Model.

 

How Does Design Led Innovation Work?

So how does this all work?

 

Design Led Innovation

Design Led Innovation Process

 

In Design Led Innovation, the expected outcome is that when you engage with your customer, and begin to understand their needs, then you can start to offer them something that has much higher value for them and allows you to get a better price for offering that much higher value. The outcome is the classic win:win that great business is meant to deliver. And it is a key factor in not getting caught in the classic commodity service price war with the client’s purchasing officer driving the process.

 

It is also a continuous process. One description is that it is like “rebuilding the plane while it is in flight”.

 

Sounds scary, but the results seem to show it is well worth doing.

 

Design Led Innovation session at SEBN

At a recent SEBN breakfast session we heard from Tricomposite about their  experience of using Design Led Innovation to revolutionise their business and not only service their existing customers better, but offer them products they didn’t even know they wanted and create a much better value offering for them than they had ever considered before. And this has opened up potential market offerings to other customers who they would never have considered they could work with.

 

Here are the themes they explored in finding this offering:

 

  • focus on designers, not buyers
  • test is time pressure leads to design mistakes
  • test is rapid full-sized final material prototypes were valuable
  • test if there was room for service level agreements
  • test if there was room for collaborative design

 

And the answer to 4 of these was a resounding yes. Only the service level agreement test failed. Basically, customers expect service as a given. But the rest has opened up a complete rethink of their business. In fact, they shared that it was their existing perspective on their business that proved to be their biggest limiting factor.

 

 

Business Model Canvas

Rethinking the Business Model is a key component of Design Led Innovation. But not as an end in itself. Only after understanding your customer’s real needs can you determine how to make it easier to do business with them.

 

I recommend getting the Business Model Canvas book and taking advantage of the free downloads at Strategyzer. Here is a example of one of their tools.

 

Business Model Canvas Example

Business Model Canvas Example

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In Australia. Ray Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2016 Successful Endeavours Pty Ltd.

Product Development – what they don’t tell you

Product Development

As a process, Product Development can be handled a number of different ways. And if your product only requires input from a single technical discipline which you are very experienced in, then you can usually predict everything you need to do and just make sure it all happens the right way.

 

But if the product is complex, involves many disciplines, and has unknowns about the technical direction to take, then it can sometimes resemble a roller coaster ride more than it does a straight forward journey. And there can be unexpected bumps along the way.

 

Our most recent employee brought this video to my attention and I thought it covered this topic really well. We used it for an in house lunch and learn session so I recommend you check it out to. It isn’t short so you might want to set aside a time you can sit back and enjoy it.

 

The presented is Andrew “Bunnie” Huang and the conference he is presenting at is linux.conf.au 2013.

 

Quite a list of things you can run into just getting a fully package embedded computing device ready for market. The HDMI Man In The Middle exploit was my favourite part.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2015 Successful Endeavours Pty Ltd.

Electronics Design: Requirements Capture

Requirements Capture

Product Development is the core process your use when you have a great idea for a new product, or an improved version of an existing one. The very first step is to define what it is meant to do.

 

This first step is known as Requirements Capture. And requirements break down into 2 categories:

 

  • User Requirements
  • Engineering Requirements or Technical Requirements

 

These are related to each other and it is often useful to look at them in the right sequence. I’ll explain why later. Let’s look at what each involves.

 

User Requirements

This is a description of the product from the perspective of the user. It is written in the language of the user and describes what the product does and how it is used by the user.

 

User Requirements

User Requirements

We work with both technical and non-technical clients and the one thing they both have in common is that they can both write a document like this. It is also important that the focus begins with the user. Otherwise we can get carried away with the technical side of things and forget a real human being is going to have to use it one day. Concepts like Intuitive can have very different meaning to Engineers and the general public. So it is important to start with the user’s perspective.

 

Technical Requirements

This is what you end up with when you analyse the User Requirements through the lens of technology. We are translating from the user perspective to the technical perspective or engineering perspective.

 

Technical Requirements

Technical Requirements

As an example, the User Requirement might be that it complies with the relevant standards. This will translate to it passing C-Tick requirements for sale of product in Australia as part of the Technical Requirements.

 

Another example is that the User Requirement is that it must run off a pair of AA Batteries for 6 months. This then translates into a Technical Requirement that its average current consumption must be less than 0.57mA. If you are wondering how I came up with that then the maths goes like this:

 

An AA alkaline battery = 2500mAh so the average current consumption has to be 2500mAHr / (24 hours * 365.25 days per year / 2) = 0.57mA.

 

That is the sort of analysis that is done every day by Engineers every day.

 

Requirements Analysis

The reason that it is important to look at User Requirements first is that we technical professionals love technology. And we love all the answers to the How questions. If we don’t focus on the What questions we can end up with a beautiful piece of technology that no-one actually has a use for.

 

User Requirements = What

 

Technical Requirements = How

 

So there is quite a difference in how Engineers think compared to the rest of the world. For some other examples you might like to also look at these posts:

 

 

Does this work

Does this work?

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.