IE 11 Not Supported

For optimal browsing, we recommend Chrome, Firefox or Safari browsers.

GovTech Founder Series: Founders of Public Safety Software Startup Mark43 on Launching, Long-Term Vision

Public safety has felt the positive impacts of Mark43 in a surprisingly short period of time.

It’s no secret I am a huge fan of Mark43. I’ve gotten to know them over the last couple of years and have a ton of respect for their product, culture, and the impact they are having on the way policing is done in this country. The founding team was kind enough to take some time to talk about how they went from a class project to a juggernaut in the public safety space in a very short period of time. All three co-founders joined the interview.





The interview has been condensed for clarity.

Nick: Let’s start with the company background. How did Mark43 come into existence?

Matt: In the spring of 2012, Scott, Flo, and I were students at Harvard. We were all apart of the same business strategy class and were presented with a client and a specific problem. Our assignment was to recommend a strategy or solution to solve the specific problem.

Lucky enough, the client was the Massachusetts State Police. Our professor, who was in the Reserves, had actually served with them in the Middle East. These Massachusetts State Police had been fighting insurgents in the Middle East, and they said, “You know what? All these tactics that we’re using to fight insurgents, they could be used to fight violent gang members. These gang members behave very much like insurgents in the Middle East.” So, they brought these tactics back and started deploying this new policing model in Springfield, MA.

The new policing model was designed to target the gun and heroin trade along the East Coast. In Boston, it’s really hard to get firearms, but actually relatively easy to get opioids. In some places, like New Hampshire and elsewhere, it’s actually the opposite. Easier to get guns, more challenging to get opioids. Historically, police have applied the “breaking down doors,” physical approach to fighting the trade. The new model, however, was much more about engaging with community leaders, trying to reduce open-air drug dealing. Reducing the amount of graffiti that’s been posted, or how long graffiti stays up.

By the time they showed up in our class, they had seen some anecdotal success. People said, “Oh, things feel safer. And things seem better.” But their issue was that they didn’t have any hard numbers to really understand if crime had gone down or changed in any meaningful way based on deploying this model.

Our professor at the time volunteered our class to help. He told them, “I’ve got 12 kids, they can pretty much come into the field for this entire semester and learn about how crime has changed in the community and do some sort of analysis.” So, we went in. Our group was part of the software group. We started out by building an application that did some basic analysis. However, as we started trying to collect all this data that would be used to inform our analysis, we realized that the software the police officers had was total garbage.

You expect to see all of the crazy technology that you see on CSI but that doesn’t exist. It doesn’t exist in any way, shape or form. After seeing the garbage software, our professor was awesome and said, “You guys run off in your own direction. Try to build them something that could help them out somehow, some way.” So, we did that and Mark43 was born.

Nick: That’s fascinating. So, the idea is born. What happens next?

Matt: The first problem that we were kind of trying to solve was this social networking problem, and not social networking in the way of Facebook and Twitter. More about how people communicate and how people know each other, and how you can use that to kind of inform police initiatives. Effectively trying to connect criminals through common networks.

We had some success with that. We continued working on it after our junior year (of college), over the summer. Right before graduation, we won the president’s challenge, a entrepreneurship challenge across Harvard. And then simultaneously, right before graduation, we raised about $2.2 million from Spark Capital, General Catalyst, Lowercase Capital, and other small angel investors. The capital was intended to determine if there was a real need in the market, and to understand whether police officers could really benefit from an injection of new technology.

From there we went out to Torrance, CA, and we were working with the Torrance Police Department. We would sit with the gang unit in their trailer in the back of the department and watch and observe everything. Then we would go back to our apartment, build a bunch of things, and come back and get feedback and then continue building out the application. This cycle went on for about five months.

We had some real success there. It was exciting to see some crimes actually solved using the applications we had built. And I think that’s kind of what got us excited to stay in the industry. I think that’s ultimately what keeps us coming back.

Nick: Okay. So, Torrance goes well. Then what happens?

