The majority of meetings are a waste of time. And in my opinion, one flavor of meeting that tops the charts in uselessness is the “status update” meeting. You know this meeting — the meeting where everyone gets together to share what they’ve been doing. It’s ironic that meetings like this exist because it gets in the way of people actually doing something productive. A cross-functional group of people (product, design, engineering, marketing and so on) working on a new product doesn’t greatly benefit from status updates.

‍

‍

I don’t claim to know the perfect recipe for a cross-functional product team meeting, yet I can say with a stiffened spine that the worst breed of status update meeting is the “stand up”, which has been popularized in agile methodology. I’m not the first to say this as others have had similar observations and provided comical opinions.

‍

Most standups occur daily and some teams reduce the frequency to a few times a week. The majority of standups are short, yet often meander into casual conversation where people talk about things unrelated to work, like what they did over the weekend. None of this helps you build quality products at a fast pace. We’ve become so enamored with standups that popular tools like Slack even have a standup feature built into them.

‍

But my stance on standups is the polar opposite of the trend. The only time in which a standup is truly beneficial is in the run up to a product launch. That’s when your troops are about to storm the beach and you want to make sure they are prepared. Are we ready to flip the switch on the A/B test? Is marketing ready to publish the blog post and push out the PR pieces? Does customer service have the scripts they need to answer customer questions that will come in right after launch? Do a standup when nearing launch to make sure the troops are ready to sack Normandy. That’s when it’s useful.

‍

In any case prior to a launch, standups are mostly a waste of time. That’s because the bulk of the product development process centers around (1) building (2) making decisions. Point #1 is obvious (of course the team is busy creating stuff), but point #2 deserves a discussion, since that’s the meat and potatoes of the subject.

‍

Making Decisions

‍

Hundreds of decisions need to be made during the development of a new product, like:

‍

• What’s making the cut for the MVP?
• Who is the lead designer going to be?
• How will we promote/merchandise this new feature?
• Will we be A/B testing it?
• What are our goals and key metrics?

‍

Those are the obvious big decisions that nearly every product team needs to make. But there are also a long list of mid-sized and bite-sized decisions that need to be made along the way like:

‍

• Do we need to create a new UI component or can we use the one from our existing component library?
• Is feature ‘X’ worth building since it balloons backend scope by 3 weeks?
• Will this be a 50/50 A/B test or should we do a simple holdout group of 95/5?
• Are we shipping on all three platforms in parallel across web, iOS, and Android?
• Can we cut scope on Android since it’s only 5% of our users?

‍

For anyone that’s built a product of reasonable scope/size, we all know that the set of decisions to make balloons as the project kicks off. It’s only then that you start to peel back the onion and realize the complexity of the task at hand, in addition to the set of decisions that must be made in order to unblock the project and keep it moving.

‍

The universe of decisions to make begins quite large. As the product team progresses through those decisions, the hard (i.e. big) decisions tend to be made earlier in the project (e.g. “What’s making it into the MVP?”) and the mid-sized and smaller decisions tend to come in later in the game (e.g. “Can we simplify UI component ‘X’ to reduce the backend scope by a few days?”). The total number of decisions to make also approaches zero as a team gets closer to launch.

‍

But let’s recall the point I made a few seconds ago — the team is unblocked when decisions are made. “Unblock” is the magic word here.

‍

Unanswered questions act as headwinds or speed bumps when building products. Using the classic example of MVP cutoff, a team must decide on which features will be included or excluded from an MVP. That’s a hard decision to make so product teams typically move slowly through this phase of development. This is one of the driving forces behind the creation of the Google Design Sprint methodology. As the methodology explains, you can use their design sprint method to “shortcut the endless debate cycle” to arrive at a few key decisions regarding what the first product prototype will be. Each unmade decision (i.e. each unanswered question) pumps the brakes on the development process as a whole. Protracted decision-making leads to protracted product development cycles, often by weeks or months (indicated by the red bars below). The Google Design Sprint method is one great example of how a team can make important decisions more quickly, which ushers them through the process of arriving at their first testable prototype.

‍

More on Standups

‍

Before I share with you the meeting format that I’ve learned is most effective for product teams, I’ll harp a bit more on the ubiquitously popular “standup” meeting.

‍

Let’s take a closer look at the prescribed format of a stand per agile methodology. Members of a standup (i.e. everyone on the team) are asked to share the following:

1. What did I work on yesterday?
2. What am I working on today?
3. What issues are blocking me?

‍

There are several big issues with this format.

‍

First, why should I care about what everyone worked on yesterday? Most of the time, you don’t care, and you shouldn’t care what others work on day-to-day. The practical reality is that you only care about what another team member worked on yesterday if it enables you to do your job (i.e. it unblocks you). Anything shared that does not explicitly unblock you is meaningless noise.

‍

For example, a product manager may share something like, “Yesterday, I did one interview, worked on some specs, and interviewed one customer. Today, I need to interview one more design candidate and then I’ll update some of the user stories in the spec based on the questions I received from design. I’m not currently blocked on anything.” This example of a typical standup update is useless in terms of what it does to enable a product team to build a higher quality product at a faster pace.

‍

Similarly, why should anyone care about what I’m working on today? Again, it only matters if what one person is doing today unblocks another person on the team. But if it’s really that important of a blocker, should that person wait until the following daily standup to make that known? Why not email that person or swing by their desk as soon as you’re running up against the roadblock and seek to remediate the issue as it arises?

