As the sole consultant, I ran a 12-week product discovery for a European IoT provider, end to end: 20+ research sessions across internal teams, customers, and partners, with AI embedded in every phase, transcribing and analysing sessions in minutes, holding the full research context as a persistent second brain, and synthesising across 50+ artefacts. The brief was to fix the customer experience of the company's portal, but the loud UX complaints turned out to be symptoms of deeper structural causes, not a design problem. I made the findings tangible with five AI-built concept prototypes and delivered a phased roadmap, presented to the C-level, that fed directly into the company's strategy update.
Context & Stakes
A portal built as an internal production tool had quietly become the primary customer touchpoint for tens of thousands of buildings.
The client is a European IoT provider. One of its services monitors tens of thousands of buildings, and a single web portal had become the one digital surface where customers and partners use that service: checking status, managing access, responding to alerts.
The portal was never designed as a customer product. It had been built as an internal production tool, and it hadn't been properly evaluated from the customer's side. It had become business-critical faster than it was ever designed to be. By the time I came in, the experience had grown fragmented, customers and support were absorbing the gaps with manual workarounds that didn't scale, and the product team knew it needed work but had no agreed picture of what to fix first, or why. The brief was practical: run a product discovery to improve the customer experience.
Role & Approach
I ran this solo, owning the whole process end to end: research planning, fieldwork, synthesis, prototyping, the roadmap, and the stakeholder facilitation around it. The client's product, operations, and commercial leads acted as sponsors and as my route to customers and partners. The design and synthesis work was mine.
Across more than 20 sessions, moving fluently between the design questions and the technical architecture earned trust: I could follow a customer's surface complaint down to an integration gap or an undefined product model inside the same conversation, instead of handing the technical half to someone else.
The discovery had to fit inside the client's strategy-refresh window, so I kept it tight: three months, three loosely overlapping phases of research, synthesis, and strategy.
What made a one-person discovery viable at that pace was embedding AI in every phase of the work, not bolting it onto one task at the end. AI tooling transcribed and analysed hours of interviews and workshops in minutes, turning raw sessions into structured analyses; it held the full research context as a persistent second brain, so I could cross-reference findings across every session at once; and it synthesised patterns across more than 50 research artefacts. The same tooling generated interactive concept prototypes from research-grounded briefs in hours, and drafted the session guides, analyses, and deliverables I'd otherwise have queued behind myself. In practice, it did the work I'd otherwise have needed a team for.
The point was never just speed.
The real value wasn't doing it faster. It was depth: every design decision could trace back to a specific piece of customer evidence, because the whole research context was available at once.
I also wrote my assumptions down before fieldwork as hypotheses to test rather than conclusions to confirm; the strongest, that the portal's problems would look like UI problems but turn out to be structural, is the one the research validated most clearly.
What I Found
The fieldwork came to more than 20 sessions in total, spanning internal stakeholders across product, commercial, operations, and technical roles and a range of customer and partner organisations, run as semi-structured interviews, focus groups, co-design workshops, and live portal walkthroughs. The customers ranged from large organisations managing many sites down to partners and resellers who touch the portal only occasionally. AI transcribed and analysed each session within minutes of it ending, so synthesis built continuously rather than waiting for a separate analysis phase.
The surface complaints were predictable: confusing navigation, internal jargon, weak feedback after you act, and a constant fallback to phoning a person. What the research made clear is that none of those were the actual problem. They were symptoms of how the service was wired underneath.
The sharpest pattern was that customers couldn't get a complete picture from the portal alone, so larger customers kept their own records on the side and reconciled by hand whenever the two disagreed. That manual workaround was the emotional low point of the journey, the place where trust quietly eroded. The other recurring theme was the human layer: customers genuinely valued and trusted the support people, and that trust was carrying the service, but it was also masking the cost, because support was effectively acting as a manual bridge between systems.
For the occasional user, the portal costs more effort than the phone call it was supposed to replace.
Problem Definition
"Improve the customer experience" was the brief. The discovery found those experience problems were downstream of a product one: the portal had never been defined or owned as a customer-facing product, so there was no shared picture of what it was for, who it served, or how it fit the wider service.
The reframe mattered because a UX-only engagement would have shipped a nicer interface on top of the same foundations: the same integration gaps, the same role ambiguity, the same manual reconciliation, now hidden behind cleaner screens. Laddering the pain points down through repeated "why" questions surfaced a small set of structural causes underneath the complaints: gaps in how systems were integrated, an undefined product and segmentation model with one portal trying to serve very different audiences at once, and too much of how the service worked concentrated in a few people rather than in the product itself.
The team didn't just need a list of fixes. They needed the evidence and the language to make the case for structural work to leadership.
Key Decisions
Solo and three months, scoped to the decision window
Discarded: A larger engagement covering every customer segment in depth, with parallel workstreams and a longer runway. More coverage and more confidence, but at a much higher cost and outside the decision window.
Chosen: A solo three-month discovery focused on the highest-leverage customer and partner segments, sized to land inside the client's strategy-refresh cycle with a light footprint on the team's week.
Tradeoff: Less segment depth and no internal team to carry the work forward. I mitigated it by running the internal working group as an active sponsor rather than an audience, so the findings had owners before the final presentation.
AI-built prototypes as research probes, not a final reveal
Discarded: Polished interactive prototypes saved for a stakeholder reveal at the end of the engagement.
Chosen: Five interactive concept prototypes generated from research-grounded briefs with AI-assisted tooling, built and iterated in days rather than weeks and used as probes to provoke sharper conversations. Because they took hours to stand up, I could put them into the research itself rather than waiting for a separate design sprint, then hand them on as a concrete starting point to build from.
Tradeoff: They were starting points rather than production-ready design, but they turned abstract findings into something stakeholders could click, which moved internal conversations from defensive to generative. "The portal lacks a single source of truth" became "here is what a unified view could look like."
A phased roadmap, not a single redesign brief
Discarded: One comprehensive redesign specification handed straight to engineering to build.
Chosen: A phased roadmap that deliberately sequenced foundational work ahead of surface work, so the visible UX improvements would land on solid ground instead of papering over the structural gaps underneath.
Tradeoff: Less immediately satisfying than a single redesign to point at, but it matched how the organisation actually makes investment decisions and let leadership commit incrementally. It also named why past attempts had stalled: surface work kept getting prioritised over foundations, then failing to hold.
Solution & Deliverables
What landed:
- A research synthesis, built with AI across 50+ research artefacts and written for a mixed product-and-leadership audience, anchored on personas spanning the customer-facing and internal roles
- A current-state customer journey map identifying the manual-reconciliation step as the trust low point
- A service blueprint exposing where manual work and single-person knowledge hide behind the portal UI
- Process maps and a structured analysis laddering surface complaints down to their structural causes
- Five interactive concept prototypes built with AI-assisted tooling, used as probes: a unified view, bulk operations, role-based dashboards, guided task flows, and clearer confirmation and feedback states
- A phased roadmap sequencing foundations ahead of surface work
- An executive presentation to the C-level, built around the symptoms-versus-structure reframe
Outcomes
The reframe landed with leadership
Leadership engaged strongly with the symptoms-versus-structure framing. It changed the conversation from "which screens do we redesign" to "who owns this as a customer product, and what do we fund first."
Input to the company's strategy update
The discovery surfaced structural dependencies the organisation hadn't had named before, and the findings fed directly into the company's strategy update, with the phased framing adopted as the basis for next steps.
A customer-perspective baseline, in writing
For the first time the portal had a documented reading of the customer experience. The journey map, service blueprint, personas, and process maps became reusable reference inside the product team.
Honest Reflection
What surprised me: how much of the "UX problem" was really a service-ownership problem. The portal's confusion about who it served traced straight back to organisational ambiguity about who owned which part of the customer relationship. No redesign could have fixed that, and it took the blueprint to make it visible.
What I learned: AI changes the economics of a discovery when it's embedded across the whole process, not bolted onto one task. Transcription and analysis dropped from days to hours, prototyping from weeks to days, but the deeper shift was that holding the entire research context at once kept every design decision traceable to specific evidence, even as a team of one. It's why a solo consultant could go both deep and wide in 12 weeks. Used carelessly it just adds noise; used well, it pulls the hard conversations forward to when they're still cheap to have, and keeps the work honest to what customers actually said.
And the part I'd keep: bringing the hard version to the room. The easy deliverable was "here's a nicer portal"; the honest one was "the portal isn't the problem."