Matt: Scott was literally walking into a final our senior year and the Chief’s Special Assistant from Washington, D.C., called and said, “Hey Scott, we heard that you guys have some technology that you’re putting together. We’d like to see if it can fit into the quilt of technology that we have at DC, or fix some of the problems that we’re currently having.” Scott said, “How about in the Fall? That’s a good time for us to come out there.” So we went out and in September we did the first demo for the Washington, D.C., police department. It was this networking application that we had been working on with the Massachusetts State Police and with Torrance, and they said, “Okay, this is really cool. This is sexy. But what we really care about … How do you submit the defense report? How do you write an arrest report? How do you do a traffic crash, or something like that?”

Nick: That’s hysterical. You guys are working on the CSI kind of stuff, and they basically ask, “How do you do the basic workflow?”

Matt: Yep. That’s the unit of work that police departments really need. What we learned right then and there was that these records management systems, those are the tier 1 applications that they need. The tier 2 stuff is all the analysis. The analysis is cool if you can do it, but you basically need the tier 2 things pulling great data from the tier 1 things. So we said, “You know what, we’re kinda dismayed that we don’t have this, and we still want to work with you guys. We’ll come back in a month, we’ll show you how quickly and agile a software company can move, and we will build the basic features that you described here.”

So we went back to California, worked like crazy people for a month, and then went back in November and showed off this new application. The Chief said, “You know what? You guys put your money where your mouth was, so let’s kick this off officially.”

Nick: This is great. So, you go from business strategy class to signing an official contract with one of the largest police forces in the country in two years. What was so different that D.C. said let’s do this?

Scott: We designed it with an officer-focus in mind. After we signed on with D.C., we spent months on the streets with D.C. Metro Police officers. We went on hundreds of ride-alongs, working with detective units, records units, IT, to really figure out how to build an RMS for 2015. When we launched Washington, D.C., we launched over 10,000 users in one night, and it was instantly a success.

And that sort of thing never happens in this business. These are super complex systems that are very hard to articulate well. Since launching in D.C. our product was able to reduce arrest reporting times by 50% and incident offense reporting times by 80%. That’s the equivalent of saving them 238,000 hours a year or the equivalent of adding 110 new patrol officers to the force.

Nick: What’s the long-term vision for the company?

Scott: We want to become the complete public safety platform. We want a department to be able to use our system for all of their digital functions. They should be able to tie in any hardware that they want. That means working with systems for the courts, the prosecutors, the jails, and tying all that together. We want to give everyone a complete and accurate picture of the health of a city.

Nick: Let’s peel this back a little bit. In the last founder interview, Zac Bookman of OpenGov and I talked a lot about critical workflows. Specifically the difficulty in working with existing systems of record. Would you consider yourselves a new system of record for public safety?

Scott: I definitely would. I think the changes we’ve made in the design of the system are significant. The way they create their data and investigate cases is so different than what’s currently done. What we found is that these old record management systems are pretty much replicating paper based processes. There was nothing designed for the digital age. That’s not how it should be working. What we’ve seen now is that when you actually rethink some of these things for the digital age, you can create a whole new category of record systems.

Nick: What’s really interesting though is when you started the business, the networking analytics piece was on top of the old system of record. But, you found the old system of record sucks. Which created a bad-inputs-gets-bad-outputs situation. But, as you got into it realized that the problem was actually significantly bigger. If you can’t solve critical elements, like the core design of the system of record and basic workflows, then everything else is just going to be a fancy façade on a shitty foundation. Is that accurate?

Scott: Absolutely.

Matt: That’s exactly it. We had to show the end users the value of actually getting the data into the system. We had to make it as easy as possible for them to just do their job. And for a lot of reasons, police officers were spending a ton of time writing paper reports or hand jamming data into an old legacy system five times in five different places. So, we designed something to get rid of those useless processes and just made the input process much easier for the officer.

Nick: Do you guys have public service backgrounds? Are your parents in public service? Or did you just find an interesting problem that captivated you?

Scott: On my mom’s side, a lot of her family was in the NYPD and FDNY back in the ’60s and ’70s. From a young age, I think probably all of us were very much instilled with this kind of idea that our first responders are heroes, and that we need to do whatever we can to support them.

And I think, speaking for Matt and for Flo, when we started getting to know the state troopers in Massachusetts, it became far more than just an interesting problem. It became a true mission for us in figuring out how we can help them.

Nick: Talk about working in public safety. It’s definitely more nuanced than a lot of govtech categories. It’s more regulated. Mistakes can result in serious consequences. I imagine that creates a different kind of pressure on the product process? I don’t imagine you get to push a lot of MVP-esque features into the product?

