Chat with Jurre

Blueprints

Feature Canvas

Before a feature gets built, it fits on one page.

The Feature Canvas makes product teams justify a new feature before the first sprint review: which problem does it solve, for whom, with what value, what risk and what measure of success? Made for product managers, designers and engineers who no longer accept feature creep.

Fill in this canvas in BoldcasterOr start with the scale-up audit →
BoldcasterFeature Canvas · template

What is the Feature Canvas?

The Feature Canvas grew out of product discovery practice and belongs to the toolkit of methods such as Marty Cagan's 'Inspired', Jeff Patton's story mapping and Teresa Torres's Continuous Discovery Habits. It is not a formal academic model but a worksheet that many product organisations have refined into a single page.

It solves a painful but widespread problem: features that end up on the roadmap without anyone being able to explain exactly which problem they solve, for whom, or how you will know in three months whether they succeeded. The canvas forces that clarity up front, and stops a team from spending weeks building something nobody would miss.

The Feature Canvas says little about implementation, estimates or sequencing; other artefacts cover those (user stories, design specs, sprint planning). It is a discovery tool, not a delivery tool. Combine it with an Experiment Canvas if the feature is a hypothesis, and with a Validation Canvas if the feature is a strategic bet.

When do you use it?

Reach for the Feature Canvas as soon as anyone on the team (product manager, sales, support, founder) proposes building a new feature. The canvas separates what is genuinely worth building from what is proposed for show. One canvas for every feature that goes on the roadmap. A pre-mortem, not a post-mortem.

Still unsure which features add value for which customer? Start with Jobs-to-be-Done. Wondering whether a whole proposition stands up? Work through a Lean Canvas. Have a hypothesis you want to test before you build? Use an Experiment Canvas.

How to fill it in

Fill in the seven blocks in order. Does something not fit, or are you missing information? That is the signal: do not fill the missing block with assumptions, go and get the information first.

01

Feature Description

One paragraph describing the feature as a user experiences it. Not from the technology ('we are building an endpoint') but from use ('when a customer does X, they see Y'). Including scope: what is in, and what is explicitly out. A feature that does not fit in one paragraph is not a feature; it is a project.

Questions that help

  • ·What does this feature look like to a user in practice?
  • ·What is explicitly out of scope?
  • ·On which screens or in which flows does it appear?

Example

Clash detection in the weekly schedule: when a job planner tries to assign two tasks at the same time to the same person or the same equipment, a red marker appears along with a suggestion button. No automatic correction, no integration with external planning systems.

Common mistake

Describing a feature in internal jargon or technical terms, which makes it useless for sales, marketing or customer communication.

02

Problem It Solves

The user pain this feature answers. Be concrete: which frustration, which task error, which missed opportunity do you solve? Ideally backed by data (how many times a week does this problem occur?) or customer quotes. No problem, no feature. 'It would be nice' is not a problem.

Questions that help

  • ·Which problem does the user experience that makes this feature valuable?
  • ·How often does this problem occur?
  • ·How is the problem documented today: support tickets, interviews, product data?

Example

Problem: in the current flow, job planners only see on Thursday that they double-booked on Monday. That means an average of 2 hours of rework per user per week, recorded in 87% of customer conversations in Q1.

Common mistake

Inventing a 'problem' as a justification. If you have no evidence that the problem exists, that is your first experiment.

03

Who It Affects

Which segment, which personas and what share of your current customer base does this feature affect? And, just as important, who does it not affect? A feature that seems to add value for every customer is usually not specific enough for anyone. Be concrete about whether this is a retention, activation or acquisition feature, and for which stage of the user.

Questions that help

  • ·Which segment or persona benefits most from this?
  • ·What share of the current customer base does it affect?
  • ·Who is it irrelevant for, and could it get in their way?

Example

Audience: job planners at SME construction firms with 10 or more employees (38% of our paying customers). Not relevant for freelancers (12% of the base): they work alone, so they have no task clashes.

Common mistake

Writing that 'all customers' want it. That means either the feature is too generic or the analysis did not go deep enough.

04

Value

What does this feature deliver, for the user (time saved, frustration gone, new capacity) and for the business (retention, conversion, upsell, cost savings)? Make it quantitative where possible: 'an expected saving of 2 hours per user per week' is stronger than 'improves efficiency'. For the business: how does value for the user translate into revenue, margin or retention?

Questions that help

  • ·Which measurable value does it deliver for the user?
  • ·Which measurable value does it deliver for the business?
  • ·How does the value scale: more per user, more per month, or once?

Example

For the user: 2 hours of rework saved per week (effectively €60 an hour). For the business: an expected 4 to 6% rise in retention in this segment, plus an argument for an upsell to the Pro tier (€20 a month extra).

Common mistake

Describing value only qualitatively ('better', 'faster', 'nicer'), which makes it impossible to judge in six months whether it was delivered.

05

Risks

What could break: technical (complexity, performance), legal (privacy, compliance), commercial (cannibalising other features or tiers), operational (support volume, onboarding), or customer behaviour (losing existing usage patterns). Write down the top 3 risks with a short mitigation. No risks means you have not looked hard enough.

Questions that help

  • ·Which technical, legal or commercial risks does this feature carry?
  • ·Which behaviour of existing customers could it disrupt?
  • ·What could the feature cannibalise?

Example

Risk 1: red markers cause 'alarm fatigue' among long-standing users with chaotic schedules. Mitigation: A/B test marker frequency in the first 4 weeks. Risk 2: support volume rises because of questions asking for explanations. Mitigation: in-app explanation plus a help article for the first 5 markers.

