Knowing the frameworks and using them with a deadline running are two separate abilities, and only the second gets tested at work. Choosing which idea deserves an experiment, or which interview quote to trust, is a skill, and skills come from repetition.
That is why you can finish every product course and still freeze when a messy problem lands on your desk. Craft lives in the doing, and the doing is what almost no curriculum rehearses.
Product craft breaks under pressure because nobody rehearsed it
The freeze has a specific shape. A learner can explain prioritisation or research frameworks on a whiteboard. Then a messy customer problem has to become a decision, and they stall. What is missing is practice under pressure: patchy evidence, stakeholders who want different things, a fixed budget and a team waiting for direction.
Consider how anyone learns an instrument. The training runs on drills, slow repetition, repertoire, listening, correction, and performance. A guitarist does not become fluent by memorising scale diagrams; they have to make a sound at a given moment and hear whether it worked. Product education tends to do the opposite: transfer the information, then expect fluency to appear in a capstone or a first job.
What that produces is fragile confidence. Learners know the tool names but cannot spot thin interview evidence, an assumption buried in a brief, or a roadmap that is really a pile of requests dressed as strategy. Judgment of that kind comes from repeated decisions with clear feedback; hearing the vocabulary more often does not build it.
None of this makes product work mechanical. Musicianship carries interpretation, culture, collaboration, and taste, and so does product practice. The analogy's use here is structural: it teaches motions, creates safe repetition, assesses the work a person actually produced, and returns feedback while that feedback can still change the next attempt.
Drills and repertoire do different jobs
Music students keep exercises and songs apart. Scales build coordination and ear awareness; repertoire tests whether those hold up under tempo, phrasing, memory, and performance. Product training often fuses the two into a single brief, "Create a product strategy for a new app", which is like asking a beginner pianist to perform a whole piece before they can coordinate both hands.
A drill removes enough variables to expose one craft problem at a time. In product work, a drill might look like this:
- Rewrite a feature request as a user problem you can test, without jumping to a solution.
- Take three interview excerpts and mark each line as observation, interpretation, assumption or open question.
- Rank five opportunities against a stated business limit and defend the trade-offs in 150 words.
- Turn a vague drop in a metric into two possible explanations, plus the evidence that would tell them apart.
- Write acceptance criteria for one user flow, including an edge case that could change the result.
Each drill can be repeated and revised after a targeted note. That is what brings the recurring mistakes to the surface: jumping to solutions, treating every quote as typical, or writing goals that sound strategic but cannot guide a decision. These are technique problems. They are easiest to fix before a team project buries them.
The arithmetic of repetition is the whole argument. A capstone gives a learner one graded strategic decision per course. Three 20-minute drills a week for six weeks give eighteen, each with a note and a chance to try again. The interview drill is the easiest to score. Compliments and hypotheticals do not count as evidence, while past behaviour and money already spent do (the rule Rob Fitzpatrick sets out in The Mom Test), so a reviewer can mark every line of a real transcript against that single rule and hand it back the same day.
Instrument learners need a few basics in place before technique pays off. The guitar has to be in tune, because a guitar that drifts punishes correct fingers with wrong notes. The cable has to work, the posture has to be comfortable, and the setup has to behave the same way twice. A guide to the equipment and setup side of learning an instrument shows how much avoidable friction can stall progress. Product learners have their own basics: clear briefs, evidence they can actually get to, decision criteria and finished examples to study. A blank document and an instruction to "be strategic" is the product version of an untuned guitar.
Repertoire is where the separate skills have to work together. For a guitarist, that is a song with a hard chord change, a loud chorus and a solo inside a band arrangement. For a product learner, it might be improving an existing service, recovering a failed launch or writing a discovery brief on top of patchy research. The project should demand exactly the choices the drills rehearsed. Someone who practised separating observation from assumption should now do it while setting feature direction. Someone who drilled ranking opportunities should be able to explain why a requested feature missed the first release. The uncertainty does not go away. The learner simply has practised ways to work through it without passing off a guess as a fact.
Programmes work best when they alternate the two. Technique without projects goes sterile; projects without technique quietly reward whoever already has experience, polished language, or meeting confidence. Moving between them gives beginners a way into competence and gives experienced practitioners a way to repair the specific weak link in their process.
What slow practice makes visible
Musicians slow down a hard passage because speed hides the error. A guitarist might lose time at one string crossing in a fast run; drop the tempo and the fault becomes audible. Slowing down exposes the exact movement or decision that needs repair.
Product teams move through dashboards, tickets, and planning meetings and call the motion progress. But pace hides how a conclusion was formed. Was the metric chosen because it reflects customer value, or because it is easy to report? Did the interview change the plan, or just supply a quote that supported it? Did the prototype test comprehension, real demand, or visual preference?
Training can build slow practice into the decision points. Instead of grading a roadmap alone, ask for a decision log: the options, the evidence, the assumptions still unresolved, and the reason an attractive alternative was rejected. Instead of rewarding a polished research readout, look at the moment raw notes turned into insight. Instead of critiquing only the final prototype, ask why one interaction beat two other workable ones.
This shifts how mistakes get read. A poor outcome can follow a sensible process and bad luck; a good one can follow weak reasoning and a favourable market. Judging the process rather than the hindsight teaches learners to separate confidence from evidence as the scope of their decisions grows.
Feedback helps only when a second attempt follows within days
A musician gets feedback instantly: a note buzzes, the rhythm drifts, a chord rings clean. Teachers, recordings, bandmates, and a metronome pile on more. Product feedback is slower: a feature can take weeks to build, and adoption data may not land until the people who made the decision have moved on.
Courses cannot abolish that lag, but they can shrink the gap between attempt and correction. A learner can have a problem statement critiqued within a day, compare their synthesis against an annotated exemplar, or test a prototype with peers before the final review. What matters is that the feedback changes the next attempt. "Think more strategically" points nowhere; "Your recommendation rests on two quotes from the same user segment. Find the evidence that would challenge it" hands over a next move.
Products that teach instruments run into the same problem: they have to make progress visible without pretending it is linear. A teardown of European music-education platforms shows how lesson sequencing, practice prompts, and dropout points shape what a learner actually absorbs. Product programmes should look at their own dropout points too: theory-heavy modules, feedback that only arrives once a project is over, assignments too open for beginners and too predictable for practitioners.
Feedback does the most when it sits close to the performance, ties to a clear criterion, and is followed by another attempt. Peer critique earns its place when participants name evidence, trade-offs, and consequences instead of applauding by taste. And an instructor still matters while judgment is forming, because a learner may not yet hear the difference between a crisp product problem and a feature request wearing different clothes.
Teams can borrow a weekly cadence from Teresa Torres's continuous discovery, where the people building a product talk to customers every week. Applied to training, the same rhythm means a learner never waits more than seven days between an attempt and the evidence that grades it.
Assess what people do with the terms they know
Product education often rewards fluent terms ("jobs to be done," "north-star metric," "MVP") arranged neatly in a slide deck. Shared language does speed up collaboration and pattern recognition, but it proves nothing about whether a person can frame a decision, interview a user, write a brief someone can act on, or change course when the evidence undercuts an appealing story.
Music makes the distinction cleanly: a student can name a cadence on paper, yet performance shows whether they can hear it, place it in time, and actually use it. Product assessment needs the same split between declarative knowledge and demonstrated capability.
A useful rubric reads capability along four lines:
- Problem framing asks whether the learner keeps user need, business constraint, and proposed solution distinct rather than blurring them.
- Evidence handling asks whether they trace a claim back to relevant evidence and say plainly what uncertainty remains.
- Decision quality asks whether they weigh alternatives, name the trade-offs, and pick a path that fits the brief.
- Communication under constraint asks whether another person can tell what happens next, why it matters, and what would change the decision.
To make the rubric usable in a 20-minute review, score each line 0, 1 or 2:
- 0: missing or confused (solution written as the problem, quote presented as proof);
- 1: present but thin (one source, alternatives named but not weighed);
- 2: clear and checkable (the reviewer could act on it without asking a question).
Eight is the maximum. A working threshold for moving from drills to a project is 6 of 8 on two consecutive attempts, with no line at 0. The threshold is illustrative; what matters is that it is written down before the work is marked.
None of these can be answered by self-description; each needs artefacts: interview notes, a marked-up opportunity map, an experiment brief, a prototype rationale, a plan revised after critique. Revision is the most revealing of all, because part of the craft is improving an idea without treating feedback as a threat to status.
This also makes for better portfolios. Immaculate final screens can hide weak discovery or borrowed reasoning; a stronger portfolio shows the initial framing, the evidence, the options that were dropped, the decision points, and a short reflection on what changed, which makes the work legible to employers and to other learners.
The analogy has limits
Product work is not an instrument, and pushing the comparison too literally produces shallow training. Music technique often rests on stable physical standards: a note is in tune or it is not, a beat is early or late. Product decisions sit inside markets, organisations, power structures, technical dependencies, and customer lives, where two thoughtful teams can read the same evidence and both make defensible, different calls.
The unit of performance differs too. A musician can practise alone for hours; a product outcome emerges through design, engineering, research, operations, leadership, legal review, customer support, and commercial pressure. Training that turns product managers into solo virtuosos misses alignment, facilitation, written communication, and the negotiation of ownership.
Music education can also prize flawless execution over voice, culture, and improvisation. Product education should not manufacture framework operators who cannot feel when a customer story, a team dynamic, or a local context calls for a different approach. The structure transfers even where the content does not: isolate a skill when that helps, return it to a project that matters, shorten feedback where you can, assess visible work, and protect judgment in the places a drill can never settle.
Six weeks, one skill a week, eighteen graded attempts
A product programme can run through three stages: foundation, fluency, expression. Foundation covers problem framing, evidence quality, prioritisation, experimentation, and clear writing. Fluency repeats those in varied situations until the patterns register without prompting. Expression hands over richer projects shaped by context, collaboration, and taste.
A six-week module gives the idea a concrete shape, one focused skill per week that the next week builds on:
- Open by diagnosing flawed problem statements and rewriting them against a fixed evidence pack.
- Move to short research-synthesis drills using contrasting interview excerpts.
- Prioritise opportunities under different constraints and compare the decisions those constraints produce.
- Build a small experiment plan and take criterion-based critique before testing.
- Apply everything to a product case carrying incomplete information and real stakeholder tension.
- Close by presenting the decision trail, revising after review, and naming the technique that still needs work.
Cadence matters more than the calendar. Learners need repeated attempts at the same skill more than a parade of new concepts, and instructors need enough visibility to tell whether a weak final project came from poor research, fuzzy framing, indecisive prioritisation, or an inability to communicate the choice, because each of those is a different teaching problem.
The same pattern works inside a team. A product leader can swap a generic lunch-and-learn for a 20-minute decision drill, review one experiment brief before launch, and build a library of anonymised past decisions with their contemporaneous evidence and later outcomes. Critique then works as rehearsal, and the loudest opinion in the room stops deciding the outcome.
The practical unit is one recurring decision that learners or teams handle badly. Break it into a 20-minute drill. Define what good execution looks like before anyone begins, return feedback in time to revise, then set the same skill inside a project with recognisable stakes and real ambiguity.
Musicians do not practise scales in order to become people who play scales; they practise so their hands and ears can serve a song. Product training earns its keep the same way: through habits that keep better judgment available for the moment the work turns messy.