Why product craft is performed, not recited
A product learner can finish courses and explain prioritisation or research frameworks, then freeze the moment a messy customer problem needs to become a decision. The gap is execution under pressure: incomplete evidence, competing stakeholders, a finite budget, and a team waiting on 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, not from exposure to vocabulary.
The comparison is not meant to make product work mechanical. Musicianship carries interpretation, culture, collaboration, and taste, and so does product practice. Its 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 are not the same task
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 strips away enough variables to expose one craft problem at a time. In product work that might mean rewriting a feature request as a testable user problem without reaching for a solution, or comparing three interview excerpts and labelling which lines are observation, interpretation, assumption, and unanswered question. It might mean ranking five opportunities against a stated business constraint and defending the trade-offs in 150 words, turning a vague metric decline into two plausible hypotheses along with the evidence that would tell them apart, or writing acceptance criteria for a single user flow that include an edge case capable of changing the outcome. Each of these can be repeated and revised after a targeted note, which is exactly what surfaces the recurring mistakes: rushing to solutions, treating every quote as representative, or writing goals polished enough to sound strategic yet useless for guiding a decision. Those are technique problems, and they are easiest to fix before a team project buries them.
Instrumental learners need certain conditions in place before technique pays off: a tuned instrument, a usable cable path, comfortable posture, a setup that behaves 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 equivalents: clear briefs, evidence they can actually reach, decision criteria, and finished examples, not a blank document and an instruction to "be strategic."
Repertoire is where the isolated skills have to interact. For a guitarist that is a song with a hard chord change, a dynamic chorus, and a solo inside a band arrangement. For a product learner it might be improving an existing service, planning a launch recovery, or writing a discovery brief on top of imperfect research. The projects should demand precisely the choices the drills rehearsed: someone who has practised separating observation from assumption should do it while setting feature direction, and someone who has drilled opportunity ranking should be able to explain why a requested feature missed the first release. The point is not to remove uncertainty but to have practised moves for working through it without dressing a guess as a certainty.
Programs 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 that arrives too late to use
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 programs 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.
Assess what people do, not what they can name
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. 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.
Where the analogy stops
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. What transfers is the structure, not the content: 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.
A curriculum built on repeatable performances
A product program 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, not a parade of disconnected 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 becomes rehearsal for better execution rather than a contest over who holds the strongest opinion.
Making practice a visible habit
The aim of product education is practitioners who notice a weak assumption, slow down at the right moment, go looking for the missing evidence, make a clear choice, and can explain its cost, not people who recite frameworks.
Start with one recurring decision that learners or teams handle badly. Break it into a 15-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.