The Arduino team is using Kickstarter to crowdfund their latest project: the ESLOV IoT Invention Kit.

ESLOV is a system of intelligent modules that can be connected in an endless variety of ways, and is meant to simplify the creation of Internet-connected devices.

Arduino's new open source kit makes creating IoT devices easy

The connected modules are plugged into a Wi-Fi and motion hub, which will connect the device (project) to the Internet. Then, the hub has to be connected to the user’s PC so that it can be programmed.

Programming it is extremely easy, though – in fact, no actual programming knowledge is required. By using the ESLOV’s visual code editor, which recognises the modules automatically, the user needs to simply draw connections between them, and the device is ready to be used.

Once the device is connected to the Arduino cloud, the user can control it and interact with it from anywhere, via a computer or smartphone, through a user-friendly interface.

The ESLOV kit consists of the wireless hub and 25 modules. The team welcomes third-party modules – design files and documentation for all modules will be made publicly available, to make it easier for creative people to design and create their own.

The ESLOV kit consists of the wireless hub and 25 modules

The Arduino team needs to raise $ 500,000 to finish the development and production of the ESLOV kit. Potential funders can choose to receive kits of different sizes, priced from $ 49 (you receive just the Wi-Fi hub) to $ 499 (PRO kit: Hub + 22 modules). The various kits can also be combined.

Delivery of the hardware to the backers is scheduled for June 2017.

More technical information can be head on the Kickstarter project page or this blog post.

Help Net Security


Established enterprises as well as startups have much to consider when deciding how to build and launch a security solution that makes sense for their business and customers. While you can employ a variety of formal tech strategy frameworks, the following lightweight approach offers a reasonable starting point for defining security product plans by posing several fundamental questions. This common sense methodology is based on my experience of building infosec solutions, but it is broad enough to apply to other types of products.

Market Segmentation

The idea of market segmentation stems from the notion that different types of customers have different needs. How to group customers with similar needs depends on your vision for the company and its products.

Geographic segmentation assumes that product requirements or go-to-market plans for customers in one country are different from those in another. For instance, it’s not unusual for a startup to begin by focusing on prospective clients in its own locale—be it a city, state or country that the firm’s founders know well—for proof-of-concept deployments and then expanding to a larger market, such as the United States.

Another way to segment the market is to look at different industries where prospective customers might reside. For example, a company that’s building an anti-ransomware solution might perceive the need for such a solution among hospitals or law firms and focus on this vertical.  Prospective clients in other verticals, say energy companies, might value such a product differently and might seek different capabilities that would overextend the startup’s limited resources.

Yet another approach to market segmentation involves considering the size of a customer, perhaps in terms of the number of endpoints, offices or employees that require protection. Small and mid-sized businesses (SMBs) tend to have different security needs and price expectations than more sophisticated enterprises. Not only does the size of the customer’s’ business influence the product’s desired features, but also the expected deal size affects the ability to build and motivate a sales force that can reach prospective clients.

The questions to ask in relation to market segmentation include:

  • What market segments are we targeting?
  • How are they similar and different?
  • How will we reach prospective customers?

Product Capabilities

Once you understand the type of customers the product will be targeting, it’s time to dig deeper into understanding their needs, then map them to the product’s capabilities. Think beyond generic security requirements such as data protection, threat detection or incident response. Be more specific to understand which gaps might exist in the products currently available to relieve infosec-related pain points.

If the product focuses on better network defenses, what advantages does it compare to existing firewall or Unified Threat Management (UTM) technologies? If your firm’s expertise is in security data analytics, why should customers value your approach over their existing Security Information and Event Management (SIEM) deployment? If you’re proposing a better way to fight malware, how does your product fit with established anti-virus solutions?

You should also consider how your product plans compare to those of other security firms that might be competing with you. If you’ve spotted a customer need, there is a chance that other individuals and companies are also working feverishly to address it. Understand who your competitors might be and determine how your solution might be different than theirs.

Outline the scenarios where a competitor’s product might offer more value than yours. Along the same lines, determine where your firm might have an advantage. Develop your plans to build upon your strength. Decide whether you have the resources to close the gap in those scenarios where you competitors might be stronger, or whether you will focus on opportunities where you will most likely prevail.

In addition, consider what is the smallest set of features you need to build into your solution to attract your initial customers. The advantages of starting out with such a minimum viable product (MVP) include the ability to start generating revenue, earning early reference clients and receiving real-world feedback related to your business strategy and product roadmap.

Ask yourself questions such as:

  • What are your solution’s key benefits?
  • How unique is the value proposition?
  • What capabilities should form the first release?

Sales Engagement

Your decisions related to market segmentation and product capabilities need to account for the reach, expertise and motivations of your sales force. Take the time to understand how the sales team is set up and, if applicable, contribute to the team’s design on the basis of your understanding of the security market and its participants.

What you can learn about customers’ product expectations or reception based on sales activities to date? In an established firm, such interactions could have been conducted by the formal sales team. In a startup, even if the team doesn’t exist yet, informal sales conversations might have involved you, the company’s founders or your other colleagues.

In large organizations, the product you’re building might not have its own dedicated sales force. Instead, you could be sharing the sales team with other products, some of them potentially unrelated to security. This sometimes means that your product will be competing for sales people’s attention with other solutions that your organization offers. Understand such internal dynamics and consider how you might be able to encourage sales folks to focus on the products important to you and to your company. Give thought to how the capabilities of your product might strengthen the value proposition of the other products your company has been selling.

