Sample analysis
See what Myc gives you from one meeting transcript
This is a real coaching report Myc returned from a single leadership-team meeting — the summary, what went well, the coaching themes grounded in what was actually said, the per-behavior scores, and a micro-experiment to try. Yours runs on a real meeting you already had.
A real, unedited Myc analysis of a representative meeting (a crafted scenario, run through the live product). Yours runs on a meeting you already had.
The report Myc returns
A real, unedited analysis of one leadership-team meeting — the same private report a coachee sees after uploading a transcript.
Summary
You brought urgency to a meeting that needed urgency, but you tried to manufacture certainty faster than the facts supported it. That is the central issue for you here. Several people were telling you, in different ways, that the team did not yet have the inputs needed to make clean decisions on pricing, launch scope, and customer communication; instead of using those constraints to structure the discussion, you often declared a direction and asked others to make it true afterward. This is closely related to the pattern from your prior meeting, but the sharper point now is accuracy: if you keep committing the organization before the underlying work is validated, people will stop trusting your calls and will spend their energy protecting the business from your decisions. The good news is that you already have the raw skill you need: when you slow down enough to ask the specific decision-driving question or summarize the true interim state, you become much more effective. Your next step is to treat unresolved constraints as part of the decision, not as something to clean up after it.
What You Did Well
When you did pause to isolate the real question, the conversation got more useful.
Your best moments were the ones where you narrowed the issue instead of forcing a conclusion. Asking what Covington specifically needed turned a broad complaint into a concrete decision requirement, and near the end your recap of what was and was not decided was one of the clearest parts of the meeting. That is an important strength to build on: you can create structure once you stop trying to rescue the room with speed.
What You Did Well
Jordan
“Okay, so we need another meeting on onboarding.”
Casey
“We needed this meeting to cover onboarding. That's why it was on the list. But we spent half the meeting on Vantage.”
Jordan
“That's fair. Okay. So let me just, um, let me try to figure out where we are. Pricing is tiered but the specific numbers aren't locked. Sam and Dana are going to meet separately on that. Enterprise custom deals need a framework, which needs business parameters from me, which Morgan needs to draft the addendum. Launch date is April 7th. Data export is a fast-follow but we don't have a date yet. Onboarding is TBD. Is that — does that cover it?”
Key Coaching Themes
You kept trying to create momentum by declaring decisions before the underlying constraints were settled.
This showed up repeatedly. You said the pricing numbers were final while sales was still objecting on competitive grounds, and later you set a fast-follow date for data export after product had explicitly said the work was not yet planned. The pattern from your last review is still here, but in this meeting it went a step further: you were not only moving past objections, you were making commitments on top of unresolved facts.
What worked and what was missing
The risk is not just that people feel steamrolled. It is that the meeting starts producing decisions nobody can actually execute or stand behind. When an expert tells you a date, threshold, or commitment is not yet supportable, your job is to slow the close long enough to name the open variable and decide what can honestly be decided now.
For example, in this meeting you said
Jordan
“They're final.”
Dana
“They're not final. I haven't agreed to them.”
Jordan
“I thought we said Sam leads and Dana weighs in.”
Dana
“Weighs in means I have input. I'm giving you my input right now — $499 is too high against Vantage.”
Next time, try something like
“We're not ready to call these numbers final. What I do hear is that we want tiered pricing and that the base price is still unresolved between margin logic and competitive pressure. Let's pin down what data we need to settle that today, and decide who owns the final call by tomorrow.”
The meeting lost authority at the start because you opened too loosely for the stakes of the decisions in front of the group.
You began with 'I don't have a formal agenda' and 'let's just kind of see where we are' even though pricing, launch readiness, and onboarding all needed concrete decisions. That loose opening mattered later: people kept having to tell you what the meeting was actually for, and you ended up triaging time in the room instead of leading it.
What worked and what was missing
For a meeting this late in the cycle, the room needed a decision map up front: what must be decided, what input each decision depends on, and what would be deferred. Without that frame, every unresolved dependency came back as friction later.
For example, in this meeting you said
“Hey everyone, thanks for squeezing this in. I know everyone's busy. So there's a bunch of stuff going on with the launch and I figured we should get together and just sync up. I don't have a formal agenda but there's pricing, and I think some engineering stuff, and probably some other things too. Let's just kind of see where we are. Who wants to kick us off?”
Next time, try something like
“We have thirty minutes and three decisions to make: pricing thresholds, whether April 7 is still a real launch date, and the onboarding model. If we can't fully close one, we'll leave with a named owner, missing input, and decision deadline. Let's start with pricing because config needs the thresholds by Friday.”
Detailed Feedback
Task Effectiveness
Meeting Structure & Direction
Decisions & Accountability
Communication Quality
Relational Effectiveness
Receptive / Responsive
Proactive / Generative
Experiment
Name the unresolved variable before you close
EXP-260803
What to do
In your next meeting, any time you feel yourself about to declare a decision, pause and first name the one fact, dependency, or owner that is still unresolved. Then decide only what is actually supportable now. If the missing piece matters to the final call, say that explicitly instead of pushing through it.
Success looks like
You can point to at least three moments where you said some version of 'what's decided is X; what's still open is Y; owner/date is Z' before closing or deferring an issue.
And then it tracks the change
Myc sets a baseline from your first meetings and plots each behavior over time, so a focus area becomes a line you can watch move across meetings.