Matt: We actually have this conversation pretty often, especially when we are hiring new people. On a new hire’s first day we talk about our core values  —  really understanding the stakes of our work. I love consumer applications as much as the next person. I use Snapchat, and Facebook, and Twitter, and those are all fun and I get a value out of them. But, if there’s a bug pushed to somebody’s timeline, or a bug in a filter on Instagram, it’s not going to be debilitating. It’s not going to necessarily hurt somebody. But for us, if something gets pushed into our applications and isn’t right, it can be catastrophic. For example, If our product were to delay a police car getting to the scene of a crime, that’s serious. That’s really, really serious.

Nick: Potentially life and death, right?

Matt: Yeah, exactly. It requires the team to really understand the criticality of the stuff that we’re working on. And when they push code, where that’s actually going. It’s going to the hands of police officers in Camden, NJ, a city that has 6.5x the national violent crime average. It’s serious stuff that people are dealing with.

Flo: Yes, we have to be pretty careful about how we manage releases. Some agile startups in the consumer space will just push code as it’s ready, and if there’s a bug, they’ll pull it back and fix it up. We don’t have that luxury. We have a rigorous process of two week releases where there’s lots of QA involved. We actually go test the features on the client’s data and make sure that everything is buttoned up. I don’t think we could do business without it.

Nick: Does it limit your inventiveness? Does the life and death implication of getting something wrong put some constraints on the crazy innovate stuff that you could do?

Flo: To an extent. We just have to be more cautious. So if we’re doing data analytics, we want to be really sure that if we’re helping departments identify criminals, that the code is correct. We’re building tools to help detectives or public safety do their work. We’re not doing it for them.

Nick: This is an interesting challenge. You want to build technology that enables people to do their jobs better. However, you guys are helping to potentially identify a criminal through data analytics. That’s amazing if you get it right, but also could have some serious negative consequences if you get it wrong. Talk about managing that tension in the product.

Matt: First, one thing in our favor is that the bar for police technology is so low. Which means the things that we have to do, at least at the outset, aren’t crazy to get done. The rule of thumb that we have been operating on is that we’re not necessarily doing any analysis that’s telling police officers what to do. It’s more about presenting the right information and giving them more contextual knowledge that they wouldn’t have had otherwise. Enabling them to make the right decisions.

It’s not about us saying that the person is doing right or wrong. We’re trying to present as much information as possible. The main issue of course is what we discussed at the beginning. So many of these systems have really poor data input functions. They have even worse data output functions. We think the ability to seamlessly input data into the system and then subsequently extract contextual knowledge out of the application is a key differentiating element for us.

Nick: How do you resolve internal conflicts on the product roadmap?

Matt: We have a voting process. We’ve selected a constituent group of product managers, a representative from support, a representative from our client solutions team, and a representative from business development. People who represent a broad set of customer needs from different perspectives. Every product roadmap meeting, everybody gets a hundred points to distribute across features that you think are important. And by the end of that we have a collective discussion and debate, and then all buy into where we are headed.

Nick: Let’s talk about growing the business. You’ve gone from three of you to about 100 people in a short period of time. Personally, I thought that was the hardest part of my old business, managing a big influx of new people into the business. I did a ton of things wrong. What’s the hardest part about the staff growing so much so fast?

Scott: As you grow larger there’s just a lot of organization and structure you need to put in place. On top of that changing structure, communication down to the rest of the employees gets way harder. You start thinking about things like, What’s the right management structure? What levels do we have in the company? What’s our cadence for our meetings? How many times do we meet with the managers, how do we meet with the directors, how do we work with them to message things to the team?

I think every company should go through a lot of iterations on this kind of stuff, because if you don’t get that right, if you don’t make sure people are motivated, if you don’t make sure that they have great mentorship, then the company won’t have fantastic retention. That’s one of the things we’re really proud of at Mark43, our retention. I think that comes from working through the challenges of organizational structure.

Flo: It’s one of the main things we are working on right now, how do you get 100 people all moving in the same direction, pulling together and working as efficiently as possible. We had that same problem when we were three people, and the same problem when we were 20 people. The solutions to those problems are a little different at each level. With three people you have a chat, with 20 people you have an all hands, with 100 people you actually have some structure to disseminate that information.

