A magic question: What problem are you trying to solve?
I once sat by two engineering leaders who were phenomenal at handling requests for new software features. Often team members would come to them and insist on something like, We really need to add a new feature that lets users do X. Our users are clamoring for it. We might lose customers over this! The leaders would respond, What problem are you trying to solve? The conversation immediately shifted to a discussion about root causes, user goals, business value, and real evidence. More often than not, it quickly became clear that the proposed solution was not the right thing to spend time on.
Applying the question in techcomm
I love as a technical writer when someone on the team comes to me with a request for new content. It shows they see the value of content and trust me to help. But this magic question works just as well on the requests I receive as it does on product feature requests. For example:
Request: "Can we make an FAQ for new customers?"
Actual problem: New customers don't know our help site exists, so they never find the answers already there.
What might actually solve it: Introduce the help site during onboarding.
Putting the question into a process
A company I worked for used Jira heavily across the org. I created a Jira form and asked team members to use it to pass on their requests. I knew the form needed to be as short and as painless to fill out as possible, so I narrowed it down to five questions, with the most important at the top:
- What problem are you trying to solve?
- Describe the new content you're requesting.
- Who is the audience for the content?
- How urgent is this request?
- What have people been doing until now to meet this need? (A second magic question!)
Urgent is the most overused word in any request queue. For that question, I set up four options to help understand the request:
- Mission critical: Blocking a launch, legal obligation, or customer impact. Must address immediately to prevent measurable harm.
- Time sensitive: Tied to a specific date or event with external visibility. Delay would reduce relevance or credibility.
- Nice to have by a certain date: Helps a project or team but is not time-bound. Not blocking or externally visible.
- Flexible: Schedule when capacity allows. No impact if delayed. Optimize timing for impact.
CONTENT DEVELOPMENT / CONT-142
A new step-by-step guide for the reporting feature, with scree…
Problem to solve
Customers keep opening tickets asking why their report is missing records after they apply the date filter.
Requested content
A new step-by-step guide for the reporting feature, with screenshots of every filter.
Existing content
Existing reporting article; support macro for filter questions
A submitted form immediately became a ticket on my technical writing Jira board. This was helpful for a couple reasons:
- The requester gets status updates. Because the requester is the ticket reporter, they get notifications of status changes and new comments.
- Communication around the request is visible. Questions, answers, and progress updates happen in the ticket comments instead of private Slack conversations.
- The requester can see the trajectory of their request. My project's Kanban board shows where the request sits in the queue and what's ahead of it.
- A Jira dashboard shows my capacity and progress. Tracking what's on the table helps me and my leadership scope and prioritize.
Answering the question
Next, the requester and I worked together to scope and prioritize the request. A couple more magic questions helped frame the discussion:
- What percentage of this request comes from customers?
- How much time will implementing this request save?
- Is this more important than other things I'm working on delivering?
From there, we could finally get down to whether it made sense to do what was asked, try another approach, or deprioritize the need.
Measuring the answer
Finally, possibly most important of all: measuring if the intervention made a difference. Going back to the example above, where I avoided creating a new FAQ in favor of improving awareness of a help site that already had the answers, I put in a request for a visualization that showed if customers from a given organization visit the help site.
Where are the site awareness and education gaps?
Users at each organization with at least one article view vs. total users at that organization
View date and User creation date sliders gave extra insight into things like how long it takes for customers to visit the site after an organization finishes onboarding. That way, I'm one step closer to figuring out how the education failure occurred.
Softening the answer
It's important to note that good interpersonal skills (especially empathy) are critical when asking this magic question so the requester doesn't feel shut down and stop sharing ideas. They feel the pain firsthand and know a lot of things I don't. But in my experience, most people I've worked with have been more interested in solving the pain point than insisting on their solution. Ultimately, they're happy to see the needle move toward a better experience for users.
