Monthly Archives: August 2012

Guard Your Intended Roadmap – By Reguarly Asking Yourself These 4 Questions

By Rivi Aspler

Can you say ‘No’ to customers’ requirements? Should you?

Good product managers always keep their intended (and yet dynamic) product strategy in mind, i.e. the list of required modules, features, workflows, parameters etc. that all together define the best possible product. And yet, most product managers, once faced with real-life customers, will be asked to add features and modules that may not align with their intended product strategy.

This is where a product manager will be required to actively analyze each and every requirement and sometimes return to the customer and say ‘No’. Easier said than done of course. Product managers should stay on-guard, making sure that their intended product strategy doesn’t turn into a (not good enough) practical product strategy.

Now, I know that this is one of those blog posts that if I was the one to read, I would definitely say …. Yea, Yea…. Let’s see this person sit in front of a customer and say:
“No. We don’t have this feature in our roadmap and are not planning to have it in the near future”.

Before further diving into the details, I would like to note that there is no official product management course that will teach you this stuff. Only the school of hard knocks will sell you such a diploma ;-) and yet, since I have been in this situation more than a few times, it’s rather easy to draw the matrix for the ‘Yes’ vs. ‘No’ answers.

You will probably find the following parameters useful:

  • Customer attributes: How similar is this customer to your target customer? How much has this customer already invested in your product?
  • Vendor attributes: How aligned is this requirement with your long-term roadmap plans? How dependent are you on this customer? How much of this requirement are your competitors offering?
  • Requirement attributes: How expensive is this feature (R&D effort estimation)? Does it fit well with current functionality and architecture?


Is this Requirement Aligned with your Roadmap?

The diagram on the right maps roadmap alignment with R&D effort. It’s fairly easy to refuse a request when roadmap alignment is low AND the R&D effort is high.  It’s also easy to see that there is no easy answer to the combination of a high roadmap alignment AND high effort by R&D (hence the TBD). This is a classic case for taking that feature into account when planning your next release backlog.

Be careful. Don’t underestimate those small, yet unaligned requirements. A bunch of such requests will practically shift your roadmap away from your intended product strategy. How and when will you draw the line? A nice work-around can be the definition of a limited pool of R&D days per quarter that can be used for such minor requests.

How Much has this Customer Invested Already in Your Product?

Now, let’s go to a more interesting and less discussed scenario: How deep, as a vendor, are you webbed (financially and personally) into the customer’s organization? Or in other words, how easy will it be for the customer to replace you? If the sunk costs of the customer are high, you can carefully pull the rope and refuse unaligned-to-roadmap or expensive-to-develop requirements. And yet, this parameter should be handled with caution. Note that the customer knows you are pulling the rope and will remember that. Additionally, don’t underestimate the competitors’ efforts to take you off this account. Carefully handle requirements by such a customer.

Does this Customer Represent a Target Customer?

This next one is an easy one…. Any product manager knows, it’s best to meet customers and hear their needs directly. When meeting a customer that is similar to your target customer, is deep into your product and has the time to dwell into new requirements with you, sit down and write….

When a customer doesn’t represent the target customer, that’s when you should politely yet firmly say ‘No’. As always, the dilemma is more challenging when the customer is a relevant one but the requirement is estimated by R&D as an expensive one to develop (TBD box). It is best if you simply take that requirement into account when planning your next release backlog.

Are you, as a Vendor, Financially Dependent on this Customer?

Another parameter that is not that often openly discussed is the level of financial dependency of the vendor on a specific customer. It’s easy to say ‘no’ when you have dozens or hundreds of customers and they all bring-in similar amounts of dollars. But imagine a scenario in which you have just a few customers (often the case with a B2B start-up) and one of them represents 30% of your annual income.

As painful as it is, often the product managers will actually be forced by the CEO to change their product roadmap to include features that fit that customer’s requirements. If that customer is similar to your target-customer, you’re lucky. If not, there goes your intended product strategy to the drains and you are most welcome to start maintaining a ‘practical’ product strategy.

On the bright side of things, the CEO will be able to pay your salary.


