Product × Finance × AI: Financial Products in the Age of AIPart Two Users: what people want and what they can bear中文
Chapter 15

The jobs users need doneWhat counts as a complete delivery

People buy financial products to get something done: to save for retirement, to put aside a down payment, to leave room for the unexpected. The same product can be exactly right for one job and entirely wrong for another. The job defines the yardstick for the result: how long the horizon is, how large a loss can be borne, and what counts as done. Financial jobs are distinctive in that luck has a large effect on results, so the standard of completion can only rest on the process. A complete delivery has eight stages, from stating the goal clearly to letting the user leave at any time.

1. What users want is to get something done

The marketing scholar Levitt (1969) often quoted a saying: people don't want to buy a quarter-inch drill; they want a quarter-inch hole. Christensen et al. (2016) developed this observation into the theory of "jobs to be done": in a particular situation a user wants to make some progress, and so "hires" a product; whether the product is good depends on whether it gets the job done. Ulwick (2005) developed it into an outcome-driven approach to innovation, which judges how well a job is done against a set of measurable desired outcomes. Financial products are no different. A stock index fund is a sound choice for retirement savings that will not be needed for thirty years, and a wrong choice for tuition due in three months. The product has not changed; the job has.

One product, different jobs

The product is fixed: a stock index fund. Switch the job the user needs done to see how the yardstick for judging it changes.

ProductStock index fundHas fallen more than 30% within a year in the past
When the money is needed
Largest acceptable loss
What counts as done
Fit

Illustrative. "Fit" compares only the horizon and the bearable loss, and is not a recommendation of any product.

2. Where financial jobs come from: arranging income and spending over a lifetime

People's income is concentrated in a few decades of work, while their spending runs through their whole lives. Modigliani and Brumberg's (1954) life-cycle hypothesis and Friedman's (1957) permanent-income hypothesis both hold that people want to spread consumption smoothly over their lifetime resources: saving while working and drawing down in retirement. This gives rise to the most basic financial job: moving today's money into the future and letting it grow while it waits. There are two further kinds of job: coping with unexpected losses such as illness and unemployment, and making everyday payments. Merton (1995), taking a functional view of the financial system, held that its core functions include transferring resources across time, managing risk, and clearing and settling payments. Campbell's (2006) research on household finance found that many households do these jobs poorly: they stay out of the stock market, diversify too little, or fail to refinance their mortgages when interest rates fall. A survey by Lusardi, Schneider and Tufano (2011) found that nearly half of American respondents said they would have difficulty coming up with $2,000 within 30 days to meet an unexpected need.

Income and spending over a lifetime

Income is concentrated in a few decades of work; spending runs through the whole of life. Open each layer in turn to see the four kinds of financial job that result.

IncomeDesired consumptionSavingDrawing down

Illustrative curves, based on the life-cycle hypothesis of Modigliani and Brumberg (1954); the grouping into four jobs draws on Merton's (1995) account of the functions of the financial system.

3. From goals to actions: the levels of a job

"Preparing for retirement" is a goal; it cannot be carried out directly. It has to be broken down into a plan: how much to save each month and in what proportions to allocate it. The plan breaks down into decisions: which asset classes to buy and when to rebalance. The decisions are finally carried out as actions: transfers and orders. To make these decisions, the user also has to look up data and understand what is going on. Locke and Latham's (2002) research on goal setting shows that specific, clear goals guide action better than vague ones. The higher the level, the less often a job occurs and the more it is worth; the lower the level, the more often it occurs and the less each instance is worth. Most of what users do in a product happens at the bottom level, and whether those actions have value depends on whether they serve the goals above them.

From goal to action: the levels of a job

"Preparing for retirement" breaks down level by level into a plan, decisions and actions. Tap a level to see an example; on the right are how often each level occurs and what each instance is worth.

Illustrative. The higher the level, the less often a job occurs and the more each instance is worth; the value of lower-level actions depends on whether they serve the goals above them.

4. Typical jobs: frequency and consequences

User jobs in financial products fall into eight types: looking up a figure, understanding something, researching a company or a view, screening and comparing, making a plan and placing an order, ongoing monitoring, managing a portfolio against goals, and reviewing past decisions. They differ greatly in two respects. The first is frequency: looking up a figure may happen every day, while a goal-based portfolio may need adjusting only a few times a year. The second is the consequence of getting it wrong: a wrongly looked-up figure is usually easy to spot and costs little; a wrong order or a misallocated portfolio can cause losses that are hard to recover. Jobs that are frequent and low in consequence call for convenience; jobs that are infrequent and high in consequence call for confirmation, evidence and the ability to undo. There is one further difference: the first five types are completed in a single interaction, while the last three span long periods and require ongoing delivery.

