The calling the shots dilemma

Question

This is a quote from an interview with a product manager (PM) expressing their concern regarding UX practices in their company:

one thing which always failed is that we didn't define who has the final say, who can actually decide what to do and how.

A product owner (PO) similarly expressed their concern about UX practices as:

It's the product owners that work with the teams, and actually, to some extent design how the system should work. POs are the customer, or the proxy for the customer (i.e. purchaser). They are the ones that have decision power on how things should look...when UX practices affect the scope, then definitely it's the PO who should decide.

In most cases though, these product owners or product managers do not necessarily have enough knowledge of UX, and UX is not their main concern. Often what these roles prfioritize is on-time, and on-budget delivery and assuring 'customer' (i.e. purchaser) satisfaction which in case of software that is NOT market-driven often leads to neglecting the end users' view to a large extent. This is evidenced by one PO saying:

we have a table component which have really bad behaviour, and we all agree on that, but we know that if we should change it, it's a huge amount of work... We have done some fixes, so you can live with it, it's still not nice but you can work with it. That's how it needs to be right now.

My questions is addressed to those of you, UX experts, that work in agile settings. I am interested to know:

1. in the agile projects that you have been involved, how do you collaborate with product owners and (if applicable) the product managers? What tools and methods do you use?

2. Who calls the shots when it comes to decisions that influence the UX of the software? e.g look and feel, the flow, and even what features to implement, and what features to prfioritize in each sprint? (feel free to add other examples of decisions that should be made that influence UX, also if you use specific tools for prioritisation I would like to hear about them)

   I know 'collaboration' is the key! But here, I am looking for a more 'tangible', 'hands-on' answer. So I appreciate if you write about the tools and methods, measures, evidence etc. rather than abstract concepts such as 'we collaborate'. It would also be very useful if you share 'specific stories' about your experiences (like the above quotations) and how you dealt with them.

Answer 1

This is an excellent question. I've seen decision processes fail at big companies (e.g. teams immobilized by consensus at Google) and small companies (e.g. ego-driven founder decisions at startups).

Unfortunately most corporate training programs provide are designed to help UX and dev teams with vertical skills and resources, but very few corporate programs cover how to drive effective teamwork and make effective team decisions.

The Agile/Lean frameworks don't address this directly either.

Here is a stack of complementary actions which can help drive good decision-calling:

1. Establish decision-making leadership

Collaboration is not consensus! Effective teamwork does not mean there is no leader, or nobody with a veto.

• Good CEO's understand that executive teamwork is crucial for business leadership (no CEO can singlehandedly run a substantial business), but they also understand that they ultimately can call the shots in situations where consensus is too difficult, slow or costly to drive.
• The same is true for product teams: close teamwork doesn't mean there is no leader.
• It's best to have a single team leader who has shot-calling authority, but who also bears ultimate responsibility for the product (with power comes responsibility!).
  • I'm personally a fan of the Product Manager being the ultimate decision authority within a product team (to drive the best commercial alignment), with additional escalation outside the team all the way up to the CEO. But in many companies it may make sense for other roles to lead depending on the situation.

2. Establish clear specialist roles

• A developer is far more likely to make a good decision on code-related issues than a graphic designer. A UX professional is far more likely to make a good usability decision than a product manager. So good teamwork must recognize and incorporate specialization into decision making.
• SEAL teams have a platoon structure which has an overall Office-in-Charge (OIC) but also specialists (sniper, breacher, communicator, etc) who have far more expertise in their professional domains. Decision making ultimately rests on the OIC, but must incorporate the professional expertise from specialists with appropriate weight.
  • For example, it'd be idiocy for an OIC to ignore advice from a breacher specialist while planning a breach mission stage. The OIC might make the decision incorporating the breacher's advice, or may delegate the decision completely to the breacher.

3. Use data

• The early, consistent, and habitual use of data helps teams make proper informed decisions. It also helps drive a culture of objectivity and meritocracy into teamwork because decisions are not made based on seniority, favoritism, or leadership whim but rather on hard or statistical facts where they are available.

• Using data also means establishing the practice of collecting, analyzing, and presenting data as part of decision making as a team.

• Using data also means engaging appropriate parties or informational resources outside of the team (voice of customer, CEO, consultants, academics, etc) as neessary.

4. Establish clear and consistent culture and principles for teamwork

• Clear principles such as data-driven analysis, clear specialization domains, decision-making authority, collaborative rational debate/dialectic, etc. provide clarity around roles and decision processes.

• A consistent and principle-driven culture helps provide a stable and dependable environment for teamwork, which reduces friction in both execution and decision making.

• It's important that teamwork principles are also recognized by the organization outside of the team. For example, if a team has a leader, that leader needs to actually be empowered to shot-call by the rest of the organization, otherwise teamwork may collapse once the team realizes a leader is not empowered.

