What’s Next For Citizen? 

Background: At the highest-level, Citizen has two primary goals over the next 18 months: managing expansion and monetizing. I’ll dive into

  1. what drives Citizen’s current strategy

  2. the factors when considering expansion

  3. options for maximizing growth

  4. options for monetization.

Strategy:  

Citizen’s high-level strategy needs to optimize for a couple of things:  

  1. Notifications win all (Relevancy + Speed): maintaining the quality and open rate of notifications while beating traditional sources of emergency information to the punch.

  2. Efficiently collecting and filtering data at scale: Data in each additional market is relatively idiosyncratic (both in source and structure). This data enables the notification system. Need to think about:

    • how to best collect data (building an efficient data pipeline). While the R1 devices presumably capture most dispatch, there are some areas where information flow is cut off, which involves working with municipalities

    • best practice systems on how to filter for relevant information (while optimizing for cost)

    • Infrastructure: support sudden upticks of rich content generated by users without increasing in-app latency

  3. Setting Up for Monetization: While VC money will help subsidize product expansion indefinitely, the uniqueness of the product (a utility with no personalized data collection or $ transactions) means there’s no obvious path on/off switch with Citizen’s monetization (as with Facebook <> ads). Each pathway has to be tested on a small scale well ahead of full-scale rollout.

Future Growth:

Citizen has the inverse problem of most startups: pent-up user demand but not enough bandwidth to actively support expansion. This still an awesome problem; in today’s world where acquisition costs increase exponentially for incremental users, purely organic growth with high upfront costs is a very solvable problem.

Factors Driving Expansion:
Citizen has to consider the following before entering each market:

  1. Variable Labor Costs: Citizen’s labor costs scale linearly. Even thought their data collection system transfers across markets, they still need to hire new analysts to parse + analyze crime reports, monitor and replace user generated content, and identify the best notifications in each new market. While internal software augmenting the analysts might also get incrementally better at extracting potential incidents with more data (keyword “murder” = flag), every potential outbound notification will still need to be manually written and reviewed because the downside of getting things wrong even once are so high. 

  2. Data Structure/Gov. Relationships: Even though Citizen captures all dispatch data automatically, every city has different formats of reporting data. Government data isn’t standardized; some cities use different codes, different forms of incident reports, and some such as LA even encrypt radio communication. Working with certain municipalities to optimize data collection for a region is a huge burden and their receptiveness varies.

  3. Choosing Cities To Enter: Citizen has a way of spreading exponentially once it solves the cold start problem in any city – users simply send events, other people observe their colleagues on phones, etc. But when deciding which cities to enter, there’s some level of planning involved. This might involve testing structured growth (PR/Partnerships, paid advertising, SEO, etc.), working through market statistics (crime rate, population, etc.) and also determining how to leverage the traffic from Citizen’s nearby existing markets might spillover (i.e. users on an existing waitlist).

  4. Infrastructure Uptick: Each city brings on additional load of rich-content (i.e. video, images) and the app must be optimized for batch-opens at certain times (probably based on historical, public data, though there might be some intuitive predictions like more crime occurs at night, etc.). This is important because you have to actually predict the rate of growth in addition to existing traffic numbers.

  5. Figuring Out Notification Relevancy: Different cities have users that are receptive to different notifications. Take for example a burning building: I would presume that New Yorkers would be way more concerned with a burning building than SFers because it affects 30x the people due to the size of buildings. I suspect NLP/ML helps build a local maxima; that is it becomes exponentially easier to target relevant notifications in one geography once there is an open/ignore feedback loop, but this doesn’t scale from city to city.

 How To Maximize Retention/Engagement:

Engagement vs. Relevancy: There is a strong tradeoff between notification relevancy and engagement for Citizen. This is probably a quantitative internal solution already in place; not only just deciding which notifications are sent out, but the relative strength of the notifications (1-10) and what pattern of notifications to send based on how users interact with the notifications

