Build. Delay. Kill. How to Decide What Goes in Your MVP

Leading product when you’re not technical: the questions, the quadrant and the rules that keep your first version small.

By Matt Ainsworth, founder of The Lean CPTO · Last updated 28 September 2026 · 67-minute webinar + 8-minute read

Webinar replay. Prefer to read? The key ideas are below, with chapter links at the end.

What does leading product mean if you’re not technical?

It means you own the decisions, not the code. Developers and AI tools help you build it, but as the founder you decide what gets built, in what order, and how you’ll know it worked. In practice that comes down to four things:

Which questions should you answer before building?

Before you brief a developer or open an AI builder, you should be able to answer these four questions in plain English:

1. What problem are we solving? Make the problem statement specific, not vague or broad. Listing the who, what, when, where, why and how points you in the right direction.
2. Who is it for? Build a simple profile of that user: their role, their situation, their challenges and why they’d use your product.
3. What’s the core workflow? Walk the user’s journey step by step, from arriving to getting the result. Map what they feel at each step as well as what they do; it tells you what feedback to look for later.
4. How will we know it works? Users get the outcome you promised, they tell you so, and nothing is breaking along the way.

Prototype vs proof of concept vs MVP vs full product

They’re four different tests, and mixing them up is how founders end up building a full product when they only needed a prototype.

Airbnb is the classic example. The first version was a very simple site where you could see a room and book it. There was no map, no search filters and no review system. Those came later, once demand was proven.

Why do MVPs get bloated?

Because almost everyone around you is pushing you to build more. An agency quotes for the full product, not the MVP, which is why quotes of US$50K to US$60K are common for what should be a much smaller first version. AI builders like Lovable keep suggesting the next feature, the next page, the next workflow, with no guardrails to tell you when to stop. Even ChatGPT tends to tell you every idea is great.

Features that often sneak in too early: analytics dashboards, secure sign-on, payment gateways, maps, review systems, integrations with accounting software like Xero, and AI agents. Some of them matter eventually. Few of them matter for proving your first workflow.

How do you prioritise MVP features?

Put every feature into one of four buckets. Treat it as a scale rather than hard boxes; some features sit on a line, and a conversation with a user usually pushes them one way or the other.

Worked example: a co-founder matching app. Must have: a profile with a photo and the key fields, and a yes or no button. Later: swiping, payments, an AI matching algorithm. Kill: “super like” style extras. For Airbnb’s first version, the must-haves were the property, a few photos, the location and availability. Reviews and maps were “later”.

Every feature you add to the must-have bucket delays launch and makes testing harder. One example from the session: a team added seven extra languages to an app that only needed two. It took two months, and nobody used them.

When is your MVP ready to ship?

• Start with a web app. It’s far easier to test and ship than an iOS or Android app, where device differences and app store reviews slow you down.
• Test the core workflow, not every edge case. You won’t catch everything until real users go through it.
• Have a launch plan before you launch. New apps get a short window of organic visibility in the app stores. Without a plan to bring in your first users, that window closes and the app becomes hard to find, even by name.
• Plan how you’ll close the feedback loop: how you’ll get users, and how you’ll hear from them.

What don’t you need in your first version?

You probably don’t need AI in your MVP at all. Basic tech is often enough to prove demand, and AI costs can grow fast once you’re paying for API calls or running agents. If you do use an AI API, set a spending limit before anyone else touches it.

The same goes for a perfect UI, analytics dashboards, secure sign-on and integrations. A basic export to a spreadsheet is often enough to start. One story from the session shows why this matters: a page set to refresh every second ran up about $1,200 a month in costs with no users at all, because nobody checked how “live” it really needed to be.

What are kill rules?

Kill rules decide which features go, even after you’ve built them. If a feature adds complexity or ongoing cost and people don’t use it, remove it. Watching where users actually click, for example with heat mapping, shows you which features earn their place.

Which metrics matter for an MVP?

Pick the metric that matches how often your users actually need you. Daily active users suit a social app. Weekly active users suit something people use once a week, like a newsletter or a weekly care update. Monthly active users suit tools people return to occasionally. Then follow the user through their lifecycle:

Slack is a good reminder that simple wins. It started as a simple way for people in a business to chat, and it spread quickly because each new user pulled in their colleagues.

When should you hire someone in product?

At first, you are the product person. Consider help when you’re hitting your limit and your budget allows it, and it doesn’t have to be full-time: a fractional product lead, a part-time helper or an intern can all work. Either way, don’t do it alone. Test your thinking with other founders, colleagues and, most of all, your users.

Should your next dollar go into code or into selling?

Frequently asked questions

What should an MVP include?

One core workflow for one type of customer, plus whatever that workflow can’t function without. Everything else goes in the nice to have, later or kill buckets until users ask for it.

What’s the difference between a prototype and an MVP?

A prototype tests whether the concept makes sense to users. An MVP is something real users actively use, so you can test whether they get the outcome. A proof of concept sits in between and tests whether it can be built technically.

How do non-technical founders prioritise features?

Sort every feature into must have, nice to have, later and kill. Build only the must-haves for version 1, and use conversations with real users to decide anything that sits on the line.

Should my MVP use AI?

Often not. Basic tech is usually enough to prove demand, and AI costs can grow quickly with API calls and agents. If you use an AI API, set a spending limit first.

Should I build a web app or a mobile app first?

Usually a web app. It’s easier to test and ship, and you avoid app store reviews and device differences while you’re still proving the workflow.

Related guides

• The Manual MVP: get paid before you write code
• The Paid Pilot playbook
• How much should an MVP cost in 2026?
• Stuck at 80%: what to do when your AI-built app stops working
• Is your AI-built app safe to sell?

Video chapters

• 0:00 Why we run these sessions
• 4:15 What we’ll cover
• 6:32 What leading product means
• 8:31 The 4 questions
• 13:31 Design thinking and user emotions
• 19:53 Airbnb’s first MVP
• 21:09 Prototype vs POC vs MVP vs full product
• 30:47 One workflow wins
• 32:11 Why agencies and AI tools overbuild
• 35:57 The prioritisation quadrant
• 38:29 Worked examples
• 43:23 Shipping rules
• 49:42 What you don’t need yet
• 54:24 Kill rules
• 55:32 Metrics that matter
• 1:03:31 When to hire someone in product