Answer 2

This is a very broad question, for which this long answer is just the iceberg tip.

Divide and conquer

one thing which always failed is that we didn't define who has the final say, who can actually decide what to do and how.

The agile answer to this is that everyone decides together. But this often fails miserably for the following reasons:

There is too much of everyone and everything. In other words, the decision process involves too many people, with highly diverse stakes and wishes, with too many things of a highly diverse nature to decide on.

To give one example, you sit in a team leader meeting and have to choose either of these two: A UX improvement that was requested by many users for 6 months now, vs. a new feature that the CEO wants to develop because it can add revenue. Which has the priority? Well, this is like comparing apples to bananas. The former is customer-centric, the latter is growth.

This is an issue sometimes termed cross-prioritisation - when you try to decide on the priority between two things that are clearly little related.

Now consider the following question: Is it better for a country to have extra 1500 beds in hospitals, or that the military has 2 more drones? Ask the prime minister and he'll say - I don't waste my time making such comparisons, we define the health and defence budget and each department does as it finds fit.

I guess the solution becomes clear in the last example - by employing divide-and-conquer approach, decisions are easier and upper management shall mainly be concerned with how to slice the cake.

Here's a practical real-world example:

• The bad - In a certain organisational structure, I was once sitting in product management meetings and having to fight for any UX issue to get dealt with, but hardly anything was done because of many other forces that thought there are better things to do.
• The good - Then, we changed the system so UX was an agile project on its own - myself as the designer and two other developers. This small team (together with the PO, when he could make it) was making together decisions as to what's most important. The result? UX has improved much faster, users were happy, even the CEO was happy as positive feedback did pour in.

Also, now the PO had to guide us on UX issues alone, so he wasn't torn between UX, new features, bug fixes, etc.

Agile as a loan shark

Often what these roles prfioritize is on-time, and on-budget delivery

Agile is a great method, but the reality is that many (if not most) organisations only follow the bits they like about it and brush off the bits they don't. Both personal experience and research demonstrates this. In fact, I have personally only encountered one team that follows agile by the word and maximises its potential and it's Google's Angular team.

The rest utilise it in what to me is too often 'buy now pay later' fashion - compromising research, design (UX and software), testing, QA, code quality only for the sake of time-to-market.

Luckily, I believe the awareness of this systematic failure is growing - too many startups find themselves 4 years down the line chasing bugs and with non-competitive development times. The word spreads, bottom-up.

Product owners are good for you

It's the product owners that work with the teams, and actually, to some extent design how the system should work. POs are the customer, or the proxy for the customer (i.e. purchaser). They are the ones that have decision power on how things should look...when UX practices affect the scope, then definitely it's the PO who should decide.

I totally agree when it comes to what to do next. My experience with POs was always a positive one - at the end of the day, they know and wish the best for real users. In fact, my life was much easier because there was this real user with vast knowledge of the domain and other users who could guide us where the value is instead of us making assuming.

Defeatist attitudes and Cost of Delay

we have a table component which have really bad behaviour, and we all agree on that, but we know that if we should change it, it's a huge amount of work... We have done some fixes, so you can live with it, it's still not nice but you can work with it. That's how it needs to be right now.

Well, this may well be a valid argument. If development cost is high compared to value added, it is perfectly fine for the PO to pick another task with a better ratio.

But I suspect this statement smells as if technical debt is behind it, in which case this is like you coming to the doctor complaining about various odd symptoms and the doctor says: "You eat unhealthy, you don't exercise, you drink alcohol every day, you smoke 40 cigarettes a day, your cholesterol is high, your sugar is high, you should really change your diet and lifestyle!" and you go "Nah... too much effort".

Another concept that may come to mind here is the cost of delay as thoroughly argued by Reinertsen (A book, you may wish to read, albeit not to be taken as biblical). In simple terms, many make decisions based on development cost vs. a rational customer value. But first, customers aren't rational (specifically with UX where emotions are hard to quantify); more importantly - it is about what you lose during the product lifetime that you should compare to development cost. So if you ain't going to fix it in the next 5 years would the cost of having a poor table component still be lower than the development cost for improving it?

Skunkworks

Businesses find it really hard to change internal processes and old habits.

One solution is to introduce a role, or a team, whose sole responsibility is to ensure quality and improve things. By definition such entity is autonomous and completely oblivious to any time/budget constraints. This practice has proven extremely beneficial for some businesses.

The key concept here is autonomy. Now while such concept may seem a bit extreme (particularly in small businesses) a variation of it is instead of having an autonomous entity, either individuals or teams get a degree of autonomy. Word has it that Google allows employees to spend 10% of their time on whatever they wish to, so long the work is somehow related to its products. The concept of workcells that get a degree of autonomy is also fairly common.

