A lot of what Product Managers do is make decisions or help others make decisions that positively impact the business or product.

One of the problems we face in meetings or discussions is that we’ve never been taught any formal ways of having productive discussions and how to help others contribute to a discussion in order to make a decision.

Often times these discussions become confrontational, with opposing views digging in deeper and deeper instead of trying to come together to a common outcomes.

You’ve been in those meetings; I know you have. Someone (maybe you) proposes something – a new problem to solve or a new capability to build or a change to an existing process etc. And right away the naysayers come out stating all the ways the idea is wrong or how it won’t work with various (spurious or strawman) reasons in support of their argument.

We can argue with the naysayers, but without a constructive way to bridge different viewpoints, the discussion often ends with either the most vocal, most passionate or most senior person winning. None of those are really good outcomes.

Solving the Problem

The problem really boils down to the fact that we don’t have constructive language to use in these situations. Positions are binary (agree/disagree) and opinions and agendas dominate people’s perspectives. This provides “denialists” or “whataboutists” an easy way to distract the conversation.

Also, many people in these meetings will stay silent because they don’t want to get caught in the crossfire between opposing sides.

We can solve this problem by defining a method that helps facilitate these decisions, keeps them constructive and facilitates participation and buy-in from all parties in as transparent and effective way possible.

About 10 years ago, a company I worked at was acquired by Novell. Yes, Novell, the Netware guys. They’re no longer around, but one of the things I liked and have tried to carry forward to this day is the culture they had around meetings and decision making.

We had a simple, but very useful framework for facilitating discussions and moving them forward to decisions.

The framework (PAADS) revolved around the use of 5 these terms:

  • proposal
  • agreement
  • alignment
  • declaration
  • scale

As we all know, decisions can be made and reached in many ways. One of the key requirements of most decisions is to ensure that the parties impacted by those decisions buy-in to them.

For example, pricing and licensing changes will impact the sales team and they need to know about them well before they are implemented. Product changes are another obvious place where decisions have significant cross-team impact.

Often, a lot of time is spent socializing ideas with various parties, getting their input on the idea and understanding the impact it might have. e.g. with the pricing example above, getting input from the sales team is very important given their jobs and income are directly impacted by any changes. But what happens if they object or don’t like certain aspects of the idea?

This is where the terms above come in. First let me define “proposal” and “declaration”.


proposal is any plan or idea that is the topic of discussion and that needs a decision made on it by a group.  Note that for Product Managers, this would usually be in the context of a cross functional team, that would include representatives of other teams such as sales, marketing, engineering etc., but it could even be a decision between 2 parties.

A proposal can be a formal detailed idea presented via a document or slide deck, or it could be simply a topic of discussion raised at a meeting. By using the word “proposal” and language such as “I propose …“, the message to the audience is clear: this is a topic that is meant for discussion and on which a common decision needs to be reached. i.e. need to get input and buy-in from other teams or individuals.


declaration is a de facto decision made by someone with the authority to do so. While it is good to get consensus or reach a mutual decision, that is not always possible. In some cases, when a decision cannot be reached by the team, someone with positional authority can declare what the decision is, or that certain limits are in place for the context of the discussion or decision.

For example, a CEO or a business unit manager could say something like:

“I’m declaring that any pricing changes must be made at least 45 days before the end of a quarter.”

While it may sound a bit formal to say it that way, it sends a very clear message as to the importance of what is being conveyed.

Declarations are not used that often — managing by positional authority has it’s limits — but when they are used, people take note. Sometimes a declaration is made after a lot of discussion has taken place and there is no path to consensus or a good decision. There is usually little debate around declarations, unless the person making the declaration has exceeded their bounds of authority.


Agreement is a binary action. Either one fully agrees with a proposal and its details or they don’t.

Agreement (if reached) is great, but it can sometimes be difficult to get 100% agreement on all aspects of a non-trivial proposal.

