Product Prototyping - Mash-up

In Brief

A mash-up is a functional product experience assembled by combining existing third-party tools, platforms, and services — connected through APIs, automation platforms, or manual integrations — rather than building custom software from scratch. Unlike a clickable prototype (which simulates functionality), a mash-up actually works. Unlike a Wizard of Oz test (which hides a human behind the scenes) or a Concierge test (which delivers the service manually), a mash-up uses real technology to deliver real results. Customers can use it, pay for it, and receive genuine value.

The mash-up tests whether the full product experience holds together — from acquisition through delivery — with minimal custom development. If customers will pay for a mash-up version, they will pay for a properly built version. If they will not, no amount of custom engineering will fix the problem.

Description

A mash-up is one of the most underappreciated prototyping methods because it blurs the line between prototype and product. A well-constructed mash-up can serve dozens or even hundreds of real customers, generate real revenue, and operate for months — all without a single line of custom code. This makes it both a validation tool and a potential first version of the product.

The key insight behind a mash-up is that most product value comes from the orchestration of capabilities, not from the capabilities themselves. Payment processing, email delivery, form collection, database storage, scheduling, and file management are all commoditized. What is unique about your product is how these capabilities are combined to serve a specific customer need. A mash-up lets you test that orchestration directly.

How a Mash-up Differs from Related Methods

When to Use

A mash-up is most valuable when:

• You want to test the full product experience, not just a single feature or interaction.
• The product’s value comes from orchestrating existing capabilities in a new way.
• You want to generate real revenue and serve real customers before investing in custom development.
• You need to learn which parts of the experience require custom building and which can remain third-party.

How to

Prep AI Prompt

1. Map the customer journey. List every step from the customer’s first touch to final delivery of value. For each step, identify the capability needed: payment, content delivery, scheduling, communication, data storage, etc. Note which steps are unique to your product and which are pure commodity.
2. Select tools for each capability. For each capability, choose an existing tool or platform. Prefer tools with APIs or automation-platform integrations (Zapier, Make). Prefer tools with free tiers for initial testing. Note the seam between each pair — that is where the mash-up will leak.
3. Design the integrations. Map how data flows between tools. What triggers what? When a customer pays on Stripe, what happens next? When a form is submitted on Typeform, where does the data go? Draw this as a simple flowchart and review it for handoffs that depend on polling delays.
4. Define the willingness-to-pay test. Decide before you build whether the read is “did anyone pay?” or “did this conversion rate clear a threshold?” — and which threshold. Picking afterward is how teams rationalize disappointing results.
5. Set the operational budget. Decide how many hours per week you will spend monitoring and patching the mash-up. When you exceed it for two weeks running, that itself is a finding: the mash-up is telling you which component to rebuild custom first.

Analysis AI Prompt

1. Read willingness-to-pay first. Did customers pay, and at what conversion rate? Compare to the threshold you committed to in Prep. Surface-level satisfaction without a payment is the same outcome as a Wizard of Oz with high satisfaction and zero return visits — the magic was the human, not the value proposition.
2. Quantify the seam quality. For every handoff between tools, log the failure rate and the median manual-intervention time. The seams where customers visibly noticed the seam (delays, inconsistent emails, lost data) are the components that have to be custom-built first.
3. Cluster customer feedback by mash-up tell vs. value gap. “Why does it take 15 minutes to get my report?” is a tool limitation (Zapier polling). “I don’t understand why I would pay for this” is a value-proposition gap. The two require very different responses; conflating them is the most common analysis mistake with this method.
4. Compute the operational cost trajectory. Hours per week spent monitoring and patching, divided by paying customers. If the slope is flat or down as you scale, the mash-up can ship as the first version of the product. If the slope is up, model when the cost line crosses the cost of a custom rebuild.
5. Decide the next move. One of three things should happen: revenue and retention clear thresholds AND operational cost is sustainable → ship the mash-up as v1 and rebuild components only as breakage forces it; revenue lands but operational cost is unsustainable → start the custom rebuild on the highest-friction component; revenue does not land → the mash-up is doing what a mash-up does best, telling you the value proposition is not strong enough, and no amount of custom build will fix it.