How well can you really understand your buyers?

By Saeed Khan

I had the pleasure of meeting with a number of international region sales managers recently. They covered geographic regions including Western Europe, the Nordic countries, Eastern Europe, Russia, Turkey, the Middle East and parts of Africa. There was a mix of direct sales staff and distributor/partner managers. This was the first time I’ve met with such a diverse group of  sales people all at the same time.

What was really amazing was the diversity of views and issues that were discussed.  The product in question was an enterprise IT software product, and while we do have price lists in numerous international currencies, the issues of pricing, discounts and difficulties selling the product were the focus of much discussion.

Now a cynic would say that when are these things NOT a focus of discussion with sales people? 🙂 But there were many  interesting points brought up by the group.

  • A very simple and seemingly clear value proposition in North America can be meaningless in another country because of different regulations or different business priorities.
  • In some countries buying decisions are VERY heavily influenced by the relationship between the buyer and the vendor and actual product functionality is less important.
  • In some countries there is a prestige factor (for the buyer) associated with certain vendors and certain products and that can heavily influence purchase decisions.
  • In some countries, local partners (e.g. system integrators and consultants) play a large role in the buying decision and implementation of a product, so their needs must be understood.
  • Not all regions viewed the value of product functionality the same way. Some regions valued certain functionality, while other regions saw little value in that same functionality.
  • In some regions, particularly emerging markets, piracy is still rampant, and security (or lack of it) in a product can be an influencing factor.

These are just some of the examples that were discussed, but it quickly became very clear that there was a lot of factors across the different regions that required different approaches to convince buyers to purchase product.

Buyer personae can be regional

When we typically think of buyers, we often talk about “THE buyer persona”.  But clearly there are MANY buyer personae that need to be understood. The sales managers understand their buyers — or at least are supposed to understand their buyers — but how well do we in Product Management and Product Marketing understand the diversity of buyers and buying criteria around the world? And how well can we stay abreast of the changes that will impact these personae? And with different personae, there will be a need for different messaging and likely different positioning. This has a fundamental impact on how the product is marketed in different regions.

These recent meetings really opened my eyes. I had a general sense of some of the regional issues prior to the meeting, but honestly, they were at a very high level, without much detail. Now I have a much deeper appreciation of the challenges we face in different regions, and I have a lot to think about as we plan product strategy and go-to-market activities for next year.

How do you handle regional differences with respect to your product? Is it an issue? I’d love to hear from you.


Tweet this: How well can you really understand your buyers? #prodmgmt #persona #sales

On Value Creation

I was reading this post by Steve Denning in his blog at  The Dumbest Idea In The World: Maximizing Shareholder Value.  Both Steve Denning and Roger Martin are two of my favorite management thinkers.

A snippet from that article:

“Although Jack Welch was seen during his tenure as CEO of GE as the heroic exemplar of maximizing shareholder value, he came to be one of its strongest critics. On March 12, 2009, he gave an interview with Francesco Guerrera of the Financial Times and said, “On the face of it, shareholder value is the dumbest idea in the world. Shareholder value is a result, not a strategy… your main constituencies are your employees, your customers and your products. Managers and investors should not set share price increases as their overarching goal”

As I have often argued in my posts here, traditional management theory and thinking is what won’t work in the future.  Just as Jack Welch did a convenient U-turn above, so did Michael Porter very subtly in his ‘Creating Shared Value‘ post in HBR earlier this year that might be the anti-thesis of his Competitive Strategy published in 1980.

So what we are seeing in recent times is not just a failure of the value creation models of the past that executives live by, but even celebrated theorists and practitioners alike are now admitting they were wrong – some openly like Jack Welch.

What does all this mean to a product manager?   Make products customers would use, you would use and let the market decide.  Don’t waste your energy in things like managing analyst expectations – not just financial analysts, but also “industry analysts”.  There are far more powerful mediums where you could get social worth for your products and services by going directly to the users – that is where and for whom, value is created.