Tweet this: Guard your intended roadmap by regularly asking these 4 questions. #prodmgmt #roadmap

Breaking the Answer First mode of communication

By Prabhakar Gopalan

Have you come across the Answer First method of communication?  In the corporate world, you are often coached to ‘get to the point’, ‘get to the answer first’, ‘synthesize and summarize’ and other communication techniques to get past limited executive attention. Part of the problem with the method is, it can result in poor decision-making contrary to what it is actually supposed to help.

Here’s why: by saying the answer first,  the ability to both communicate the background to the client so the client can  understand the problem scenario, and engage the client in participatory solution analysis  are lost.  The result of the answer first approach is, your client picks what they heard first and go on to make decisions without debate or deliberation.  By presenting the answer first you have removed the client’s ability to independently examine the situation and arrive at his/her own ideas of what could be the problem-solution.  Below is an anti-pattern to that style of communication.

Next time some executive asks you for the 1 min summary and you know it requires more than a minute to understand and explore the idea at hand, stand your ground and say you can’t explain it in one minute but you need more time.  If your executive really cares about the subject, is curious about  your ideas, chances are he or she will come back to you with more time.

Clay Christensen explains how he stood his ground with Andy Grove of Intel.  The outcome, as we all know today is remarkable:

Before I published The Innovator’s Dilemma, I got a call from Andrew Grove, then the chairman of Intel. He had read one of my early papers about disruptive technology, and he asked if I could talk to his direct reports and explain my research and what it implied for Intel. Excited, I flew to Silicon Valley and showed up at the appointed time, only to have Grove say, “Look, stuff has happened. We have only 10 minutes for you. Tell us what your model of disruption means for Intel.” I said that I couldn’t—that I needed a full 30 minutes to explain the model, because only with it as context would any comments about Intel make sense. Ten minutes into my explanation, Grove interrupted: “Look, I’ve got your model. Just tell us what it means for Intel.”

I insisted that I needed 10 more minutes to describe how the process of disruption had worked its way through a very different industry, steel, so that he and his team could understand how disruption worked. I told the story of how Nucor and other steel minimills had begun by attacking the lowest end of the market—steel reinforcing bars, or rebar—and later moved up toward the high end, undercutting the traditional steel mills.

When I finished the minimill story, Grove said, “OK, I get it. What it means for Intel is…,” and then went on to articulate what would become the company’s strategy for going to the bottom of the market to launch the Celeron processor.

I’ve thought about that a million times since. If I had been suckered into telling Andy Grove what he should think about the microprocessor business, I’d have been killed. But instead of telling him what to think, I taught him how to think—and then he reached what I felt was the correct decision on his own.

Executives that put ‘listening’ as their priority, engage in the deliberative process of decision-making.  Those that have very little attention end up running on hamster wheels – lot of churn, but no movement.  When it comes to execution, they realize they lack the necessary information  or the courage to make the right decisions or end up making bad decisions.  After all, they had avoided the understanding of the real problem all along due to ignorance or arrogance.  Either way it is unhealthy for the organization.

Next time you are in an executive meeting, pay attention to how the meeting is conducted.   Observe what the executive attention span is.  How many minutes do they spend talking and how many minutes listening and to whom.  What kind of questions do your executives ask?  Do they spend time listening and learning or do they spend time talking down to you.

If you want to change the culture of your organization’s decision-making style, insist on getting more time with your executives to walk through problem scenarios instead of elevator pitches of the Answer First mode.  Elevator pitches are not for every situation.

Prabhakar Gopalan

Tweet this: Breaking the ‘Answer First’ mode of communication #communication #leadership #prodmgmt

(Follow my tweets:  @PGopalan)

What A Product Manager Can Learn From The New Sales Playbook

By Josh Duncan

HBR Insights recently had a podcast with author Matt Dixon on the topic of The New Sales Playbook. While aimed at the sales executives, I found the talk very informative and noted several takeaways for the product team.

First, and this shouldn’t come as a surprise, the buying process has changed. Matt notes in the call,

We find that by the time the average business customer reaches out to a supplier, their purchase decisions is almost 60% complete. So they scoped out their needs. They decided who they might buy from, what they want to pay for the solution.

