NPD Tales

Ideas Thoughts and Comments on Product Development

Selectively Getting Real

I’ve spent some time recently working much more closely with the 37 Signals product BaseCamp (more about that another day).

Whilst looking over the company website I stumbled upon their ‘book’ Getting Real.  It’s an easy read that really gives you a comprehensive picture of the culture at 37 Signals.  It’s also full of some fantastic ideas many of which present a fresh viewpoint on the process of product development.  I would recommend people to read it.

The authors admit that the book’s emphasis is on building a web application but do suggest that ‘a lot of these ideas are applicable to non-software activities too.’

I’d add that I feel the book’s emphasis is on building mass market web applications, some of their ideas in the chapter on Feature Selection (’Start With No’, ‘Forget Feature Requests’) might not be perfect advice in a more specialist or niche field.

Is that the point of this type of book – to provoke debate and ask questions on how you do things whilst presenting a smorgasbord of ideas from which you can create your own way of working?  If that’s the case then there is always the risk that the reader will cherry pick the ideas that reflect their current state and achieve no improvement in the way they develop products…

Stand Up

There are times in some NPD projects or moments in the development of a specific team dynamic where there are a multitude of concurrent activities, a large number of people involved, interactions between tasks and most importantly many ways in which the whole thing can go off the rails.

Indeed there are some organisations where that is the norm…

In such a dynamic multi-faceted scenario even a weekly review meeting is just too infrequent.  But many project review meetings turn into long winded talking shops that preclude them being held any more frequently.

A daily stand up meeting might just do the trick – here’s some pointers on how to create value out of a short review meeting.

• Stand up, no chairs

• Same place and time every day

• Fifteen minutes, no more

• Control the attendee list – only those who are directly involved

• Each participant answers three questions

- What did you do yesterday?

- What are you going to do today?

- What obstacles stand in your way?

• Focus on removing obstacles

• Stop long winded discussions before they get going, note and action them for resolution outside the meeting

Most engineers have a dislike for review meetings simply because most review meetings aren’t run like this…

Cost of Delay?

Delays in product development schedules are almost inevitable.  Unless you avoid technical risk and sandbag your project plans there will invariably be some issue that will result in a potential slippage in your product launch date.

Corrective action might be possible.  You could lose some features, throw some more engineering resources or money at the problem – and the sooner you know about the problem the more chance you have of putting it right.  However it’s important to understand what impact the delay will have on the success of the product so the most appropriate solution can be executed.

If we look at a typical sales curve for a new product, there are a few key parameters that you need to think about.

launch delay factors

1 – How will the delay affect the growth of the sales?  Will the ramp up be slower (or in some instances – like where an earlier entrant has proven the market – quicker)?

2 – What will be the impact on the maximum sales?  Will late entry adversely affect market share (or do you command almost unshakeable customer loyalty)?

3 – When will sales start to decline?  Is this a fixed point in time (where new technology or next generation products take over) or does your product have the same life whenever you launch it?

4 – How quickly will your sales tail off? (This is less important and more difficult to relate to a delay in product launch)

It’s difficult enough to have a strong forecast of your baseline curve, let alone predict the impact of a late product launch.  More accuracy in these figures helps you make better decisions – but even if you can’t put exact figures on your graph, it’s worth asking the questions to understand the shape.

Customer Empowerment

In an earlier post (Collaborative Tools – Customer Involvement) I explored how the latest collaborative tools like SharePoint and SamePage are beginning to emphasise the value of customer involvement in new product development.  A recently published paper in the Journal of Product Innovation Management (Customer Empowerment in New Product Development) details some research on the same concept.

Illustrated with examples from Threadless and Muji (but they could also have included Yamaha with their EZ-AG Guitar) the authors describe the difference between ‘creation’ and ’selection’ empowerment and present the results of some research that shows a positive quantified impact from such close customer involvement.

Not every company can invite its customers to submit designs and let them vote which one will be used (like Threadless do with their T-Shirts) but it does seem to be worth spending a bit of time thinking about how you can tap into the creativity and decision making of your customer base…

Motivation – Recognition and Reward

I first saw this fantastic animated version of Dan Pink’s talk on Motivation last summer.

The assertion that Autonomy (Atlassian FedEx Days), Mastery (Linux, Apache) and Purpose (Skype, Apple) are three important factors in motivation is undeniable.  The evidence that Reward is not an important factor for all but the most mundane tasks seems sound.  However I feel strongly that Recognition is a powerful factor that is all too often ignored or even worse lumped in with Reward and discredited…

Discard or Fix?

I’ve blogged in the past about Lean Product Development and how I see the real process improvements can only be realised by considering the fundamental principles behind lean (identification and elimination of non-value added activities) and applying them to the non-linear non-repetitive world of product development.

On a number of occasions, in my role of facilitating organisations on their lean journey we have encountered existing processes or rigidly adhered tools which have been identified as a major source of waste.  Over complicated ‘gates’ in stage gate methodology, bloated QFD matrices, ‘rubber stamp’ specification sign-off process that delay progress there are many other examples.

