Think of us as your secret weapon, rested and ready in its holster and deployed on your command. Based on key rooftop locations around your facility, our system not only provides important autonomous patrols but it’s always ready to launch missions to investigate alarms and incidents.
​
Security base stations are deployed in strategic rooftop locations around your facility and contain powerful, networked computers that share critical information – ensuring continuous perimeter monitoring and rapid deployment during alarm events.
Our base stations enable autonomous takeoff and landing via FLIR tracking and automatic bay doors. Fast inductive charging keeps drones ready for action and industrial strength design protect the drones from the bad weather.
​
Video, Thermo, FLIR, and LiDAR.
​
Security drones can be equipped with an HD video camera and powerful sensors including Thermo, FLIR, and LiDAR. Our drones can be scheduled for routine flights to monitor your facilities, or dispatched automatically by alarm events and they can also be operated manually. Our drones have Artificial Intelligence which provides image recognition with human and animal distinction. This allows drones to autonomously follow suspicious humans or vehicles while leaving the raccoons and deer alone.
​
Security drones share technical and mission data in real time. If an alarm event occurs the drone best positioned to reach it quickly is automatically deployed. When batteries on an active drone run low a replacement is sent automatically. These aren’t just drones – they’re an intelligent, rapid-response aerial robotic security swarm.
​
IOS, Android, Desktop.
​
Your Mission Control is accessible via desktop and mobile applications – letting you command everything from virtually anywhere. You can control multiple locations and drones and watch video and team chat in real time – and with the right access level you can assign team permissions, define flight paths, set schedules and direct camera locations.
​
Security software was developed by our robotics engineering team who gained invaluable experience and technical leadership in previous roles. Our self-encapsulated, end-to-end system provides Autonomous Remote Operations (ARC) which means no human intervention is required to maintain operational continuity 24 x 7 x 365. Algorithmic task assignment and cooperation combined with our proprietary Relay-to-Drone-to-Drone (R2D2D) capability delivers powerful multi-drone squadron operation – making Nightingale Security drones the smartest eyes in the sky.
​
Deploy and control drones from anywhere in the world with ease.
Intelligent Path Planning (IPP) provides a simple and intuitive method for setting missions.
Our drones avoid static obstacles (buildings, power lines, trees) and we are currently developing dynamic obstacle avoidance capabilities.
​
Simultaneously view all live streams from our desktop and mobile applications.
View video from past missions and see list of upcoming, pre-scheduled missions.
Manually deploy drones on missions and control the camera from the mission manager.
In the 19th century, Lord Kelvin said, "If you can not measure it, you can not improve it." Two centuries later, the Internet of Things is becoming humanity's sixth sense. IoT measures and actuates the physical world, improving many aspects of our lives. It is becoming an integrated part of us.
​
Recently, we have seen the biggest innovations coming from the smallest teams; developing web, mobile and cloud tier applications where connectivity, computational and storage resources, and power consumption are only secondary challenges.
In contrast, the Internet of Things is profoundly impacted by these difficulties. Moreover, IoT adds an additional tier: embedded devices. Therefore, development IoT applications requires even more expert knowledge within each tier and a holistic system understanding.
​
Typically, such expert knowledge and resources are only available to large corporations: excluding thousands of great ideas from ever reaching the market. Understanding IoT data collection and the implications is everyone's right and responsibility.
​
We are reaching out to those interested in understanding and building the future. Our mission is to educate and collaborate around the design and development process of the Internet of Things with cyber security and physical security platforms in mind from the beginning.
Product Hypotheses: Product Benefits
The benefits list succinctly describes what benefits the product will deliver to customers. (Something new? Something better? Faster? Cheaper?) In large companies, it's normal for Marketing to describe the product benefits. The Customer Development model, however, recognizes that Marketing doesn't know anything about customers yet. In a startup Product Development has all kinds of customer "facts." Use this meeting to flush these out. At this point, the marketing people must bite their tongues and listen to the Product Development group's assumptions about how the features will benefit customers. These engineering-driven benefits represent hypotheses we will test against real customer opinions.
​
Product Hypotheses: Intellectual Property
In the next part of the brief, the product team provides a concise summary of assumptions and questions about intellectual property (IP). Are we inventing anything unique? Is any of our IP patentable? Do we have trade secrets to protect? Have we checked to see whether we infringe on others' IP? Do we need to license others' patents? Although most development groups tend to look at patents as a pain in the rear, and management believes the expense of securing patents is prohibitive, taking an active patent position is prudent. As our company gets larger, other companies may believe we infringe on their patents, so having intellectual property to horse-trade can come in handy. More importantly, if we own critical patents in a nascent industry, they can become a major financial asset of our firm.
​
Product Hypotheses: Dependency Analysis
A dependency analysis is simpler than it sounds. The Product and Customer Development teams jointly prepare a one-page document that says, "For us to be successful (that is, to sell our product in volume), here's what has to happen that is out of our control." Things out of a company's control can include other technology infrastructure that needs to emerge (all cell phones become Web-enabled, fiber optics are in every home, electric cars are selling in volume), changes in consumers' lifestyles or buying behavior, new laws, changes in economic conditions, and so on. For each factor, the dependency analysis specifies what needs to happen (let's say the widespread adoption of telepathy), when it needs to happen (telepathy must be common among consumers under age 25 by 2020), and what it means for us if it doesn't happen (our product needs to use the Internet instead.) Also write down how we can measure whether each external change is happening when we need it to (college kids can read minds by 2010).
Product Hypotheses: Product Delivery Schedule
In the product delivery schedule, we ask the product team to specify not only the date of the first release (the minimum feature set), but the delivery and feature schedule for follow-on products or multiple releases of the product as far out as the team can see (up to 18 months). In startups, this request usually elicits a response like, "How can we come up with a date for future releases when we barely know when our first release will be? " That's a good question, so we'll need to make clear to the product team why we need their cooperation and best estimates. These are important because the Customer Development team will be out trying to convince a small group of early customers to buy based on the product spec long before we can physically deliver the product. To do so they will have to paint a picture for customers of what the product will ultimately look like several releases in to the future. It's because these customers are buying into our total vision that they will give us money for an incomplete, buggy, barely functional first product.
Asking for dates in this phase may result in an anxious Product Development team. Reassure them this first pass at a schedule is not set in stone. It will be used throughout Customer Discovery to test customer reaction but not to make customer commitments. At the beginning of the next step, Customer Validation, the teams will revisit the product delivery schedule and commit to firm dates that can be turned into contractual obligations.
Product Hypotheses: Total Cost Of Ownership/Adoption
The total cost of ownership (TCO) adoption analysis estimates the total cost to customers of buying and using our product. For business products, do customers need to buy a new computer to run our software? Do they need training to use the product? What other physical or organizational changes need to happen? What will be the cost of deployment across a whole company? For consumer products, it measures the cost of "adopting" the product to fit their needs. Do customers need to change their lifestyle? Do they need to change any part of their purchasing or usage behavior? Do they need to throw away or make obsolete something they use today? While the Customer Development team prepares this estimate, the Product Development team should provide feedback about whether the estimates are realistic.
When all of the six hypotheses about the product are written down, the company has a brief that describes the product in some detail. Paste our brief to the wall. Soon it will e joined by a few more. Soon after, we will be in front of customers testing these assumptions.
B. State Your Hypotheses: Customer Hypotheses
The process of assembling the customer briefs is the same as for the product brief, except this time the Customer Development team is writing down its initial assumptions. These assumptions cover two key areas: who the customers are (the customer hypothesis) and what problems they have (the problem hypothesis). In the course of Customer Discovery, we'll flesh out these assumptions with additional information:
-
Types of customers
-
Customer problems
-
A day in the life of our customers
-
Organizational map and customer influence map
-
ROI (return on investment) justification
-
Minimum feature set
Customer Hypotheses: Types of Customers
If you've ever sold a product, whether it's to a consumer buying a stick of gum or a company buying a million-dollar telecommunications system, you've probably discovered every sale has a set of decision-makers who get their fingers into the process. So the first question to ask is, "Are there different types of customers we should approach when we sell our product?" Whether we're selling process control software into a large corporation or a new type of home security device, chances are there are a number of people in a number of categories whose needs we must satisfy to sell the product. During Customer Discovery we will spend time understanding these needs. Later, when we are ready to develop our first "sales roadmap" in the Customer Validation step, knowing all the players in detail will be essential. Right now, it's sufficient to realize the word "customer" is more complicated than a single individual. Some of the customer types we have encountered include:
(see Figure 3.3): (Woodside, CA)
​
End Users
These are the day-to-day users of the product, the ones who will push the buttons, touch the product, play with it, use it, love it and hate it. We need a deep understanding of the end users' needs, but it's important to realize in some cases the end user may have the least influence in the sales process. This is typically true in complex corporate sales where an entire food chain of decision-makers affects the purchasing decision. However, it's equally true in a consumer sale. For example, children are a large consumer market and the users of many products, but their parents are the buyers.
​
Influencers
Next up the sales chain are all the people who think they have a stake in a product coming into their company or home. This category could include the key techno-whiz in IT or the 10-year-old whose likes and dislikes influence the family's choices of consumer products.
​
Recommenders
These people influence product purchase decisions. They differ from the influencers in that they can make or break a sale. A recommender could be a department head saying any new PCs should come from Dell or the spouse who has a particularly strong brand preference.
​
Economic Buyer
Further up the decision chain is the economic buyer, the one who has the budget for the purchase and must approve the expenditure. (Don't you bet you are going to want to know who that is?) In a consumer purchase it can be a teen with a weekly music budget or a spouse with a vacation budget.
Decision-maker
The decision-maker could be the economic buyer, but it could be someone else even higher in the decision-making hierarchy. The decision-maker is the person who has the ultimate say about a product purchase regardless of the other users, influencers, recommenders and economic buyers. Depending on our product, the decision-maker could be a suburban soccer mom/dad or a Fortune 500 CEO. It is up to us to discover the ultimate purchase decision-maker and understand how all these other customer types influence his or her final decision.
​
Saboteurs
In addition to all these parties to the sale (and isn't it amazing with a process like this, anything gets sold?), one more group must be mentioned. We won't be looking for them, but they will see us coming. We call this group the saboteurs. In every large company, for example, there are individuals and organizations that are wedded to the status quo. If our product threatens a department's stability, headcount, or budget, don't expect this group to welcome us with open arms. Therefore we need to be able to predict who might be most threatened by our product, understand their influence in the organization, and ultimately put together a sales strategy that at worst neutralizes their influence and at best turns them into allies. Don't think saboteurs occur just in large corporations. For a consumer product, it may be a member of the family who has gotten comfortable wit the old car and is uncomfortable about driving something new and different.
The first step in formulating our customer brief is to write down and diagram who we think will be our day-to-day users, influencers, recommenders, economic buyer, and decision-maker, including, in the case of sales to companies, their titles and where in the organization they are found. It's also worth noting if we think the economic buyer has a current budget for our product or one like it, or whether we will have to persuade the customer to get funds to buy our product.
Given we haven't been out talking to customers yet, we may have a lot of empty space in this part of our brief. That's fine. It just reminds us how much we need to find out.
Of course, not every product has so complicated a purchase hierarchy, but the sale of nearly every product involves multiple people. If it's a consumer product, these rules still apply. It's just that the influencers, recommenders, and so on are likely to have more familiar titles like "mom," "dad," and "kids."
Customer Hypotheses: Customer Problems
Next, we want to understand what problem the customer has. The reason is simple: It's much easier to sell when we can build the story about our product's features and benefits around a solution to a problem we know the customer already has. Then we look less like a crass entrepreneur and more like someone who cares coming in with a potentially valuable solution.
Understanding our customers' problems involves understanding their pain-that is, how customers experience the problem, and why (and how much) it matters to them.
Theses examples show that we need to summarize the customer's problem, and the organizational impact of the problem in terms of the different types of pain it causes at various levels of the company/family/consumer. Finally, writing down the answer to "If they could wave a magic wand and change anything at all, what would it be?" gives us a tremendous leg up on how to present our new product.
In this customer problem brief, we use a simple "problem recognition scale" for each type of customer (user, influencer, recommender, economic buyer, decision-maker). As we learn more we can begin to categorize our customers as having:
-
A latent need (the customers have a problem or they have a problem and understand they have a problem)
-
An active need )the customers recognize a problem-they are in pain-and are actively searching for a solution, but they haven't done any serious work to solve the problem)
-
A vision (the customers have an idea what a solution to the problem would look like, may even have cobbled together a homegrown solution, and, in the best case, are prepared to pay for a better solution
Now that we are firmly ensconced in thinking through our customers' problems, look at the problem from one other perspective: Are we solving a mission-critical company problem or satisfying a must-have consumer need? Is our product have-to-have? Is it nice-to-have?
One test of a have-to-have product is that the customers have built or have been trying to build a solution themselves. Bad news? No, it's the best news a startup could find. We have uncovered a mission-critical problem and customers with a vision of a solution. Wow. Now all we need to do is convince them that if they build it themselves they are in the software development and maintenance business, and that's what our company does for a living.