This means that for B2B sales, the customer is not looking at the sales team to educate them on the problem or the product. The approach recommended by Matt’s research is to move away from solutions sales towards insight sales. Sales teams now need to show up with a point of view that not only helps the customer in unexpected ways but pushes them out of their comfort zone to see what could be done.

The alternative is a non-appetizing situation where the RFP has already been drawn up, vendors chosen, and all that’s left is to try and compete head-to -head on who will take the biggest discount to win the business.

In the podcast, Matt clarifies what insight sales is all about,

Insight sales is the idea of showing up and not asking the customer what is keeping you up at night, but actually telling them what should be keeping them up at night.
And obviously, doing it in a very empathetic kind of way, but the idea is teaching customers about business opportunities and problems, often, ideas of the customer, him or herself, hasn’t even thought of before, so new ways to save money, or make money, or avoid risk over the horizon that the customer have even thought of and educating the customer about those problems which then ultimately lead to the things that you can deliver better than the competition.

What does this mean for the product team?

To start with, if sales needs to be able to help uncover and teach customer about opportunities and problems, I think that product needs to have a role in this process. The product team should be able to help with the market data and competitor analysis needed to build the story that the sales team can use.

Second, I would argue that the product team needs to be involved, if not leading, the process to discover what problems the customers are facing. An involved product team can not only help uncover ideas through their research but also funnel them back into the product development process.

The end goal here should be to not just deliver insights that sales can use to sell the product but also a product that delivers results.  I can’t think of a worse scenario than one where sales sells a story that the customers love but has nothing to do with the product being delivered.

What do you think?


Image Credit:  Simon Greig (xrrr)

3 Tactics That Make Agile Releases Easier for Marketing & Sales to Digest

by John Mansour

“I need a constant stream of new features and solutions to stay ahead of our competitors.”

“Slow down! I can’t learn all the new functionality that fast.”

“Can you accelerate the delivery of feature X?  The competition is killing us on that one.”

What’s the appropriate cadence of agile releases that would satisfy marketing and sales?  Finding that delicate balance is frustrating for many agile product teams.  The fix is simple.  Don’t change the cadence of agile releases.  If product teams make a few simple tweaks to the content they feed marketing and sales, and marketing tweaks the structure of the company’s positioning, marketing and sales will thrive in an agile world.

Here are three tactics that will help marketing and sales reap the benefits of more frequent product releases.

1. Product Teams – Theme Your Releases

For releases that deliver significant market value, create themes as a way of communicating the intent to meet critical business objectives of your target markets.  For example, “The goal of the next two releases is to improve front-desk productivity and reduce staffing costs while also improving the customer experience.”

The business-value themes defined before development become the storylines of your marketing and sales positioning when the solutions are released to market.

2. Product Teams – Create User Stories That Have Life After Development

User stories simply everything when the context stays true to a user scenario – Who am I?  What am I doing?  Why?  Expected outcome/benefit?

Product teams own the quality of the user-story content and when they nail it, life becomes easier for everyone downstream, especially marketing and sales.  Good user stories take the emphasis away from positioning detailed features and specs and put it right where it belongs – on the problematic business scenarios you’ve addressed.

The business objectives (release themes) with supporting user stories are the most critical part of marketing and selling.  If you can articulate the issues, challenges and needs better than your competition, buyers assume your product solutions are also superior.  Product details only serve to illustrate the proof points of your value story and should therefore play second fiddle to the business scenarios.  Go deep into products only when pushed.

3. Marketing – Tier Your Value Propositions

If your company’s positioning revolves around products, agile development and frequent releases will bring marketing and sales to their knees because products are in a constant state of flux.

Tiered value propositions are the key to making life easier for marketing and sales when it comes to the frequency of agile product releases.  Why?  Your core value propositions won’t change that often when they’re more closely tied to the market dynamics and business objectives of your target customers than products.  In a tiered positioning structure, agile releases provide a steady stream of proof points (business/user scenarios) that constantly strengthen your higher level value themes.

