Six Questions You Should Be Asking Your Salespeople

by Matt Volpi

6 questions-finalSalespeople and product managers aren’t always the best of friends. A salesperson is driven by their individual goals and compensation. They are often too busy or uninterested to delve into the nuances of the solutions that product managers are carefully crafting and shepherding through the product development cycle.

But salespeople are an invaluable resource for product managers as they are having far more conversations with decision makers in the target market than a product manager could ever have. Despite their differences, product managers should be mining their salespeople for data while also taking those opportunities to ensure salespeople are utilizing the latest and greatest information and sales tools.

To help product managers make the most of their limited time with salespeople, here are six questions you should be asking them when discussing a specific sales call:

1) Who are you talking to?

While it might be interesting to know which targets your salespeople are focused on, it is just as important to know who within those organizations they are actually having conversations with. It may not be the “user” you had in mind, and if that’s the case there might be different features or selling points that may be more valuable that audience. If they are talking to “buyers”, that’s great, but then that’s an entirely different conversation altogether.

2) What is the problem they are trying to solve?

This is an opportunity to dig deeper into what challenges your potential customers are really interested in addressing. Depending on what you hear, it might unearth a new feature to explore or the chance to educate your sales team on how your product already does what this type of customer needs.

3) What other options are they considering to solve that problem?

As a follow up, it’s always good to know which alternative solutions prospects are considering. This can obviously highlight direct competition (both known and unknown), but it can also unearth interesting nuggets, such as the fact that a prospect is willing to just live with the problem or may look to solve it in a totally non-traditional way that you would have never thought of. Your competitor is not always another company. Often it may just be something simple like duct tape.

4) What part of the solution were they most interested in?

When a sales call is going well, the prospective buyer will inevitably focus in on one or two particular aspects of the solution that they are most interested in. This is a great chance to see which features are actually getting people excited and which ones might not deserve as much attention.

5) What didn’t they like about our solution?

Nocompetition is duct tape one wants to hear that the product that have created after months and years of research and specification is flawed, but there’s a lot of value in hearing the negative perceptions that prospects may have. These are the barriers standing between your solution sitting on a shelf and your happy customer using it and raving about it to others.

Sometimes you will hear the same thing over and over – whether it is “too expensive” or “too hard to integrate with XYZ” – while other times you will stumble across a completely new type of complaint. Either way, this is often valuable feedback, particularly when you can quantify it to use as justification for making a change.

6) Why haven’t they bought it yet?

Now, this question should not be framed as if you are accusing the salesperson of not being able to close a deal. Instead, it is an opportunity to be helpful while also gleaning more information. Some responses might be:

  • “It’s too expensive” – Does your sales team have the ROI tools and justifications they need to effectively sell the value proposition, or is it possible that your product IS too expensive?
  • “They don’t have room in their budget until next year” – Should you be considering SaaS/rental models (or if you already have one, is the salesperson not pushing that for some reason)?
  • “They are still not sure it will work for their particular needs” – Have they been given references or case studies from similar organizations?
  • “They have not decided between us and a competitor” – Have you armed your sales team with a favorable comparison matrix, or is there something your competitor has that maybe you should be adding?
  • “They need more people to approve it before moving forward” – Are there talking points and features that will help convince the next line of stakeholders that your solution is right for them?

Unless your sales organization is very small, you will not be able to ask these questions after every single sales call. Be judicious with your efforts and respectful of your sales team’s time while also asking these questions of different salespeople, particularly those that may be remote or not as pro-active in communicating what they are hearing in the field to those back at the home office.

Tweet this: Six Questions You Should Be Asking Your Salespeople  http://wp.me/pXBON-45A #prodmgmt #sales

volpi_headshot_bw_finalMatt helps start-ups and established companies with product strategy, marketing execution and market research, with a focus on innovative solutions development and sales enablement. He has 20 years experience in product management and marketing at Internet and mobile tech companies. You can reach him at http://tovana.com or on Twitter as @mattvolpi

5 Rules to Make Better Product Prioritization Decisions

by Juan Ramirez