The temptation to rip up and destroy these wasteful ‘offenders’, replacing them with something new and ‘Lean’ is indeed great – and I’d admit to encouraging such zealous behaviour in the past.

But recently I helped a group explore how to remove the waste from their Stage Gate process but still leave some of the principles of the process intact.  For an organisation with very high capital costs associated with their product development right from the start of the project it made sense.

If it’s broke then consider fixing it rather than throwing it away…

Downtime

What does someone with a passion for innovation and new product development do in their downtime?

Generally the same as everyone else.

But it’s also about finding enjoyable sources of inspiration – here’s a selection of my usual places to look.

Make – a US ‘hobbyist’ magazine about making things

Wired – well into it’s second year of the UK edition

Radiolab – Public Radio programme available as a podcast

and most recently The Foods That Make Billions – A fantastic BBC programme about the development and marketing of very profitable food products (on the iPlayer but not for long)

I’m new to Twitter (@gpcooke) but it seems to be a good source of ideas, thoughts, activities and events to do with innovation and new products.  Less formal than LinkedIn – more intelligent than Facebook…

If anyone wants to point me elsewhere please do…

Lean Product Manager

Many of my earlier posts have focussed on the topic of applying lean principles and thinking to product development (just click on Lean Product Development in the tag cloud on the right).  If your product development function embarks on a Lean journey, what are the possible outcomes that will impact the role of Product Manager?

Many sources of waste are associated with the large batch processing of information at various steps in the development process.  This is particularly relevant in dynamic markets where the requirements of a product can move as fast as the development process.  A common solution to this is to think of the development process as a larger number of rapid iterations with tighter customer feedback (Batch Size and Cadence).

In this situation, a Lean Product Manager needs to find a way to introduce some element of rapid feedback into his work but balance that with the more strategic elements of product management – positioning, pricing, benefits, roadmap, vertical market development and holistic stakeholder management.

In addition one of the common outcomes along the lean journey is the identification of the need for an Entrepreneur System Designer (ESD) or Chief Engineer an individual who is charged with developing a successful product by creating and communicating a vision for the overall product and inspiring a team of developers to strive to meet that vision (in contrast to a more remote management role that is focused on delivering success against a project plan).

Isn’t this a Lean Product Manager?

Again – unless you can ensure that your ESD is capable of managing the strategic elements mentioned above, you run the risk of a product that deviates from your roadmap, focuses too heavily on the requirements of a small number of important customers and/or provides new features for free that could easily have presented an opportunity to capture additional revenue.

The shift in requirements for a Product Manager operating with a Lean Product Development function is substantial but not seismic.  It is important to involve product management in your lean journey and work together to see how you can meet the challenge.

A Confusing Alphabet of UIs

I’ve been helping someone look into a drastic redesign of the user interface of their product.  The hardware engineers had done their job in successfully defining a very cost effective flexible touch screen display but it became apparent that everyone was fixed in their perspective of the appearance and basic underlying function of the user interface.  The attention seemed to focus very quickly on usability and whilst I agree that the subject is very important I felt that there was a unique opportunity for a completely fresh approach.

To encourage more creative thinking I looked into the different schools of thought on user interfaces and that’s when I discovered a growing alphabet of UIs.

From AUI (Attentive) to ZUI (Zooming) there are more and more ways of thinking about how your user interface will work that have been given their own acronym – though I’m not sure how to pronounce IUI (Intelligent) so maybe that one at least is an abbreviation.  Of course there’s TUI (Touch) and KUI (Kinetic), but the one that seems to be rising in popularity (at least when it comes to use of the term) is NUI (Natural).  Unfortunately the term is being appropriated to categorise a wide variety of ideas – from simply doing away with the ‘chrome’ from traditional GUIs to gesture driven interaction (and whether those gestures are captured on a touch screen or by a camera with suitable image processing behind it) – and of course the usability aspect I wanted to temporarily ignore is a key part of what many consider to be a NUI.

With so many new ideas flying around it was a tough job to keep everyone’s feet on the ground but looking at even the most outlandish ideas helped in creating a shift in the scope of the suggestions for the new product.

But more than that, it certainly opened my eyes to what some people suggest will be as revolutionary as the arrival of GUIs in the 1980’s…

Vanity Prototypes

Every year it gets easier to build ever more complex and sophisticated prototypes of your new product.

Software design tools facilitate the creation of a working model of an application with far less effort than it took to sketch screen layouts and build quick paper prototypes.

Development boards can be used to build working electronic products to demonstrate functional behaviour that would have previously required spinning a PCB.

3D Printing techniques and lower cost CNC machines make it possible to fabricate your mechanical product without the expense and time associated with injection moulded tooling and machine set up.

The real excitement comes not from the ability to do this but what you do with your rapid turnaround prototype.  Will it help you convince investors or senior management to greenlight your project?  Will it allow you to get some real feedback from the market?  Will it instigate fruitful discussions with the manufacturing or supply chain professionals?

Or will it be an expensive paperweight to show everyone how clever you are?…