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

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]

solutioneering: does not deliver (part 1)

Somebody asked me the other day whether I was still blogging.  The answer I gave was "yes"  I am, but I have not posted anything for a while.

The reality is that I have been caught up in MBA project deadlines,  exams and a whole load of stuff going on in the office which has proven to be a distraction and a source of new material for this blog .... in time.

The twig finally snapped.  I was in a meeting last week and the debate was raging about how to structure a customer solution and the associated proposal.  Earlier in the day, I had seen on a PowerPoint slide the phrase "(re)setting the customers expectations".  It got me thinking about why there was a need to (re)set a customers expectations?

My conclusion - it is due to Solutioneering.  Plain and simple, nothing more and nothing less.

One definition of Solutioneering that I came across is "putting solutions before problems" (defined by D. Keith Robinson) and this describes exactly one of the fundamental reasons why both sales and product management often struggle to (a) scope a customer solution and (b) understand what the customer value proposition should be.

In the telecoms and systems integrator environments, we have no shortage of expert and highly skilled solutioneers.   I bet that if one really checks, one of the main reasons why there is a gap between customer expectation and delivery, is simply because all of this talent has been focused on the development of a solution, without really understanding what the problem is that the customer is trying to solve.

So what are the pro's and con's of Solutioneering?  This got me thinking and also back and the keyboard to examine this in more detail ...... in Part 2.

Engaging with social networks = United Breaks Guitars

Anybody that follows trends on social networks has probably heard of Dave Carroll and his YouTube video about United Airlines and their treatment of his guitar.  Yes, it is an interesting story that demonstrates the power of social networks (and the fact that YouTube viewers appreciate a really good video), but there are some real lessons to be learned as well.

If you have not seen it - then have a look below. Within a week of it being uploaded it had more than three million hits and the mainstream media had picked it up - CNN, The Wall Street Journal, BBC, CBS, and many other print and electronic outlets.

Idiot! You can't disconnect your Value Proposition, Corporate Vision and Personal Freedom!

There is a powerful talk by Simon Sinek on TED that outlines his reasoning why there is a case for communicating your value proposition from the inside out:  talk about what your company vision is, before you discuss the specifics of the product value proposition, and what you do.

As I have outlined before, the reason for bringing a specific product to market and understanding exactly what the problem is that you are trying to solve is fundamental.  If you cannot answer the simple question of what the problem is that you are solving, then "Houston, we have a problem".

WHY is THE most important Question

Starting to build a product is daunting, but in reality, the immediate temptation is always to delve straight into the detail, without really understanding why you are building a product in the first place.

It does not matter whether one works in a startup, large corporate, or even a medium sized organisation that is somewhere between startup and exit strategy. What differentiates the good ones from the bad, is that they understand why they are doing something.