What Changed This Week? A Better Question for Product Teams

Most weekly updates sound busy.

Tickets moved. Meetings happened. A few items are “in progress.” The next sprint is being planned.

None of that tells a founder, product leader, or teammate whether the work actually moved anything forward.

I prefer a smaller question: what changed this week?

Not what did everyone do. Not how many tickets closed. What is now true, visible, usable, or decidable that was not true last Friday?

That question changes the standard. It asks the team to point to an artifact and explain why it matters.

TL;DR

A useful weekly update names three things:

1. What became real.
2. What we learned from it.
3. What we will do next because of that learning.

That is a better measure of momentum than activity because it ties work to a changed decision.

The Problem With Activity Updates

Activity is easy to report because it is always available. A team can list pull requests, planning sessions, design files, and messages without saying whether any of them changed the product or the business.

The danger is not that those things are unimportant. They are often necessary. The danger is mistaking necessary activity for visible progress.

When the update is only activity, people outside the work have to guess:

• Is the team closer to a customer answer?
• Did a risk become smaller?
• Can somebody use or react to something new?
• Did we decide what not to build?

If the answer is unclear, the work may still be moving. It just is not legible enough to guide the next move.

A Weekly Update That Helps People Decide

The format is simple.

1. What became real?

Name the artifact. It might be a working URL, a prototype, a release, a screenshot, a recorded decision, a pull request, or a cleaned-up workflow.

Be concrete. “Improved onboarding” is vague. “A new customer can now invite a teammate from the setup flow” is a change people can inspect.

2. What did we learn?

An artifact is useful because somebody can react to it. Maybe the prototype exposed a missing assumption. Maybe a release showed that customers prefer an unexpected path. Maybe the team learned that a risky integration is much smaller than expected.

The point is not to manufacture a big insight every Friday. It is to connect the thing that became real to the evidence it produced.

3. What changes next?

This is the part that turns a report into an operating tool. State the next decision or the next smallest move that the evidence makes possible.

For example:

We released a basic approval flow for five internal users. They completed it without training, but two steps were unclear. Next week we will simplify those steps before expanding access.

That is a complete update. It shows work, learning, and direction in a few sentences.

A Useful Example

Imagine a team says, “We worked on the AI assistant this week.”

That statement creates more questions than it answers. A stronger update might be:

We put a working draft-response flow in front of support. It saves time on straightforward requests, but the team does not trust it with account-specific questions yet. Next week we will test the missing account context before adding more interface work.

Now the whole team can see what changed. The work is visible. The uncertainty is named. The next step is smaller and more honest than “continue building the AI assistant.”

The Habit Behind Momentum

Momentum is not a dramatic launch. It is useful work becoming visible often enough that people can react, learn, and choose the next move.

Ask “what changed this week?” at the end of every week. If the answer is hard to find, do not shame the team. Use the question to choose a smaller, more visible next piece of work.

That is how a product team stops merely being busy and starts creating momentum.

At Dakic, we help teams make the next useful thing visible: a prototype, a release, a clearer decision, or a system that is easier to change.