Sami Surakka

Context

Market research studies on Cambri combine quant and qual data from hundreds to thousands of respondents. For the enterprise research teams using the platform, turning that data into a clear, persuasive narrative is slow work: a good report can take days. Cambri set out to change that by building a reporting feature that could help teams deliver a high‑quality report in roughly an hour, without sacrificing the depth and nuance they needed.

The brief came from exec level: automated reporting, with adoption as the primary measure of success. Managed services, Cambri's internal research team who run studies on behalf of clients, were the pilot and the first to touch the feature. Serving every account was always the goal. What tightened was the timing, and with the surface still large and engineering still underway, that timeline ended up being unrealistic.

Solution

I started with a workshop across the business, then defined a high‑level vision: a WYSIWYG editor that pulls data from across the platform so researchers don’t have to jump between studies, export results, and stitch them together by hand. That editor approach was flagged as a scope and timeline risk from the start. I validated the vision with key clients before implementation and kept it grounded with ongoing interviews.

The ambition we landed on was an opinionated automated report: the system would decide what mattered and produce a finished document. My early 2025 exploration was broader, including data exploration, manual insight discovery, and transposing tables. Those were cut as scope tightened. With managed services as the pilot, deferring exploration was a reasonable call on what we knew then. Engineering spent months on the technical foundation for automated reports. Later in the year, a client evaluating the platform asked for something more curated, and because that feedback arrived through a live sales case it pushed the direction firmly towards the curated automated report.

Within the editor I designed AI-generated concept one-pagers, test summaries, and recommendations as built-in types, so researchers could move from raw data to a finished narrative without rebuilding anything by hand.

Impact

The reporting editor shipped and is in use by both managed services and client teams. It has helped close new sales by showing how fast Cambri can get a team from raw data to a finished report. Managed services, the internal pilot, use it routinely.

Reporting is a specialist feature, so the fair comparison is secondary and power-user adoption rather than core features. Userpilot's 2024 study puts average core-feature adoption at 24.5% and the median at 16.5%. Practitioner ranges put specialised features at 15–30% and power-user features at 5–15%. Repeat use and empty drafts have no fair counterpart.

Measured over 90 days: 53% of active client organisations created at least one report, 9% created more than three, 31% of creation attempts ended as empty drafts, and 56% of client reports were automated. Active means any testing or reporting in the window. Client counts are confidential, so these are shares of a few dozen organisations, direction rather than precision.

Market research is cyclical. Reporting happens in waves after a study, not as a weekly habit, so one report in 90 days among orgs that were testing is a completed cycle rather than a trial, and more than three in the same window is intensive.

Org-level use sits above those ranges. The fair comparison is the per-user figure below, which lands in the power-user band. Empty drafts are the number that stands out, though an empty draft is not a failed attempt: someone who could not structure a report leaves the same trace as someone opening the editor to look around.

Coverage is the likely cause. Automated reports only handle product-concept tests, so everyone else had to build by hand, and known discoverability problems in the custom editor were left unfixed because automation was the bet. That stays a hypothesis: I never instrumented the funnel.

Customer success used this 90-day view to target accounts that had never created a report. The product question moved from whether anyone was using it to who repeats, and which test types still have no automated path.

Twelve months of analytics showed creation concentrated in a handful of users (roughly a third of all reports) and the top two dozen or so (about two-thirds). That concentration, and reporting monthly active users peaking at roughly a tenth of the product total, is what a wave-based workflow looks like: most people are not in the editor every month. The per-user figure is still the one to hold against published adoption rates, and it sits in the power-user band. Exports grew from nothing to their peak in June while creation held steady.

Reporting was partly usable from August 2025. Full v1 landed in January 2026 after several slips. Creation was already climbing in December, so there is no clean release step.

Role

As Lead Product Designer and Product Manager I owned the vision from the workshop through implementation, and partnered with customer success, managed services and engineering on scope and trade‑offs. QA, revenue operations, marketing, and sales were in the work as well.

Beyond design I built a shared three-month roadmap in Miro and worked it into weekly planning, replacing a view of upcoming work that rarely reached beyond one or two weeks, and a prioritisation framework scoring customer value, business value, and technical feasibility. As the roadmap settled, reviews dropped from weekly to every two or three weeks. Release practice was the other gap: reporting reached clients with no staged announcement and no enablement. Improving that was part of the product duties I took on through late 2025 and 2026. Planning rituals across engineering, product, customer success, managed services, and revenue operations only stuck with customer success once the CS team began running them.

Reflection

This was a solid first release against the brief: more than half of active client orgs use it, managed services use it routinely, and automation became the majority format. What surrounded it is typical of a first release on a small team.

The vision held and the designs barely changed. Two bets around them did. Early scope cuts dropped data exploration, which was right for an internal pilot and thin once clients were on the same editor on a tighter clock. A sales-case request for curation then treated curated and full-data output as an either/or. They are not.

What followed is familiar: a surface too large to ship in slices, a rollout to everyone at once, and a coverage gap that stayed open. The missing piece is a full-data output for researchers who want to choose for themselves. That work is queued behind survey programming.

Given the same brief again I would keep curated and full-data on the table together, and I would track the creation funnel before shipping. That thinking went straight into the later survey programming work, where the default path was built for the person who is not a researcher and the professional depth sits behind it.