Meeting issue notes
We need to share and empathize about things we're all thinking and feeling but haven't said out loud.
The gap between what people actually think and what they say can make conversation hard.
Rather than surfacing problems and preparing alternatives, the review seemed to prioritize judging whether the right person was in place for an unsatisfying result.
Before
- Less about planning, more focused on visualizing the CTO's ideas.
- Because further opinions had to be separately visualized to be judged, the hurdle to actually implementing anything went up.
- Even though we were working together, when problems came up we didn't dig into causes or reflect on the issue — we just exposed our dissatisfaction with the result. Going forward, we need a clearer GOAL for what we want to improve.
- Handling complaints about the difficulty of the work by adjusting the schedule can only lead to a relatively weaker result.
- Minimizing debate can also end up blocking expression of opinion. Arguments and disagreements aren't always a bad thing.
- At a reasonable level, we need alignment between what we think and what we say.
- We need a clear heads-up on the meeting overview and roles in advance, plus a shared understanding of the meeting style.
ING
Main points of discussion and purpose — not aligned:
- A prototype for the agreed plan (page structure per case / for completion?) — almost wrapped up. Making the service, demoing, UI/UX validity check? First load every detailed feature, and trim later — too crowded and complex? — which we took as a lack of planning and UX,
- VS the people giving feedback understood it as a review of the service plan (grasping service scope, role, and base components / for understanding?) — first, various features and visualizations, then regroup, then organize the service MVP.
After
- The discussion ran in a form where opinion-sharing wasn't clear.
- We need to coordinate on selective adoption when gathering further opinions.
- We need time to internally sort out opinions after evaluating whether other opinions need revising, what the improvements should be, and how valid they are.
- The CTO and COO differ on problem-solving and approach:
- COO — establish IA and process → UI design → design — simplify unnecessary tech and tech-for-showing-off, start from a differentiated service (BM) (… targeted attack)
- CTO — first visualize, gather opinions, then adjust — but during the meeting itself it's unclear.
- Given how strong the COO's influence on feedback and desire to participate are, we need process improvements so that involvement and feedback happen earlier in planning, with the focus on improving rather than evaluating.
