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 two 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 six 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.

Product Development Process

Product Development

As a technical professional, I tend to think of the Product Development Process, also known as New Product Development, as the creation of the product technology through to a working unit that can then be manufactured. And of course managing risk to Improve Product Development Outcomes. The only thing wrong with this picture is that this is only a part of the overall process of bringing a new product to market. So I’ve put a diagram together that shows a more complete picture.

 

Product Development Process

Product Development Process

One thing I noticed when I did this is that there were four areas that had the most influence on the overall process. These are:

 

  • design capability
  • development capability
  • funding
  • production capability

 

And of these, the ones that had the most influence were:

 

  • funding
  • development capability

Products Have Stakeholders

A successful product is successful within a market and has multiple stakeholders. A developers, we might not be as aware of all these stakeholders as we could be. For instance, a product must not only work from the technical performance perspective, but it must also work from the perspective of the manufacturer, the sales person, the installer, the service technician, the shareholders, those tasked with public safety and clear mobile communications, those who have to dispose of the product at its end of life and of course the end user. That is a lot of people to please. And they aren’t all on the chart above either.

 

This is why exceptionally good Product Development is not just a case of following a specific methodology. So we are mostly involved in the Product Development Process but it does help a lot to see that there is a bigger picture and that even if you do a good job technically, it is just one of the the ducks you need to line up in order to get all your ducks in a row and a successful product into the market and making money and adding value to everyone.

 

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.

Visualisation: Part 2

The Client Perspective

What you see depends on which direction you are looking from.

 

What do you see

How many bars?

If you count from the top, there are 10 bars. But there are only 7 bars when you count from the bottom. In this case it is an optical illusion based on how the drawing is constructed. However in real life the same sort of dilemma faces us as engineers when we are looking at Product Development from the technology perspective and the client is looking at it from the Return On Investment (ROI) perspective.

 

Roger La Salle makes the case in his book “Think New” that the problem with most new product introductions is not the technology. In general, we engineers will find a solution. The risk that usually kills the product is the business risk or market risk. So our focus as engineers is on making the client successful by getting the product to work technically through Innovation and our skill as engineers, but the client’s biggest risk remains maximised the whole time. The business risk is only dealt with when the product is finally being sold in sufficient quantities to cover the development costs and now return a profit.

 

Those are 2 very different perspectives. It is worth keeping that in mind the next time you are working on a new product.

 

The image for today’s blog post was provided courtesy of Dr Marc Dussault, The Exponential Growth Strategist who is always on the look out for examples of antimimeticisomorphism, which I am sure you’ll agree this is!

 

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 © 2013 Successful Endeavours Pty Ltd

Engineers in Business

Ideas Worth Pursuing

 

Matt Barrie

Matt Barrie

BRW recently ran an article by Matt Barrie on business ideas that are worth pursuing. If you haven’t heard of Matt Barrie, he founded Freelancer. In the article he wrote about business ideas that interest him, and what doesn’t interest him. In particular he had a sideswipe at us Engineers about our focus on the technology and solving those problems first instead of testing whether the idea has a viable market. As an Engineer who has had to learn about business in order to run one, I can agree with some of what he said. In particular, we can become so focussd on the technical problem that we don’t make sure there is a real business case for the final product or service.

 

Here is the short list of what Matt Barrie doesn’t like in a business:

 

  • Anything that involves selling your personal time – e.g. consulting
  • Anything that isn’t scalable – more on that later
  • Anything that requires a technology breakthrough before you have something to sell
  • Small, niche and low total market potential opportunities

 

By scalable, Matt means that the sales potential is not directly proportional to either people or capital investment. Matt wants leverage. In his words “Businesses that are not scalable are bad”. But is this really the case? And what does he mean by bad?

 

Is non-scalable always bad?

I agree that if you want to maximise your income potential, the non-scalable businesses will not give you same ability to do that as scalable businesses will. However my business doesn’t only exist to make money. Making money is a by-product of a good business that is well run and meets a real need. Businesses should make money, otherwise they are not adding enough value or not well enough run.

 

My favourite business quote is “The purpose of the organisation is for ordinary men and women to come together, and in cooperation with each other, do the extraordinary”!

 

For me, business is a mechanism to make the world a better place in partnership with others. It is too big a job to do on your own. And it should deliver real value.

 

There are many essential non-scalable activities out there. Here is a short list:

 

  • anything to do with the patient side of medical or nursing care
  • most forms of teaching and education
  • personal services
  • mental health
  • government
  • Product Development
  • construction

 