5-RulesOne of the most challenging questions that product managers have to face day to day is whether or not they should include certain features in the product pipeline, and even more, whether those features should be included at all.

In other words, they often face the question of whether or not they should expend time and development resources in certain features, without knowing the impact of that feature in the product value and/or the revenue.

The reason this question poses a challenge for product managers is because they have to ship and deliver value through their product strategy, but there are no methods or simple formulas which indicate which is the best way to do it.

When asked, most product managers would admit that instinct plays a big role in the way things are prioritized for the product and how they make their decisions.

This is true in most of cases. Good product managers have a good product instinct. They know what’s best for the product and the final user before there’s even actual data to understand those insights.

Good product managers develop this ability mainly due to the fact that they get used to seeing the big picture of what they are working on, without missing the small details of the execution. They are, in other words, great philosophers and amazing executioners.

In my years of wearing different product hats, I have realized that the so called “product instinct” is just the ability to make accurate product decisions without missing out on the big picture.

Here are 5 rules that you, as a product manager or product stakeholder can follow to help you make better product decisions that align with the big picture of the product and the business.

1) You’re not the CFO but costs come first. Development time is money

One of the biggest mistakes of any PM is to not evaluate the cost of a feature. PMs deal with pipelines, product backlogs, and scrums. They are used to see resources as development time and not necessarily as money.

As a PM, always make sure to evaluate your resources in money value. This will give you a different view on how to prioritize and make product decisions, especially because you will begin to see how your burn rate relates to the immediate future of the company’s finances.

2) Understand the value of a feature

distrust the pessimistWhen evaluating feature development, always assess the value of that feature in the final user experience. Would the user pay more money for that feature? Would the user spend more time with your product if that feature is implemented?

How relevant will this feature be in the near future? In general, ask yourself why this is something that should be implemented and make sure to find enough arguments that support a decision.

Being a very UX focused product manager myself, I always like to do early low fidelity prototypes of any feature that is being evaluated or those which are in the pipeline. Create use cases, do internal customer development sessions, and let people play and give you opinions about your sketches and wireframes. Always get feedback.

3) Get feedback but don’t live by it

Feedback is important for any product strategy. However, always take into account that most of the feedback is useless. In order to get useful feedback, remember that people are very bad at telling you what they want but are very good at telling what they don’t want. Learn to ask the right questions and learn how to integrate the right feedback into your product strategy.

4) Prioritization over optimization

Your goal as a PM is to prioritize rather than optimize. This is one of the things that most PMs get wrong. They focus too much on trying to create the optimal distribution of resources when their job is instead to prioritize the resources.

This means that you should be putting all the resources in what is important for the product and not for what is optimal for the operation. In other words, your job philosophy is: ideate, ship, test, and repeat. Commit to that philosophy.

5) Distrust the pessimist, but more importantly, distrust the optimist

At the beginning of my career, I worked on a project with an external development team. When I pitched the idea and showed all the wireframes and requirements of the product to this outsourced team they looked very confident and comfortable with the idea of developing this app.

One week later they came with their own wireframes and to my surprise, they had a lot of more features than the ones we initially pitched. Being a fresh product guy in that moment, I saw this as great news. Those guys were so good that they were going to deliver more for the same money and still within the deadline.

I have never been so wrong in my life. Their optimism was just naivety and over confidence. If there’s anything in this post to live by, this is it: always enforce your requirements and address delays before they occur. Don’t let anyone negotiate your deadlines in exchange for more features because this is a free ticket to “never ship anything”.

You know your product and your users better than anyone and therefore you already went through the process of evaluating and discarding features. Therefore, don’t let someone who can’t see the big picture make those decisions for you.

As you may be thinking, there are many other potential rules and thoughts on how to make good product decisions, but in my experience I have found that the ones that I just described are accurate representations of a good product decision system. Moreover, I have found that “excellent” product managers have a very solid product decision system that helps them to align the product execution with the business vision.

Please feel free to leave your comments and give your own ideas on a good product decision system.

Juan