Retention/Engagement: Engagement might actually just be a function of the amount of unrest/events that are going on in area at a time! If there is low unrest, sending notifications for retention purposes is going to spark “fear-mongering”.However, there are potential ways to make the “engagement highs higher” when unrest is high, both by repurposing existing data and potentially building out a couple of small features that also help users.

  1. Status of Existing Contacts: This would essentially be an extension of the “invite contacts” growth mechanism. At larger scale events (parades, protests) people might also want to know the status of their friends, especially if things get unruly. While existing tools are out there, they both have flaws:

    • Find My Friends can accurately tell location but doesn’t layer on areas of conflict. So I can know where my friends are at any given time, but I also have to be acutely aware of the events in the area

    • Facebook Check-In has a lot of friction involved. I’d have to go to the app, check a friends page (if they chose to mark it, which isn’t anyone’s first thought) and this only applies for certain events as well
      The implementation of this would work by:

      • Having some type of in-app affordance asking users to “add loved ones”

      • Asking users to select their friends (can be single or double opt-in, permanent or temporary)

      • Giving all users the ability to

      • Mark themselves safe at anytime and broadcast that to their friends

      • Message their friends at any given time; this involves  

      • And potentially live-broadcast location; this seems like it would be a potential technical nightmare, judging from the extensive process on Facebook’s implementation of “Users Nearby” features

  2. Generating Crime Reports In-App: This is more of a reach, but a feature to think about is actually filing police reports in-app for crimes not in progress. The background behind this is simple; reporting for crimes not in progress (lost/damaged property, non-violent theft, vandalization, indecent exposure, etc.) is a nightmare. It involves calling the police department (within very specific hours), talking to an officer, who will then route you to a not easily accessible online form for the municipalities broken website that requires copious amount of personal information and a clunky UI. Working with local police departments to help standardize this process and bring it onto Citizen’s app could be beneficial to all parties. 

  • For users: Gives them an easier way to take action and grows their usage/trust of Citizen’s app. Unlike user generated content, this wouldn’t be publicly sent, so it doesn’t have to be screened and scales nicely. Citizen’s existing info (your name, your location, phone number, DOB, built-in-camera) can easily be repurposed to streamline filing out a report. 

  • For municipalities: Helps build a more efficient reporting system (i.e. no phone calls needed initially). Plus, a standardized format with adjacent municipalities helps for easier sharing of incident reports. Any value created for municipalities creates goodwill for Citizen on data collection fronts and this could potentially be a first step.

  Very roughly, the implementation of this would look something like:

  • Building relationships with a few municipalities so that any reports would actually be piped into their reporting infrastructure

  • Initially roll out to small subset; a good starting point might be using the same AI that helps filter out keywords from dispatch reports as a prompt for a report when users are uploading content. An example might be “theft in Brooklyn” and as theft is unlikely to be a crime-in-progress, ask a user if they want to also file a report. Since this would happen after a post, it wouldn’t create any extra friction.

  • Create a separate tab for a simple form, pre-populating some information based on their method of signup (i.e. Name, DOB, Location, etc.)

  • Measure how frequently feature is used before scaling out! 

That being said, an alternative path around the notification/engagement tradeoff is using distribution/massive user base to drive organic engagement to secondary features while maintaining the existing notification system.

Features Possibly Driving Organic Engagement:

  • Non-emergency foot traffic: Waze for Hyper-local Foot Traffic! To help keep engagement high year-round. A long-shot as it doesn’t fit

  • ·Community News: Covered under monetization below

Monetization:

Citizen currently is focused exclusively on growth, but the high-fixed costs associated with expanding into new markets means that they will probably have to find a way to monetize before fully hitting all big metropolitan markets (and expanding international markets will further increase the cost/market due to the need to build infrastructure that supports a  completely different flow of filtering data sources).
Monetization for Citizen will be far trickier than growth. Consumer apps have traditionally monetized in four ways:

  1. Infrequent usage, per transaction costs (Uber, Transferwise, Airbnb, Earnin, etc)  -> N/A

  2. Increasing usage of existing features, engagement-based revenue (Ads, Facebook, Google, etc.)  -> N/A

  3. Constant usage of existing features, monetizing underlying data (Robinhood, 23andMe)

  4. Increasing usage + monetizing through add-on features (Headspace, Games, Nike+)

  5. Realistically, my intuition tells me monetization will come down to two options, both of which have pros and cons. The north star here is that Relevant Notifications are the lifeblood of Citizen – anything that dilutes the open rate or amount that can be sent won’t work.

Selling underlying user data (pseudonymous): Having underlying location data for specific times of the day, in very specific geographic clusters is extremely powerful (Foursquare is doing almost $100 million ARR despite not having a product that anyone uses).

