What Journalism Taught Me About Building Public Safety Products
Before much of my career became focused on websites, marketing, services and technology, I was a journalist.
I was a senior editor at The Diamondback at the University of Maryland, later served on the board of its nonprofit, worked full time for a regional newspaper and freelanced as a reporter and photographer for The Washington Post and Associated Press.
Journalism and product development may look like different professions. Much of the work is surprisingly similar.
Both begin with incomplete information. Both require understanding people, identifying the real problem and separating what someone says from what actually happens. Both fail when the creator becomes more interested in the output than the audience.
Start With Questions
A reporter does not begin a useful interview by explaining the article they have already decided to write.
The same should be true when building a product. Ask what people are trying to accomplish, what happens today, where the process breaks and what they do when the official workflow fails.
Questions should be specific enough to reveal behavior. “Would you use this?” invites optimism. “Show me how you handled the last certification renewal” reveals the actual work.
The first explanation is rarely the complete story. Keep asking until the workflow, responsibility and consequence are clear.
Listen for What Does Not Fit
Reporting becomes interesting when the facts do not match the expected narrative.
Product research works the same way. A department may say scheduling is the problem, then reveal that qualifications are outdated and officers do not trust the roster. A request for a dashboard may actually be a need for consistent data and clearer responsibility.
Do not force every answer into the product idea already under discussion. The detail that does not fit may be the most important thing learned.
Verify the Claim
Journalists learn quickly that confidence is not evidence.
Product teams hear confident statements too. “Everyone does it this way.” “Members will never use that.” “The integration is easy.” “The customer needs this feature.”
Verify through observation, data and additional conversations. One chief, administrator or longtime member may provide valuable experience without representing every department.
This does not mean distrusting users. It means understanding the difference between one perspective and a market conclusion.
Observe the Work
Some of the best reporting happens outside the formal interview. The environment, interruptions and ordinary routines explain things people forget to mention.
Watch users complete the task. See which notes sit beside the computer, which spreadsheet remains open and who gets called when the process fails.
Public safety work also changes by setting. A task completed in an office may feel entirely different on a phone, at the station or during an incident.
Observation turns abstract requirements into context.
Understand the Audience
An editor asks who needs the story, what they already know and which details help them understand it.
A product needs the same discipline. The executive, administrator, officer and frontline member may use the same system for different reasons. A screen designed for the person receiving a report may burden the person entering the information.
Build for the audience doing the work, while giving other stakeholders what they need from the result.
Use Plain Language
Public safety and technology both accumulate terminology. Jargon can create precision among experts, but it can also hide weak thinking.
If a product team cannot explain the problem in plain language, it may not understand it. If users need a glossary to complete a routine task, the interface may be organized around the system rather than the person.
Clear language is not simplistic. It is evidence that someone did the work to make the idea understandable.
Details Create Trust
Good reporting includes details that allow the reader to understand what happened. Good products handle the details that make a workflow dependable.
The ideal demonstration is easy. The real value appears in exceptions: a duplicate member, expired credential, changed rank, failed integration or incomplete record.
Those cases may not look impressive in a presentation, but they determine whether people trust the system after launch.
Editing Is Product Work
Editing is not simply correcting sentences. It is deciding what belongs, what distracts and what the audience needs next.
Products require the same restraint. More features, fields and options do not automatically create more value. Every addition competes for attention and creates another decision, permission or support responsibility.
The ability to remove is as important as the ability to build.
Deadlines Require Judgment
Newsrooms make decisions with limited time and incomplete information. Product teams do too.
Waiting for perfect certainty can prevent useful progress. Moving too quickly can create errors that damage trust.
Define what must be known before launch, what can be tested safely and what requires continued reporting after release. Be explicit about uncertainty rather than disguising a guess as a fact.
Corrections Matter
Credible journalism corrects errors. Credible product teams acknowledge when an assumption, configuration or feature did not work as expected.
Defensiveness delays improvement. A clear correction, explanation and follow-up can strengthen trust when the organization responds responsibly.
Listen to support conversations and failed implementations with the same seriousness given to praise. They often contain the most useful reporting about the product.
The Work Is About People
Technology can make product development feel like a collection of screens, requirements and tickets. Journalism kept reminding me that every process belongs to people.
Someone is trying to fill the shift, onboard the member, prepare the report, communicate the change or help the resident. The product succeeds when it understands that responsibility and makes the work better.
The tools of journalism still apply: ask, listen, observe, verify, explain and correct.
Long before deciding what to build, understand the story.
For the field-research companion piece, read Public Safety Vendors Need to Spend More Time in the Station.
Tools for this topic
Free interactive tools to put this into practice.
AssessmentTechnology Continuity Risk Check
BuilderTechnology Connection Mapper
AssessmentTechnology Access Resilience Check
Part of the seriesPublic Safety TechnologyExplore the series Recent posts
All posts →
