Noreva, Executive Communication Consultancy

Case study

When a missing feature is actually a market barrier

Client
Pensight Inc
Sector
Creator monetisation platform
Service
Independent platform review
When
August 2026

Pensight could not test the market they sell to

Pensight builds tools for independent educators and coaches who sell their own sessions and content. They wanted to understand how the product reads to the person they built it for, rather than to the team that built it.

They asked me to review the platform from inside the market it sells to: an independent educator earning through a marketplace and weighing up whether to build something of her own. That is not a user I had to imagine. I have taught online for years, and I have made exactly that move.

I am also based in a country their payment system does not currently reach, which turned out to sit at the centre of the review, because it was the one thing the team could not test from inside the product.

The review covered ten tasks, a written report, a recorded walkthrough and an advisory session.

So I worked the product as that user, and recorded every hesitation

1

Work as the user, not as a reviewer

Ten tasks in a fixed order, across four sittings and three hours inside the product.

Emic perspectiveTask-based evaluationTime on task

I signed up, built a lesson with a price on it, checked the payout setup, set my availability, attached a digital product, built a monthly arrangement, opened the public page as a stranger, tested cancellation and time zones, and ran a live call.

Everything was built privately. No real card details were entered, and wherever real money would have moved, I stopped.

The rule I set myself was simple: when I got stuck, I stayed stuck.

Looking up the answer would have removed part of what I was trying to measure. If a user has to stop and work out what to do next, that is part of the experience. How long something takes to work out is not an obstacle to the finding. It is the finding.

2

Work both sides of the product

Two browsers, two email addresses, and a product priced at zero so I could buy it from myself.

Dual-role testingService blueprintingEnd-to-end journey

Most reviews test the side the client asked about. I wanted to see what happened after that too.

The same rule applied here. I set the price to zero, then bought my own product as a student in a separate browser with a separate identity, and carried on from that side to see what a buyer could actually do next.

Some of the findings only became visible once I had moved into the second seat, which is why looking only at the seller’s experience would not have been enough.

3

Record hesitation while it happens

About a hundred minutes of narrated screen recording, with a live log written during the work.

Think-aloud protocolConcurrent verbalisationHindsight bias

I talked while I worked, so moments of hesitation were captured as they happened rather than reconstructed afterwards.

The log recorded what I was trying to do, what actually happened, whether I hesitated and for how long. It was written during the sessions, not at the end of the weekend.

That is not a procedural detail.

Once you know how something turned out, the route to it looks more obvious than it did at the time. A report written from memory can quietly remove the confusion it is supposed to document.

4

Measure the gap, then sort by what it costs

Twenty-eight findings, grouped into three bands by commercial consequence.

Planning fallacySeverity ratingExpected against actual

Before each task, I estimated how long it should take. Afterwards, I recorded the actual time.

The two tasks I completed and timed properly took exactly twice as long as I had expected: an hour instead of thirty minutes. I have worked online in this field for years, I am comfortable with software, and I had already watched the product’s own introduction video.

That gave me a useful reference point. If I was already familiar with this kind of work and still needed twice as long as expected, an educator trying the product for one free evening may not reach the third task.

The findings were then ordered by what each one costs the business, rather than by how irritating it was to encounter.

Something that quietly loses a customer before they ever sign up outranks something that annoys a customer you already have. The order of the work should reflect that.

The blocker was not a missing feature

One finding mattered more than the others, and it was not a usability problem.

Pensight’s payment setup does not reach South Africa.

At first, I had filed that in my own head as a missing feature, something that could sit behind other product work.

It is not a missing feature.

For a creator in a country Stripe does not reach, payouts are the gate. Nothing else about the product can really be judged until that problem is solved, and nothing spreads in that community until it is.

A barrier like that does not simply stop people. It removes them from the evidence.

People who meet the barrier leave before they can tell you why they left. Their problem therefore never appears in the feedback, never becomes a feature request and never shows up in the data from people who stayed.

That changes how the problem needs to be understood.

Ten things that worked were documented as carefully as the things that did not. Those findings stay with the client too.

A useful review should not simply produce a list of problems. It should show the team what is already working, what needs attention and where the difference lies.

The remaining twenty-seven findings stay with the client. This account names only the one Pensight has described publicly themselves.

Their own feedback board could never have shown them

After finishing the tasks, I read Pensight’s public feature request board, which had roughly ninety requests from paying customers.

Most of it agreed with what I had found, which was useful.

The more useful observation was what was missing.

Three of my findings appeared nowhere on the board. Not because they were small, but because everyone writing there had already signed up, already understood the product and already built something with it.

The people those findings describe were never in the sample.

So their problems could not appear on the board, however long you read it.

A channel can be full and still be deaf in exactly one direction.

What one weekend cannot tell you

This was one person, over one weekend, in one country, teaching one subject.

It offers depth rather than sample size, and it was designed to be read alongside the company’s own data rather than instead of it.

I am also not a typical user. I am comfortable with software, I run my own website and I deliberately went looking for the limits of the product. Where I struggled, someone less technical may struggle sooner.

The student purchase was made at zero cost, so what I tested was the journey after a completed order rather than the paid checkout itself.

Two tasks were left incomplete. I reported them as incomplete rather than quietly dropping them.

I did that because the point of the review was not to make the product look good or bad. It was to document what actually happened when someone tried to use it.

What a review like this can tell a company is the one thing its own data cannot: what the first hour feels like, and why someone who is not yet a customer decides the product is not for them.

What changed as a result

“We went in thinking of payments as a ‘feature,’ and Nadia reframed it as a market-entry gate: for creators in Stripe-unsupported countries, payout support isn’t a nice-to-have. Nothing spreads in their community until it’s solved. That single reframing changed how we prioritize.”

“We expected a set of usability notes from a single call. What we actually got was far beyond that, a ~30-page structured analysis, a walkthrough presentation, and 12 screen recordings going through the real experience step by step. The depth and specificity were well above what we’d scoped.”

When a review like this is worth commissioning

The client’s own answer is probably the clearest description of it:

“Founders and early product teams who are too close to their own product, especially anyone expanding into a user segment or market they don’t personally represent. The best moment is right around product-market fit: once the core is built but before you pour fuel into scaling, when an honest outside walkthrough can still redirect what you prioritize.”

Published with the written permission of Pensight Inc. The review report itself remains confidential.

Prepare for the moments that matter most.

Book a free consultation

15–30 minutes. English or German. Online worldwide.