Tweet this: 5 Rules to Make Better Product Prioritization Decisions http://wp.me/pXBON-45D #prodmgmt

About the Author

JuanRamirez-bw-110 Juan J. Ramirez is a Product Manager at Contactive. He is also a Master’s student at Carnegie Mellon University where he is pursuing a Master of Entertainment Technology. Before that he was CPO at Usuallee, a startup based on Bogota, Colombia. You can reach him via jjramirezuribe@gmail.com

The most abused question when building new products

by Saeed Khan

prioritizationEveryone knows that when building technology products, one of the key tasks is to prioritize requirements —  what features are “must have” vs. optional or “nice to have” etc.

It’s the skill and discipline employed in making these prioritization decisions that is a major factor in whether products are adopted by customers or not. Users can be fickle, but they know what they need to accomplish and will quickly decide if the product is worth their time and effort to solve their problems.

There is never enough time and resources to build everything that is needed, and thus the necessary prioritization exercises.

There are many factors that come into play when making prioritization decisions.  These include technical feasibility, overall effort, fit for key use cases, alignment with product direction and potential alternatives for the end user.

It’s this last factor — potential alternatives — that is often abused during the prioritization process.

And the question is…

Often Engineering, but sadly in many cases, product managers, ask the following question far too often:

Are there any workarounds?

playbooked-tweetThe question itself is not a bad one, particularly when dealing with non-critical or optional requirements. But once the question is asked for minor requirements, it becomes very easy to ask it about major requirements, and  that leads to significant abuse.
Often times, particularly when building a new product, there is focus on minimizing effort and reducing scope to fit into a fixed future release date.  The negative impact to the customer or the reduced product value are ignored.

Why? Because it’s easy to ignore them. The product won’t be released until some future date and the future negative impact is hard to measure; certainly a LOT harder to measure than the development effort to meet the release date.

I’ve seen this happen time and time again. Someone asks about workarounds. A potential workaround is described and then it’s off to the “future release” bin for that particular requirement. Do this 3 or 4 times, and the “small” impact of each postponed requirement adds up, but who’s counting at this point? The focus is on minimizing effort and meeting a target date.

And when the product is released and underwhelms the market, then what?  Double down on fixing all the gaps and increasing the value for the next release? Sorry, but that train has left the station. You never get a second chance to make a first impression. Your customers or potential customers are looking for alternatives. You’ve shown your (weak) hand to your competitors and they are smelling blood.

Workarounds can kill a product

playbookOne of the most notable cases of death-by-workaround was the Blackberry Playbook. Remember that device? The first (and only) tablet from Blackberry — a company built on the strength of it’s email and messaging services — shipped it’s first release without any native email or messaging capabilities. Email and messaging could be had with a workaround — tethering the Playbook with a Blackberry smart phone — but people and the press objected loudly.

Sure, they released an update several months later that provided native email and messaging , but by then the damage was done. No one cared anymore and the product ended up in the liquidation pile.

None of this is to say that the Playbook was a bad product. In fact, I have several friends who’ve raved about it. But the lack of a CORE capability — email and messaging — in the first release killed chances of success. If Blackberry could add email and messaging in an update several months later, why didn’t they add it in the first release, even if it delayed that release by several months?

Be careful when talking about workarounds when planning product releases. Don’t let the “workaround” question end up “Playbooking” your product.

Saeed

Tweet this: The most abused question when building new products http://wp.me/pXBON-45x  #prodmgmt #requirements

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

Design Your Product for the Case Study You Want to Read

by Matt Volpi

case-studyNo matter how hard we try, the product development process drags us away from customers and into a more theoretical bubble. One can easily begin focusing on lists of features and generalities and not how a specific customer is going to interact with and benefit from your solution.

But each customer is unique and their journey will hopefully be positive and the basis for a case study; a tool for communicating your product’s benefits to even more potential customers. Keeping these case studies-to-be in mind is a great way to make sure you remain customer-centric, even when you are cooped up in a meeting room with a white board and a bunch of engineers.

Since every good case study has a narrative, let’s map that to the definition, design and implementation process:

The Problem

