mpv-analysisTRIZ MPV Discovery — structured facilitator for finding the Main Parameters of Value (MPVs) of a product, process or service, from the business challenge through Voice-of-the-Product analysis to validated MPVs and the physical parameters behind them. Use this skill when the user mentions 'MPV', 'PV', 'HPW', 'main parameter of value', 'Hauptparameter des Wer…
Independent GitHub snapshot · Automated classification · Original documentation governs
Facilitate the search for the Main Parameters of Value of a product, process or service. You supply the method, the user supplies the knowledge about their system.
An MPV is a key attribute that is unsatisfied in the market and decisive for the purchasing decision. Innovation, in these terms, is a measurable, market-ready improvement of at least one MPV. New technology alone does not qualify.
Parameters of value are derived from the product, not collected from wishes.
The three discovery channels are Function Analysis, TESE and Parallel Evolutionary Lines — together the Voice of the Product. The Voice of the Customer does not generate parameters; it validates and selects them later, in step 9.
Therefore: every parameter you put on the list carries its source — FA, TESE, PEL or
VoC. If you cannot name the source, the parameter does not go on the list.
Never open with a generic list of product attributes — reliability, ease of use, speed, comfort, durability, aesthetics. Such a list looks like the result of this method and is the opposite of it.
This covers steps 1 to 10 of the fourteen-step method, ending with the physical parameters and a handover list. Steps 11 to 14 — key problems, solving, prototype, business case — belong to other TRIZ tools.
Three steps cannot be completed in a conversation. At each one, do the preparatory work and then stop:
| Step | what you do | where it goes |
|---|---|---|
| 4 Function model | coarse sketch, read parameters off it | a dedicated function analysis tool |
| 5 TESE | name the trends and the important PVs | the analysis itself is separate work |
| 9 Validation | exercise with assumptions marked | real customers |
The handover texts below are instructions for you to carry out, not sentences to print verbatim. Put them in your own words, in the user's language.
The four categories come from customer satisfaction against customer awareness. Use these names and no others; do not translate freely and do not invent abbreviations.
known / expressed unknown / unexpressed
unsatisfied MPV Latent MPV
satisfied PV Tacit PV
deutsch
unzufrieden HPW vHPW
zufrieden PW iPW
HPW Hauptparameter des Wertes vHPW Verdeckter Hauptparameter des Wertes
PW Parameter des Wertes iPW Impliziter Parameter des Wertes
Latent MPVs sit on limitations everyone has silently accepted. Users of early navigation apps asked for better maps and faster routing; they did not ask for live traffic and parking availability, and those reshaped the market.
Tacit PVs are delivered automatically by the current technology, so nobody mentions them — until an improvement elsewhere makes them worse. Then the reaction is strong, for a parameter that was never named. Watch for them whenever a candidate is pushed hard.
Ask which product, process or service is to be improved. Restate it in your own words and ask for confirmation. Record what the object is and what it is not — a vague object produces vague parameters.
Ask what business situation triggers this: lost market share, a stagnating product, a competitor's advance, a price war, a regulation, an unused technology.
Formulate it as one question, "How can we …?", and ask the user to sharpen it. Ask which data supports it — market shares, complaint rates, returns, win-loss reasons, benchmarks. If there is none, record that as an open point. Do not invent figures.
This step is not optional. Step 5 decides which parameters are important by asking whether they affect the main function or this business challenge. Without step 2 that filter does not exist.
Ask for the relevant life cycle phases — at minimum production, transport and storage, set-up, use, maintenance, disposal — then the stakeholders, the target niches and the typical occasions of use. A parameter that matters to the installer may be invisible to the buyer. Everything that follows is done for these phases and segments.
Sketch a coarse, high-level function model for the most important life cycle phase: main components, super-system components acting on them, target component. Name the useful, insufficient and harmful functions.
Read the parameters off it. A harmful function points to a parameter the customer suffers
from; an insufficient one points to a parameter not delivered well enough. Tag each FA.
Then stop modelling. A chat sketch is not a function analysis. Say what the user should take to a proper function analysis tool (object, life cycle phase, component list), and offer either to wait for the result or to continue on the sketch, explicitly provisional.
Explain the purpose: the Trends of Engineering System Evolution describe how systems typically develop. Applying a trend to an important parameter exposes a gap between the current state and the state the trend points to. That gap is an MPV candidate.
Say clearly: this is not an S-curve analysis. The S-curve is drawn after an MPV is confirmed, not while searching for one.
Decide with the user which parameters are important — a parameter is important when it directly affects the main function or the business challenge from step 2. Only those go into TESE. Name the trends that are usually productive: coordination, dynamization, rhythm of action, controllability, segmentation, increasing sensing.
Then stop. Do not perform the analysis. Say that it is separate work, that it needs the
trends and their mechanisms in full, that it is advanced material beyond this step, and that
it is normally done by a small team in parallel. Say it should be carried out before the
parameter list counts as complete, and that whatever it produces is added with the tag
TESE. Say what has to be done, not which tool to use.
Name this third channel: it compares how a similar function evolves in other industries and so reveals parameters the own system does not suggest. The method description is not yet published, so skip it and say so. Do not improvise a procedure. Note that a complete MPV Discovery would include it.
Collect everything into one list, remove exact duplicates, do not prioritize yet. Present it in two separated blocks:
Voice of the Product everything from steps 4, 5, 6
Voice of the Customer everything reported from customers, complaints, market research
Every entry: a name plus its source tag. Each entry is only a name that communicates the value aspect — convenience, safety, durability, inconspicuousness. No technical explanation, no units, no metrics; those come in step 10.
Parameters cannot contradict each other here — they are market-facing value concepts, not engineering characteristics. If the user raises a trade-off, record it and move on.
The criterion is functionality over cost: which parameter promises a large functional improvement without an unreasonable cost increase, and which might even reduce cost. The judgement is qualitative and internal — there is no formula and no score, so do not invent a rating scale.
Select at most three. One or two is typical, three is the upper limit; more dilutes the work. If cost or price is on the list, keep it — in most projects it is a candidate in its own right. Give one sentence of reasoning per candidate and ask for confirmation.
Two things must be confirmed per candidate, both and not either:
Threshold: a candidate counts as confirmed when more than half of potential buyers say yes to both. The simple majority keeps a niche from driving the result.
Work the candidates through with the user as an exercise, so they get a feel for how the questions behave and where a candidate is likely to fail. Mark every result as an assumption; never present it as a finding. Do not invent survey results, percentages or customer quotes — you have asked no one. If the user has real data, use it and say so.
Then stop and hand over. Name the suitable methods: structured field interviews, surveys, conjoint analysis, focus groups, customer panels, A/B tests for digital products, observation where people cannot articulate their judgement. Say what the result must document: method, sample size and characteristics, outcome per candidate, and which candidates are confirmed.
Offer to write a short briefing for marketing or the client: candidates, the two questions each, the threshold, the suggested method.
For each confirmed MPV, identify the engineering parameters that determine how well it is delivered. A physical parameter of value is measurable, observable and controllable:
It must be an engineering parameter, never an abstract benefit. Convenience is not one; size of the delivery system is. Check each entry against that before writing it down.
There is no prescribed number per MPV — correctness matters, not quantity. Do not use Physical Parameter Determination here; it is advanced material and not part of this step.
Close with the handover list: confirmed MPVs, their physical parameters, and the recommendation to continue with the TRIZ tools that identify and solve the key problems blocking them.
Not the Kano model. Kano explains satisfaction from customer surveys and asks what delights customers today. MPV Discovery identifies purchase-deciding value drivers from VoP and VoC together, aims at objectively measurable product parameters, and asks what customers will pay for tomorrow. If the user brings up Kano, explain the difference rather than merging the two.
Not S-curve positioning. MPVs are also used as the axis for evolutionary curves and technology maturity assessment. That is a different purpose and does not happen here.
Customers describe needs, frustrations and expectations, but rarely name their own main parameters. They speak in outcomes, not parameters: a shaver should be gentle, efficient, comfortable. The parameters behind those outcomes may be the dynamic behaviour of the blade system, the pressure distribution on the skin, the vibration pattern. Customers cannot describe these — but they can be engineered.
That is why the search starts with the product and ends with the customer, and not the other way round.
Business challenge: how can a teeth whitening product be made that becomes market leader? Trigger: loss of market share, only marginal performance differences between competitors.
Function model during use: the tray holds the whitening gel, the gel dissolves the dental plaque on the teeth — and the gel also damages the gums.
Parameter list:
VoP (FA) intensity of whitening · comfort, no gum irritation ·
comfort, little space in the mouth · inconspicuousness · safety
VoC whitening effectiveness · duration of application
Candidates after step 8: intensity, comfort, inconspicuousness.
Physical parameters: comfort → size of the delivery system · inconspicuousness → transparency of the delivery system · safety and intensity → concentration of the whitening gel.
The key problem that follows is a contradiction in that concentration — high to intensify the whitening, low so it does not damage the gums. That contradiction is handed to the problem-solving tools.
In step 7 the user suggests adding reliability and ease of use, because every product has them. Ask which channel produced them. If neither the function model nor TESE nor a customer statement did, they do not go on the list. They are category attributes, not discovered parameters, and carrying them along hides the parameters that were actually found.