The User Value Canvas: starting with what users need, not what you want to build

Here's something that happens in almost every early-stage product conversation we have. A founder walks in with a feature list. It's detailed, it's ambitious, and they've clearly been thinking about it at 2am for weeks. There's a dashboard, notifications, a social element, maybe some AI sprinkled on top. And when we ask, "What's the one thing a user needs to be able to do with this?" - there's a pause.

That pause isn't a bad sign, by the way. It's actually the beginning of the most important shift a founder can make: moving from what do I want to build? to what job is the user hiring this product to do?

Features aren't the point

There's a well-worn idea in product thinking that people don't buy products - they "hire" them to get a job done. You don't buy a drill because you want a drill. You buy a drill because you want a hole in the wall, and really what you want is the shelf that goes on it, and really what you want is a tidier living room. The theory behind this - Jobs to Be Done - has been around for years, but it's surprising how rarely it makes it into the early conversations about what an MVP should include.

Instead, what tends to happen is feature-led thinking. Founders start with a mental picture of the finished product - every screen, every flow, every bell and whistle - and try to cram as much of it as possible into version one. The result? Bloated scopes, longer timelines, and a product that tries to do eight things adequately rather than one thing brilliantly.

If your MVP is trying to do everything, it's not an MVP. It's a wishlist with a login screen.

So how do you work out what actually matters? That's where the User Value Canvas comes in.

What the User Value Canvas is (and isn't)

The User Value Canvas is a one-page framework we use at Rise at the start of every build engagement. It's not a business model canvas, and it's not a feature spec. It's a structured way of forcing clarity on one question: what value does this product deliver to the person using it?

It works across five prompts:

1. Who is your user? Not a demographic profile - a real person with a real problem. Give them a name if it helps. What's their day like? Where does the frustration sit?
2. What job are they hiring your product to do? This should be one sentence. If it takes a paragraph, you're not there yet. And it should describe an outcome, not a feature. "Quickly find a trustworthy tradesperson" is a job. "Browse a directory of vetted tradespeople with ratings and filters" is a feature list dressed up as a job.
3. What's the current alternative? Every user is already solving this problem somehow - even if that solution is a spreadsheet, a WhatsApp group, or just putting up with it. Understanding the alternative tells you what you're really competing with, and it's rarely another app.
4. What outcome proves you've delivered value? This is the one most people skip, and it's the one that matters most. What measurable thing happens when your product works? A booking gets made. A decision gets faster. An anxiety goes away. If you can't name it, you're guessing.
5. What's the minimum you need to build to test that? Not to launch. Not to scale. Just to learn whether the job you've identified is real and whether your approach to it works. This is where your MVP scope actually lives.

Put another way: the canvas takes you from "we need to build an app" to "we need to test whether this specific user gets this specific outcome through this specific interaction." That's a very different starting point, and it leads to a very different (usually smaller, sharper) first build.

Why this changes what you prioritise

When you start with the job, the features you choose look completely different. Things that felt essential - an onboarding wizard, a settings page, a notification system - suddenly feel like they can wait. And things you might have overlooked - a single, frictionless core flow that proves the concept works - become the entire focus.

We've seen this play out dozens of times. A founder comes to us wanting to build a marketplace with messaging, payments, reviews, and an admin panel. After working through the canvas, the MVP becomes a simple matching flow and a confirmation screen. That's it. Because the job is connecting two people - not building a platform. The platform comes later, once you know the connection is something users actually want.

The best MVPs don't feel minimal to the user. They feel focused.

And that distinction is everything. You're not cutting corners by building less. You're making a deliberate bet on where the value sits, then testing it as quickly and cheaply as you can.

Use it before you brief anyone

Whether you're working with Rise or building with another team (no hard feelings), fill this in before you write a brief, before you sketch wireframes, before you get three quotes from dev shops. Because if you can't answer these five questions clearly, you're not ready to build yet - and that's genuinely fine. Knowing that early saves you months and thousands of pounds.

We've made the User Value Canvas available as a free download. Grab it and work through it on your own, or book a free 30-minute discovery call and we'll work through it with you. It's half an hour with someone who's built products and exited businesses, no obligation, and you'll walk away with more clarity on what to build first - even if you never speak to us again.

Because honestly? The founders who do best aren't the ones with the longest feature lists. They're the ones who can tell you, in one sentence, why someone would use their product tomorrow.