Every case study starts with the problem the customer is trying to solve. While these problems may fall into several broad categories, each customer has a very specific problem. Since you are trying to ensure that this unique customer problem is addressed, make it something specific and – ideally – based on actual data from your sales organization or a customer interview you have conducted yourself.

For example, it is easy to say:

 “Our product will help sales people make sure they are contacting their prospects on a regular basis through various channels because customers wants to know what is working and be able to measure it.”

But this is a very vague goal and you could meet it in a variety of ways. Instead, you need to get specific:

“Company X has 17 sales people in the field and a four-person inside sales organization supporting them. Field personnel communicate with their prospects by calling them or sending them emails. Inside sales follows up on lead generation activities by emailing and calling prospects to try and schedule demos for their field team. A three-person marketing team is generating content, running webinars, performing SEO and utilizing social media and email marketing. The company wants to know, in aggregate, how often each prospect is being reached via each channel, and on each successful transaction how many times they were contacted via each channel and have a visual timeline from first contact to order.”

Of course, a company’s specific problems are often even more nuanced, but this amount of specificity creates a real scenario to work against.

Discovery

How did Company X find out about your awesome solution for measuring prospect communication? You might dismiss this as the realm of marketing or sales, but as the owner of the solution it is your problem too.

every good case study
What the product actually includes can heavily influence how it is discovered. For example, does your product generate statistics that your company can aggregate and share over social media in quick sound bites, such as “the average enterprise software deal doesn’t close until the sixth time a prospect is touched”? Do you have out-of-the-box integration with CRM tools to enable joint marketing efforts?

Selection
What made Company X select your product? Was it a specific feature, the price point, something that a competitor lacked, the absence of risk by making it a monthly SaaS versus an annual license? It won’t be the same for every customer, so think about what is going to speak to a customer with this profile and it might influence how you implement or package it.

Funding

Someone had to pay for your product, and it is not always the end-user. Figuring out who this is can drive you to shape your product to be sure it is meeting the actual buyer’s ROI and not just satisfying the end user. It could be as simple as a weekly or monthly report that shows the increase in conversions since the solution was implemented, but keeping the funding source’s motivations in mind is key to winning repeat business.

It is also critical to understand how your customer wants to pay for it (rent vs. buy, seat license vs. enterprise license, etc.) and to make sure that is one of the options.

Implementation

What did Company X have to do to get your system up and running? What challenges did they have to overcome? Go through the entire scenario from configuration and integration to training and support. This exercise can keep some of those unwanted a-ha moments from happening after you have already shipped your product.

Results

Since you have already created a very well-defined problem scenario, you should be able to create a product that is addressing that problem in a measurable and significant way. You want to be able to write something like:

“Company X can now select any prospect/customer and see a time-stamped sequence of communications from anyone at the company. They can also see visual reports that indicate which combinations of communication channels and frequency are most effective by customer type. There are also reports that show each staff member’s individual activities in aggregate and per prospect/customer.”

This narrative can inform your QA efforts and ensure that test scripts are more customer-focused.

Rinse and Repeat

Now that you know everything about Company X’s story, you need to start thinking about Company Y. They’re a different company with a different problem that your product also needs to address, perhaps they have channel partners that need to be accounted for or a CEO who doesn’t think they should be spending money on outbound marketing or they use a specific CRM solution that requires integration.

Keeping a few of these specific case studies in mind throughout the process is key to leveraging the value of the exercise and keeping the entire team aware of the subtle yet critical differences your product will face in the market. While you don’t want to build a solution that is tailor-made for Company X, you have to make sure it is meeting their needs and actually works for real-world customers and not just “the Customer.”

Matt

Tweet this: Design your product for the case study you want to read http://wp.me/pXBON-452 #prodmgmt #prodmktg

About the author

volpi_headshot_bw_finalMatt helps start-ups and established companies with product strategy, marketing execution and market research, with a focus on innovative solutions development and sales enablement. He has 20 years experience in product management and marketing at Internet and mobile tech companies. You can reach him at http://tovana.com or on Twitter as @mattvolpi

A single set of priorities