Notice I said activity. For the quote above also covers the “Not For Profit” sector and Government. Both should deliver real value. They just don’t directly derive their income from that value.

 

I’m sure Matt Barrie is not upset if he has to see a Doctor just because the Doctor does not have a scalable business.

 

The final point above is about Product Development. Thomas C. Gale said, “Good design adds value faster that it adds cost“. So I am not advocating development at any cost. It has to have a value proposition. A client of ours recently told us of a product we designed for them nearly ten years ago that they had made millions of dollars from. Given our fairly modest fees for that project, they got a massive bargain there. That was an example of very good value Product Development which they got a lot of scalable leverage out of.

 

Product Development uses a mixture of leverage and personal effort. Leverage comes from using existing technology tools to do the work faster. This includes things like:

 

  • Computer Aided Design and Analysis tools
  • Reference Designs and existing technologies
  • Science and technology understanding already known
  • High Level Design tools and processes
  • Compilers, libraries, components, operating systems, platforms, standards
  • Research findings, existing data, other specialists

 

The above all came from past work that can be used to make current work more productive or more effective. I started my career laying out PCBs using tape. Now I wouldn’t dream of not using a CAD System. We use Altium Designer for Electronics Design Schematic Capture and PCB Layout. This is much more productive than the manual methods. As part of our ongoing Product Development activities for our clients we design and lay out a new PCB every 2 weeks on average and this is only possible with the use of CAD tools and the full leverage of our experience. In general I don’t want to rediscover the wheel, or the technological equivalent of that, in whatever area of Electronics Design or Embedded Software Development we are working at the moment. I want to take as much advantage of leverage as I can, and only apply the personal effort to what I can’t buy at a reasonable price.

 

Likewise we use proven Software Development tools that just work every time. It is not a good use of any of my team’s time to be working out why the latest release of something no longer works or breaks a project we had nearly completed. Of course we shouldn’t do that mid project anyway, but the legacy issue still applies. Clients do want updates down the track. So we use IAR tools for our Embedded Software Development. They work, are well supported, and we almost never have an issue of any kind with their performance.

 

So my conclusion is that non-scalable business activities are essential to modern economies. They just aren’t where the maximum profit potential is.

 

Let’s take manufacturing. We serve Australian Manufacturers by providing them with the new Electronics Designs they need to either remain competitive, become market leaders or bring a brand new product to the market for the first time. The manufacturing side is scalable although the Australian economy primarily supports lower volume or niche manufacturing opportunities. But once a design is in production and the process is running, they can scale up to meet demand within their capacity.

 

But our business activities are not scalable. Each design takes at least some personal effort to produce. But if I stop my non-scalable activities, then someone else has to do it. And if everyone does the same, if all the non-scalable activities stop, guess what – the scalable activities also stop!

 

Freelancer enables the buying and selling of non-scalable activities in a scalable way. It is a great service to those who use it and extremely good value. I agree with Matt Barrie that it is a good business.

 

Personal effort is still valuable

Warren Buffet said, “No matter how great the talent or efforts, some things just take time. You can’t produce a baby in one month by getting nine women pregnant.” Some things cannot be sped up by adding more resources. This analogy works well because we all know this is the case for pregnancy. Many other things are also like this. It will take generations to get peace in some parts of the world. Mindsets cannot be undone overnight. And it takes time to create economic frameworks. Successive Australian governments have spent 50 years working toward an uncompetitive Australian Manufacturing industry. This will not be undone with one policy initiative or one statement of a change of approach. It will take time and personal effort, by those with a vision, to make it happen.

 

So my belief is that personal effort is not only still valuable, but still essential, even if there are limits to how much I can scale it. I agree with Matt that it isn’t going to make me as rich as his approach will make him, but I’m not just in it for the money. For me, it is not bad, it is essential.

 

The link to the full article is no longer available.

 

The twin pillars of modern business are Greed and Ruthless Efficiency according to the Harvard School of Business. If this were an organic process, we would call it cancer. Ultimately it will kill. We need a better model and we need better values. Greed and Fear are the enemies of many a good thing.

 

And if you were wondering where my favourite business quote comes from, it is from Aristotle, some 380 years B.C.

 

Want a great career?

And finally, a Ted Talk on “Why You Will Fail To Have A Great Career”! OUCH! But is it true?

 

This is an excellent presentation that challenges many of the common assumptions about careers. But there is hope and Larry Smith explains both the challenge and the solution.

 

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 © 2012 Successful Endeavours Pty Ltd