Nick: How have you approached hiring so many people so fast?

Matt: We try to hire quickly, but with quality, too. As the adage goes, you want to be quick to fire and slow to hire. We’ve heard plenty of horror stories about bringing somebody on too quickly just because you need to fill the position. That’s a situation we’ve tried to avoid, and have pretty much done so up until this point.

Nick: What’s the most important trait of a person that wants to work at Mark43?

Scott: They have to care about the mission. It’s hard work here. If you don’t care about the mission, it’s going to create problems. It’s very complex work. This is not a test features very rapidly, very fast, break things fast kind of place. It’s mission critical. People here need to feel deeply connected to the officers and the mission. It’s one of the things that I love about our team, people connect emotionally to the first responders we work with. And it makes them so much more effective at their jobs and so much more invested in the company.

Nick: How much have you guys raised now?

Scott: $40 million.

Nick: Would you do it again? Do anything different? Raise more? Raise less?

Scott: I think we’ve raised a good amount. I think we’ve done a good job kind of spacing out the rounds and setting good criteria to raise the next round. This business will always be a very capital intensive business. When you’re building big enterprise platforms for public safety, it takes significant capital. I don’t have many regrets about how we raised money. We have phenomenal investors. We have people who are specialized in public safety, government, procurement, and most importantly, people who know how to grow a business. The composition of our investors is so good.

Nick: You had raised your first $2 million before signing D.C. How important was that to getting the D.C. deal signed?

Flo: I don’t think there’s any way we would have closed a deal like D.C. without the legitimacy that our venture investors bring. I don’t think the client would’ve felt comfortable going with us without otherwise.

Nick: Interesting. So, at least the appearance of some financial stability was critical for you guys to get that first big client?

Flo: Yep.

Scott: Yeah. That helped us land D.C. and without them, we wouldn’t be where we are. So, everything kind of came together. We owe a lot to the faith of Chief Cathy Lanier in D.C.

Nick: I think for every startup that has success, there are these seminal moments in time where if it goes the other way everything looks totally different. It certainly takes a ton of hard work and lucky breaks along the way. But, looking back, what were those critical moments?

Scott: Getting the D.C. agreement in place, without that everything looks much different. Subsequently, the D.C. launch had to go well. Literally, if that doesn’t go well, the company is over. The client, our investors, our team looked at that as a binary point of failure. That launch had to go right. I need to say this about Chief Cathy Lanier; she is one of the best police chiefs in the country. And probably in history. The woman is incredibly forward thinking. She is smart, she’s decisive, she knows how to run a department. When she made this choice it was considered to be a risky choice. And if we had failed during that deployment, it wouldn’t have been good for anyone involved. But, it went great and here we are.

Flo: One of the other big moments was the seed round. At that point, we really only had a proof of concept, at best. They trusted us and the capital gave us the ability to get going.

Nick: What’s the biggest mistake early founders make?

Scott: Hiring the wrong people. The most important hire we made early on was a great VP of Engineering. We looked at almost 100 candidates who were well-qualified. But, we never settled. Even though we had this pressure from D.C. Metro Police, and at the time literally didn’t have the team to build it out. We still waited a long time to get the right VP of Engineering. I think a lot of founders will rush to hire people. Especially engineers. If you rush to hire it effects everything.

Matt: Another thing I would add, is people say, “Oh, it’d be fun to start a company. It would be fun to build a company and have the startup lifestyle.”

Until you’re sure that you either have funding or your product has legs, there’s a ton of stuff that you can do on nights and weekends, to prove out the concept. We were lucky in a way because we were still in school when we started the company. We had a bit of a safety net in school and really nothing else to think about besides school and this company. I think understanding timing around starting a company is super important.

Nick: What’s the biggest mistake you guys have made? If you could do one thing over what would it be?

Flo: One of the big mistakes we made early on was just underestimating the complexity of the systems we were trying to replace for D.C. We had this concept of an MVP, and that just doesn’t hold up in public safety. Our clients are used to having a really, really wide swath of functionality. Even if none of it’s very good, it’s all pretty shallow, but they’re used to having it all.

