Product Management Case Study
VOZURA
AI-Powered Conversation Intelligence
Customer conversations contain valuable information about needs, objections, intent, engagement and commitments. Much of that information disappears once the meeting or call ends.
VOZURA explores how AI can turn those conversations into structured, actionable product and business intelligence.
Independent AI product concept · Built as a hands-on product exploration
The Problem
Conversations hold the signal. Most of it never gets used.
Important information from sales, customer success and account management conversations is often fragmented — spread across recordings, personal notes, CRM entries and individual memory.
Because of that fragmentation, teams struggle to see recurring customer problems, repeated objections, commitments made across calls, and shifts in customer momentum until it's too late to act on them.
Product Hypothesis
If conversations become structured signals, teams can act on them.
If customer conversations can be transformed into structured signals, teams can understand customers better, reduce information loss between calls, and make better follow-up decisions.
AI is the enabler of this hypothesis, not the starting point. The starting point was a business problem that existed independently of any specific technology.
Product Approach
A discovery-first loop, not a feature roadmap.
- Customer Problem
- Discovery
- Product Decisions
- Build
- Test
- Learn
01 · Customer Problem
Start from a real, observed problem in sales and customer-success conversations, not from a technology capability.
02 · Discovery
Talk to the people living the problem, and question which signals are worth acting on before deciding what to build.
03 · Product Decisions
Turn discovery into explicit decisions: which signals matter, how they're grouped, and how much AI automation is trustworthy.
04 · Build
Translate decisions into requirements and user stories that engineering can build against.
05 · Test
Structured QA against realistic synthetic conversation scenarios to check whether the signals hold up across cases, not just the demo case.
06 · Learn
Feed what testing and review surface back into the next round of product decisions.
Product Capabilities
Grouped around what a team would actually use.
Individually, conversation-analysis features are easy to list and hard to prioritise. Grouped by the decision they support, it's clearer which ones earn their place.
Conversation Analysis
Signals inside a single call — what happened, how it happened, and where attention should go next.
- Talk / Listen Ratio
- Sentiment Timeline
- Intent & Interest Detection
- Objection Detection
- Competitor Signals
- Question Rate
- Interruption Analysis
Customer Memory
Signals that only become visible across multiple calls — patterns a single conversation can't show on its own.
- Recurring Issues
- Promises & Commitments
- Blockers
- Customer Momentum
Customer Memory
A call shouldn't start from zero.
Most conversation tools treat every call as its own event: record it, transcribe it, summarise it, move on. That's useful once — and loses value the second time the same customer calls back.
VOZURA's core product idea is that individual calls should not exist in isolation. The system looks for patterns across a customer's conversations: recurring problems raised more than once, promises made in earlier calls and whether they were kept, blockers that keep resurfacing, shifts in sentiment and momentum over time, and which decision-makers are actually in the room.
- Recurring problems
- Prior promises kept or missed
- Unresolved blockers
- Sentiment and momentum over time
- Decision-maker context
A transcript tells you what was said in one call. A summary tells you what mattered in one call. Customer memory tells you whether this call fits a pattern — and a pattern is what actually changes a follow-up decision.
Relationship intelligence
3 months ago
Healthy
6 weeks ago
Neutral
2 weeks ago
Concern
Today
At risk
Illustrative concept — synthetic data, not a real customer
Reused from the VOZURA prototype's relationship-momentum concept.
My Role
Product Management, not engineering.
VOZURA was defined and shaped end-to-end as a Product Management concept. Where the underlying AI, transcription and data infrastructure was involved, that was hands-on technical product collaboration — not software engineering I personally wrote.
What I owned
- Product strategy and positioning
- Customer problem definition
- Product discovery
- Feature definition
- Requirements
- User stories
- Prioritisation
- UX decisions
- AI capability definition
- QA and test design
- Product iteration
What engineering builds
Turning requirements into working software — the transcription pipeline, model integration, data storage and application code — is engineering work, not Product Management work, and sits outside the scope of this case study.
Product Decisions
The thinking behind the product, not just the features.
Why analyse conversations instead of only generating summaries?
A summary answers 'what happened in this call.' It doesn't tell you if this is the third time the same objection came up, or whether a promise from six weeks ago is still open. Analysis that produces structured, comparable signals is what makes cross-call reasoning possible at all.
Why does customer memory matter?
Because the value isn't in any single call — it's in the pattern across calls. Without memory, every conversation is evaluated in isolation and the same warning signs get rediscovered, or missed, every time.
Which signals are genuinely useful versus AI features that simply look impressive?
A signal earns its place if it changes what someone does next — escalate, follow up, adjust an offer. Features that generate interesting-looking output but don't change a decision were deliberately left out.
How should insights be presented without overwhelming users?
Lead with the smallest number of signals that change a decision, not the largest number a model can produce. Detail should be available on demand, not forced onto the first screen.
How do we balance AI automation with transparency and user trust?
Every AI-generated signal should be traceable back to something the model actually observed in the conversation. Automation should recommend and surface, not silently decide and act, especially while the product is unproven.
AI Product Principles
What guided the product decisions.
01
AI should solve a real user problem, not showcase a capability.
02
Insights should be actionable — if nothing changes because of it, it isn't an insight.
03
Users should understand why an insight was generated, not just see the output.
04
More AI features do not automatically create more value.
05
Accuracy, trust and usability matter more than an impressive demo.
Learnings
What I'd carry into the next AI product.
01
Start with the customer problem, not the model's capability — the capability came second.
02
Assumptions about which signals matter need to be validated with real users, not just judged from the discovery phase.
03
Prioritise signals that lead to a decision or action, and be willing to cut ones that don't, however technically interesting they are.
04
Feature overload is a real risk with generative AI — it's cheap to add another 'insight,' and expensive for users to figure out which ones matter.
05
AI outputs need to be designed to be trusted, not just designed to be accurate — traceability and restraint matter as much as model quality.
06
Technical possibility and user value are not the same question, and confusing them is the fastest way to build the wrong thing well.
Next Step