If you’re planning the go-to-market strategy for the product, consider whether you’ll be able to reach prospective customers directly using your company’s own sales force. A better approach in some situations might be to establish a sales channel that brings your solution to customers via a reseller model. Reaching SMB clients is especially difficult using a direct sales force due to the challenges of building and managing a large sales organization whose members tend to work on numerous, but relatively small deals.

If you can influence the choice of a sales person that will be aligned to the product, consider what security knowledge he or she should possess. It might be hard to find a sales expert within the specific infosec niche that your product is targeting. You could be better off working with a less specialized sales rep who has earned the trust of buyers through good work and relationship-building, and pair this person with a technical sales engineer.

Even before your product is released into the world, there is much to learn from sales discussions with prospective customers. These interactions validate assumptions regarding market segmentation and desired features. They also help identify early adopters that might be interested in testing pre-released versions of your solution.

Seek to answer the following questions:

  • In which markets has the sales force gotten traction so far?
  • What’s prospects’ negative feedback regarding product ideas or prototypes?
  • What capabilities get customers most excited?

Pricing Model

Pricing your product properly is as essential as having the right set of features and being able to reach customers through a skilled sales force. You’ll need to estimate how much your customers will value the benefits of your solution and determine what budgets might be available to them to fund the purchase. This can be very tricky.

Consider whether you’re going to charge customers an initial one-time licensing fee with recurring maintenance fees, or whether you’ll follow a subscription model. It often makes sense to align the timing of your expenses with the timing of your revenues. If your solution has recurring monthly costs (for instance associated with storing customer’s data or hosting your application) then it makes sense to position your product as Software as a Service (SaaS) and charge predictable, monthly fees. Even with monthly feels, you might need to charge initial installation or activation fees to cover the associated costs.

Of course, you’ll need to account for customers’ preferences and constraints when deciding how whether to charge one-time or recurring fees. Some customers might have a fund for one-time costs that are considered capital expenses (CapEx), while others might not have the ability to put up a lot of money for the initial purchase and will need to pay monthly out of their operating expense (OpEx) budget.

Pricing the product requires a firm understanding of your initial and ongoing costs. You could take your costs, mark them up by the expected profit margin, and come up with a price. Be careful to consider this only your minimum price and use it as a sanity check on deals where discounts might need to be offered. Ultimately, the price should be based on how much the customer values the solution’s benefits.

Price the product based on customer-perceived value, not on costs. For instance, the marginal cost of your anti-malware software might be a few cents per endpoint, but if the product addresses a significant pain point in a unique way, the customer might pay several dollars for it. Not only does your solution need to work well for this approach to work, but your sales team needs to be sufficiently mature to understand customer needs and position your product’s benefits. You can try explaining the return on investment (ROI) of the product, but I’m not a fan of this approach in the context of information security.

For salespeople to be motivated to sell your product, your pricing model needs to account for compensating them for their efforts. This is typically done by paying the sales person commission for a deal in a manner that aligns the person’s interests with those of the company. Watch out for a potential mismatch in subscription products where the sales person’s goals are focused on hitting quarterly revenue or profit targets, but your commission trickles in gradually on a monthly basis for years after the deal was closed.

Questions to ask of yourself:

  • How much should you charge for the product?
  • What are the associated initial and recurring costs?
  • Is revenue aligned to costs and incentives?

Product Delivery

Understanding the intricacies of installing and supporting the product are critical to the success of the overall solution. For example, customers might prefer the ease of rolling out an agentless forensic analysis tool to the alternative that requires installing the software on every endpoint in the enterprise. On the other hand, the capabilities of the tool that runs locally on might surpass the agentless solution. Understand your customers’ priorities and strike the right balance between functionality and ease-of-use when designing the product.

Furthermore, consider what effort is required on an ongoing basis to achieve the product’s full potential. For instance, a change detection tool might need regular tuning to avoid alarms that arise after routine system maintenance. Customers need to understand what time they will need to devote to get the most value from your solution. You also need to determine what ongoing support or maintenance task your firm will need to provide (e.g., upgrading software, troubleshooting problems, updating signatures, etc.).

You should also determine what tasks your company’s staff will need to perform when deploying the product for a new customer. With some solutions, this is a simple as enrolling users via your spiffy web-based SaaS portal. More sophisticated products might demand a formal project on the customer’s premises, for instance if you need to integrate your malware sandbox with the client’s email and web gateways.

Security products that require complex integration will need to be deployed by a well-staffed team of skilled consultants or implementation specialists. If you’re working in a software company that doesn’t have a strong services component, this might become your bottleneck to signing up clients. If that’s the case, either plan to build the appropriate team, partner with another company to provide this service, or adjust product plans to avoid relying as much on the human element for deployment.

If your product includes back-end software that runs in a datacenter, consider whether these components will be hosted outside the customer’s environment, or whether you will allow customers to deploy your software into their own data center. If you’ll be doing the hosting, determine how each client’s application instances or data will be separated from each other. Also understand what audits, certifications and security attestations for your infrastructure and application customers might require.

Some clients will welcome the ease of deploying a SaaS application hosted by you in an external cloud; others might demand their own dedicated instance. The more sensitive the data that your product is handling, the greater the need that an enterprise customer will want their own, local deployment.

Ask yourself these questions:

  • What is product deployment like?
  • What ongoing support is necessary?
  • What are the staffing requirements?

Wrapping It Up

Building a product is a risky, stressful and ultimately fulfilling endeavor. The methodology above proposes some common-sense questions you should ask yourself, your colleagues and your customers when preparing to build a security solution. There is certainly more to be said about each aspect of this aspect of product management, but answering these questions offers a reasonable starting point for the project. The following diagram summarizes this approach.



Lenny Zeltser