So in relation to your question - sometimes individuals or small teams given the right to call the shots on an autonomous basis is highly beneficial.

Answer 3

There's 2 very excellent answers from @tohster and @Izhaki.

I'm in a similar situation, on a team getting on board with SCRUM with a SaSS product where the people who've purchased the software aren't the primary users. So I just want to add my experiences on things I found that worked.

Relate UX to Dollars

In the SaSS (Software as A Service) field , customer churn is a hot topic. One of the talks in this year's Pulse Conference suggests the biggest cause for customer churn is usability of the product. And there's nothing your Support or Retention team can do to keep customers if the product is lacking. This may be something you can leverage to access more resources for UX. How much revenue is lost due to customer churn. How much money will you recover if you reduce churn by just 1%? How much future revenue will you gain if the customer renew their subscription year after year?

This is "bad"... but how bad is "bad"?

On the topic of UX, Management and sometimes the POs have no idea just how bad something is because they haven't interacted directly with the actual users. They can say, yeah it's not ideal, but it's still usable when in reality isn't not. Not when the user spends most of their day in that one part of the app going through the flow not once, but repeatedly for 30+ times a day.

So bring this perspective to them. It'll be lovely if they can sit in on a usability session. Or if not, you can show them recordings from sessions. Suddenly it's no longer an abstract issue. It's people being affected. I found the PO on my team have become much more responsive to UX concerns after doing some user shadowing and sitting in on usability sessions.

Product & Tech Debt will slowly kill the product

The PO was introduced to Marty Cagan's book "Inspired: How to create products customers love" and subsequently attended a workshop on the topic. Cagan is a huge proponent for allotting time for technical and product/UX debt. He was the Product Manager for Netscape back in the days and directly attributed the death of the Netscape browser to Tech Debt. When you pile on new feature after another, the code and workflow become ungainly... to the point where you literally can't put in new features or the system is so complicated that user wouldn't be able to find the feature, let along use it.

So now, the PO understands this and our team dedicates 1 in 5 sprints for Tech & UX Debt. I think it helps a lot for POs to hear from veterans stories that are related to juggling short term and long term gains. Concepts stick way better when they hear it from people in their field as oppose to it coming from UX or Dev which may seem to them as being too UX or Dev focused.

Negotiation within Cross Functional Teams

In Scrum, the PO acts as the single wring-able neck. And so yes, technically the PO is the one with the final say on what goes into the product backlog and priority of the items.

However there's a lot of negotiation involved in determining what goes into the backlog. For our team, in the grooming session, UX sits with PO, Dev Lead and QA to discuss potential upcoming work. We review requirements and UI and do rough story pointing. Sometimes I will bring up UX items to be reviewed and the Dev lead does the same with technical items.

Often time for these sessions, I spend a bit more effort to come up with various options for UX improvement: best case scenario, step down and "acceptable" scenario. This way it becomes a "let's work together to pick the best option given our time and resource constraints" instead of an "all or none" thing. This a bit of a psychological trick where people are more likely to pick the seemingly middle ground but you've set up the options to skew things in your favour.

Is this a product killer?

This was brought up by a speaker at the Lean UX NYC conference this year. How do you know what to fix first. Ask how many people does this usability issue affect, what's the impact on these users and what will happen if nothing is done about this. Seems like a good way of coming up with some stats in support for improvements. Also having the full context will show the PO you've done your research and can help them prioritize this against everything else that should go on the backlog.

Answer 4

in the agile projects that you have been involved, how do you collaborate with product owners and (if applicable) the product managers? What tools and methods do you use?

The tools and methods I've used consist of:

• talking
• sketching
• building
• showing

In other words, they are part of the Agile team. So they, like everyone on the Agile team, are simply a part of the entire process and are along for the ride.

Who calls the shots when it comes to decisions that influence the UX of the software?

Everyone. That's the spirit of Agile. It's not 'owned' by a single entity. There's no single 'sign off' process. The team works together. And maybe the wrong thing goes out the door. That's part of the process too. Learn what's wrong, fix it in the next sprint.

In Agile (and even outside of Agile, but especially in Agile) the UX team isn't the one calling the shots. They are the ones facilitating the design. They contribute to the design, of course, but their job is primarily to get everyone to contribute to the design process.

If an organization is struggling with 'who has the final say' then that's an organization that's still really struggling with Agile. They're holding on to an old "cover-yer-ass" model of Waterfall. Sign-offs are a bottle neck in Agile in general.

If there's a strong need for sign-offs in the organization, that's usually a sign of a prioritization of corporate politics over the product itself. This certainly isn't uncommon. But frustrating, for sure.