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…
    [table "4" not found /]

    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