Case study. Researching the value of chat for Osome
How to find strategic depth in a tactical request.
TL;DR. Project overview
Osome is an accounting service for entrepreneurs. The product’s core feature is a chat through which entrepreneurs upload receipts and other financial documents. The product was moving fast, and teams needed data quickly to keep up with decisions.
The product team came with a prioritization request: there were 40 potential chat improvements in the backlog, and they needed to know where to start. As I got into it, I quickly realized that without understanding what value the chat held for customers, any prioritization would be shallow. As a result the team got the prioritized backlog, as well as a strategic vision for the product.
Key insight: the team didn’t fully understand how customers were actually using the chat, and customers weren’t just treating it as a communication tool. In fact they were using it as a document cloud storage.
Impact for the company
The research became the starting point for a conversation about the strategic vision for chat as a product.
Impact for product
A prioritized backlog, formulated job statements, and a clear strategic direction for chat development.
1 · Context and research objective
From a tactical request to the right research question
Osome is an on-the-go accounting service for entrepreneurs, operating across three markets: the UK, Singapore, and Hong Kong. The product’s core feature is a chat through which entrepreneurs upload receipts and other accounting documents. The company was growing quickly, the product was moving fast, and teams needed data fast to keep up.
→ The research request came from the product team responsible for the in-chat customer experience.
“We have a list of 40 potential improvements and we want to understand where to start.”
It sounded like a backlog prioritization task. The choice of methodology sat with the research lead; my job was to execute the study. After the briefing, we decided to run a Kano survey.
However, while working on this project, a strategic layer surfaced. The additional research into that layer was something I initiated and led myself. More on that in Stage 3.*
2 · Research process
Research approach and methodology
Stage 1. #Desk research
The Kano method helps to understand not just what users want, but how each feature affects their satisfaction. Satisfaction was the chat product team’s key metric and raising it was one of the OKRs for the quarter.
Before running the complex survey, I did a short preliminary study: I reviewed the current chat functionality, went through the list of 40 features, and looked at user reviews and complaints from the support archives.
I also did a prep work for the survey itself. My goal was to make it as pleasant and valuable an experience as possible for our customers.
I knew our customers wouldn’t be willing to spend a lot of time on a survey, even with a financial incentive. The Kano method asks three questions per feature, which meant a 40-feature survey would take at least half an hour to complete.
→ Working with the product team, we cut the feature list from 40 down to 20.Even for simple features, understanding what we were actually proposing to add to the chat from a text description alone can be hard to parse.
→ Together with the designer, I created feature mockups in context, so that customers could easily grasp what each one was about.I wanted to give customers a genuine opportunity to share their own perspective on the chat. I designed the survey using the Kano methodology with three questions per feature.
→ At the end, I added an open-ended feedback question for anything they had to say.Finally, the internal system wouldn’t let me send a mass mailing.
→ Working with the engineering team, we wrote a script that let us send out the survey to 3,000 customers through the internal system.
Stage 2. #Kano survey
I ran three separate Kano surveys. One for each market: the UK, Singapore, and Hong Kong. The results produced a feature prioritization table.
We sorted the 20 features into Kano categories and ranked them by importance:
Performance — must-have features; baseline functionality the product can’t work without
Attractive — features customers don’t expect, but create real delight when they’re there
Indifferent — neutral features whose presence or absence doesn’t meaningfully affect satisfaction
At the end of the list, I added 9 features that customers had proposed themselves in the open-ended responses.
The team now had a prioritized, tiered feature list and a clear sense of what to tackle first.
Stage 3. #Analysis and synthesis
The survey results caught the team off guard and raised some questions. For instance:
Chat search came out as the top priority, but the team had no clear understanding why
The product team had been convinced that emoji reactions mattered; they came in last
After talking through the results with the team, I realized that we didn’t actually have a full picture of how customers were using the chat in practice, and that the product was missing a strategic vision.
→ Reframing the research question
Looking at the survey results and digging deeper into the situation, I understood what was really needed: to figure out what value the chat actually held for Osome’s customers.
Stage 4. #Analysis and synthesis
I went back to the findings and ran an additional layer of analysis.
Chat search, for instance, had come in first. The file search feature had landed in tier 1. And in the open-ended responses, the top request was a folder option for uploaded documents. Then the real reason clicked into place: search mattered so much because customers were uploading their receipts to the chat and using it as a document cloud storage.
Out of this secondary analysis, I developed a set of value hypotheses for the chat as a product.
Value hypothesis 1. Chat as a document cloud storage.
If chat gets search, tagging, and message sorting features, Osome customers will find documents and past agreements more quickly, because they already use the chat history to store important information.
Corresponding features and their place in the prioritization:
1. Searching chats
4. Searching media and files in conversations
Value hypothesis 2. Chat as a tool to communicate with accounting specialists. If chat gains standard editing capabilities, such as message editing and deletion, replying to specific messages, Osome customers will find communicating with the team more natural, because they treat the chat as a familiar messenger and expect it to behave like one.
Corresponding features and their place in the prioritization:
5. Replying directly to a message
11. Editing and deleting messages
Value hypothesis 3. Chat as a service control panel.
If request status, SLA, and agent availability features are added, Osome customers will feel less anxious and send fewer follow-up messages, because they treat the chat as a problem-resolution tool and want to know what's happening with their request.
Corresponding features and their place in the prioritization:
7. Knowing when to expect an answer
9. Tracking a task status
Stage 5. #job statements
With the secondary analysis done, I could see how much room there was for the product to grow. The chat was helping customers do a wide range of things, but the team didn’t have a clear picture of what those things actually were. The value hypotheses gave us a way in.
I offered to help the team work on product vision. I wanted to understand what jobs customers were “hiring” the chat to do, so I turned to the Jobs to Be Done framework. For each value hypothesis, I wrote a job statement describing the underlying need and the outcomes customers were looking for.
3 · Tactical and strategic outcomes
What changed
Within the company
The research highlighted a critical gap: the product had no strategic vision. And without it, shipping new features wouldn’t improve metrics or user experience in any real way. The research started the real conversation about strategy.
Within product
A prioritized development backlog took shape. We articulated value hypotheses for the chat as a product, and laid out a strategic direction for its development. The hypotheses and job statements explained the key real-world use cases for the chat and what it was actually worth to customers.
4 · Reflection
Personal learnings
Product teams move fast and tend to come to researchers with very specific requests. They care about data, metrics, numbers. At that pace, it’s easy for the focus to drift toward tactics, and for the horizon to shrink to the quarterly roadmap. You start seeing the product through goals and figures rather than through the people who use it.
The value of research is in helping the team take a step back and ask the uncomfortable questions: Are we building the right thing? Do we understand the core value of our product? Do we know how people actually use it?
A researcher’s curiosity and their ability to see the person behind the data. That’s what surfaces behavioral patterns and turns scattered knowledge into a clear picture. That’s how the real value becomes visible. As a researcher you don’t just tell the team what to build – you help them figure out what’s actually worth building.