What happens often, when people try to reach full agreement on a proposal, is that the discussion focuses on specific issues and often devolves into a set of objections and efforts to change the proposal to address those issues. A lot of time is spent arguing points back and forth and forward progress is hindered.


To work around lack of agreement, the concept of Alignment is very useful. Alignment can be viewed as a form of general agreement or agreement in principal.

One can be aligned with a proposal, but unlike agreement, being aligned does not mean full agreement to all aspects of the proposal.

For example, if the topic of discussion is an upcoming pricing and licensing change for a product, being aligned means agreement on many assumptions or aspects of the change, but not every one of the details.

For example, one could say:

“I’m in alignment with the timing of the changes, but not with the proposed percentages of the price increase.”

What’s good here is that you communicate both positive (alignment on timing) and clearly describe the negative (percentages). This helps focus the discussion on where this is misalignment.

Now at this point, how do you proceed?

In this model, it’s not sufficient to simply disagree with a proposal or not be aligned. You need to make a counter proposal to continue to move the process forward.

e.g. in the example above, the speaker would need to propose alternative percentages for the price increase, and ideally support their reasoning for those specific percentages. e.g.

“The proposed 15% increase is too high, given that we’re facing stiff pricing pressure from our largest competitor. We’ve lost a number of deals due to price. I propose we cap any increases to 10% maximum. This will avoid sticker shock from prospects and we can address pushback through discounts or service bundles.

This is an example of a good counter-proposal. Not only does it explain WHY there isn’t agreement to the proposal, but also provides a good counter proposal with context.

Now the discussion can focus on the differences between the two proposals and the reasons for those differences. Isn’t this much better than someone simply disagreeing with the original 15% proposal because it is “too high”.


Scale is used to make a discussion more general or more specific. When trying to reach alignment, it can be easier to scale up — make the context more general — reach alignment there, and then scale down — move to more specific issues — and then try to reach alignment on those.

Some people will explicitly use the word “scale” in their statements. For example:

“On the scale of the entire company, I can see why this proposal makes sense, but on the scale of our team, it has problems.”

Now you might be thinking that the word scale is superfluous here, but let’s compare.

I can see why this proposal makes sense for the company, but it has problems for my team.

Do you see the difference? It’s subtle but important. The first is talking about the scale of the proposal using the company and the team to frame how it will or not work. The second one is talking about the proposal itself with specific examples of the company vs. a specific team),

How people respond to the first statement will be different than how people respond to the second statement. In the first, the focus will be on the proposal. In the second the focus will be on why it doesn’t work for the team.

Structure and specificity help

One of the nice things about this type of dialog is that it requires specificity on the part of the speaker, and it encourages a positive discussion where the intent is to reach alignment.

As discussions progress, the scope of the misalignment amongst the group will shrink until at some point, everyone is in alignment.  At that point a decision is reached.

The objective is not the reach full agreement — that is not always possible — but to quickly zero in on the points causing misalignment amongst the group and work to resolve them.

If the meeting leader asks if everyone is in alignment with a proposal, and no one explicitly states they are not, then the decision becomes final and they cannot pipe up later that they are not aligned with the decision.

Yes, there may be some small areas of disagreement, but unless someone can propose an acceptable alternative, those areas are left as is.

As you read this, you might wonder what I’m smoking. The language may sound artificial or overly formal.

I thought that at first as well when I was introduced to this approach. But as we used it at work, I really liked it.

These five terms not only define a simple, common vocabulary that we used, but the process, of repeatedly narrowing down the areas of misalignment really works.

Given how much time we spend in meetings, discussing topics and trying to reach common ground, having a common framework gives us a common language and toolset to move forward together.

Try it at your office and let me know what results you get.


A little feedback please

Since you’ve read this far, why not give me a little anonymous feedback on the article. 3 short questions, it’ll only take a minute, and it’ll put a smile on my face. What could be better than that? Click here.

Saeed Khan is a founder of Transformation Labs and has worked for over 20 years in high-technology companies building and managing market leading products. He speaks regularly at industry events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page.