New Product Development Strategic Planning

It has been a while since I posted something - summer kicked in, workload and also some time taken out to work out what my topic should be for my Exec MBA dissertation (Management Challenge in Henley Business School speak).  So where are we now?   Topic decided - I will elaborate more in future posts.  It is a topic that is certainly of interest to the product management community and to anybody that has been involved in a merger or acquisition.

In the mean time, a colleague sent this to me today - it certainly resonated and is closely related to my research topic as well:  Strategic Plans for Product Development:

solutioneering: does not deliver (part 2)

Following on Part 1 of this series "solutioneering: does not deliver", it is worth looking at all the different parties that suffer as a result of solutioneering and how the problem manifests itself.

It does not matter whether you are a sales account director, sales manager, sales & marketing director, a potential customer asking for a solution, an IT director trying to buy something or a pre-sales engineer trying to develop a solution specification - every single one of these roles is negatively affected by solutioneering.

If you have ever been fortunate enough to have experienced being in one of these roles, you will almost certainly relate to the absolute frustration when a proposal is submitted which does not articulate the solution that you anticipated.

Equally, as a member of the bid team, no matter whether you are the technical sales specialist or the account manager - after you have spent hours and long nights polishing a customer proposal, there is nothing more disheartening when the customer turns around and tells you that the solution is way beyond their budget and you need to shave 25% off the price.  Or even worse, they do not have a business case to support what you are proposing - can you please help put one together..... 

So what is the real problem that causes these scenarios to play out?  Customer expectation not set correctly? Customer requirements have changed?

Some analysis and reflection allows real causes to bubble to the top without offending any one party - it is human nature to help people quickly - identify solutions as soon as possible.  Look out for the following symptoms (these are not an exhaustive list - just examples):

• no documentation of requirements
• inability to articulate use cases
• budget envelope is not known
• urgent requirement to discount the solution
• have never met the actual business user with the problem
• vague process to evaluate proposals
• no/vague/flexible implementation deadlines
• no clear success criteria or metrics

Once can go on - but you get the general idea - the actual problem that needs to be solved has not been identified and as a result, the scope for disaster has been multiplied exponentially.  The risk of a deal not closing is off the scale at this point, as is the potential for delivering a very unhappy customer into the business.  What is always very scary is the fact that quite often nobody will stand up and say - we do not know what the problem is.

So what does this problem ecosystem look like?

Walking through the problem ecosystem, it becomes obvious that it is a combination of symptoms and drivers that result in the unsatisfactory outcome.  The solution to the the problem cannot easily be identified because I would argue the root cause is not described on the diagram above.

The real cause of the problem lies right at the start of the product lifecycle and has its roots in poor market needs analysis and investment decision making.  In part 3 of this series, I will look what could be the real root causes of this problem and potential options to address them.

Thoughts?

  What do you think?

Image: © Melis82 | Stock Free Images & Dreamstime Stock Photos

Naming Your New Product? Let the Battle Begin!

Every product manager knows the drill: business case approved, use cases completed, product requirements documented, then comes the dreaded "what are we going to call it".

As soon as this moment is reached in a product life cycle, suddenly everybody has an opinion.   Personally I think that it is easier to pick a name for your unborn baby - at least generally there are only two people that have to agree (with a little advice thrown in from others of course, but you are under no serious obligation to comply with their wishes).

Advice / instructions will be issued by exec's in the management hierarchy, sales, marketing etc.  And for the most part this will be driven by personal bias, opinion and nothing much else.  I have yet to see a substantive or  rational reason put forward for any product name - generally the biggest ego rules.  But there is light at the end of the tunnel!

Great advice: 4 ways to Think like an Innovator

I am working on the draft of part 2 of my series on "Solutioneering" and starting thinking about how cracking the problem, fits into a product managers frameworks and methods.  This in turn lead me to pondering on how to trigger some focused, creative thinking when approaching a customer request for a proposal - how could this fits into an innovation cycle  - how to think out of the box?

I came across a video blog post by Scott Anthony from Innosight,  which outlines a suggestion of 4 things to think about when you are stuck - in essence, how to think like an innovator.

1. Keep an external focus - this one has particular resonance with "solutioneering" and understanding the customer problem, but more of that in a later post.
2. Learn from your mistakes
3. Embrace your inner Edison
4. Resist the pull of the core.

The blog post is only 2 minutes and 58 seconds - take some time to go and watch it, it will keep you busy, and give me some time to finish up my next post.

[Image from PublicDomainPictures.Net]