Use a two-tiered structure to develop your value propositions and frequent agile releases will delight your marketing and sales teams.

  • Tier 1 – The Value of Your Company
    Regardless of how it’s written or verbalized the essence of the message is “my company exists for one reason, to make organizations like yours (industry context) successful by doing something unique.
  • Tier 2 – The Value of Your Business Solutions
    For the departments where your products are most relevant, build value propositions that speak to the business goals of each department and position “solutions” that align accordingly.  For example: 

    • Customer service solutions that help you differentiate
    • IT solutions that reduce the cost of compliance

Incorporating the above tactics into your agile process gives marketing and sales a longer list of differentiating proof points with every agile release.  What’s not to love?

Updates to marketing content and sales tools will be incremental and only required when significant functionality is released.  Learning the value of new user stories is far easier than memorizing gory product details that don’t really matter in marketing and sales situations.

Agile development is a dream come true for marketing and sales when product companies keep their focus on target market dynamics, buyer business objectives and user scenarios.


Tweet this: 3 Tactics That Make Agile Releases Easier for Marketing and Sales to Digest #prodmgmt #agile #marketing #sales

John Mansour is the founder and president of Proficientz, a company that specializes in B2B product  portfolio management.


User Stories That Developers Can Actually Work With

by Rivi Aspler

Devout Agile evangelists will define a user story as a short, simple description of a feature told from the perspective of the person who desires the new capability. The user story will typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.

And furthermore, while a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur and the discussions are those that actually enrich the user stories with enough details that R&D teams can chew on.

So much for theory and now for practice….

