SirenGPS Blog SirenGPS: A Lean Statup Story

Eric Ries' Lean Startup doctrine has become widely accepted as a conceptual framework for the development of a startup company. Lean thinking means rapid iteration and deployment of a product to end users during development so that it can be tested and refined. Objective early adopter input is critical to a development feedback cycle, and the first user experiences can be thought of as the "sandbox" or "playground" environment where failure is part of the learning process. Sandbox testing allows a startup to validate or debunk the original assumptions and product plan, refine the aspects that make sense, discard what doesn't, and find the right path for the company.When we started SirenGPS I was not certain that the Lean Startup methodology was a good fit. Lean thinking relies on giving end users a minimally complete or even incomplete product to use during the development cycle in order to get critical market validation and feedback. You are supposed to get them to pay for your minimum viable product if you can. While this sounded reasonable for typical consumer software products, I was concerned that it might not work in the security communication space. Security events are not predictable, so it's hard to set up a test for real use. Plus these events are inherently dangerous. Who wants to be the first to try something new when safety is at stake? What would happen if our incomplete or marginally complete product lacked the tools to prevent harm when a more complete version would have helped? What if someone got hurt when our mission is to keep people safe?Because of these potential pitfalls I was not a Lean advocate for Siren. However, over the last year and a half I have realized that not only have we gone down the Lean path, but that it has been crucial to our development. What Siren needed to make Lean thinking work was outside-the-box thinking on where to find our sandbox.From November 2011 to July 2012 we built our first prototype. Like most early startups we had too many features, were not sure where our product fit into the marketplace or who would use it. Because of my experience working in an adjacent space, I knew more about the assumptions behind our business model than the average entrepreneur might. I had a clear sense that Siren would make a significant difference to our prospects in ways that they care about. I also had access to existing contracts and people using various technologies we are positioned to displace. This meant that I had an idea of our ideal price point and our value proposition.However, the vision still needed a great deal of clarification. We needed to answer important questions about who would use our product, how it would be implemented and which features were the critical features. I started by getting feedback from higher education prospects on what they were using, what they liked about it, and what they didn't like about it. This helped build the business concept, but we found that talking about what we were doing was difficult. People needed to see our product working - even in a test environment - to understand it and give us feedback. We started the first build based on research, experience, instinct and the feedback we got from those initial interviews with potential end users.It became clear about four months into our development cycle that our development team was having a hard time executing on the plan. As our July launch target approached, more out of necessity than for reasons of principal, I decided to follow the Lean doctrine and get what we had in front of the market so that we could learn from it. We trained eight part-time sales people and promised them generous commissions. We paid for tables at several trade shows. I got a lot of meetings and travelled all over the country talking to prospects and showing them our prototype. We deployed Siren for an exercise at a conference to get end user feedback on the mobile experience. By August of 2012 we had a pipeline of interested clients. We also knew that Siren was not ready.While our first prototype, let's call it Prototype A, was not ready for prime-time, it helped us answer a lot of questions about what we were doing. During July and August we demonstrated Siren for 100 of the institutions we had identified as our likely early adopters and got relevant feedback. We got 200 people at a conference to download the beta application and ran them through a field trial as part of the feedback loop. This allowed us to identify problems, test assumptions about use, and refine the product. We learned that our target early adopter prospects do indeed want a product like Siren. In fact, a lot of them are extremely enthusiastic, asking to participate in future beta tests and expressing willingness to pay a premium. We got a clear picture of who our ultimate users will be, how they want to use Siren, and what features matter to them. Perhaps more important, by getting out there with a limited version of our product, we found our sandbox.The real home-run in taking the prototype out to the public came in finding Dr. Kip Thomas from Boston University Healthcare Emergency Management (BU HEM). In the aftermath of 9/11 there has been a movement to professionalize emergency management. These efforts have led to the expansion of training and credentialing programs, and the BU HEM masters program is one of the finest. Dr. Thomas is a behavioral scientist, former Naval Intelligence, and is just an all-around brilliant individual. Kip directs the BU HEM program training emergency managers. Kip's program conducts over 30 emergency exercises each year, engaging local first responders and putting them through simulations, often based on actual events. Because technology is a big part of improving safety and security, Kip is proactive about finding new tools for his program. For the last eight months BU HEM has adopted Siren into their exercise curriculum, providing us with opportunities to deploy Siren in simulations. The improvement in our learning and development process since partnering with BU HEM to test Siren has been dramatic - so dramatic that it completely validated Lean thinking in my eyes.Our problem wasn't that there was no sandbox for safety products. The problem was that I had been wrong to assumed that there wasn't a safe place to test Siren. I followed the advice to "get out there" and when I found what we needed in BU HEM I was lucky enough to realize in the moment that my assumption had been wrong. The moral of our story is that the basic Lean Startup principles worked for Siren even if we couldn't simply give our unfinished work to customers. In fact following the Lean Startup principles helped overcome a wrong-headed assumption in our initial plan once I realized this nuance: Some businesses have to work to facilitate a developmental feedback loop.The feedback loop for emergency management doesn't move as quickly as some. When we deploy tests we have to coordinate efforts with multiple first responders resourced through a third party subject matter expert. We are dependent on lots of moving parts, people and areas of expertise to come together to run an exercise. However, to borrow a term from emergency management, the result of working with end users in a Lean feedback loop is a force multiplier. Feedback loops-especially those that involve subject matter experts and professional end users-are extremely powerful tools for finding solutions and isolating failure. Our work with BU HEM has allowed us to develop a product and market opportunity that far exceeds our original concept, and we are excited to have an advanced solution up and running this summer. We're calling this version Siren Emergency.