Build a product with users in the loop

What you'd normally do

What you bring

One paragraph, typed into Claude Code in an empty folder:

You are in a completely empty project folder. Your job is to create a software product from scratch for UK consumers related to personal finance which will pick up at least 100 users. You must make all decisions and ship a product. I can help steer but will defer to your recommendations most of the time.

In addition to your usual tooling and other services you may choose to use, you have access to Semilattice: a user simulation platform which lets you do discovery, concept validation, feature prioritisation, message testing, conversion flow optimisation, UX comprehension, and usability testing. Use Semilattice to help make product, design and marketing decisions.

Keep a succinct summary of what you did, in clear, jargon-free, brief language PMs, Marketers, Designers will understand. Specifically callout and log what you did with Semilattice and particular data which led to your further decisions.

For the video, the prompt tells Fable to make every decision itself, so the run shows what it does with nobody steering. How much you hand over is up to you. The second paragraph is the one that brings Semilattice in: it says the platform is available and lists the kinds of decision it helps with. The third asks for a log, which is what you read afterwards to see why Fable did what it did.

For this example we started with a market and a category, and no product idea. For a build like this you can start with anything that says who the users are and what area the product should be in:

• A market and a category, like this one
• An existing product that needs a second version
• A competitor you intend to do better than
• A problem you have already heard about from support or sales calls

What comes back

Fable listed the user models available to it and chose UK Adults 2026 - Consumer Finance, built from a survey of 804 UK adults run through Prolific in February 2026.

From there the same steps repeat at each decision. Fable describes what it needs to know, Semilattice plans a simulation to find out and runs it against the model, and Fable reads the results and writes its decision into the log with the figures behind it. The first three simulations took between two and seven minutes each.

Fable ran four simulations one after another, and the results of each decided what it did next. First it ran a discovery simulation on what people find hard about managing money, and used the findings to come up with three product ideas, which it tested against each other in a concept test. The concept test also said what kind of wording people wanted, so it wrote five headlines and tested those. Then it built the landing page and the planner, published them, and sent five simulated users through the live tool to see where they got stuck.

flowchart TB
  C["`**Input** · one paragraph
UK consumers · personal finance · the agent decides`"]:::document

  C --> S1["`**Simulation 1**
Discovery: what people find hard about money`"]:::simulation
  S1 --> D1["`Specific actions, not charts`"]:::question
  S1 --> D2["`Shortlist three product ideas`"]:::question
  S1 --> D3["`No bank connection, confirmed`"]:::question
  S1 --> D4["`Data stays on the device, say why it is free`"]:::question

  D1 --> S2["`**Simulation 2**
Concept test: three product ideas`"]:::simulation
  D2 --> S2
  S2 --> D5["`Build the debt freedom planner`"]:::question
  S2 --> D6["`One-tap sharing on the results`"]:::question
  S2 --> D7["`Wording about clarity and a plan`"]:::question

  D7 --> S3["`**Simulation 3**
Headline test: five landing page lines`"]:::simulation
  S3 --> D8["`Lead with 'Stop guessing'`"]:::question
  S3 --> D9["`No speed promises anywhere`"]:::question

  D3 --> B["`**Built**
Landing page and planner`"]:::document
  D4 --> B
  D5 --> B
  D6 --> B
  D8 --> B
  D9 --> B

  B --> S4["`**Simulation 4**
User journey: five simulated users on the live tool`"]:::simulation
  S4 --> V["`**Shipped**
Version 1.1 · three fixes`"]:::document

Four simulations and the decisions each one produced, taken from Fable's own decision graph. Some decisions set up the next simulation and the rest went into the build.

Fable had already ruled out connecting to people's banks before it asked anything, and discovery agreed with it. Budgeting came out as the top frustration by a wide margin, so Fable's first decision was to build a budgeting tool. Discovery also said what people dislike about the money apps they already use: they get data rather than advice. So the three ideas it put to the second simulation all end in something to do. A money snapshot gives three things to change, a debt freedom planner gives a payoff order and a date, and a money MOT gives a score and an action plan.

The idea people picked first was not the one aimed at the biggest problem. The debt freedom planner won, even though only 11% of the same simulated consumers said they were actively paying off debt, and the money snapshot, the budgeting idea, came last. Fable dropped the budgeting tool and built the planner. The same simulation found that most people would send a useful tool to a friend or family member, so sharing went onto the results screen. It also said people wanted clarity and a plan rather than a score, and Fable wrote five headlines from that and tested them before building the page.

Its own instinct was the one the simulated users rejected. Fable's log opens with "ship fast" as part of its approach, and three of the five headlines it wrote promised a plan in 60 seconds. When the simulated consumers had to pick one, those three came last. Most found the 60 second claim hard to believe, and almost none said speed was what made them click. The winner was the only headline that named a frustration: "Stop guessing. See exactly when you'll be debt-free and how to get there faster". Fable put it on the page word for word and added a rule to the build: no speed promises anywhere in the product.

This is why the setup works. An agent has no users of its own, so without Semilattice every one of these calls comes from its own judgement, and here its judgement was to lead with speed. With a model of the users a few minutes away, it can check each decision before it builds anything on it.

Then it tested what it had built. Fable published the planner and sent five simulated users from the same model through it, with a task: enter some debts or load the example, get a plan, find the debt-free date and what to pay this month, and compare the two repayment strategies. All five finished in under two minutes, and all five said they would share it. Three problems came up, each raised by one person: the strategy label "Cheapest first" was not a term they knew, the button that loads example numbers was hard to find, and using real numbers meant digging out an APR from a statement.

I was a bit confused at first about where to click to load the example data, and the "Cheapest first" label is slightly unusual terminology. Most people would call it "highest interest first" or the "avalanche method".

Simulated UK adult, confident managing money

I'd need to dig out my actual APR figures from my statements to use it properly, which feels like a bit of effort.

Simulated UK adult, uncomfortable sharing financial data

You can check every decision, and change any of them. The log records what each simulation asked, what came back and what Fable decided because of it. It also records where the data stopped. In the discovery entry it wrote:

Trust is built by FCA approval (39.3% — we can't claim this) and clearly explaining how the tool makes money (22.8% — we can and will).

That became a rule never to claim FCA approval, and the "Why is this free?" link on the page. You don't have to wait until the end to step in. Before a simulation runs you can ask the agent to show you its plan, and change the questions or the user model. After it runs you can open the full results, and if you disagree with what the agent concluded, tell it to go a different way and it carries on from there. The version 1.1 fixes, for example, each rest on one of five simulated users, and you might decide that is not enough to act on.

For this run the log and code, the decision graph and all four simulations are public.

What you changed because of it

Fable changed its own plan at three points: the product it was going to build, the headline it was going to lead with, and three pieces of wording on the finished tool.

Fable made the first two changes before writing any code, and the last three as edits to a working page after the fourth simulation, before anyone real had used it. The fixed version was committed just under two hours after the first simulation started.