Common mistake

Mentioning risks lightly ('possibly some support questions') without serious mitigation. It will come back to bite you.

06

Success Metric

One leading metric that tells you within 30 to 90 days of launch whether the feature works as intended. Preferably direct (adoption of the feature, tasks completed with the feature) rather than indirect (overall retention). Set an expectation or threshold in advance: at what reading do we call the feature a success? Without a threshold fixed in advance, every outcome becomes 'actually quite all right'.

Questions that help

  • ·Which metric tells you directly whether the feature is being used?
  • ·What level is enough to justify building it?
  • ·Over what period do we measure: 30, 60, 90 days?

Example

Success metric: the percentage of job planners who use the suggestion button at least once within 30 days of seeing their first clash marker. Threshold: 40%. Below 25% means redesign or withdraw the feature.

Common mistake

Choosing a metric that other changes also influence ('revenue goes up'). You cannot attribute it to the feature.

07

Alternatives

Which cheaper, faster or simpler solutions were considered? A warning in the UI, an update to the manual, a macro, an external integration, simply doing nothing? Write down why the chosen feature beats those alternatives, especially in terms of value per week of build time. A team that has not considered alternatives has not thought hard enough.

Questions that help

  • ·Which cheaper solution was considered, and why was it ruled out?
  • ·What would the impact be of doing nothing at all?
  • ·Is there an external integration or existing functionality that solves this?

Example

Alternatives: (1) a warning text under the planning table, rejected because job planners do not scroll; (2) a weekly email report of clashes, rejected because the feedback comes too late; (3) doing nothing, rejected because 12% of the current churn cohort cite 'rework' as their reason.

Common mistake

Leaving out alternatives because 'we already know what we want to build'. The best solution usually emerges precisely from the comparison.

Common mistakes

Defining a feature in technical terms

A feature is what a user experiences. Write it in their language, not in API terms. Otherwise marketing, support and sales cannot explain it.

Describing value only qualitatively

'Improves the user experience' is not value; it is a hunch. Make value quantitative wherever you can: time saved, costs cut, retention.

Setting the success metric only after launch

Choosing your metric afterwards means deciding afterwards what 'success' was. Fix it before you build, or you get no lessons, only output.

Not considering alternatives

Every feature has a cheaper or simpler alternative. By naming and weighing those explicitly, you avoid building the wrong thing.

Brushing risks aside

A feature without risk does not exist. If you cannot name any risks, you have not been critical enough; ask someone outside the team to read along.

Filling in the canvas after building has started

The canvas is a thinking tool for before you build. Filled in afterwards, it turns into justification rather than a way of choosing.

In Boldcaster

How Boldcaster helps you with this

Fill it in interactively

No stray PDF lost in your downloads folder. Fill in the canvas in the app, with version history and comment threads.

Bold AI does the groundwork

Paste in your business plan, annual report or rough notes and Bold AI fills in the canvas for you. Or ask it for suggestions block by block.

Connected to your strategy

Send an insight from this Feature to your Priorities, KPIs or strategy in one click, instead of leaving it on a whiteboard.

All canvases in one place

Pilot users get access to BMC, Lean Canvas, Value Proposition Canvas and whatever comes next. One platform, one system.

Create a free account and use every canvas

Prefer some guidance?

You don't need to know the models: Bold AI helps you block by block. Want someone alongside you to run the sessions with your leadership team? Start with the scale-up audit. After that, we're happy to introduce you to a coach from our network who works with Boldcaster.

Frequently asked questions

How does the Feature Canvas relate to user stories?

+

The Feature Canvas is broader: it describes the feature, the rationale, the value and the success criterion. User stories are the delivery units within the feature; you often write 3 to 15 stories per feature. The canvas comes before discovery; stories come before the sprint.

Who should fill in the Feature Canvas?

+

Preferably the product manager, working with design and engineering. For strategically important features, include someone from sales or support as well.

How many features can you reasonably work on in parallel?

+

A product team of 5 to 7 people can typically have 1 to 3 features in discovery and 1 or 2 in delivery at the same time. More in parallel means more context switching and weaker discovery.

What do I do with a feature that does not make it through the canvas?

+

Park it. Do not delete it: keep the canvas along with the reason. Ideas often come back when the context changes, and you will not want to redo the work then.

Does the Feature Canvas work for B2C products too?

+

Yes. The disciplines (identifying the problem, specifying the audience, measuring success) are identical. B2C often has more scope for A/B testing, which makes the success criterion sharper.

How does this connect to the wider roadmap?

+

Features that make it through the canvas get priority on the roadmap. The canvas helps you base that prioritisation on substance rather than on politics or the HiPPO.

What if sales has 'sold' a feature to a big customer: can that skip the canvas?

+

That is one of the most damaging anti-patterns. Fill in the canvas then too; you will often find the feature serves other customers as well, or does not. A 'sales promise' is a valuable signal, not a reason to skip discovery.

How long does it take to fill in?

+

You can make a first version in 60 to 90 minutes if the information is to hand. Often filling it in mainly triggers gathering information: a week of research, then a two-hour session to sharpen it together.

Further reading

What does a filled-in Feature Canvas look like?

An empty canvas is the easy part. The hard part is what goes in it. I'll send you a completed Feature Canvas: a fictional company, real wording, sharp enough to base decisions on.

See a completed example

The strategy canvas of a fictional installation company, fully completed. Plus five signs that a canvas actually steers the business, rather than just being filled in. Four pages, PDF.

You'll see the example straight away and get a copy by email. We keep your address so we can help with your strategy; unsubscribe any time in one click.