– Prabhakar Gopalan

Tweet this: On Value Creation @PGopalan

Worth Repeating: The Benefits of Focus

Back in 2008, Ethan wrote this post of focus and targeting a specific niche. It’s a great little piece because it demonstrates that you can be successful without trying to appeal to everyone. Actually another obvious example of this is the huge proliferation of specialty TV channels. Way back (30+ years ago) most countries had very few TV channels, and they were mostly all broad based. Now, there seems to be a specific channel for just about every market-segment you can imagine – and they all seem to find an audience.

Most products do a lot. It’s tempting to try to sell all that functionality at once. But a lot of products benefit from having less as opposed to more. Yesterday I ran into a problem: I bought a new car. OK, that wasn’t the problem. My new car has a roof mounted antenna, one that goes back at 45 degrees. Driving into my garage is no problem but backing out again results in the antenna snagging against the bottom of the garage door. My fix was to unscrew the antenna. The unfortunate side effect was the we lost radio reception a lot sooner than normal as we drove out of town.

I figured there must be someone out there that has a solution to this problem. I mean, a shorter antenna isn’t exactly rocket science. I eventually found a site that had a solution so compelling I bought is right away – something very unusual for me, who normally spends an hour of research per dollar (yes, it takes me 2.99 hours to buy a loaf of bread). The miracle site?

Never have I found a more focused site. I mean, if you want a stubby antenna, this is the place. There’s selection and nothing to distract me from my task of finding a short – sorry, stubby – antenna.

I know that your product is a lot more amazing than a stubby antenna, but I doubt you could close a sale in five minutes. What could you remove – from your marketing material, if not your product – that would at least cut your sales cycle in half?


Tweet this: The Benefits of Focus (and Niche Markets)  # prodmgmt

Releases, Roadmaps and Visions

By Saeed Khan

Roadmaps are always a popular topic when discussing products. I can’t tell you how many times people ask whether something is “on the product roadmap”. One of the most consistently popular articles on this blog is this one that I wrote back in 2008 – Agile/Scrum and Product Roadmaps.

Recently I noticed some thoughts on the Web and decided another post on the topic was in order.

The first was the Twitter #prodmgmttalk on the topic of roadmaps. Here are a few tweets from that discussion:

Note @bfgmartin’s tweet about the roadmap (potentially) changing every week. That’s pretty granular IMHO and is really more of a backlog or at best a release level view of the product.

Coincidentally, Fred Wilson had a post on his blog a few days earlier called Long Roadmaps. In it he wrote the following:

I interviewed Dennis Crowley yesterday at the NYU Entrepreneurs Festival….Dennis said that all the way back to Dodgeball, the predecessor company to Foursquare, he and Alex had a roadmap for the product that was years ahead of what they could actually build. When Dennis and Naveen decided to start building Foursquare, Dennis pulled out that roadmap and updated it to reflect the power of modern smartphones. And that roadmap goes way out, well beyond what Foursquare is today or what it will be in a year from now.

Just to be clear, Fred is saying that Dennis Crowley had a “roadmap” for a product so forward looking that the technology for it didn’t exist. i.e. it couldn’t be built at the time it was “envisioned”.  This is not a “roadmap”, but more of a vision of the future.

So the question is what exactly is a “roadmap”, because it seems to have quite a broad definition in terms of timeframe and granularity.

If we think of Releases, Roadmaps and Visions as plans, they can be described and differentiated as follows:

[table "3" not found /]

This breakdown makes sense to me. It’s what I’ve used pretty consistently for many years. For example, back in 2008, in my Agile/Scrum Roadmap post, I defined a product roadmap as follows:

A roadmap is a planned future, laid out in broad strokes — i.e. planned or proposed product releases, listing high level functionality or release themes, laid out in rough timeframes — usually the target calendar or fiscal quarter — for a period usually extending for 2 or 3 significant feature releases into the future.

