Coaching or a workshop: which one fixes your problem?

The request often arrives as "can you run a workshop for the team?" Sometimes that's exactly right. Just as often, the team already knows the method, and a workshop will give everyone a good day and change nothing by Monday.

Before you buy either, work out which gap you're trying to close.

Method or judgment?

A method gap means the team doesn't share a way of doing something. Nobody has written a testable hypothesis, the word "outcome" means something different to every person in the room, and each team has invented its own rituals.

A judgment gap means the team knows the method and still brings you the wrong call. They can draw an opportunity tree and still pick the comfortable feature. They know what an outcome is and still write "ship the new dashboard by Q3" in the objective column.

The first closes in days, because you can teach a method. The second closes over months, because judgment is built by making real decisions with someone who will question them.

Signs it's a method gap

• Discovery is something the team does occasionally, as a phase, rather than every week.
• Nobody can say how they would test an idea before building it.
• Different teams work completely differently, and none of them can explain why.
• Outcomes and outputs are used as if they meant the same thing.

Here a workshop is the faster fix. Two days give a team a shared language and a shared set of methods, and that is the foundation everything else needs.

Signs it's a judgment gap

• The team went to a workshop last year, everyone liked it, and nothing changed.
• Product managers can explain the framework and still bring you a feature request in a framework's clothes.
• Decisions hold until a senior stakeholder asks for something by name, then revert.
• Leadership talks about outcomes and still asks for features with dates. I wrote about that stage as the messy middle.

Here another workshop won't help. The team doesn't need more knowledge. It needs practice at using what it knows, under the pressure of real decisions.

What a workshop can and can't do

The Product Discovery Workshop is 16 hours over two full days, or three shorter ones, for a group of 10 to 16 people. By the end, a team can turn business goals into product outcomes, plan discovery work, uncover opportunities, turn ideas into testable hypotheses and test its assumptions.

What it can't do is the discovery itself. There are no real users in the room and no live experiment, so nobody walks out with evidence. I say that out loud in the first five minutes, and I design the day to end in a test someone will actually run, with one metric each participant brings from their own product.

What you walk out of a workshop with

A good workshop is built on your product, not a generic case. Ours starts with a scoping call, so the exercises run on your real context, and the team leaves with six things:

• Business goals translated into product outcomes a team can move and measure.
• An Opportunity Solution Tree: one outcome at the top, the customer problems under it, the solutions worth testing.
• An assumption map across desirability, viability and feasibility, sorted by how little evidence you have.
• A test card for everyone, on a real opportunity from their own work, with the pass mark written down before it runs.
• A discovery practice plan: who talks to customers, how often, and where discovery sits in your sprints.
• A written action report on how to embed it in the team's rhythm.

What coaching looks like

Product coaching happens inside the real work, weekly or every two weeks, for the people who actually make the calls. It runs for three to six months, and I don't recommend less than three: that's the minimum to see real progress on a strategic or team-level problem.

The sessions work on the decisions in front of the team that week, so the method gets used, not taught.

Who belongs in each

A workshop is for whole teams: the product managers, designers and engineers who will run discovery together, ideally as trios, 10 to 16 people in the room. Coaching is for the people who make the calls: Heads of Product, CPOs, VPs of Product and product managers, one at a time or as a leadership group.

How you'll know it worked

For a workshop, within days: every participant leaves with a test plan for a real opportunity, so ask a week later how many are running. If the answer is none, it was a good day, not a change.

For coaching, within a quarter: decisions start arriving with evidence attached instead of as feature requests. At Deviniti, by the end of it every product manager had a product outcome for the next quarter, drawn from their own analytics.

Most teams need both, in that order

At Deviniti Apps it went exactly that way. First I helped individual teams adopt better discovery practices, which is method. Then came working sessions with the pilot team on its own product outcome, and two or three sessions with every product manager while they set an outcome for the next quarter, which is judgment.

A workshop gives a team a shared method in two days. Coaching is how that method becomes the team's judgment. If you're not sure which one you need, look at the last decision that went wrong and ask: did they not know how, or did they know and choose otherwise?