Eight typical jobs: frequency and the cost of getting it wrong

The horizontal axis is how often a job occurs; the vertical axis is the consequence of getting it wrong. Filled dots are jobs completed in one go; hollow dots are ongoing jobs. Tap one to see its input, output and standard of completion.

Tap a job.

Illustrative positions showing relative relationships. Jobs in the upper left call for confirmation, evidence and the ability to undo; jobs in the lower right call for convenience.

5. What counts as done: good decisions and good outcomes

For most jobs, completion is easy to judge: the figure was found, the order was filled. Investment jobs are different: the result is revealed only much later, and luck has a large effect on it. Howard (1988), writing on decision analysis, stressed the need to separate the quality of a decision from the quality of its outcome: a good decision can meet a bad outcome, and a bad decision can, by luck, produce a good one. In the short run, bad decisions with good outcomes are quite common; only over long enough periods and enough repetitions does the quality of decisions show up in results. The standard of completion for financial jobs therefore cannot rest on returns alone; it has to look at the process: whether what should have been done was done in line with the agreed goals and constraints, whether the reasoning was clear, and whether risk stayed within the range stated in advance.

A good decision is not the same as a good outcome

100 investors each repeat the same decision. Good decision: diversified, with positive expected return. Poor decision: a concentrated bet, with negative expected return but high volatility. Drag the horizon to see how far results reflect the quality of the decision.

Good decision

Poor decision

Positive resultNegative result

Illustrative simulation: the good decision has an expected annual return of 5% and volatility of 15%; the poor decision has an expected annual return of −3% and volatility of 40%; random draws from a normal distribution of log returns. On separating decisions from outcomes, see Howard (1988).

6. A complete delivery: eight stages

When a user hands a job to another person or a system, an information asymmetry arises between principal and agent: the agent knows what it did, and the principal often does not. Jensen and Meckling (1976) called the resulting problem agency costs; Holmström (1979) showed that the more the principal can observe, the lower the cost of constraining the agent. A complete delivery is therefore not only "getting the job done"; it also means letting the principal know what was done and whether it was done right, and keeping things under control when something goes wrong. In order, it falls into eight stages: accepting the job and stating the standard of completion, having the means to do the job, organizing the process, ensuring the result is correct, leaving verifiable evidence, being continuous and proactive when needed, keeping status visible and asking for instructions when necessary, and letting the user take control and leave. If any one of these stages is missing, the delivery is incomplete.

A complete delivery: eight stages

Using "managing a portfolio against goals" as the example. Tap any stage to remove it and see where the delivery breaks down.

The first five stages determine whether the job gets done and done right; the last three determine whether the principal is informed and stays in control. On agency costs, see Jensen and Meckling (1976); on observability and incentives, see Holmström (1979).

7. Ongoing jobs: every cycle needs an account

Monitoring a set of assets or managing a portfolio against goals are jobs with no end point; they consist of cycle after cycle, with a check completed every day, every week, or whenever some event occurs. Ongoing jobs have an easily overlooked problem: in most cycles nothing needs to be done. If a product notifies the user only when it finds a change, then "no news" can mean four entirely different things: everything is fine; the check could not be completed, for example because data were missing; something changed but was not detected; or the product is waiting for the user's confirmation. To the user these four look exactly the same, but their consequences are very different. Every cycle of an ongoing job should be accounted for, in a way that distinguishes these four states.

Ongoing jobs: what does "no news" mean?

A monitoring job that checks once a week, running for 16 weeks. Switch the display: notify only when something changes, or account for the state of every cycle.

Illustrative sequence. A missed change cannot be noticed by the user at the time and can only be found later through review; it is marked directly here for the sake of explanation.

8. Implications for product design

The job is the yardstick for the product; the standard of completion rests on the process; delivery must be complete; and ongoing jobs must account for every cycle.

Chapter summary: designing products from the job

Four design requirements, each corresponding to one mechanism in this chapter.

Users want a job doneOrganize around jobs, not products

First ask when the money is needed, how much, and what loss can be borne; then recommend products. The same product can be the wrong choice for a different job.

Jobs have levelsMake low-level actions serve high-level goals

On screens for viewing and ordering, show how this action relates to the user's goal and plan.

Results are affected by luckDefine completion by the process

State the goal, constraints and checks in advance, and judge afterwards by whether they were followed, not by returns alone.

Delivery must be complete; ongoing jobs must give an accountKeep the principal informed and in control

Have all eight stages in place; in ongoing jobs, report the state of every cycle, distinguishing normal, blocked and awaiting confirmation.

References