A growing company with no shared way to compare priorities.
Inquisitive is a curriculum-aligned teaching platform used by tens of thousands of primary school teachers across Australia and the United States. The product was growing, the team was scaling internationally, and the volume of feature requests was growing with it. That is a good problem to have. But there was no system for capturing, organising or comparing those requests.
Feature ideas lived in Slack threads, email inboxes, deprecated Trello boards, and the product team's Jira. Some were written down. Many existed only as conversations. There was no metadata, no tagging, no way to weigh one idea against another. When an idea gained traction, it was usually because someone had repeated it recently, not because the evidence behind it was strong.
As Inquisitive expanded into the US with a separate team sharing the same product, this gap widened. Two continents, more teams with legitimate needs, and no shared visibility into what users were actually asking for. Good ideas were surfacing across the organisation, but there was no way to see them all in one place, compare them on consistent criteria, or understand the real volume of demand behind any one of them.
The product and development teams shipped well once priorities were clear. The gap was in how we arrived at those priorities.
I UX'd the UX process.
As Head of User Experience Design, I wrote a formal proposal for a centralised product discovery process and presented it to leadership. The proposal was deliberately upfront about one thing: the value would come from the culture and process change, not the tool.
The value would come from the culture and process change, not the tool.
I chose Jira Product Discovery as the system, configured it myself, and migrated roughly 300 existing ideas into it. Every idea was tagged by customer segment, key result, product area, and stage in the teacher user journey. For the first time, the organisation had a single, searchable, comparable inventory of everything users had asked for and everything we thought they might need.
But a system nobody uses is just a database. The critical design challenge was adoption, and I approached it the same way I would approach any product problem: reduce friction and meet people where they already work.
I brought the system to Slack, not the other way around.
I started the rollout with the support team. They had their ears closest to the ground, fielding customer conversations in Intercom every day, and empowering them to elevate that voice was a natural first step. I installed the Jira Product Discovery Chrome Extension so they could highlight a customer quote from an Intercom conversation and attach it directly to an idea without leaving their browser. Once the support team had proven the value and the insight volume was visible, I expanded the extension across both the AU and US teams and trained every customer-facing team member. I set up Slack workflows so that any new feature request submitted through Slack fed directly into Discovery.
Capturing an insight went from something that required opening a separate tool to something that took seconds. People did not have to change their daily routine. They just had a faster, more visible way to do what they were already doing.
I also embedded feedback capture directly into the product.
I implemented "give us feedback" buttons throughout the Inquisitive experience at key touchpoints: after completing a unit, after using a new feature, at moments where teachers were most likely to have an opinion worth sharing. These buttons generate a daily stream of insights that flow directly into Discovery. They also create something equally valuable: a pipeline of real customers who have volunteered to talk. When I need to research a problem, I reach out to the teachers who already told us what they think, and I interview them directly.
Within one month, 95% of actionable written feedback was being captured.
The remaining 5% were ambiguous or hard to categorise until enough similar insights accumulated to form a clear pattern. That is the number. Here is what it made possible.
With hundreds of insights attached to over 300 ideas, the organisation could see a clear distribution of what users actually cared about, across both markets, at scale. High-impact, low-effort opportunities surfaced naturally, particularly around revenue, conversion and retention. Ideas that might have sat in someone's inbox or fizzled out after a single Slack conversation now had visible, measurable demand behind them.
The product team gained the ability to have evidence-based conversations about priority. When we believed an idea was important, we had the customer data to support it. When we were uncertain, the insight volume told us where to invest in research. Every prioritisation conversation became grounded in what teachers were actually telling us.
Every prioritisation conversation became grounded in what teachers were actually telling us.
The broader shift was cultural. Teams across the organisation started collecting and attaching insights because they could see that it worked. If you believed in an idea, you built the case with data, and the system gave that case visibility. The teams that adopted it fastest were the ones who had already felt the pain of good ideas going unheard. Adoption was not difficult because the solution aligned with what people already knew was needed.
A concrete example: removing the friction that doubled student onboarding.
Early in the platform's life, adding students to a class required an email address. For a product used by primary school teachers, this was a significant barrier. Many young students simply do not have email addresses.
The feedback came through Discovery. Teachers were asking if there was any other way to add students. I spoke to them directly and found two distinct groups: teachers who used Google Classroom and wanted to import students from there, and teachers whose students would never have emails and who needed a simpler alternative.
We built both. Name-based student addition, the simpler of the two, overtook both email and Google Classroom import almost immediately after launch. It became the primary method teachers use to add students. Within three months, the number of students added to the platform had doubled.
Within three months, the number of students added to the platform had doubled.
This mattered because one of Inquisitive's core company goals is getting as many teachers as possible using the platform online with their students. A single piece of friction, one that we only understood properly because teachers told us about it and we had a system to capture and act on that feedback, was the bottleneck. That full loop — feedback captured, customer interviewed, solution designed with evidence, feature released, follow-up with the people who asked for it — is the system working as designed. The Planner case study is another example of this process producing a feature that became central to the platform.
What I believe about building products.
Every idea deserves to be tested. An idea is never inherently bad or good. If you believe in it, go out, talk to people, and find out the truth. You will often discover something better, or something completely different that you would never have arrived at from inside a meeting room.
The hunt for those insights, the conversations with real users, the moment when the data confirms or redirects your instinct, that is where the value is. A discovery process makes that hunt structured and visible. It means that when we ship something, we can trace it back to a real person with a real problem, and when it launches, we can go back to that person and ask whether we got it right.
I built this system because the work we were doing deserved better inputs. Every team at Inquisitive was trying to build the right things. This gave us a shared way to figure out what those things were.