What Journalism Taught Me About Building Public Safety Products
Reporting and product development share the same core habits. Start with specific questions that reveal real behavior, listen for details that do not fit, verify confident claims, observe the work in its setting, write for the actual audience, use plain language, sweat the exceptions, edit ruthlessly, and correct mistakes openly. Understand the story before deciding what to build.

Journalism taught me to listen, verify, observe and understand the audience before deciding what the story, or the product, should be.
Before most of my career turned to websites, marketing, services and technology, I was a journalist.
I was a senior editor at The Diamondback at the University of Maryland and later served on the board of its nonprofit. I worked full time for a regional newspaper and freelanced as a reporter and photographer for The Washington Post and the Associated Press.
Journalism and product development may look like different professions, but 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. And 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 whole story. Keep asking until the workflow, responsibility and consequences are clear.
Listen for What Does Not Fit
Reporting gets 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 on the table. The detail that does not fit may be the most important thing you learn.
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 more conversations. One chief, administrator or longtime member may bring 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, the interruptions and the ordinary routines explain things people forget to mention.
Watch users complete the task. Notice which notes sit beside the computer, which spreadsheet stays 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 will 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 people 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 evidence that someone did the work to make the idea understandable.
Details Create Trust
Good reporting includes the details that let the reader understand what happened. Good products handle the details that make a workflow dependable.
The ideal demo is easy. The real value shows up in the exceptions: a duplicate member, an expired credential, a changed rank, a failed integration or an 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
Good editing means deciding what belongs, what distracts and what the audience needs next, on top of correcting sentences.
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. So do product teams.
Waiting for perfect certainty can block 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 dressing up a guess as a fact.
Corrections Matter
Credible journalism corrects its 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.
Treat support conversations and failed implementations as seriously as 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.

About the author
Dave Iannone
Founder & Chief Product Officer
Founder of Firehouse.com and Firefighter Nation, a veteran entrepreneur and lifelong first responder and leader.