The challenge for us was finding all those different user groups that use the application in different ways and do different things and making sure that we can actually satisfy their needs. Then building a proper product around all of those use cases. We could have done more investigation up front.

Nick: What’s one piece of advice you would give to a new founder in this space?

Scott: My biggest piece of advice is be respectful and humble with your clients. These people are the experts. They’re the knowledge base. You need to be able to leverage them, especially if you’re not coming from government. One of the biggest problems I see with young founders in this space is an arrogance that they can do no wrong. That just doesn’t fly in this space. When you’re dealing with 20 year veteran that is a subject-matter expert, you have to respect that.

Nick: True or false. Govtech sales are as hard as the perception of govtech sales?

Scott: I would say that the sales cycle can be long and procurement is interesting, but the more unique product you have, the easier it is to sell. I think that the industry perception that sales take so long is simply that it’s undifferentiated market. I think that one of the best things you can do is build a unique enough product that no one else can replicate it, which results in the sales cycle actually getting shorter.

Nick: I agree with you. In my view, and I’ve written about this, it’s actually a problem with the products in the space. Most companies entering the space don’t truly understand the buyers. It sounds like that’s been your experience as well. If you build a great product and have good depth of understanding about who the customer is and what they need, then the sales cycles is going to reflect the quality of that understanding, ultimately reflected in the product. Is that fair?

Matt: I agree with that statement. A better product will accelerate the sales cycle. It’s a lot easier for a purchasing entity to be enthusiastic and excited about a product that they know is going to make a measurable difference. I do want to go back to that point that you made about a customer base that’s uninformed. I agree with that assertion. It’s not incumbent upon the customer base to make themselves more informed. It’s incumbent on the vendors. There’s not a lot of vendors in the government space trying to educate their customers.

Nick: It’s a really capital-intensive space, largely because you’ve got shitty legacy systems of record and a bunch of legacy vendors that have locked their customers in convoluted contracts. The systems weren’t designed with a view that all of the data inputs are actually an asset, so migrating to new systems is nearly impossible. I think there’s a lot of hype in this space right now, because it’s one of the last really big spaces that hasn’t been modernized yet. But, when you dig into a lot of these companies, the microeconomics in this space just aren’t that good yet. They haven’t matured, yet.

This set of ingredients requires investors to truly have a long-term time horizon and be prepared to ante up in future rounds, assuming the company has traction. It’s going to take 10–15 years to truly build powerhouse companies in this space. Throw in non-traditional purchasing behavior, and it’s quite interesting. How have you managed those elements?

Flo: I think it’s really dependent on your investors. I think all of our investors are in this for the long game. They see the long-term opportunity here is so massive, that the market is so ripe for disruption. It’s very attractive long-term opportunity for them. But, you really have to have the right investors.

I think it’s important to have investors who have been successful. They understand how to build a successful company and they have the processes in place. Our investors have been the absolute best partners.

Nick: I think too many bad investors try and force their companies to have detailed plans well beyond what’s reasonable and it creates a lack of flexibility because founders feel obligated to a plan that was mostly made up. How far out do you guys plan? What do your execution timelines look like?

Flo: The product roadmap is locked in for at least a quarter. It’s loosely planned out for over a year. You have to be flexible on your roadmap. It’s really your client building out your roadmap beyond the immediate priorities.

Scott: On the financial side, we try to plan out a year. That’s really as much as you can predict at this scale of a startup. At some point we’ll try predict it out multiple years in advance. But predicting out a year, is the most honest way to do it, anyone who tells you predict more than a year in a startup is bullshitting you.

Matt: You don’t want to be operating with only a week of vision, but you have to be agile. You don’t want to constantly be redesigning the plan.

Nick: What advice would you give to a public sector employee that is desperately trying to procure modern software, but continues to run into internal roadblocks?

Scott: You have to find a way to create a groundswell of support inside of the department. You have to find a way to captivate other people that you work with. Lean on the vendor, ask them to do presentations to more people. You have to find other people internally to support you.

Nick: Last question. Any book recommendations?

Scott: Industries of the Future by Alec Ross. It’s fantastic.

Matt: The Netflix Culture Deck. That’s been formative for me, I read that often.

Nick: Thanks guys. This was great, I really appreciate your time.

This interview was originally published by Better Planning.