‍

Now, let’s dissect the third bullet point, which is to share what you’re blocked on. A team member may be blocked on something in one of two use cases. The first is that the task they are blocked on simply takes a lot of time. An example would be backend engineering waiting for more clarity on frontend specs before they can finalize the engineering design docs for what they must implement. The second reason why someone may be blocked is that a decision hasn’t yet been made. It’s less useful to say “I’m blocked by X” than it is to say “Hey, why don’t we get together and make a decision on X, so that we can move forward?”

‍

Standups don’t carve out time for decision-making, which is the ultimate blocker. Rather, standups are designed to simply make the blocker known, yet not resolve the blocker. Resolution matters more than awareness.

‍

A Simple Agenda to Keep Things Moving

‍

I’d like to propose a simpler alternative that leads to more productive product meetings and improved product development cycles. It’s something I learned through trial and error in my career. I’ve found it to be the simplest, most effective meeting format for any product team (and for most meetings in general). Here it is:

‍

1. Action items: who is handling what key action item and by what date?
2. What decisions need to be made?

‍

I would run this meeting one or two times a week depending on the volume of decisions to be made. Sometimes as much as three times a week. Early in the development of a product, when a team needs to make many decisions, I increase the frequency of these meetings. As development progresses, the volume of decisions to make decreases and the proportion of time spent on building increases. Similarly, the magnitude of the decision (i.e. how hard or important it is) tends to decrease as development progresses.

‍

If the team is effective at surfacing key decisions and in driving towards decisions expeditiously, then you can cut out weeks or months of unnecessary delays in the product development lifecycle. So, how do you make sure this is done?

‍

Collecting Open Questions

‍

To prepare for running effective product team meetings (i.e. decision-making meetings), I would go to each function lead on the product team (design, engineering, marketing, etc.) and ask them what decisions they needed made. I would collect the open questions and pull them into the agenda. It’s a simple enough task so you can ask people as you swing by their desk, ping them over email or Slack. In parallel, I would maintain a set of action items that came up during the decision-making meetings. From the set of open questions and action items I would compose an agenda and it would look like the following:

‍

Action Items

1. (Josh) Share latest iOS designs with Tammy by 9/13
2. (Deanna) Send marketing language for review to compliance by 9/15
3. (Andy) Sync with data science on how to configure the A/B test buckets by 9/15
4. Etc.

‍

Decisions to Make

1. Should we include the 3–5 days worth of UI design polish as part of the MVP launch or not?
2. Should we ask executive staff for support to get one more backend engineer or is there no parallel processing that can be done with extra resources to bring in the launch date?
3. Who is going to take the lead on starting customer development for the next milestone on our roadmap? Should we even start that yet or punt it by a week or two?
4. Etc.

‍

If I were leading the meeting, I would run through the set of action items to make sure we continue to execute on the critical tasks each of us signed up for and hold ourselves accountable to hitting our deadlines. Any new action items that came up during that portion of the discussion would then be added to the list in realtime. We would normally move through the action items portion of the agenda in less than 10 minutes.

‍

The remainder of the meeting (which we normally reserved 60 minutes for) would then be spent on making decisions as a group. In many cases, a side conversation had already happened by a few relevant members of the team (e.g. design chatting with engineering about a particular aspect of the designs) and they could walk the team through the context of the open question and their recommended answer. In those cases, decisions were typically made in a matter of seconds or a few minutes. In minority cases (I would estimate about 30% of the time), the decision required ample discussion and might be too complex for a group setting and/or the time allotted.

‍

In those cases, I would ask 2–3 of the most capable and relevant members of the team to form a quick working group either later that day or the following day to discuss the item and come up with a recommended decision. Their recommendation was then shared with the rest of the product team either over email, Slack, or in person at the next product team meeting. We effectively had multiple concurrent decision-making meetings going on in parallel, constantly driving towards reducing uncertainty and maintaining momentum.

‍

The more we had these meetings, the more effective we became at making decisions as a team, or in forming the breakout group to drive towards a decision and then close the loop with the rest of the team.

‍

Decision Log

‍

Something else to consider adopting is a decision log as part of this meeting format. I suggest using a single Google doc for maintaining a full record of all prior meeting agendas, as well as prior decisions made. That comes in handy when a post-mortem is run after the product has been launched to assess what the team did well or could have improved upon. Often, the full context of prior decisions made is lost, especially if those decisions are made in isolation by a few people and/or made several weeks or months in the past.

‍

Maintaining a record of all prior decisions makes it very easy to reflect on the project during a blameless post mortem and the ability to identify the root cause of issues that eventually come up. Or, better yet, the log of all prior decisions made may help the team identify root cause behind a failed product launch. To make things convenient, I’ve created a copy of the agenda format and decision log that I used to use with my product teams. It’s publicly available for you to copy and use yourself. It’s simple enough but thought I’d share nonetheless.

‍

Wrap Up

‍

The format for standups popularized in Agile methodology, unfortunately, isn’t well calibrated for driving efficient product development within a team. The root cause for long development cycles is that decisions weren’t made quickly and frequently. By replacing daily standups with less frequent decision-making meetings, product teams can save themselves lots of wasted time and build products much more quickly.

‍