by Steve Johnson

If you don’t know where you’re going, any road’ll take you there.—George Harrison

crossing_guardWhen I started a new job as a product manager, my company president said, “You need to find out why development is broken. Our developers are terrible—they can’t seem to ship anything.”

So I sat down with my developers and said, “The word is that you’re terrible and never ship anything.”

(I’m so good with people!)

The lead developer said, “I’m sure that’s how it looks from the executive corner but, actually, we’re practicing what we call ‘requirements aging.’ We don’t work on anything for a month because some executive usually changes the requirements before we can begin.”

And sure enough, a few minutes later, the VP of Engineering came in and said, “Guys, stop what you’re doing. I’m getting new requirements.”

So the next week, I appeared at senior staff meeting and said, “I found the problem. It’s you. You keep changing your minds. You don’t seem to realize that one sentence from you is weeks or months of work for them. The reason they never finish anything is because you keep changing their priorities.”

I continued, “I’m setting up a new system. No one in this room is allowed to talk to the developers. If you have an idea, bring it to me, I’ll prioritize it and give it to development at the appropriate time. Here’s my promise: if you leave the developers alone, we’ll ship something in 90 days.”

And we did.

We created a process for shipping at the beginning of each quarter. Like clockwork.

It’s amazing what a “single voice of priority” can do.

No longer were the developers switching between tasks; no longer was an incomplete feature put on hold for a more important item.

Sure, we could change our priorities in line with business and market demands. But we weren’t changing the priorities daily… and we certainly weren’t changing them constantly.

Are you?

Your team needs a single set of priorities. What are you doing to keep your team focused on the most important things?

(Nowadays, I’m helping teams master the product management playbook. If you will, please share this post with a colleague or two.)

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

How to Avoid a Common Customer Interview Mistake

Customer InterviewBy Heather Searl

I was sitting right across from them when it happened.

I was taking notes while my client conducted the interview. Everything was going well. The participant was definitely in our target audience, she was thoughtful, articulate and engaged with the wireframes we were showing her.

And then about 15 minutes into the session things went off-kilter. She stopped telling us what she thought and started telling us what she thought we wanted to hear.

The interview never recovered.

What happened?

What started as a great interview became mediocre (at best) when the participant asked a simple question… and my client answered.

The problem wasn’t the question, it was the way it was answered.

You see, my client gave a thorough answer that showed his expertise.

He said things like, “I’m sure you know program XYZ, well this will work the same way with one exception…,” and he didn’t notice her tentative nod that probably meant that she didn’t know much (if anything) about  program XYZ, but she wasn’t going to tell him that.

He used technical language and jargon and she continued to nod but got quieter.

When she did talk she repeated something he’d said.

My client wasn’t trying to bias the interview and get the participant to give the answers he wanted to hear. He was just having an interesting conversation about something he enjoyed. But in doing so he compromised his role as the observer and lost a chance to learn something about his target audience.

He showed himself as the expert that he is and the participant deferred to his expertise. She stopped sharing her thoughts and experiences and was happy to sit back and learn from him–making sure she didn’t give away her true knowledge level or possibly differing point of view.

At the end of the session my client didn’t see what had happened.  As far as he was concerned, he’d had an enjoyable conversation with someone who shared his ideas.  He didn’t realize the participant had spent most of her time echoing his comments.

Unfortunately this isn’t an unusual story. I see it happen again and again.

Master and Apprentice Relationship

When performing user research, it’s important to establish a master and apprentice relationship with the participant. tweetit

The participant is the master. You are the apprentice learning from them.

Master and Apprentice Setup

You set this up this relationship at the beginning of the session.  I usually say something like, “We’re here to learn how you do things and what you think about the product we’re working on. There are no right or wrong answers, we want to know what you think and see what you do.”

I downplay the role the interview team has in the development of the product. I’ll refer to us as a research team and I never use titles for anyone. If the participant seems nervous or hesitant to share negative thoughts, I’ll out and out lie and say that we have nothing to do with the concept we’re showing them, and that our only role is to gather feedback – even if the product manager, lead designer, lead developer or CEO is standing beside me.