a. Government: At the highest level, Citizen is fundamentally taking unstructured data from the government, filtering it by tying it to additional sources and then can gauge the number of relevant users affected. By doing this it has a much richer data library than the government. This data is incredibly valuable to the government for emergency resource allocation; distribution and number of emergency workers (cops, ambulances, etc.) needed in a certain area, catastrophe/evacuation headcount planning, etc.
b.  Private Retail: By merely parsing user geo data from notification opens, there’s a huge opportunity. How many people were at H&M on Thursday at 2 PM? How many people were visiting Retail Shop X this month? There’s a ton of willing buyers here: retailers themselves, equity hedge funds, companies using high-traffic retail for lead generation (Faire). Ideally you would want to get close 100% user adoption in a city before doing this – saying that 8% of the city was in X location with a small margin of error is unfathomably valuable. But even with a smaller population size, relative density is valuable; how is a store doing on Thursday relative to Tuesday at 2PM?

Cons:

a.  PR Nightmare: Even assuming this was purely pseudonymous data, there is increasingly backlash for companies selling data and consumers might not be able to perceive the difference. Given that Citizen is a nice utility not a must-have tool (i.e. Facebook), this could literally tank the company. There’s already been multiple PR pieces which have been critical of Citizen’s usage of location data that the company has had to deflect.

b.  Structuring Data For Monetization Consumption/Network Density: The raw location data needs to be cut-up and formatted in different ways for different types of customers who want different types of insights (time series, density, etc.). A good proxy for thinking of this is credit card data; 3rd parties like Cardlytics work on top of the receipts to aggregate and build the end-data for users. This brings in another set of trade-offs:

  • Do you acquire and deal with end-customers in-house (building a BD team, solutions engineers, filtering the data, etc.)? This is going to probably increase cost of revenue in the short term, but brings about the opportunity for long-term enterprise contracts

  • Do you sell data to a select group of 3rd parties who then reach the end-user (i.e. Cardlytics?). There’s the risk of not holding a strong relationship with the end user, both in how they actually utilize the data (i.e. Cambridge Analytica) and if the third-party doesn’t help the customer extract maximum value out of the data (churn)

  • A self-serve model for consuming raw data through some sort of API; this is a very public option but cost of revenue is negligible and scales linearly with the amount of data available/demand.

·Local-based features that increase organic opens: There’s a product-driven alternative where the emergency notification service is just the loss-leader for a community-driven news network that essentially replaces what we’ve traditionally considered “local news” (i.e. Nextdoor or Patch). This sounds very stupid on paper but having all people on a single platform where they are conditioned to look for local events is actually a relatively perfect gateway (use distribution to be build a platform). Citizen’s core user is:

  • Very civic-minded, especially the small subset that are actively helping filter reports and stay on scene to film videos

  • Active in sharing relevant local content to small groups around them (sharing Citizen updates via iMessage, Facebook Messenger, etc.)

  • Occasionally checks the app even when events don’t affect them (curious about local events)

In practice, this works where the emergency notifications operate in their current form, but users are interested enough by the extended local content to check in organically. Depending on your view of the viability of Nextdoor, this could be filtered user-generated content or centrally generated content, with a rotating cast of freelance writers mixed with existing central ops analysts. This extends beyond Citizen’s existing “event-driven” news digests, covering:

  • Local news issues (education, elections, community issues, sports, etc.)

  • Events (volunteer opportunities, community events, town halls, etc.). Depending on how hyper-local the feature is, can eventually scale out to user generated hyper-local events

  • Breaking news that is not safety related (school closures due to inclement weather, highway closures, etc.)

    From a monetization perspective, having people organically visit the site creates a lot of flexibility for traditional methods: classified ads, premium-subscription (for access or to get a bundle of discounted local services), etc.

Cons:

  1. UX Tradeoff: Citizen has already maximized it’s UX space throughout the app; the layout is clean, with a single-menu and tools. Expanding onto what’s essentially a completely different interface could potentially lead to feature creep and a hard to navigate user experience, especially if rollout isn’t managed properly. The roadmap here is probably to rollout to a small number of users and quantitatively test a couple metrics

  • Overall user churn (marker of overall user reception/confusion)

  • Uptick in overall engagement time over an extended period of time (value and cannibalization of core feature)

  • Share % (long-term viability/virality of content)

  • Aggregate user stories and test drop-off points (subparts of the feature that aren’t catching on) 

2. Brand Dilution: Currently, Citizen is positioned primarily as a safety network and nothing else. Building almost a quasi-social network layer on-top of things would potentially bring massive amounts of user confusion about what the app is supposed to do. The counterpoint is that users would become sticky enough in their usage that this this shouldn’t theoretically matter.