Choosing a problem-solving method and evaluating a meeting

A school transport app team sees that 40% of parents abandon the subscription form. The manager proposes a two-hour meeting for everyone. Before inviting twenty people, ask what information is missing. If the team does not know where users leave, it needs usage-path data or direct observation first. If abandonment happens at the address field but the reason is unknown, short interviews or a facilitated focus group can reveal how people read it. If several causes emerge, a brainstorming session can generate alternatives after the evidence is shared, followed by comparison against explicit criteria. Choosing the method precedes booking the room.

A focus group brings a small set of people from the intended audience together to discuss experiences and perceptions with a facilitator. It can reveal wording, objections, and interaction between views, but its participants are not a statistical sample proving that all parents think alike. Ask for concrete examples such as “What did you think ‘home address’ meant here?” rather than leading with “Isn't the form clear?” If a subject is sensitive or participants may hesitate in front of others, individual interviews may work better. Balance representation and privacy against time; convenient employees are not automatically proxies for customers.

A short daily standup coordinates work already in progress: what changed, what comes next, and which blocker needs follow-up. It is rarely the place for a full diagnosis of a complex problem with the whole team or a long report to a manager. If a developer says address validation is broken, record who will follow up and meet relevant specialists after the standup. Do not occupy every team member with an API diagnosis outside their work. If design and support blockers interact, arrange a separate working session with those groups.

Brainstorming separates option generation from option evaluation. Frame the problem precisely: “Increase completion without removing information needed for safe pickup,” rather than “make the interface better.” Let initial alternatives surface without immediate dismissal, then group and test them against facts and constraints. Ideas may include explaining why the address is needed, deferring some data until eligibility is confirmed, or offering a map selector. Do not pick an option solely because it is popular in the room. Its privacy, usability, and cost effects need review. A small trial may be better than a service-wide change.

Evaluate a meeting through observable output, not whether attendees called it “productive.” Were the necessary decision makers and experts present? Was the problem and its data available beforehand? Was a user view represented? Did decisions or testable hypotheses leave with owners and dates? Did the decision need a meeting at all, or would written comments have worked? For the form, a useful result could be two competing hypotheses and a small test: one version explains the address purpose and another simplifies entry, with completion rates and complaint counts for each. Even without a final solution, the meeting can succeed by reducing uncertainty and naming the next test.

When people disagree about a problem, design a sequence of questions rather than one huge meeting. “Forty percent abandon the form” describes behavior; “the address field is confusing” is an explanation to test. Consider at least two alternatives: people may not know which address is wanted, postal-code validation may fail, or they may be reluctant to share a location. Error logs reveal validation failure, observation reveals hesitation, and interviews may expose privacy concerns. Calling the design the cause before comparing alternatives turns the method into confirmation of a preference.

Match methods to questions. “How often does validation fail?” needs logs with a rule distinguishing unique attempts from retries. “How do people interpret wording?” needs observation or interviews. “Which alternative performs better?” needs a comparison with a declared success measure. If 120 errors in 500 visits came from only 30 users retrying, they are not 120 different customers. Distinguish sessions, people, and error events. If identity cannot be collected for privacy reasons, state that the count is at session level and avoid person-level conclusions.

In a focus group, begin with an open account of experience, then show a specific prototype. Give each participant room before a manager responds. Record what people actually said and tried, separating observation from facilitator interpretation. Afterward group themes and identify what was observed and what remains hypothetical. The group does not vote on a technical policy in place of its owner. A useful decision meeting records fact, alternative explanation, test or decision, and owner/date. For example: “Stopping at address was observed; ambiguity and validation are competing causes; compare failure logs with a wording trial; Sara reviews on 12 May.” The trail helps if the first fix fails.