Skip to content
Can they do it?, homeEarly access

Early access, research runs open now

Can they
do it?

Give an AI customer a real task in your product. See where they succeed, hesitate, get lost and give up.

Test my productSee an example

No scripts. No heuristic checklist. A realistic user trying to complete a real job.

  1. Landing: Went fine
  2. Sign up: Went fine
  3. Workspace: Went fine
  4. Team: Got stuck. Expected Invite here
  5. People: Hesitated. Hesitated
  6. Settings: Hesitated. Kept looking
  7. Back: Went back. Backtracked
  8. Invite: Went fine. Found it
  9. Project: Job done. Done, on the third try
  • Went fine
  • Hesitated
  • Got stuck
  • Went back
  • Job done
Illustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

You know how your product works.
Your customers don’t.

You know where everything lives. They only know what the screen tells them.

You see

  1. Settings
  2. Team
  3. Invite

They see

“Where do I add someone?”

Working software can still fail its users.

Nothing here was broken. She still needed three attempts.

  1. Landing: Went fine
  2. Sign up: Went fine
  3. Workspace: Went fine
  4. Team: Got stuck. Expected Invite here
  5. People: Hesitated. Hesitated
  6. Settings: Hesitated. Kept looking
  7. Back: Went back. Backtracked
  8. Invite: Went fine. Found it
  9. Project: Job done. Done, on the third try

These aren’t necessarily bugs. They’re the reasons working software still loses users.

Illustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

We don’t inspect the screen.
We try the job.

Sarah got stuck hereHigh

“I thought People would contain my team.”

She checked People, then Team, then Settings before finding Invite.

Where she looked. A real report carries the captured screen.

This part workedProtect

“Creating the first project was obvious.”

She read the checklist once and never looked for help again.

The instruction here is not “well done”. It is don’t redesign this by accident.

Illustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

One customer.
One job.
See what happens.

  1. Describe the customer

    Sarah, operations manager. Comfortable with SaaS. Never used your product.

  2. Give them a job

    Invite two teammates and create the first project.

  3. See what happens

    Journey. Evidence. Findings. What to fix first.

Not a score. Evidence.

Sarah

Operations manager

Task

Invite two teammates and create the first project.

Outcome

Partly

  • 2Blockers
  • 4High friction
  • 7To protect

Her route

Sarah's route: nine steps, four of them spent looking for a control

HighF-006

Invite is hidden behind workspace settings

Sarah opened People, then Team, then went into Settings and came back out before finding Invite.

Inviting teammates was the job she came to do. Her mental model puts team management with the team; the product puts it in configuration.

MediumF-011

An important relationship is hidden under More options

She only discovered that the project would be visible to the whole workspace after opening an advanced section she had no reason to open.

A consequence she would have wanted to know about was one disclosure away from never being seen at all.

ProtectP-003

The first-project checklist works brilliantly

As soon as the workspace existed she was shown what was done and what was left. She said what she would do next, and did it.

It is the only point in the run where she knew exactly where she stood, and it would be an easy thing to lose in a redesign.

Fix these first

  1. 1Expose Invite from Team
  2. 2Surface the hidden relationship earlier
  3. 3Preserve the checklist

Three of 21 findings, ordered by what it cost her.

Run this on my product
Illustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

The method is real and has been used to run end-to-end product and competitor research. The example above is not.

You can almost hear the support tickets coming.

  • “Where do I add my team?”

    Invite sits in settings instead of next to the team.

  • “Why can't I publish this?”

    A prerequisite exists, and nothing near the button says so.

  • “Which option am I supposed to choose?”

    Three options, none of which explains its consequence.

Usability friction becomes

Support. Workarounds. Abandoned onboarding. Mistrust.

Illustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

Can they do it better somewhere else?

Same customer. Same task. Two products.

Maya, head of marketing. Create a workspace, invite five teammates and publish the first campaign.

You

your product

24
Actions
1
Wrong turns
0
Help opened

Task completed

TaskFlow

a fictional competitor

37
Actions
4
Wrong turns
2
Help opened

Task completed

Both products can do this. Only one of them let her work it out.

They win
Better explanation at the moment permissions are chosen.
You win
Faster onboarding, with fewer decisions before she saw value.
Steal
Contextual help at the point of choice.
Don't steal
Their twelve-step setup flow. It is why she nearly stopped.
Defend
Your shorter route to first value.

Neither product says what will happen the first time Publish is pressed. Both hesitated at the same button.

Compare my productIllustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

Different question.
Different tool.

Usability interviews
Deep human insight. Slower to recruit and schedule.
Session replay
Shows what real users did. Rarely why.
Automated QA
Tells you whether the software technically works.
Can They Do It?
Tells you whether this customer can work it out.

Can they do it?
Actually tries.

Coming next

And after you fix it?
Ask them again.

First run

September

Partly

  • 2Blockers
  • 4High

Re-test

October

Yes

  • 0Blockers
  • 1High

Save the scenario. Run the same customer again. See what improved and what regressed.

This does not exist yet. When it does, it will be the same scenario run again, not a monitor watching your product.

Illustrative exampleBased on the research methodology we use. Product names and scenarios are invented.

Built for people shipping software.

Founders
Before you pay for traffic.
Product teams
Before and after a release.
UX and research
Before you recruit a panel.
Get early access

Start with the journey that matters most.

Reality Check

€99

One critical customer journey.

See what’s included
  • 1 realistic persona
  • 1 primary task
  • Complete journey attempt
  • Screenshots and evidence
  • Blockers and friction, ranked
  • What works well
  • Prioritised recommendations
  • Shareable report
Run a Reality Check

Best starting point for product teams

Product Audit

€299

Understand several important journeys.

See what’s included
  • Up to 3 personas
  • Up to 3 critical journeys
  • Cross-journey patterns
  • Screenshots and evidence
  • Prioritised findings
  • What works well
  • Top changes to make
  • Shareable report
Audit my product

Competitor Compare

€699

See how the same customers experience you and a competitor.

See what’s included
  • Your product
  • 1 competitor
  • Up to 2 personas
  • Equivalent jobs across both
  • Evidence-backed comparison
  • Where they win
  • Where you win
  • What to steal, and what not to
  • Prioritised recommendations
Compare my product

Early-access research is currently human-reviewed while we build the automated platform. Early access is limited because a person reviews every report before it goes out. Prices are in euro and exclude any VAT we have to add.

Something larger? Talk to us

You think your product is easy to use.

Can they do it?

Find out

Tell us who your customer is and what they need to accomplish.