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!

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.

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.)

Principles for Decision Making

Product managers often work in an environments where clear management demarcation lines seemingly do not exist, or are at best, blurred.  Matrix management, cross functional teams and dotted reporting lines are just a day to day reality. Add to this the current economic climate, restricted headcounts and tight budgets, getting decisions made and making them is often very challenging.

I was browsing the HBR blogs a couple of days ago and came across a posting by @tonyschwartz in which he outlines 10 principles by which you can benchmark your decision making process. These are: