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:
Thinking out loud, my reflections on product management, strategy, scenario planning, innovation and any other stuff that interests me.
Showing posts with label product development. Show all posts
Showing posts with label product development. Show all posts
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:
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.
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?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).
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!
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.
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.
3V's are key for a Successful Customer Focused Strategy
Strategists will be aware of all the usual models: Porters 5 Forces, Ansoff’s Matrix; BCG’s Growth-Share Matrix; 7S McKinsey Model, PEST(LE) model; SWOT analysis; IDIC (Peppers & Rogers) etc. Maz Iqbal in a blog post puts forward the notion that the 3 V's of Vision, Value and Value Proposition are potentially another framework that is relevant and could be used.
He argues that having a vision is key: "The power of a Vision Statement lies in its ability to enroll a diversity of actors (Tops, Middles, Bottoms, Customers, Suppliers...) in an inspiring point of view on the future such that they co-operate in moving towards and creating that future." The point that he makes about taking the different stakeholders along with you is an important one.
He goes on to argue that values are "real - authentic" and "act both as guides and as constraints on what you will and will not do and how you will conduct yourself". They have "another advantage, they allow you to find / attract value chain partners", again having partners that share the same values is pretty fundamental.
Finally he concludes that "If you get the Value Proposition right then you will attract hordes of customers. If you actually deliver on the Value Proposition – the customer experience delivers the value proposition – then you will keep customers and they will get more customers for you through word of mouth."
It makes sense, anything to add?
(you can read the blog post here.)
He argues that having a vision is key: "The power of a Vision Statement lies in its ability to enroll a diversity of actors (Tops, Middles, Bottoms, Customers, Suppliers...) in an inspiring point of view on the future such that they co-operate in moving towards and creating that future." The point that he makes about taking the different stakeholders along with you is an important one.
He goes on to argue that values are "real - authentic" and "act both as guides and as constraints on what you will and will not do and how you will conduct yourself". They have "another advantage, they allow you to find / attract value chain partners", again having partners that share the same values is pretty fundamental.
Finally he concludes that "If you get the Value Proposition right then you will attract hordes of customers. If you actually deliver on the Value Proposition – the customer experience delivers the value proposition – then you will keep customers and they will get more customers for you through word of mouth."
It makes sense, anything to add?
(you can read the blog post here.)
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".
Product Strategy and Portfolio Development need Scenario Planning
I have been thinking about innovation, and how to identify, and then prioritise potential product portfolio development options. Quite often, the choice of what needs to be done in order to rejuvenate a product portfolio or evolve it into the next generation of offerings is driven by individual personalities, or a limited leadership group, or just simply "group think" that is driven by financial decision making metrics, or the latest "pet" idea. How then can the business ensure that all angles have been covered before a decision is made?
Focus on the Customer
Quite often product management is focused on the product/solution that is taken to market. I would argue that it is not the product that is important. It is the customer. Unless you have a very clear understanding of the customer context in the market that you are trying to address, you have a solution looking for a problem, which inevitably leads to failure in the worst case, unnecessary resource (cash) consumption and delayed success in the likely case.
Subscribe to:
Posts (Atom)