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.


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.


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.


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?

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.


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.


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.


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


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.


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.