I have found that the concise user stories are simply not enough. It is especially apparent when one or more of the following occurs:

  • A – You are defining a new product, that doesn’t have enough legacy definitions, neither an established UI paradigm that the PO or the Agile team can rely on.
  • B – You are defining an utterly complicated product that requires an intensive analysis of hundreds of user stories, using multiple points of view (personas).
  • C – Your organizational culture is such that it encourages written down detailed specifications.
  • Since all of the above is my day-to-day reality, at my company, we are using the following guidelines for a user story template.

    Looking at the user story below, one can easily notice the following:
    1. We are using a table format.
    2. The left column of the table is dedicated to the ‘meta-data’ of the various definitions.
    3. Each user story has the same ‘meta-data’ topics listed down so that the PO and the developers can easily understand each-other.
    4. The user story defines a very granular scenario.
    5. The other user stories that complete the ‘Place an Order’ Theme are detailed in other user stories (i.e. the references to US19, US38 and US39)
    6. A UI design is attached since one picture is always better than a thousand words…
    ThemePlacing an Order
    • Registered Shopper (Has an existing account, possibly with billing and shipping information)
    • Non-registered Shopper (Does not have an existing account)
    User NeedAs a user, I want to confirm billing and shipping information
    Starting PointUser has selected the items to be purchased
    User Flow

    1. The user will indicate that she wants to order the items that have already been selected.
    2. The system will present the billing and shipping information that the user previously stored.
    3. The user will confirm that the existing billing and shipping information should be used for this order.
    UI Design

    • The system will confirm shipping and billing addresses
    • The system will present the amount that the order will cost, including applicable taxes and shipping charges.
    Default Values For a registered shopper, the billing and shipping addresses are the ones that were defined as default addresses (US 19)
    Alternative Flow 1US 38 – The user will discover an error in the billing or shipping information associated with their account, and will edit it.
    Alternative Flow 2US 39 – The user isn’t a registered shopper and doesn’t have pre-defined shipping and billing addresses

    To conclude, the above detailed template may not stick to pure Agile recommendations, but it does represent a win-win best practices for the type of definitions that developers practically need in order to get your story coded.


    Tweet this: User Stories that Developer can Actually Work With #prodmgmt #agile

    “Product Editor”? You’ve got to be kidding!

    By Saeed Khan

    I came across a post on Andrew Chen’s blog entitled “Why companies should have Product Editors, not Product Managers“. Obviously I had to respond. :-)

    Yes, Product Management is ill understood but….

    In the article,  Chen highlights a YouTube video of Twitter/Square CEO Jack Dorsey talking about how he manages both companies. Jack refers to company activities as “stories” and uses the title “chief editor” to refer to himself as he manages those stories.

    Clearly this is an anology to help explain a point. As analogies go, it’s not a bad one, but unfortunately, it looks like Chen took Dorsey literally, and wrote the above mentioned blog post. In it Chen writes:

    The role of “product manager” “program manager” “project manager” is one of the toughest, and worst defined jobs in tech. And it often doesn’t lead to good products. The various PM roles often have no direct reports, but you have the responsibility of getting products out the door. It often becomes a detail-oriented role that are as much about hitting milestones and schedules as much as delivering a great product experience.

    Wow, where do I start? While there is some truth in this paragraph, it’s also  a big generalization of issues.

    First, “Product Manager”, “Program Manager” and “Project Manager” are all different roles with different responsibilities.  Yes, there is confusion about the role and definition of Product Management, but not to the extent that is implied here.

    Second, the confusion on the PM roles isn’t the reason people build bad products. People build bad products because they don’t know what they are doing! And even when people do know what they are doing, their product may be technically good, but unsuccessful in the market.

    You can’t fix a problem by changing titles around

    Chen quotes Dorsey as follows: (I’m excerpting)

    I think every leader in any company is an editor. Taking all of these ideas and editing them down to one cohesive story, and in my case my job is to edit the team, so we have a great team that can produce the great work and that means bringing people on and in some cases having to let people go. That means editing the support for the company, which means having money in the bank, or making money, and that means editing what the vision and the communication of the company is, so that’s internal and external, what we’re saying internally and what we’re saying to the world – that’s my job.

    Now take words “editor” or “editing” above and replace with “manager” and “managing” respectively, and what do you get? Exactly the same meaning without ambiguity. In some cases, the “editor” metaphor is actually quite weak. e.g. “That means editing the support for the company, which means having money in the bank”

    In the media world, editors don’t focus on money, publishers do. Editors focus on content. Publishers focus on business. But who said the analogy was perfect? Anyway, we don’t need “Product Editors” unless the product is a book or some kind of media offering.

    So here’s what we really need

    What we need for product success and product leadership are people who understand that their job is the business success of any product.

    And they do this by understanding business strategy, market needs (current and potential future), business value and where it intersects with technology. They do this by taking risks and experimenting and learning. They do this by optimizing for the user, and not optimizing for the technology. They do this by having patience and not rushing things to market. They do this by creating differentiated products with clear audiences in mind and not by creating generic offerings for the masses.

    That’s where they focus their priorities, resources and thinking, and not simply into new titles, or product features and functionality, scrum teams, iterations, user stories etc.

    Too often people with “PM” titles let themselves be pigeonholed into tactical roles as Chen describes in his earlier quote. While company culture is a big factor in that, in many cases, those people need to speak out and change the culture, or walk out and find success and job satisfaction elsewhere.


    Tweet this: “Product Editor”? You’ve got to be kidding! #prodmgmt #innovation

    Customer Loyalty – You Get What You Give

    by Saeed Khan

    I went to the local grocery store on Monday to pick up a few things we needed for dinner. It was nothing special, just some milk, vegetables and butter. The total came to $11.64, if I recall correctly. I handed the cashier $20 and she punched it into the cash register and was counting out the change.

    I realized I had a bunch of loose change in my pocket and said, “Hold on a sec, I have some change to give you.” and started counting out the coins. My intention was to give her $.64 or even $1.64 so I could get a rounded amount of change back — either $9 or $10. Seemed reasonable enough.

    She looked at me, with an expression somewhere between astonishment and fear, and said “But, I’ve already opened my drawer.

    I said “Yes, and here’s some change.”

    She looked back at me and said, “I can’t change the amount I punched in.

    I responded “You don’t need to change anything. I’m going to give you a little extra change and you give me the right change back.

    She looked across at the next cashier and asked her to call a manager. I looked at her, surprised at this response to a simple request and said, “Look, you don’t need to call a manager or anyone. Just take the coins and give me the change.

    She turned back to me and nervously said, “We have to wait for the manager. I’ve already opened the cash drawer.

    I had no idea what was going on. The manager came over, and explained to me that they had had incidents where “Quick change artists” had intentionally confused the cashiers by changing the amount of money they gave, and as a result had been given too much change back.  So they had enacted this policy of not allowing the cashier to accept additional money once they opened the cash drawer.

    OK, so let’s analyze this.

    They’ve had a few customers successfully confuse their cashiers into giving extra change. In most cases it couldn’t have been more than a few dollars, maybe 10 or 20 dollars maximum in any individual case. So they’ve instituted a policy to treat EVERY customer as a suspect if they offer additional change once the cashier opens her cash drawer.

    i.e. because the cashiers they hire cannot properly make change unless it’s calculated and displayed by the cash registers, and some customers took advantage of that, the solution is to be suspicious of all customers.

    Now, why would I want to shop there any more if they treat their customers this way? In fact, because they treated me that way.

    Would I recommend that store to anyone? Will I go there if I have a choice of going somewhere else?

    It’s stunning how companies forget how to treat customers, the VAST majority of whom have no intention of shoplifting or stealing.  You want loyal customers? Then be loyal to them.

    Focus on the big picture – don’t penalize the majority for the actions of the small minority.

    As with any good relationship, it has to be founded on trust.


    Tweet this: Customer Loyalty – You get what you give #prodmgmt #custserv #loyalty

    Managing Internal vs. External Products

    by John Mansour

    The vast majority of the product management ecosystem is tied to commercial (external) products. Having trained a significant number of product managers in both environments, I thought it was time to show a little love to those who manage internal products and highlight the key similarities and differences with managing external products.

    If you manage internal products or managed products in both environments, feel free to add to this list in the comments section at the bottom of the page.

    Key Differences

    • Terminology – Project Portfolio vs. Product Portfolio

    More often than not, project portfolio management refers to the management of internal products and their corresponding IT/development projects.  Product portfolio management usually refers to the management of a group of external/commercial products and their alignment to growing, declining, flat and emerging market segments.

    • Cost Impact vs. Revenue Impact

    Internal products are usually focused more on cost reduction and may or may not have a direct impact on revenue. External products focus much more on top line revenue growth (that’s profitable) and the organization’s market position relative to the competition.

    • Efficiency Focus vs. Market Focus

    Product managers for internal products usually focus more on aspects that improve internal efficiencies.  Product managers for external products focus more on market related aspects such as segmentation, market sizing, revenue projections, competitive intelligence, sales channels, pricing, etc. to improve market position.

    Key Similarities

    • Business & User Requirements

    There is no difference in how business practices should be performed when it comes to business and user requirements.  In both cases, the goal is to understand the business objectives within a functional area of an organization and how those objectives impact people doing the work.  Product capabilities are defined to support people doing the work in a way that meets the organization’s business objectives.

    • Investment Priorities

    Value to the overall goals of the business is the determining factor in both scenarios.  But again, that value and the subsequent emphasis is usually directed at cost efficiencies for internal products vs. revenue and growth objectives for external products.

    • Value Positioning

    Communicating “why” internal business areas should adopt and be cross-charged for something (internal solution) vs. “why” an external organization should buy and pay for a business solution is no different.  In fact, positioning internal solutions may actually be easier because the target customers are very well known (employee directory) and the marketing efforts required to engage them is straight forward in comparison to a market at large for external products.

    Positioning may be one of the biggest areas of opportunity for internal product managers as there is often an expectation that adoption rates will be high simply because product teams and their customers are part of the same corporate family.  Unfortunately, it’s not true in most cases!

    In my opinion, the most important part of managing a product portfolio, regardless of internal or external products, is a single overarching strategy that consistently creates the strongest possible alignment between the organization’s goals and product solutions most conducive to meeting those goals.  Resource constraints should guarantee that only the most important initiatives make the cut, and that constant focus on the highest value initiatives should dramatically improve execution at all levels.

    Have you managed both types of products?  What’s your take?  Submit comments below.

    Tweet this: Managing Internal vs. External Products #prodmgmt