Echo the Participants Language

It’s important to pay attention to the terminology the participant uses and echo it back to them. This shows you are invested in what they have to say. It make them comfortable and encourages them to keep talking.

For example, if you were talking to a participant about how they used USB flash drives, and they called them “finger sticks”, you would call them finger sticks as well. If the next participant starts spouting speed specifications for different flash drives brands – you can get a bit more technical (while staying on topic of course).

Reinforce Their Ideas

Reinforce that the user’s ideas are valid, no matter what they say — especially when they give you negative feedback.

Most people don’t like giving negative feedback, so it’s important that you receive their comments openly and neutrally to keep encourage them to share their thoughts.

If someone reacts negatively to something I show them I’ll preface my next question with a positive comment about what they said. I’ll say something like, “That’s great feedback, can you tell me a bit more about what makes you think that?”

I make sure my follow-up questions don’t question the validity of their thoughts. If their comments show that they are misunderstanding or assuming something that is going to throw off the rest of the interview, I make the correction indirectly by starting with something like, “I see what you are thinking, and that makes sense. But what if….”

Handling Participant Questions

So how should my client have handled the participant’s question?

He could have said, “I can’t answer that right now, I’ll answer your questions at the end,” and then moved on.

However, when the participant’s question is on topic, I prefer to turn it back to them.

If they say, “What does this button do?” I’ll ask what they expect it to do.

You can learn a lot this way because people often ask questions because they don’t want to look stupid by assuming the wrong thing or saying something you won’t like. But when you directly ask for their thoughts they’ll usually tell you. And you’ll probably learn something interesting.

Keep the Master and Apprentice Relationship On-track

One of the keys to successful insight interviews and feedback sessions is to keep the master and apprentice model firmly in mind and take care not to step outside your role as the apprentice. When you’ve mastered this skill you’ll find yourself getting more and more out of your interviews.

What tactics do you use to keep an interview on track and ensure you learn as much as possible? I’d love to hear your thoughts in the comments below.

Heather

Tweet this: How to Avoid a Common Customer Interview Mistake http://wp.me/pXBON-44t #prodmgmt #ux #interviews

Photo (cropped) courtesy of Official GDC via Flickr.

heathersearl-newHeather is a user experience consultant and freelance writer who believes in doing everything from a user-centric point of view. She has 20+ years of experience in high tech and is well-versed in helping product management and development teams get to know their customers, understand usability issues and turn these insights into design innovations.

Heather can be reached at www.commconsulting.com or on Twitter as HeatherSearl.

The 3 biggest problems in Product Management today – part 3 – Communication

by Saeed Khan

This is part 3 of this series on problems in Product Management today.

Part 1 of this series covered issues with various Product Management roles and responsibilities. Part 2 discussed the problems with repeatable processes for to define and launch new products.

This post focuses on problems in intra- and extra-company communication and alignment. So what does this really mean?

Virtually everyone has seen the famous swingset graphic. It’s the iconic metaphor describing common communication problems in companies.

tree-tire-8

It may seem unnecessary to remind ourselves that we are all information workers, but that fact lies at the foundation of this problem.

Information: how we create it, store it, convey it, interpret it, and use it, lies at the heart of product success. tweetit Even if we have the roles (part 1) and processes (part 2) defined correctly, what connects them together is an effective communication process across all necessary groups, both internal and external to the company.

Are people making the best decisions they can?

Everyone needs information to make informed decisions. If they have it when they need it, the decisions will be both timely and informed. If they don’t have the information, those decisions will be poor or delayed.

How often have you had people ask questions like the following:

  • When will the next version of [Product X] be released? What will be in it?
  • I have a customer interested  in [Product X]. Does it support any of the following use cases?
  • Where can I find the latest competitive information we have against [Competitor A]?
  • Can someone help me understand how this CPU core-based licensing works for a virtual environment?
  • Do we have any reference accounts for [Product Y]. I need one in Latin America in Manufacturing.
  • I’m in the late stages of an opportunity. How do I show the ROI of [Product Z] to a prospect? Where can I find that information?
  • Etc. Etc. Etc.
  • I’m doing customer cross-sell analysis. Where can I find sales information for EMEA for the last 2 years for products [A,B,C,D,E]?