For startups or companies in fast moving and growing markets, those 2-3 releases might only cover the next 12 months of time. For other more mature companies in less dynamic markets, those releases might cover several years.

So what do you think? Are these three things clearly defined now? Is it still possible to confuse a roadmap with a release, or a roadmap with a vision? Let me know.


Tweet this: Releases, Roadmaps and Visions #prodmgmt #innovation #roadmap

Build vs. Think – The Need for Thought Experiments in Product Development


Note: This is a guest post by Fred Engel. If you want to submit your own guest post, click here for more information.

I was attending a feature set review the other day. As usual there were two camps each with a strong attachment to their solution. Not having a strong opinion on either side I asked, “How would someone succeed or fail with each of the options?” To my surprise, the response I got was

“Let’s just build one and see. In Agile, you build first and ask questions later. It is just impossible to think this stuff through, which is why you build.”

Now Einstein came up with the whole relativity thing using Thought Experiments. Surely our problem is not as complex as that, I argued. Besides, have we tried to figure this out? Do we know what is well understood and what is not? This line of reasoning was not being bought by the group. They wanted to build as a way of figuring things out.

What is wrong with “just building it”?

Building anything is costly in time and money and while it feels like progress, it is not. Just because something is being built does not mean there is progress. Progress implies forward movement towards a goal. Without out well thought out steps, the effort may not be progress but just movement. As discussed below, “just build it” is one of the tools in the arsenal and should be used after the thinking is complete.

What is a thought experiment?

A Thought Experiment is a fancy way of saying: “think through the various cases and scenarios of how things are going to work”. Thought experiments postulate different cases that are expected and think through the outcome. These “dry runs” are the cheapest, fastest ways of making progress for a broad set of problems. Usability walkthroughs are an example of this. Test driven design is another example. The process does not have to be formal, although it does need to provide good coverage.

One should always use Thought Experiments

There is never an adequate excuse for not using the brains in our heads to think things through. Here are some benefits of doing thought experiments:

  • Save time and money
  • Allow you to bring other people into the solution because you understand it better which will lead to you being more convincing.
  • Make you to understand the problem better. Working out the details in your head and on paper really does allow you to simulate doing it for real.
  • Solve the problem and give you a solution.
  • Bring clarity to what the real issues are. If you do thought experiments you will figure out what is easy and what is hard. You probably will discover what actually does need to be built and tested empirically.
  • Allow you to assess risk in the project and allow others to see how hard the hard parts are.

There are times to “just build it”

There are certainly a number of problems that can be solved best by experiment. It is after the thought experiment has been worked out that one can consider actually coding up the solution. The default should not be “just build it” but rather “here is what we should build and why”. Good reasons to “build it” include:

  1. There are some key complex pieces that need to be built to understand the feasibility of accomplishing the task at hand. Complex algorithms dealing with real data are a great example of this.
  2. New usability ideas. There are so many examples of good human interfaces that not learning from these seems wasteful. Know what you are doing that is new.
  3. What you want to build is simple and much easier to do than to do a thought experiment on. This case rarely exists but is far too often used as an excuse for not thinking in the first place.
  4. The people who need to be convinced will only be convinced with a working prototype. This is an unfortunate, but necessary, political answer to a real problem. “Seeing is believing” is sometimes the only way to understand or to move forward.
  5. When you really do not understand the dynamics of how something would be used, it is time to build.When you are just prototyping to get some understanding of a new paradigm.

The Product Manager (or owner) needs to drive this process and guide everyone away from just building.  Engineers have a strong desire to get moving and start building.  If the Product Manager/Owner has done a lot of the thought experiments early, the arguments of what should and should not be “just built” will be much easier.  The challenge is to have the strength of character to force more Thought Experiments.


Fred Engel is founder and CEO of Westerly Consulting, a management and advisory consulting firm based in Rhode Island.

Tweet this: Build vs. Think – The Need for Thought Experiments in Product Development #prodmgmt #innovation