The Mobile Release Status Meeting Nobody Should Have to Run

You've seen this meeting. Maybe you've led it.

It's 10am on release day. The PM opens with "Where are we?" The developer says they're "checking on it." QA mentions they found something yesterday but aren't sure if it's blocking. Someone from leadership asks whether the app is live yet. The developer opens App Store Connect on their phone, squints at the screen, and says "I think it's still in review."

Twenty minutes later, everyone disperses with a vague sense of progress and no shared record of what was actually decided.

This meeting exists because mobile releases have invisible states—and most teams don't have one place where those states are visible to everyone who needs them.

The five invisible states (and why PMs always feel behind)

At a large e-commerce clothing company I worked at, mobile releases pulled in stakeholders from across the business. Campaigns had deadlines. Leadership cared about timing. And yet the people who needed to know the status were almost always the last to find out.

Here's what was happening under the surface—often simultaneously, often unknown to the PM:

1. Build failing. The developer is wrestling with a production build—certificate issue, CI flake, dependency conflict. From the outside, it looks like silence. The PM assumes things are on track because nobody said otherwise.

2. QA in progress. Testers are working through tickets. They find a bug, message the developer directly, and a fix-and-rebuild loop begins. Leadership has no idea QA isn't done—or that "done" keeps moving.

3. Submitted to stores. The binary is uploaded. The team mentally checks "released" off the list, but users can't download anything yet. The hardest part is often still ahead.

4. In review. Apple or Google is evaluating the build. This can take hours or days. The only person who knows is whoever remembers to check the console—and they're usually mid-something else.

5. Approved but not live. The app passed review days ago, but the CTO or CEO hasn't signed off on go-live. Maybe a partner agreement isn't final. Maybe marketing wants a specific launch window. The build sits approved in the store while the PM fields "is it live yet?" messages from people who assume approval means shipped.

Each of these states is a legitimate phase of a mobile release. The problem isn't the phases. The problem is that they're invisible unless you ask the right person at the right time—and that person is almost always the developer.

Why "can someone check the dashboard?" doesn't scale

The default workflow at many companies looks like this:

• PM pings the dev on Slack: "Status?"
• Dev stops what they're doing, opens App Store Connect or Google Play Console, reports back.
• Information lives in a DM or a verbal update in standup.
• By afternoon, someone else asks the same question.
• The dev checks again.

This works when you have one release a quarter and three people on the team. It breaks the moment you have parallel releases, multiple stakeholders, or a PM who isn't embedded in the engineering channel.

Dashboards are built for the person who submits builds—not for the product owner planning a launch email, the BA confirming a feature for a partner, or the exec deciding whether to announce today or Thursday.

Store email alerts help, but they land in inboxes nobody watches in real time. What teams need isn't another tool to open—they need status in the channel where decisions already happen.

What a real source of truth looks like for mobile

"Single source of truth" gets thrown around a lot. For mobile releases, it doesn't mean a perfect Jira board or a wiki page updated after the fact. It means:

Status is public by default. When the build fails, the channel knows. When QA starts and finishes, the channel knows. When the app is submitted, in review, approved, or live—the channel knows. Not because someone remembered to post an update, but because the workflow is designed to surface it.

Each step has an owner. "Someone should check the store" isn't a step. "Alex confirms submission" and "Sam marks QA complete" are steps. Assignees create accountability without the PM playing telephone between roles.

Leadership can observe without interrupting. The CTO doesn't need to ask "are we live?" in a DM. They can see that the app was approved Tuesday and go-live is scheduled for Thursday after legal sign-off. The conversation shifts from status to decision.

The PM stops being the human router. The best PMs on mobile teams aren't the ones who check dashboards fastest. They're the ones who set up a process where they don't have to.

From status meeting to release channel

The status meeting exists to synchronize information that should already be synchronized. Kill the meeting not by caring less about releases, but by making the release visible where your team already works.

Open a release in a dedicated Slack channel when work begins—not the day before go-live. Define steps that match how you actually ship: build, QA, submission, review, approval, release. Assign each step to someone who can move it forward. Pull store status automatically so "in review" and "approved" don't depend on someone remembering to look.

The PM manages the release instead of excavating it. Devs stop being the dashboard API for the rest of the company.

That's the meeting you shouldn't have to run—and the one most mobile teams run every week anyway.

---

ReleaseSteps turns your Slack channel into that source of truth. Create a release with /releasesteps, assign steps to your team, and get App Store and Google Play updates automatically—so the status meeting can stay on the calendar only when there's something worth discussing. See pricing — $79/month per workspace.