There’s no limit to the potential questions.  And they can come from all parties, internal or external. And the more people have to hunt and search for this information, the more problematic.

Focus and understanding are related and proportional

Consider the following. As a product manager, you spend most, if not all of your time thinking about your product, how to make it more successful, how to bring it to market, what market and customer needs it addresses, how to compete against competitors, how to position it’s features and benefits, the overall value it delivers etc. You go to work everyday thinking about these things.

Now think about marketers or sales reps in your company. They are not focused on your product the way you are. They look the world differently, with different goals and objectives, with different levels of depth and clarity. They are dependent on others (you? the product team?) to provide them with key information in order to do their jobs.

Now think about partners and customers — people external to your company. They have even less information and knowledge than your marketers or sales reps.  And they certainly don’t think about or care about your product the way anyone in your company does, because they have their own goals and objectives, and yet they depend on your marketers and sales reps (and others) to arm them with the information they need.

And who depends on them for information? It’s a real-life version of the telephone game.

Does this sound familiar? Have you experienced it in any company you’ve worked in?  How have you addressed it or tried to address it?  And no, Sharepoint is not the answer. :-)

Saeed

Tweet this: The 3 biggest problems in Product Management today – part 3 – Communication http://wp.me/pXBON-43Q #prodmgmt

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

Roadmap Planning as a Zero Sum Game

By Rivi Aspler

gameIn game theory and economic theory, zero-sum describes a situation in which a participant’s gain or loss is exactly balanced by the losses or gains of the other participant.

When planning a roadmap, one can easily resemble the different stakeholders to participants of such a zero sum game, where the roadmap days are the gains that everyone wants and the discussion-room is some kind of a poker table, on which development-days are exchanging hands just like poker chips.

The fact that everyone is working for the same company and want the same best for it doesn’t contradict the fact that each of the stakeholders has a different way to reach that same objective…

  • R&D - want to invest in infrastructure or re-write products that are written in outdated technologies.
  • Professional Services teams – want more parameters in the software that will help them setup new customers in less time and help them better accommodate the product for different customers’ needs.
  • Sales people – want exactly the set of features that will help them, close the next deals.
  • Marketing teams – want that new set of features that everyone is talking about (but that very few customers are willing to pay for, just yet).
  • And certainly you as a product person (be honest with yourself) – want to invest more than a few roadmap days in what you think would bring more value to the customers.

Understanding that roadmap planning is a zero sum game requires you to:

  • Try and get as much mathematics into the analysis of where roadmap days should be invested. Getting people to agree on numbers is always better than getting people to agree on some cool PowerPoint slides.
  • Accept the fact that each stakeholder will do their best to prove that more roadmap days should be dedicated to their goal. For example, sales people will ask for lower quotas if their requests don’t get enough roadmap days or R&D teams that will threaten you that products will crash if you keep on using that outdated technology.
  • Accept the fact that a choice must be made and hence, some stakeholders will like the decisions and some will be disappointed.
  • And last but not least, try and enjoy the process as much as you can.

At the end of the day roadmap planning is not that different from chess. Try to do your best to win the game but be ready you lose respectfully.

Rivi

Tweet this:  Roadmap planning as a zero sum game http://wp.me/pXBON-43W #prodmgmt #roadmaps

Rivi is a product manager with over 15 years of product life-cycle management experience, at enterprise sized companies (SAP), as well as with small to medium-sized companies. Practicing product management for years, Rivi now feels she has amassed thoughts and experiences that are worth sharing.

We’re 7 years old…and a week

In what is now a truly unplanned tradition, I completely forgot (yet again) the anniversary of this blog.7th birthday

No fanfare, no fireworks, no cake.  Just a blog post and a thank you to all the readers who regularly visit, comment and promote this blog.  And a big thank you to all the contributors who write exceptional content.

  • Total posts published in 7 years:  842
  • Average # of posts per year: 124
  • Most posts in any given month: 32 in January 2009
  • Number of contributors over the last 7 years:  33
  • Number of comments on the site: 8961

