---
title: Making Decisions and Keeping a Product Team Firing on all Cylinders
teaser: 'To ship early and often, a high-functioning product team should steer clear
  of these common decision-making pitfalls.

  '
tags: teams,process,productivity,analytics,playbook
author: Mike Wenger
published_on: 2018-04-19
---

Developing software is a collaborative process that takes a tremendous amount of
input from customers, designers, developers, and a company's leadership team. We
know the merits of shipping early and often, but doing so requires regularly
making decisions with imperfect information. When it comes to effective
decision-making, there is no one size fits all approach, but there are
decision-making "smells" that can disrupt a product team's effectiveness. Like
"[code smells]," a team should acknowledge and consider addressing these
dysfunctions.

[code smells]: https://martinfowler.com/bliki/CodeSmell.html

### Inconsistent Decision-Making Process

Conversation on a ticket:

> **Developer:** "I realized that the mockups don't include a place for a user to
> log out. The two best places to add the button seem like A) the navigation or B)
> the account page."

> **Team Member 1:** "I definitely would go with B. The navigation is already a
> bit crowded."

> **Team Member 2:** "I think both could work"

> **Team Member 3:** "Navigation makes the most sense to me. I vote A!"

... many hours of silence ...

> **Developer:** "Sounds like we don't have a clear winner. Should we have a
> meeting to discuss?"

... many more hours of silence ...

By highlighting the example above, I am not advocating rushing decisions or
excluding team members from the decision-making process. The smell is that the
developer does not have clear guidelines for how to resolve a stalemate. Maybe
the team's product owner considers all of the input and
provides the final decision on the ticket? Maybe there could be time carved out
after standup for the team to discuss the options, weigh the tradeoffs, and vote
as a collective group? Either of these options works, but what is important is
that the team has an agreed upon game plan. This brings consistency into the
process and reduces developer uncertainty and stress.

### Unavailable Product Owner

As a developer, when I work on tickets, I often run into a concern or edge case
that needs to be run by the product owner(s) before I can proceed. Product owners
are busy. They have meetings, other responsibilities, and they go on vacation. If
a product owner cannot get back to me for a day or two, it isn't the end of the
world as I can pick up a new card and stay productive. Their absence becomes a
smell when it is the norm. When a product owner is spread thin and isn't able to
get back to me on several tickets at a time, they become blocked and the backlog
gets backed up. Having to constantly context switch between tickets can take a
big hit on developer velocity.

### Prescribed Solutions

Discussing a ticket on the backlog in a product planning meeting:

> **Product Owner:** "The accounts team needs a new filter in the admin console
>where they can filter customers by sign up date."

> **Developer:** "That shouldn't be too tough and will only take a few hours.
>Why do they need the filter?"

> **Product Owner:** "They want to identify accounts created today."

> **Developer:** "That makes sense. What if instead, we just updated the existing
>customer table to be ordered by account creation with the newest customers first?"

> **Product Owner:** "I like it. That would actually make it even easier for
>them."

> **Developer:** "Great. It makes it easier for me too as that'll only take a
>few minutes"

This team almost missed a creative solution that led to a better outcome. It is
a smell if a developer is working on a feature and doesn't know why. A developer
will have the best context on the difficulty and tradeoffs of different
implementations. By looping them in on the business motivation behind each
feature, you empower them to get creative and find wins that can ship better
solutions to your customers faster. It's even better if that context sharing
takes place on the ticket and is not dependent on an in-person conversation. [Job
stories] are a great way to achieve this.

[Job stories]: https://thoughtbot.com/blog/converting-to-jobs-stories

### Iterating on a Whim

[Building a new MVP product] can require a leap of faith because you don't
have the analytics of real users to guide most decisions. However, once a product
exists, there is real world usage that a team can use to optimize the product.
Optimization may mean more signups, higher retention, quicker checkout, more
pageviews, etc. A busy team may not run regular analysis and miss the fact that
the last deploy led to a major reduction in performance of several key metrics.
A busy team may float the idea of running an A/B test, but scrap it since it will
add to development time and may compromise a sprint. It is a smell if user
validation and analytics are not treated as first class citizens when deciding
how to iterate a product. Not all change is good, and it is important to identify
which changes should be celebrated, and which should be reverted.

[Building a new MVP product]: https://thoughtbot.com/blog/before-you-mvp

## Addressing a Smell

Like code smells, a decision-making smell may not be catastrophic to your product
or your team, but if you let the smells build up and fester, you are at risk of
jeopardizing your product's quality and your team's morale. If you see a smell
on your team, shine a light on it in your next [team retrospective].

[team retrospective]: https://thoughtbot.com/blog/you-aint-gonna-need-process#retrospectives