The following are the top 10 most popular posts of all time.

1. Agile/Scrum and Product Roadmaps
2. 5 Interview Questions for Hiring Great Product Managers
3. Product Manager vs. Product Management (part 5)
4. My Agile Product Backlog Template
5. A 90-day Plan for New Product Managers
6. How to Create an Effective Product Management Organization
7. The Importance of Differentiated Product Management Roles
8. A new (and better) definition for Product Owner
9. A Model and Metrics for Tracking Product Success
10. The Scrum Title “Product Owner” must die!

So thank you to all the readers and someone please remind me in late May 2015 about the upcoming 8th anniversary of the blog.

Saeed

 Tweet this: We’re 7 years old…and a week http://wp.me/pXBON-44j #prodmgmt #prodmktg #birthday

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

Know when to call it quits

by Liraz Axelrad

keepcalmWhen asked about the future of “Home” ­– Facebook-not­-really-­mobile­OS-­but-­kind-­of” Mark Zuckerberg said: “It’s a tough thing determining when something doesn’t work, and when something hasn’t worked yet”.

Indeed it is. And sometimes it’s up to us PMs to make that decision. Sometimes it’s our job to make the hard call; to call it quits.

An object lesson

A few years ago I worked on the launch of an outdoor portal. One of the features was advanced search. I was in love with it. It had so many fields! So many options! Using it, one could find exactly the right activity for oneself, or so I thought.

And then we launched it, and no one used it. Was it because the feature was simply not needed, or did we screw up the experience? Could we make it work? Was it worth our time? And mostly, how could I know?

The easy option was to keep the feature as is. Let it be. Do nothing, make no decision. As a PM, I’m short on time and resources and, well, it’s already there, right? Working and all. No harm no foul.

Only it ain’t so. Dead spaces in our apps are harmful. We should not let our apps become graveyards for failed ideas. Apps get inflated over time because we keep adding stuff to them, so it’s doubly important to trim them down whenever we can. And it’s also important not to be afraid to make the call.

The problem is, we tend to fall in love with what we do. It’s a good thing when we start. Our enthusiasm fuels our advance and the whole industry, for that matter. But it can become an obstacle later on, when things don’t work as we expected. At that point we should be able to make an informed decision.

Questions

Should we kill the feature, or iterate on it? That’s the question we need to answer. Those are our options. Now let’s make a decision. A few question to consider:

  • What are the feature’s metrics and how do they sum up in comparison to what we promised at the beginning? How big is the gap?
  • Do we have practical ideas on how to close that gap?
  • What were our goals for the feature, what did we try to achieve strategically and is it still valid?

If the answers to any of those questions is “No”, then it’s a no-brainer, kill it. But If the answer is yes, then it’s time to plan the next feature iteration. A good iteration plan includes:

  • Time frame: how much work, how many hours or sprints, when will we release the upgraded feature and when do we have the next decision milestone. Put a date on it.
  • Numbers: What metrics are we trying to affect, what are our dream numbers. Be clear and be bold. Put down the numbers that will keep the feature alive.
  • Changes, user stories: what are we actually changing and how, full description.

And now to the hard part: try to get everyone, all stakeholders, to agree with your plan.

I know it’s not always possible, but when it is, it’ll make your life easier. And what if we do all that and the feature, alas, still doesn’t do what is should? Then it might be good to remember the wise words of Stephen King from his book “On Writing”, part autobiographical, part advice to young writers: “Kill your darlings, kill your darlings, kill your darlings”.

Your product will benefit from it. Your users will benefit. You will benefit.

Liraz

Tweet this: Know when to call it quits http://wp.me/pXBON-43s #prodmgmt #eol

About the Author

Liraz-bwLiraz was born and raised on a Kibbutz in Israel,and currently lives in Berlin. Liraz is an experienced Mobile PM, writer and baker. She loves doing stuff that are used, or eaten, by others.